BRKRST-2045 - Innovations For Extending L3 VPN Segmentation Over IP-based WAN Transport (2016 Melbourne)

Innovations for Extending
L3 VPN Segmentation
over IP-Based WAN
Craig Hill Distinguished Systems Engineer
CCIE #1628
crhill@cisco.com
@netwrkr95
BRKRST-2045
Agenda
Introduction - Network Segmentation

Drivers and Concepts
WAN Transport Impact on L3 VPN

over IP
Technology Deep-Dive on
Advancements in L3 VPN over IP
QoS, MTU, and Encryption

Recommendations
Recent Innovations Evolving in L3

Segmentation
Summary
Agenda
Introduction - Network
Segmentation Drivers and Concepts

over IP

Recommendations

Segmentation
Summary
Evolution of Network Segmentation
Means Many Things to Many People
It has evolved a long way from technologies like TDM (1960s)

From TDM, ATM/FR Virtual Circuits in the WAN, to
VLANs in the Campus, to Logical/Virtual Routers on routing devices, to
Virtual Machines on server clusters in the Data Centre
Secure Domain
Routers
MPLS
Virtual Circuits
HSRP
GRE
TDM
MPLS VPN
VRF Lite
AToM
VLANs
L2TPv3
Time
VPLS
1000v
OVS
Virtual
Port
Channel
Virtual
Device
Context
CSR
1000v
SDN
NfV
2016+
What Is Enterprise L3 Network Segmentation?
Giving One physical network the ability to support multiple L3 virtual networks
End-user perspective is that of being connected to a dedicated network

(security, independent set of policies, routing decisions)
Maintains Hierarchy, Virtualises devices, data paths, and services

Internal Separation
(sales, eng)
Virtual Network
Merged Company
Virtual Network
Actual Physical Infrastructure
Guest Access Network
Virtual Network
Why L3 Network Segmentation?

Key Drivers and Benefits
Cost Reductionallowing a single physical network the ability to offer multiple users
and virtual networks
Simpler OAMreducing the amount of network devices needing to be managed and

monitored
Securitymaintaining segmentation of the network for different departments over a

single device/Campus/WAN
High Availabilityleverage Segmentation through clustering devices that appear as

one (vastly increased uptime)
Data Centre Applicationsrequire maintained separation, end-to-end continuity of

Segmentation from server-to-campus-to-WAN, and Multi-tenant use cases for DCs into
the public Cloud
L3 Network Segmentation Use Cases

Requirement exists for L3 VPN segmentation within their organisation
Multi-Tenant Dwelling requiring Separation
Security
Mandates to logically separate varying levels of security enclaves
Regulation requirements
Airports airlines (United, Delta, etc) sharing network transport space (physical)
Government Facilities Federal agencies sharing single building/campus
Intra Organisation segmentation Separation of sales, engineering, HR, LoB
Company mergers allowing slow migration for transition, overlapping addressing
Data Centre Applications VMVLANVRF orchestration for segmentation
Separation of Facility equipment (IP cameras, badge readers) from the user data
Health Care HIPPA | Financial and Transactional Sarbanes-Oxley, PCI Compliance
Public Cloud and WAN Orchestration
L3 segmentation (VRFs) are configured dynamically, or part of the automation process, in multitenant cloud environments for network segmentation (over WAN, to Branch, etc)
Enterprise Network Segmentation

Key Building Blocks
Device
Partitioning
WAN
Interconnect
WAN
Virtualising the
Routing and
Forwarding of the
Device
Extending and Maintaining the

Virtualised Devices/Pools over
Any Media
Device
Pooling
Si
Si
Virtualising
Multiple Devices
to Function as a
Single Device
Enterprise Network Segmentation over the WAN

The Building Blocks Example Technologies
Device
Partitioning
Device
Pooling
Si
Si
VLANs
VRFs
Virtual Sw System (VSS)
EVN
Virtual Port Channel (vPC)
(Easy Virtual Network)
HSRP/GLBP
VDC (NX-OS)
Stackwise
(Virtual Device Context)
SDR (IOS-XR)
(Secure Domain Routers)
Cloud Services Router (CSR)
ASR 9000v/nV Clustering

Inter-Chassis Control
Protocol (ICCP)
Enterprise Network Segmentation over the WAN

The Building Blocks Example Technologies
Device
Partitioning
WAN
Interconnect
WAN
Device
Pooling
Si
Si
VLANs
Virtual Sw System (VSS)
VRFs
(Easy Virtual Network)
L2 VPNs PWE3, VPLS, L2 PW over GRE, L2TPv3,

OTV (Overlay Transport Segmentation)
VDC (NX-OS)
Evolving Standards PBB/E-VPN, VxLAN, NVGRE
(Virtual Device Context)
L3 VPNs VRF-Lite, VRF-Lite over GRE, MPLS

BGP VPNs, MPLS VPN over DMVPN, MPLS BGP
VPNs over GRE/mGRE, LISP Multi-tenant
EVN
SDR (IOS-XR)
(Secure Domain Routers)
Cloud Services Router (CSR)
Virtual Port Channel (vPC)

HSRP/GLBP
Stackwise
ASR 9000v/nV Clustering

Inter-Chassis Control
Protocol (ICCP)
Agenda


over IP

Recommendations

Segmentation
Summary
Transport Options for Private IP

VPN Services
WAN Segmentation Models

1.
2.
Self Deployed MPLS Backbone Supporting

BGP VPNs
Self deployed MPLS BGP VPNs over the
top of an SP Offered IP VPN transport
WAN
LAN
LAN
Self Deployed MPLS Backbone
Self
Deployed
BGPTheir
MPLS
IP VPN
Backbone
(RFCNetwork
4364) Controls E2E
Customer
Deploys
Own
Internal
MPLS VPN
Self Deployed offers Service richness

and control
Customer manages and owns:

IP routing, provisioning
Transport links for PE-P, P-P, PECE
Full L2, L3 service portfolio
SLAs, to end customer, QoS
Customer controls how rapidly

services are turned up
Allows customer full control E2E
Requires more expertise on the

operations team
BGP MPLS IP VPN Backbone

Branch
Site
CE
Branch
Site
PE
CE
CE
P
P
PE
Customer Owned IP/MPLS

Backbone
Customer Managed Domain
Campus
DC
Self Deployed MPLS over the top of SP Transport

Private
BGPIPMPLS
VPN Transparently
over- SP
offeredowns
Transport
SP Offered
VPN IP
Service
(Layer 3 Service)
Customer
CE
CE Routers owned by customer
PE Routers owned by SP
Customer peers to PE via IP
SP Managed IP VPN Transport
Site1
No labels are exchanged with SP PE
No end-to-end visibility of other CEs
CE
PE
Site 2
Route exchange with SP done via

eBGP/static
Customer relies on SP to advertise

their internal routes to all CEs in the
VPN for reachability
SP can offer multiple services: QoS,

multicast, IPv6
SP Managed Domain
CE
L3 VPN
Service
Provider
CE
Site 3
PE
IP Routing Peer
(BGP, Static, IGP)
Customer
Managed Domain
* No Labels Are Exchanged with the SP
Customer
Managed Domain
Our rapid change of network

requirements can no longer wait 3060 days for our service provider to
modify our segmentation [VRF]
requests. We need this change
management to be in hours
Fortune 50 Customer CIO
Self Deployed MPLS vs. SP Managed Transport

SP Offered
IP VPN
Service)IP
- Customer
owns CE
MPLS
VPN over
theService
top of (Layer
an SP 3
Managed
VPN Transport
Service
SP Managed IP VPN Service
Site 1
CE
SP Managed Domain
PE
Site 2
CE
Customer
Managed Domain
L3 VPN
Service
Provider
CE
Site 3
PE
IP Routing Peer
(BGP, Static, IGP)
VRFs
Customer
Managed Domain
Self Deployed MPLS vs. SP Managed Transport
MPLS
VPN IP
over
theService
top of(Layer
an SP 3Managed
VPN Transport
Service
SP Offered
VPN
Service) IP
- Customer
owns CE
CE customer owned, PE provider

owned
Customer enables PE functionality

(RFC 4364) on the CE (transparent to
SP)
SP Managed IP VPN Service

Extend L3 VRF Segmentation Over the Top
Site1
CE
Customer Routing done Over the Top

of the SP transport
Customer IP forwarding encapsulated in
GRE, so SP only sees GRE packets
Because GRE is used, all traffic can
leverage IPSec encryption
Solution must: scale, be simple to
operate, leverage standards, support
QoS, IPSec, be transport independent
SP Managed Domain
PE
Site 2
CE
Customer
Managed Domain
L3 VPN
Service
Provider
CE
Site 3
PE
IP Routing Peer
(BGP, Static, IGP)
VRFs
Customer
Managed Domain
Private VRF Extension Options

Layer 3 IP VPN Transport
Customer private
VRFs
VRF 2
VRF 1
eBGP/Static
CE
PE
Service Provider
MPLS
Backbone
PE
Back to Back VRFs VRF-Lite to provider PE

VRF-Lite over GRE tunnels - CE-to-CE per VRF
Carrier Supporting Carrier
MPLS VPN over IP
VRF 2
eBGP/Static
CE
VRF 1
Key Benefits Private IP MPLS VPN Over the Top

Extend L3 VRF Segmentation
Over the Top
Site1
CE
SP Managed Domain
PE
Site 2
L3 VPN
Service
Provider
CE
Site 3
IP Routing Peer
(BGP, Static, IGP)
PE
CE
Allows enterprise to deploy smaller scale MPLS VPN solutions over IP
VRF changes for end customer goes from days to hours
Customer Ex: 30-60 days VRF change in SP | 1 hour VRF change in Private IP VPN Solution
Can still leverage cost effective L3 transport services from SP
Can still leverage encryption, QoS, and private BGP AS over the top
Target Use cases: IPv4 VPN, v6 VPN over v4, align QoS with provider, scale
Agenda


over IP

Recommendations

Segmentation
Summary
Private IP VPN
Over the Top
Solution Options
Layer 3 VPN Peering

Private IP VPN
Over the Top Solutions
(RFC 4797)
MPLS VPN over IP

Simplifying MPLS VPN over IP Using RFC 4797 Concepts
Customer may not control the WAN transport Between MPLS networks
EXAMPLE: Customers are leveraging IP VPN Service from SP
Complex to require MPLS label forwarding everywhere in the network
Customer requires encrypting their PE to PE MPLS traffic
No native MPLS encryption exists today
Encapsulating MPLS into IP allows use of standard-based IPsec
Leveraging any IP transport between MPLS PEs is cost effective and simpler
In Summary, the Implementation Strategy Described Enables the Deployment of

BGP/MPLS IP VPN Technology in Networks Whose Edge Devices are MPLS and
VPN Aware, But Whose Interior Devices Are Not (Source: RFC 4797)
Primary Components
Segmentation component
Control Plane component
Data Plane component
Solution Additions: QoS, IPv6, Encryption, Multicast, etc
Defining the Virtual Route Forwarding (VRF)

Instance
Components, Functions, Uses
VRF
VRF
VRF
Associates to one or more interfaces on router (typically a PE)

Privatise an interface, i.e. colour the interface
VRF has its own routing table (RIB) and forwarding table (FIB)
VRF has its own instance for the routing protocols
(static, RIP, BGP, EIGRP, OSPF)
Level of segmentation allows overlapping address space
MPLS-VPN Technology
Control Plane Component
8 Bytes
4 Bytes
1:1
RD
10.1.1.0
IPv4
8 Bytes
Route-Target
3 Bytes
Label
VPNv4
MP_REACH_NLRI attribute within MP-BGP UPDATE message
Key Components:
Route Distinguisher (RD); VPNv4 route
Route Target (RT)
Label
Encapsulation for MPLS in GRE (RFC 4023)

(GRE RFC = 2784)
Original IP Datagram (Before Forwarding)
Original IP Header
IP Payload
20 Bytes
GRE Packet with New IP Header:

Protocol 47 (Forwarded Using New IP Dst)
New IP Header
GRE Header Original IP Header
20 Bytes
4 Bytes
IP Payload
20 Bytes
Protocol Version Number: 137
Indicates an MPLS Unicast Packet
Bit 0:
Bit 1-12:
Bit 13-15:
Bit 16-31:
Check Sum
Reserved
Version Number
Protocol Type
Protocol Type Field Settings (Ethertype)

Unicast: 0x8847
Multicast: 0x8848
GRE Tunnel Format with MPLS

(Reference: RFC 4023)
Original MPLS/IP Datagram (Before Forwarding)
L2 Header
Fwding Label
VPN Label
Original IP Header
IP Payload
MPLS/IP Datagram over GRE (After Forwarding)

L2 Header
New IP Header
GRE Header
20 Bytes
Ethertype in the Protocol

Type Field Will Indicate
an MPLS Label Follows
VPN Label
4 Bytes
Original IP Header
IP Payload
20 Bytes
VPN Label Is Signaled via MPBGP, which is standard MPLS BGP

VPN Control Plane operation.
MPLS Tunnel label (top) is replaced with destination PEs IP address

Encapsulation defined in RFC 4023
Most widely deployed form of MPLS over IP encapsulation
GRE Tunnel Modes

Stateful vs. Stateless GRE Tunnelling
Multipoint GRE
Point-to-Point GRE
Remote Site
Remote Site
Remote Site
IP Tunnel
IP Network
Central
Site
IP Network
Central
Site
Source and destination requires manual

configuration
Single multipoint tunnel interface is created per

node
Tunnel end-points are stateful neighbours
Only the tunnel source is defined
Tunnel destination is explicitly configured
Tunnel destination is derived dynamically
Creates a logical point-to-point Tunnel
IGP, BGP, and LDP/MPLS run through static

tunnel
DMVPN uses NHRP

MPLS VPN over mGRE uses BGP
Creates an encapsulation using IP headers
(GRE)
Advancements in Private
IP VPNs Over the Top
Enhancing the L3 VPN Segmentation Portfolio
VRF Lite Options
Leverage Carrier Ethernet E-LINE/E-LAN services

VRF-Lite Over GRE (GRE tunnel per VRF)
VRF-Lite Over DMVPN - scale to 4000 endpoints with native spoke-to-spoke access
Easy Virtual Networking (EVN) over an E-LINE Carrier Ethernet service
L3 MPLS BGP VPN (RFC 4364)

Over L2 transport (PE-PE, P-P, PE-P) optical, Ethernet, SONET/SDH, etc
Over p2p GRE tunnels (operationally not scalable)
L3 MPLS BGP VPN (RFC 4364) over IP
MPLS VPN over p2p GRE tunnels (operationally not scalable)

MPLS VPN over DMVPN with scale to 4000 endpoints and spoke-to-spoke access
Enhancing the L3 VPN Segmentation Portfolio
VRF Lite Options
Leverage Carrier Ethernet E-LINE/E-LAN services

VRF-Lite Over GRE (GRE tunnel per VRF)
VRF-Lite Over DMVPN - scale to 4000 endpoints with native spoke-to-spoke access
Easy Virtual Networking (EVN) over an E-LINE Carrier Ethernet service
L3 MPLS BGP VPN (RFC 4364)

Over L2 transport (PE-PE, P-P, PE-P) optical, Ethernet, SONET/SDH, etc
Over p2p GRE tunnels (operationally not scalable)
L3 MPLS BGP VPN (RFC 4364) over IP
MPLS VPN over p2p GRE tunnels (operationally not scalable)

MPLS VPN over DMVPN with scale to 4000 endpoints and spoke-to-spoke access
MPLS VPN over multipoint GRE (mGRE)
MPLS VPN over Multipoint GRE (mGRE)

MPLS VPNs over Multipoint GRE Using BGP for Dynamic Next-Hop Learning
Data Centre/HQ
Internet
Campus
RR
Shared
VRF
PE
IP
Transport
mGRE any-to-any IP
connectivity
VRF-Lite or
MPLS
VPN in Campus
mGRE
Tunnel
C-PE
C-PE
Offers MPLS-VPN over IP
Inherit spoke-to-spoke communications
Uses standard RFC 4364 MP-BGP control plane
Uses standard MPLS over GRE data plane
Offers dynamic Tunnel Endpoint next-hop via BGP
Requires only a single IP address for transport

over SP network
Reduces configuration: Requires No LDP, No

GRE configuration setup
C-PE
Branch LAN
Remote Branches
mGRE Interface
mGRE
interface
802.1q Trunk or
Physical Cable

Control/Data Plane Example over Service Provider Model
Internet
Data Centre/HQ
Branch Site
c-PE
RR
SP
IP VPN
Service
C-PE
c-PE = Customer PE
Routing to SP
BGP/Static
BGP/Static
Shared VRF
Campus
DC
VRF-Lite or MPLS
VPN in Campus/DC
Enterprise
Routing
RR = iBGP Route
Reflector

Control/Data Plane Example over Service Provider Model
iBGP Signalling
RR
SP
IP VPN
Service
c-PE
Routing to SP
Data Centre/HQ
mGRE Encapsulation
Branch Site
c-PE = Customer PE
Internet
mGRE
BGP/Static
C-PE
mGRE
Shared VRF
Campus
DC
VRF-Lite or MPLS
VPN in Campus/DC
BGP/Static
Enterprise
Routing
Routing and data forwarding done Over the Top of SP IP VPN Service
iBGP: (1) Advertise VPNv4 routes, (2) exchange VPN labels
eBGP: (1) exchange tunnel end point routes with SP (or directly connected)
Requires advertising a SINGLE IP prefix to SP (e.g. IP tunnel end points)
Enterprise
Routing
RR = iBGP Route
Reflector

Control Plane
Branch Site
c-PE
Internet
iBGP
AS 65000
SP Cloud
172.16.1.1
AS 1
Service Provider IP
Service (eBGP)
(AS 1)
Data Centre/HQ
RR
eBGP
Shared VRF
C-PE
Campus
DC
VRF-Lite or MPLS
VPN in Campus/DC
MPLS-VPN over mGRE
Overlay
(AS 65000)
eBGP (AS 1): used to peer to the SP PE router
i-BGP (AS 65000): used for MP-BGP and VPNv4 prefix and label exchange
C-PE for e-BGP appears as CE to the SP
C-PE for i-BGP functions as a PE in supporting MPLS-VPN over mGRE
eBGP used for advertising iBGP next-hop (and mGRE tunnel endpoint) only
MPLS VPN over mGRE Model

mGRE Interface is Dynamic and De-coupled from Physical Interfaces
System dynamically configures mGRE tunnel (via tunnel profile)
mGRE tunnel is decoupled from physical interface
User traffic is in VRF/VPNv4 of mGRE payload (hidden from provider)
Only a single IP address (source GRE/BGP-source) advertised to provider

Source IP Address of
mGRE tunnel advertised
to provider network
VRF, RD, RT
To user Campus/DC
networks with VRF
segmentation (802.1Q,
port, etc)
Gold
mGRE
Interface
Global
VRF, RD, RT
Blue
WAN to
Provider
PHY
Interface
Logical mGRE interface
de-coupled from a
physical interface
SP WAN
Transport

Feature Components
PE2
2 iBGP
172.16.255.3
172.16.255.2
1
172.16.255.1
PE1
PE3
IP Transport
PE4
172.16.255.4
PE6
172.16.255.6
PE5
172.16.255.5
4 View for PE 4
Tunnel Endpoint DB
172.16.255.1
172.16.255.2
172.16.255.3
172.16.255.5
172.16.255.6
mGRE is a multipoint bi-directional GRE tunnel
VPNv4 label (VRF) and VPN payload is carried in mGRE tunnel encapsulation
New encapsulation profile (see next slide) in CLI offers dynamic endpoint discovery:
Control Plane leverages RFC 4364 using MP-BGP

Signalling VPNv4 routes, VPN labels, and building IP next hop (locally)
(1) Sets IP encapsulation for next-hop

(2) Installs signaled BGP peer and end-point into tunnel endpoint database
Multipoint GRE
Interface

VPNv4 Configuration Example
mGRE
PE1
CE1
eBGP
Lo0: 10.0.0.1
IPv4
Transport
PE4
Lo0: 10.0.0.4
CE2
eBGP
Example for PE4

interface Loopback0
ip address 10.0.0.4 255.255.255.255
!
l3vpn encapsulation ip Cisco
transport ipv4 source Loopback0
!
router bgp 100
. . .
address-family vpnv4
neighbor 10.0.0.1 activate
neighbor 10.0.0.1 send-community extended
neighbor 10.0.0.1 route-map next-hop-TED in
exit-address-family
. . .
!
route-map next-hop-TED permit 10
set ip next-hop encapsulate l3vpn Cisco
Sets mGRE Encapsulation

Profile for BGP Next-Hop
Apply Route-Map to Received

Advertisement from Remote iBGP
Neighbour
Use IP Encap (GRE) for Next-Hop and
Install Prefix in VPN Table as
Connected IP Tunnel Interface

IPv6 (VPNv6) Configuration Example
mGRE
PE1
CE1
eBGP
Lo0: 10.0.0.1
Example for PE4
interface Ethernet 1/0

vrf forwarding green
ip address 209.165.200.253 255.255.255.224
ipv6 address 2001:db8:: /64 eui-64
!
router bgp 100
. . .
neighbor 10.0.0.1 send-community both
neighbor 10.0.0.1 route-map next-hop-TED in
exit-address-family
. . .
!
route-map next-hop-TED permit 10
set ipv6 next-hop encapsulate l3vpn Cisco
IPv4 Cloud
PE4
E 1/0
Lo0: 10.0.0.4
2001:db8::2 /64
CE2
eBGP
NOTE: Relevant MPLS VPN over mGRE

Commands That Are Same for IPv4, Are Not
Shown in This IPv6 Example
IPv6 Address Applied to CE2

Facing Interface
Apply Route-Map to Received
Advertisement from Remote iBGP
Neighbour (Same as vpnv4)
Use IP Encap (GRE) for Next-Hop and

Install IPv6 Prefix in VPNv6 Table as
Connected Tunnel Interface
Why Multicast VPNs
Workaround has been point-to-point GRE tunnels from CE to CE
Not scalable with many CE routers
Traffic overhead
Administrational overhead
Why CE-CE Tunnelling Doesnt Scale

CE
CE
CE
CE
MPLS Core
CE
CE
CE
CE
Point-to-point tunnelling removes the benefits of multicast

Traffic has to be replicated by the CE router for each remote CE router
Traffic in the core will be multiplied by the number of CE routers
Non-congruent unicast/multicast due to RPF issues
A better solution is required
MVPN CE and PE Domain Example

PE-CE PIM neighbourship
PE-P PIM neighbourship
PE-PE PIM neighbourship (over MT)
CE
PE
PE
CE
PE
Provider Network
Multicast Distribution Tree (MDT) is established between PE routers in Provider Network
CE router forms PIM neighbourship with VRF instance on PE router
PE routers form PIM neighbourship with other PE routers over MDT. This is a VRF specific
neighbourship
PE routers form PIM neighbourship with P routers. This is a global neighbourship
Multicast packets from CE routers will be forwarded over MDT
CE
MPLS VPN over mGRE MVPN Service

Customers Point of View
Multicast Domain inside of Provider
Network connects each MVPN.
Blue
CE
Blue Multicast Domain
Red
CE
Provider
Net
CE
Blue
Red
CE
Red Multicast Domain
CE
Blue
CE
Red
MVPN CE + MPLS VPN over mGRE

mGRE - multicast
PE-CE PIM neighbourship

PE-P PIM neighbourship
PE-PE PIM neighbourship (over MT)
PE-CE eBGP Peer (unicast)
MPLS VPN mGRE (GRE, MP-BGP)
C-PE
PE
mGRE - UNICAST
unicast
PE
C-PE
PE
C-PE
Provider Network
SP offers a multicast service
C-PE is a PIM peer to SP PE router
C-PE runs its own version of MVPN
C-PE runs MDT per VRF, transparent to the SP multicast domain
Leverages the SP Core for multicast replication vs. ingress replication via
GRE tunnels
C-PE customer PE
(mGRE solution)

Summary and Configuration Notes
Only requires advertising a single IP prefix to SP for mGRE operation
Leverages standard MP-BGP control plane (RFC 4364)
Dynamic Tunnel endpoint discovery is done via iBGP/route-map (no static GRE tunnel)
E-BGP can/is still be used for route exchange (mGRE end-point) with the SP
Solution requires NO manual configuration of GRE tunnels. LDP NOT required!
Supports MVPN and IPv6 per MPLS VPN model (MDT and 6vPE respectfully)
-
MVPN Platform Support today: ISR/G2, SUP-2T, ASR 1000 Series, ISR 44xx
Supports IPSec for PE-PE encryption (GET VPN or manual SA Discussed later)
Branch LAN
mGRE
interface
MPLS VPN over mGRE Support Summary

IOS-XE
HARDWARE
ASR 1000 Series (as of 3.1.2s)

Modular/Fixed
ISR 44xx
VIRTUAL ROUTER
Cloud Services Router

ISR 5xxx
IOS
Catalyst 6500 SUP2T
Cisco 7600 ES+, SIP-400
ISR 3xxx/2xxx/1xxx/8xx
MPLS VPN over mGRE Config

and Show Examples

Configuration Example Router 218
210
iBGP (AS 65000)
Lo0: 172.16.100.58
10.210.210.210
RR
218
E 0/0: 172.16.10.2
219
10.219.219.219
Lo0: 172.16.100.19
AS 1
eBGP
172.16.19.1
10.218.218.218
eBGP
mGRE
Lo0: 172.16.100.18
172.16.18.1
IPv4 Transport
!
vrf definition red
rd 1:1
route-target export 1:1
route-target import 1:1
!
address-family ipv4
!
interface Loopback0
ip address 172.16.100.18 255.255.255.255
!
interface Ethernet0/0
ip address 172.16.18.2 255.255.255.0
service-policy output parent
!
!
mpls mtu max
!
!
route-map mgre-v4 permit 10

210
iBGP (AS 65000)
Lo0: 172.16.100.58
10.210.210.210
RR
218
E 0/0: 172.16.10.2
mGRE
219
10.219.219.219
Lo0: 172.16.100.19
AS 1
eBGP
172.16.19.1
10.218.218.218
eBGP
Lo0: 172.16.100.18
172.16.18.1
IPv4 Transport
!
router bgp 65000
neighbor 172.16.18.1 remote-as 1
neighbor 172.16.18.1 update-source Eth 0/0
neighbor 172.16.100.58 remote-as 65000
neighbor 172.16.100.58 update-source Loop 0
!
address-family ipv4
network 172.16.100.18 mask 255.255.255.255
neighbor 172.16.18.1 allowas-in 5
exit-address-family
!
neighbor 172.16.100.58 send-community ext
neighbor 172.16.100.58 route-map mgre-v4 in
address-family ipv4 vrf red

network 10.218.218.218 mask 255.255.255.255

210
iBGP (AS 65000)
Lo0: 172.16.100.58
10.210.210.210
RR
218
E 0/0: 172.16.10.2
219
10.219.219.219
Lo0: 172.16.100.19
eBGP
172.16.19.1
10.218.218.218
eBGP
mGRE
AS 1
Lo0: 172.16.100.18
172.16.18.1
IPv4 Transport
218#conf t
Enter configuration commands, one per line.
End with CNTL/Z.
218(config)#l3vpn encapsulation ip Cisco

218(config-l3vpn-encap-ip)#
*%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

210
iBGP (AS 65000)
Lo0: 172.16.100.58
10.210.210.210
RR
218
E 0/0: 172.16.10.2
mGRE
219
10.219.219.219
Lo0: 172.16.100.19
218#sh adjacency tunnel 0

Protocol Interface
IP
Tunnel0
TAG
Tunnel0
IP
Tunnel0
TAG
Tunnel0
eBGP
172.16.19.1
AS 1
IPv4 Transport
Address
172.16.10.2(3)
172.16.10.2(3)
172.16.100.19(3)
172.16.100.19(3)
218#sh l3vpn encapsulation ip

Profile: Cisco
protocol gre
payload mpls
mtu max
Tunnel Tunnel0 Created [OK]
Tunnel Linestate [OK]
Tunnel Transport Source Loopback0 [OK]
10.218.218.218
eBGP
Lo0: 172.16.100.18
172.16.18.1
http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns431/ns658/white_paper_c11-726689.pdf
Enhancements to DMVPN for

MPLS VPN Support
VRF-Lite over Dynamic Multipoint VPN (DMVPN)

L3 Segmentation Extension over DMVPN
Data Centre/HQ
Internet
Shared
VRF
PE
Multipoint
GRE Tunnel
per VRF
Campus
VRF-Lite or
MPLS
VPN in Campus
IP
Transport
C-PE
MultiVRF CE
Remote
Branches
Allows VRF segmentation over DMVPN

framework
A Multipoint GRE (mGRE) interface is

enabled per VRF (1:1)
Solution allows spoke-to-spoke data

forwarding per VRF
Deployment Target: Customers already

running DMVPN, but needs to add VRF
capabilities to sites
C-PE
C-PE
Branch LAN
mGRE Tunnel per
VRF
MPLS
VPN over Dynamic Multipoint VPN (DMVPN)
MPLS VPN over a DMVPN Framework
Data Centre/HQ
Internet
Campus
RR
Shared
VRF
VRF-Lite or
MPLS
PE/P VPN in Campus
IP
Transport
C-PE
Allows MPLS VPN to leverage a DMVPN

framework
Enhancements to NHRP allows for label
switching over the mGRE tunnel
Introduces spoke to spoke support for
MPLS VPNs using DMVPN
QoS uses typical best-practices
Deployment Target: Customers already
running DMVPN and require larger scale L3
VPN segmentation (beyond VRF Lite)
C-PE
C-PE
802.1q Trunk
Physical Cable
Branch LAN
Remote
Branches
MPLS
and VPNv4
over mGRE Tunnel
Advanced Concepts of DMVPN (BRKSEC-4054)
Using Locator ID Separation

Protocol (LISP) for L3
Segmentation over the WAN
What is LISP? (Locator-ID Separation Protocol)

A Next Generation Routing Architecture RFC 6830
LISP creates a Level of indirection with two namespaces: EID and RLOC
EID
EID (Endpoint Identifier) is the IP address

of a host just as it is today
RLOC (Routing Locator) is the IP address
of the LISP router for the host
MS/MR
w.x.y.1
x.y.w.2
z.q.r.5
z.q.r.5
xTR
Non-LISP
EID-to-RLOC mapping is the distributed

architecture that maps EIDs to RLOCs
Network-based solution
Support for mobility
No host changes
Address Family agnostic
Minimal configuration
IPv4 to v6 Transition option
EID
a.a.a.0/24
b.b.b.0/24
c.c.c.0/24
d.d.0.0/16
EID Space
Prefix Next-hop
Incrementally deployable
RLOC
a.a.a.0/24
b.b.b.0/24
c.c.c.0/24
d.d.0.0/16
w.x.y.1e.f.g.h
x.y.w.2e.f.g.h
z.q.r.5e.f.g.h
z.q.r.5e.f.g.h
PxTR
In Cisco IOS/NX-OS now
More Details on LISP Covered in Session BRKRST-3045
xTR
xTR
EID
a.a.a.0/24
b.b.b.0/24
c.c.c.0/24
d.d.0.0/16
EID-toRLOC
mapping
RLOC
Space
EID Space
RLOC
w.x.y.1
x.y.w.2
z.q.r.5
z.q.r.5
RLOC
w.x.y.1
x.y.w.2
z.q.r.5
z.q.r.5
LISP Overview
What do we mean by location and identity?
IP Transport
Todays Internet Behaviour

Loc/ID overloaded semantic
When the device moves, it gets a
new IPv4 or IPv6 address for its
new identityand location
x.y.z.1
Device IPv4 or IPv6
address represents
identityand location
w.z.y.9
Mapping
Database System
IP Transport
x.y.z.1
Device IPv4 or IPv6
address represents
identity only.
Its location is here!
LISP Behaviour
Loc/ID split
a.b.c.1
e.f.g.7
Only the location changes
x.y.z.1
When the device moves, keeps its

IPv4 or IPv6 address.
It has the same identity
LISP - Basic Routing Concept

EID
1.1.1.2
Routing
Locator
1.1.1.1 RLOC 1
Where is
1.1.1.2 RLOC 1
2.2.2.1 RLOC 2
LISP TUNNEL
RLOC 1
TO RLOC1
TO: 1.1.1.2
1.1.1.1
DATA
1.1.1.2
TO: 1.1.1.2
RLOC 2
DATA
TO: 1.1.1.2
DATA
2.2.2.1
LISP Use Cases

The Five Core LISP Use-Cases
1. Efficient Multi-Homing
2. IPv6 Transition Support
3. Network Segmentation/Multi-Tenancy
4. Host/VM Mobility
5. LISP Mobile-Node
LISP Operations
LISP IPv4 EID/IPv4 RLOC Header Example
IPv4 Outer Header:

Router supplies
RLOCs
UDP
LISP
header
IPv4 Inner Header:
Host supplies
EIDs
LISP Segmentation/VPN
Efficient Segmentation/Multi-Tenancy Support Concepts
Because LISP considers Segmentation of both EID and RLOC namespaces,

two models of operation are defined: Shared and Parallel
Shared Model
Virtualises the EID namespaces

Binds an EID namespace privately defined using a VRF to an Instance-ID
Uses a common (shared) RLOC (locator) address space
The Mapping System is also part of the locator namespaces and is shared
Parallel Model
Virtualises the RLOC (locator) namespaces

One or more EID instances may share a virtualised RLOC namespace
A Mapping System must also be part of each locator namespaces
Efficient Segmentation/Multi-Tenancy Support Shared Model
Shared Model at the device level (think MPLS/MPLS-VPN )
Multiple EID-prefixes are allocated privately using VRFs

EID lookups are in the VRF associated with an Instance-ID
All RLOC lookups are in a single table (default/global or RLOC VRF)
The Mapping System is part of the locator address space and is shared
To VPNs (MPLS, 802.1Q,

VRF-Lite, or separate
networks)
EID namespace,
VRF Gold, IID 1
Shared RLOC
namespace
To VPNs (MPLS,
802.1Q, VRF-Lite, or
separate networks)
Gold
Blue
Default
EID namespace,
VRF Blue, IID 2
Single RLOC
namespace
Default table or RLOC
VRF
Efficient Segmentation/Multi-Tenancy Support Parallel Model
Parallel Model at the device level (think VRF-Lite )
Multiple EID-prefixes are allocated privately using VRFs

EID lookups are in the VRF associated with an Instance-ID
RLOC lookups are in the VRF associated with the locator table
A Mapping System must be part of each locator address space
To VPNs (MPLS, 802.1Q,

VRF-Lite, or separate
networks)
EID namespace,
VRF Gold, IID 1
RLOC uses Gold

namespace
Gold
Blue
Default
EID namespace,
VRF Blue, IID 2
RLOC uses Blue

namespace
To VPNs (MPLS,
802.1Q, VRF-Lite, or
separate networks)
LISP in Enterprise WAN/Branch

Leverage LISP Framework for WAN Branch Backhaul
MR
MS
Mapping
Database System
EID
Address
CE
Space
(xTR)
Routing to SP
Enterprise
Routing
Data Centre/HQ
LISP Encapsulation
Branch Site
SP
IP VPN
Service
RLOC
Address
BGP/Static
Internet
MR/MS
CE
RLOC
(xTR)
Address
Shared VRF
Campus
DC
EID Address Space
for Enterprise
BGP/Static
Leverage Mapping System for Address Resolution

MR/MS (redundant) at central location
LISP Encap (IP/UDP) allows over the top transport
Allows network segmentation on xTR (viewed as CE in L3 VPN model)

PE routers require minimal routes (RLOC address only, which only SP knows)
VRF Segmentation is applied to CE/xTR
Offers another over the top Segmentation solution (VRF capabilities
Can leverage GET VPN for additional data security (IPSec)
Enterprise
Routing
MR = Map Resolver
MS = Map Server
MPLS VPN over mGRE
LISP Segmentation
MPLS VPN over

DMVPN
Y (6vPE)
Y (6vPE)
No (limit of GETVPN)
Y (tunable)
2000+ (ASR 1000)
1000+
4000+
Multi-Homing
Y (simple)
Spoke to Spoke (w/ Virt)
Tunneless IP (encap)
Y (RFC 4023)
Y (native IP/UDP)
Manual Tunnel config
Y (hub only)
Y (mGRE src IP)
Y (RLOC)
Y (mGRE src IP)
RFC 4364
Mapping DB
RFC 4364
NHRP extensions
Encryption Support
Y (GETVPN)
Y (GETVPN)
Y (pairwise)
Route Learning
BGP (Push)
MR/MS (Pull)
BGP (PE-PE)(Push)
NHRP (S-S)(Pull)
N (limited, single GRE)
Y (dual GRE)
MVPN Support
IWAN Framework w/ IPC
IPv6 Transition
NAT Traversal w/ encrypt
Scale
Single IP address sent to ISP?

Control Plane
Load Balance over multiple links
Positioning What Technology, When, Where?

MPLS VPN over mGRE
MPLS VPN over DMVPN
LISP Multi Tenancy
Ideal if DMVPN is already

running (consistent operations).
Targets a scalable L3 VPN

segmentation solution
Leverages private IP transport

(L3 VPN) and non-Internet
(challenge with NAT traversal)
Desires need for Intelligent

Path Control (PfR)/IWAN
Dynamic on-demand spoke to

spoke traffic patterns
Desired pull model for

efficient scale and minimal
HW impact
Native IP VPN multicast

(MVPN)
Target Direct Internet Access

as backup transport path
IP/UDP transport offers

efficient ECMP hashing
No support for PfRv3 or

Internet as a transport option
Does not require VRFs for all

traffic
Offers efficient support for

mobility of nodes in network
Leverages GET VPN

encryption (w/ NAT traversal)
Targets scalable, simple MPLS

BGP VPN solution with any-toany traffic patterns
Leverages GET VPN

encryption for inherent mGRE
Agenda


over IP

Recommendations

Segmentation
Summary
Securing L3 VPN
Solutions over the WAN
with GET VPN
Group Encrypted Transport (GET) VPN

Any to Any Encryption for Stateless IP Tunnels (mGRE, LISP)
Private WAN
Public/Private WAN
Before: IPSec P2P Tunnels
After: Tunnel-Less VPN
WAN
Multicast
Scalabilityan issue (N^2 problem)

Overlay routing
Any-to-any instant connectivity cant be
done to scale
Limited QoS
Inefficient Multicast replication
Scalable architecture for any-to-any

connectivity and encryption
No overlaysnative routing
Any-to-any instant connectivity
Enhanced QoS
Efficient Multicast replication
Combining Technologies into Secure L3 Segmentation

Leverage MPLS VPN over mGRE + GET VPN Encryption
Key Servers
C-PE = Customer owned PE
GM = Group Member
mGRE
c-PE + GM
mGRE
MPLS VPN over

mGRE +
GET VPN
mGRE
c-PE + GM
C-PE runs MPLS VPN over mGRE for L3 Segmentation o

IP
GETVPN encrypts multipoint GRE (mGRE) tunnel payload
c-PE + GM
mGRE
c-PE + GM
Payload of VPNv4 (VRF) traffic is encrypted

Leverage simplicity of MPLS VPN over mGRE + GETVPN
MPLS VPN over mGRE + GET VPN - White Paper
http://www.cisco.com/en/US/solutions/collateral/ns340/ns517/ns431/ns658/white_paper_c11-726689.html
QoS Considerations for L3

Segmentation over the WAN
QoS with GRE, MPLS over GRE

ToS/EXP Reflection Behaviour for transit traffic Through the Router
GRE Header
Outer GRE IP Header
GRE
Original IP Header
IP Payload
Outer GRE IP Header
GRE
ToS
GRE Header with

ToS Reflection
ToS
GRE IP Hdr ToS (IP Hdr)

Original IP Header
IP Payload
GRE
MPLS/EXP
ToS
Outer GRE IP Header
EXP
MPLS over GRE

Header with ToS
Reflection
ToS
EXP
GRE (IP Hdr) EXP (MPLS Label) ToS (IP Hdr)

Original IP Header
Router will copy original ToS marking to outer GRE header
For MPLS over GRE, the EXP marking is copied to the outer header of the GRE tunnel
This allows the IPv4 transport to perform QoS on the multi-encapsulated packet
Caveats:
Traffic originating on the router (SNMP, pak_priority for routing, etc), could have different behaviour
IP Payload
QoS Deployment Models in a Virtualised Environment
Aggregate Model
A common QoS strategy is used for all VRFs
i.e. same marking for voice, video, critical data, best effort regardless of the
VRF the traffic is sourced from or destined too.
Allows identical QoS strategy to be used with/without Segmentation
Prioritised VRF Model

Traffic in a VRF(s) are prioritised over other VRFs
Example: Prioritise production traffic over Guest access
More complex. Could leverage PBR with MPLS-TE to accomplish this

Aggregate vs. Prioritised Model
Following the Aggregate Model Allows the Identical QoS Strategy to Be
Used With/Without Network Segmentation
QoS Deployment with Network Segmentation

Point-to-Cloud Example - Hierarchical QoS + MPLS VPN over mGRE
Classify and
Mark Traffic
at Edge
Red VRF
Green VRF
Si
Branch 1
Egress CIR =
600 Mb
IP VPN
Service
Red VRF
Green VRF
Branch 2
Red VRF
Green VRF
Branch 3
WAN
Edge
1 GE
Red VRF
Campus
Green VRF
Si
mGRE
Voice
Video
Best Effort
Scavanger
HQ/DC
LLQ +
Shaper
1st Layer GRE Tunnel (Parent)

Shaper per GRE
2nd Layer - Service Queuing per GRE (child)
Queuing determines order of packets sent to shaper
H-QoS policy applies to main interface (not mGRE)
Hierarchical QoS Example

H-QoS Policy on Interface to SP, Shaper = CIR
Two MQC Levels
Policy-map PARENT
class class-default
shape average 600000000 [600 Mbps shaper]
service-policy output CHILD
Policy-map CHILD
class Voice
police cir percent 10
class Video
class Scav
bandwidth remaining ratio 1
class class-default
Interface gigabitethernet 0/1

service-policy output PARENT
Gig 0/1
Service Level
Video
Best
Effort
Scav
Voice
600
Mbps
Hierarchical QoS Example
mGRE traffic +
H-QoS Policy on Interface to SP, Shaper = CIR
Control plane traffic
Two MQC Levels

Policy-map PARENT
class class-default
shape average 600000000 [600 Mbps shaper]
service-policy output CHILD
Policy-map CHILD
class Voice
class Video
class Scav
class class-default
Interface gigabitethernet 0/1

service-policy output PARENT
Gig 0/1
Service Level
Video
Best
Effort
Scav
Voice
600
Mbps
MTU Considerations with GRE Tunnels

Challenges
MTU=1500-24=1476
MTU=1500
MTU=1500
R1
MTU=1000
R2
MTU=1500
R3
MTU=1500
R4
Fragmentation is unavoidable in some cases
The use of GRE tunnels increase the chances of MTU issues (i.e. fragmentation)
due to the increase in IP packet size GRE adds
Main Issue: The performance impact to the router when the GRE tunnel
destination router must re-assemble fragmented GRE packets
Common Cases where fragmentation occurs?:

Customer does not control end to end IP path (some segment is < MTU)
Router generates an ICMP message, but the ICMP message gets blocked by
a router or firewall (between the router and the sender). Most Common!!
New MPLS MTU Enhancements
Prior to XE 3.16, MTU default = 1476 and no option for making it smaller
In addition, only max mtu is supported under the tunnel profile
Starting at release XE 3.16 a new MTU command was introduced
We introduced the MPLS MTU xxx under the tunnel profile
This will allow non-static MTU settings for the MPLS VPN over mGRE feature
!
mpls mtu 1120
mpls mtu command will allow sub 1500 B

MTU
For MTU greater than 1500, the max mtu

command inherits the PHY interface MTU
IP MTU Technical White Paper:

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml
Summary - MTU Recommendations

Point to Point GRE
Avoid fragmentation (if at all possible)
Consider tunnel path-mtu-discovery command to allow the GRE interface to copy DF=1
to GRE header, and run PMTUD on GRE
Set ip mtu on the GRE to allow for MPLS label overhead (4-bytes)
If using IPSec, ip mtu 1400 is recommended
Configure ip tcp adjust-mss for assist with TCP host segment overhead
MTU Setting options:
Setting the MTU on the physical interface larger than the IP
Set IP MTU to GRE default (1476) + MPLS service label (4)
interface Ethernet 1/0

. . .
MTU
mtu 1500
interface Tunnel0
. . .
ip mtu 1472
Best to fragment prior to encapsulation, than after encapsulation, as this forces the host to do packet
reassembly (vs. the remote router)
Agenda


over IP

Recommendations

Segmentation
Summary
Evolving Trends in Layer 3

Segmentation
Innovations Worth Investigating Further
MPLS VPN over mGRE Enhancements
MTU under tunnel profile (XE 3.15 +)

Per VRF PBR for egress interface of mGRE
Programmability and Virtual Options
REST APIs in IOS-XE
NSO (Tail-f) for adding services (L3 VPN)
Leveraging SDN for WAN Automation

Provisioning
XE 3.17 supports NETCONF/YANG/REST on ASR

1000/ISR44xx
Virtual router/network functions (IOS-XE, IOS-XR, L4-L7)
Using WAN Automation Engine (WAE) in self deployed

MPLS networks
APIC-EM for IWAN is targeting simplifying provisioning
VXLAN integration with BGP and DCI

solutions
Future DCI Example: Standalone L3 DCI MPLS VPN o mGRE

EVPN-VPNv4 Integration into MPLS VPN over mGRE
DC2
DC1
N9500
N9500
iBGP
N9500
iBGP /
eBGP
N9500
CE-PE
Spine
Routing
Leafs
Leaf
N9300
N9300
N9300 N9300 N9300
N9500N9500 N9300
EVPN
Control
Plane
Data Center 1
VXLAN
MPLS VPN over

IPVPN
mGRE
EVPN
IP
N9300
Fabric
Extenders
PE-CE
VXLAN
EVPN Route
RD, Prefix , RT, L3 VNI
Next Hop VTEP IP
Tunnel Encap VXLAN
Router MAC
MPLS
IP Route
RD, Prefix, MPLS label,

RT, Next Hop (GRE
Encap)
Features & Orchestration
Solution Characteristics
Securely Connecting WAN with DC
MPLS VPN over mGRE consistency

for WAN and DC
Leverage per-tenant segmentation

with VRF and VXLAN interworking
Extend to users/branch as well
BGP control plane options for L3 service

Option 1: draft-drao-bgp-l3vpn-virtual-network-overlays-01
Option 2: draft-sajassi-nvo3-evpn-overlay-01 ( could be used for both L2 and
L3)
EVPN VPNv4 integration
SP address space in Global Routing
VXLAN (DC) to VPNv4 (WAN)

Integration
QoS, multicast and Integrated Routing
Automation orchestration (Future)
Agenda


over IP

Recommendations

Segmentation
Summary
Summary Key
Takeaways
WAN Segmentation - Key Takeaways
The ability for an enterprise to extend Layer 3 (L3) Segmentation technologies over the
WAN is critical for todays applications
The ability to transport VRF-Lite and MPLS-VPN over IP allows flexible transport
options, including ability to encrypt segmented traffic
Understanding key network criteria (topology, traffic patterns, VRFs, scale, expansion) is
vital to choosing the optimal solution for extending Segmentation over the WAN
MPLS VPN over mGRE offers simpler, and more scalable, deployment, eliminating LDP,
manual GRE, for the WAN
Understand the options for QoS, GET VPN in mGRE environments, and the impact of
MTU and available tools in IOS for MTU discovery
Begin to understand Cisco innovations (MPLS VPN over mGRE, EVN, LISP
Segmentation) and how they can help simplify network Segmentation in the WAN for
future designs
Leverage the technology, but Keep it Simple when possible
WAN Design Network Virtualisation

Tier 1
East Theater
West
Theater
Global
IP/MPLS Core
Self Deployed MPLS VPN
In-Theater
IP/MPLS Core
West Region
Internet
Cloud
Public
Voice/Video
Mobility
Innovations MPLS VPN over

mGRE, LISP-Multitenant
(Virtualisation)
Integration of Virtualisation
Campus, Branch/WAN
East Region
Private
IP
Service
Metro
Service
Tier 3
MPLS VPN Over the Top

Solutions (MPLS VPN o mGRE,
DMVPN)
Tier 2
Innovations MPLS VPN o

mGRE, LISP Multi-tenant
Public
IP
Service
Metro
Service
Q&A
Continue Your Education
Demos in the Cisco Campus
Walk-in Self-Paced Labs
Table Topics
Meet the Engineer 1:1 meetings
Complete Your Online Session Evaluation

Give us your feedback and receive a
Cisco 2016 T-Shirt by completing the
Overall Event Survey and 5 Session
Evaluations.
Directly from your mobile device on the Cisco Live

Mobile App
By visiting the Cisco Live Mobile Site
http://showcase.genie-connect.com/ciscolivemelbourne2016/
Visit any Cisco Live Internet Station located

throughout the venue
T-Shirts can be collected Friday 11 March

at Registration
Learn online with Cisco Live!

Visit us online after the conference
for full access to session videos and
presentations.
www.CiscoLiveAPAC.com
Recommended Reading
Thank you

BRKRST-2045 - Innovations For Extending L3 VPN Segmentation Over IP-based WAN Transport (2016 Melbourne)

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

BRKRST-2045 - Innovations For Extending L3 VPN Segmentation Over IP-based WAN Transport (2016 Melbourne)

Transféré par

Droits d'auteur :

Formats disponibles

Innovations for Extending

Introduction - Network Segmentation

WAN Transport Impact on L3 VPN

QoS, MTU, and Encryption

Recent Innovations Evolving in L3

WAN Transport Impact on L3 VPN

QoS, MTU, and Encryption

Recent Innovations Evolving in L3

Evolution of Network Segmentation

Means Many Things to Many People

It has evolved a long way from technologies like TDM (1960s)

What Is Enterprise L3 Network Segmentation?

End-user perspective is that of being connected to a dedicated network

Maintains Hierarchy, Virtualises devices, data paths, and services

Actual Physical Infrastructure

Guest Access Network

Why L3 Network Segmentation?

Simpler OAMreducing the amount of network devices needing to be managed and

Securitymaintaining segmentation of the network for different departments over a

High Availabilityleverage Segmentation through clustering devices that appear as

Data Centre Applicationsrequire maintained separation, end-to-end continuity of

L3 Network Segmentation Use Cases

Multi-Tenant Dwelling requiring Separation

Mandates to logically separate varying levels of security enclaves

Health Care HIPPA | Financial and Transactional Sarbanes-Oxley, PCI Compliance

Public Cloud and WAN Orchestration

Enterprise Network Segmentation

Extending and Maintaining the

Enterprise Network Segmentation over the WAN

Virtual Sw System (VSS)

Virtual Port Channel (vPC)

(Easy Virtual Network)

(Virtual Device Context)

Cloud Services Router (CSR)

ASR 9000v/nV Clustering

Enterprise Network Segmentation over the WAN

Virtual Sw System (VSS)

L2 VPNs PWE3, VPLS, L2 PW over GRE, L2TPv3,

Evolving Standards PBB/E-VPN, VxLAN, NVGRE

(Virtual Device Context)

L3 VPNs VRF-Lite, VRF-Lite over GRE, MPLS

Cloud Services Router (CSR)

Virtual Port Channel (vPC)

ASR 9000v/nV Clustering

Introduction - Network Segmentation

WAN Transport Impact on L3 VPN

QoS, MTU, and Encryption

Recent Innovations Evolving in L3

Transport Options for Private IP

WAN Segmentation Models

Self Deployed MPLS Backbone Supporting

Self Deployed MPLS Backbone

Self Deployed offers Service richness

Customer manages and owns:

Customer controls how rapidly

Allows customer full control E2E

Requires more expertise on the

BGP MPLS IP VPN Backbone

Customer Owned IP/MPLS

Customer Managed Domain

Self Deployed MPLS over the top of SP Transport

CE Routers owned by customer

Customer peers to PE via IP