WAN Design Network Virtualization

BRKRST-2043

WAN Design: Network Virtualization

© 2009 Cisco Systems, Inc. All rights reserved. Cisco PublicBRKRST-2043 2

Cisco Live & Networkers VirtualSpecial Offer – Save $100Cisco Live has a well deserved reputation as one the industry’s best educational values. With hundreds of sessions spanning foureducational programs — Networkers, Developer Networker, Service Provider, IT Management, you can build a custom curriculum that can make you a more valuable asset to your workplace and advance your career goals. Cisco Live and Networkers Virtual immerses you in all facets of Cisco Live, from participating in live keynotes and Super Sessions events to accessing session content to networking with your peers.Visit www.ciscolivevirtual.com and register for Cisco Live and Networkers Virtual. To get $100 USD off the Premier pass, which provides access to hundreds of technical sessions, enter “slideshareFY11”.


Assumptions/Disclaimers� Participants should have:

A solid base knowledge of IP routing and WAN design fundamentals and technologiesBasic knowledge of VRF’s, GRE tunnels, and DMVPNBasic understanding of MPLS control and forwarding plane

� This discussion will not deep-dive into VMware, Virtual Machines, or other server virtualization technologies

� Understanding Data Center Interconnection (DCI) is an important application that utilizes WAN virtualization infrastructure, it is not a focus in this session.

� RFC 2547 (BGP/MPLS IP VPNs) is referenced frequently for MPLS VPN. This is for familiarity only. RFC 2547 is now replaced with RFC 4364.


Session Objectives

� Why network virtualization is needed� Key building blocks for virtualization over the WAN� Service Provider transport options and how each

impacts deploying virtualization in the WAN� Most commonly deployed network virtualization

“solutions” and when/where to position them� Integration of QoS in a virtualized WAN� Key deployment considerations and caveats

At the End of the Session, the Participants Should Be Able to Understand:


Agenda� Network Virtualization Drivers and

Building Blocks� Enterprise WAN Deployment

Considerations� Deployment Solutions for a Virtualized

WAN� Deployment Considerations and

Caveats in a Virtualized WAN� Virtualized WAN Case Study� Summary








Evolution of “Network” Virtualization…Means Many Things to Many People ☺� It has evolved a long way from technologies like TDM (1960’s)� 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 center

Time

TDM

HSRP MPLS VPNMPLS

VLANs

VRF LiteVirtual Circuits

2010+

GRE

Secure Domain Routers

VirtualMachines(VMWare)

Virtual SwSystem

VirtualDeviceContext

VirtualPort

Channel

L2TPv3

AToM VPLS


Virtual Network

Merged NewCompany

What Is “Network” Virtualization?� Giving One physical network the ability to support multiple virtual networks� End-user perspective is that of being connected to a dedicated network (security, independent set of policies, routing decisions…)

� Maintains Hierarchy, Virtualizes devices, data paths, and services� Allows for better utilization of network resources

Actual Physical Infrastructure

Internal Organizational Separation (eng, sales)

Virtual Network Virtual Network

Guest Access Network


Why Network Virtualization?Key Drivers

� Cost Reduction—allowing a single physical network the ability to support multiple users and virtual networks

� Simpler OAM—reducing the amount of network devices needingto be managed and monitored

� Security—maintaining segmentation of the network for differentdepartments over a single device/Campus/WAN

� High Availability—leverage virtualization through clusteringdevices that appear as one (vastly increased uptime)

� Data Center Applications—require maintained separation, end-to-end (i.e. continuity of virtualization from server-to-campus-to-WAN)

� New Data Center ConceptsServers cluster ExtensionVirtualization across multi-Data Centers (requires VLAN extension)V-Motion Application (requires single VLAN/Logical-IP-subnet)


SiSi

Enterprise Network Virtualization Key Building Blocks

Device Partitioning

Virtualized Interconnect

Device Pooling

SiSi SiSi

“Virtualizing”the routing and forwarding of the device

“Virtualizing”multiple devices to

function as a single device

Extending and maintaining the “Virtualized”

devices/pools over any media


SiSi

Enterprise Network Virtualization The Building Blocks – Example Technologies

Device Partitioning

VDC (NX-OS)(Virtual Device Context)SDR (IOS-XR)(Secure Domain Routers)FW Contexts

VLANsVRFs


L3 VPNs – MPLS VPNs, GRE, VRF-Lite, MPLS services (L2/L3) over GREL2 VPNs - AToM, Unified I/O, VLAN trunksEvolving – TRILL, 802.1ah, 802.1af

Device Pooling

VSSStackwiseVirtual Port Channel (vPC)HSRP/GLBP

SiSi SiSi


VRF

Device Partitioning

VRFVRF

Global

VRF—Virtual Routing and ForwardingVLAN—Virtual LAN

� Virtualize at Layer 3 forwarding� Associates to one or more Layer 3 interfaces on router/switch

� Each VRF has its ownForwarding table (CEF)Routing process (RIP, OSPF, BGP)

� Interconnect options (VRF-Lite)?802.1q, GRE, sub-interfaces, physical cables, signaling

� Virtualize at Layer 2 forwarding� Associates to one or more L2 interfaces on switch

� Has its own MAC forwarding table and spanning-tree instance per VLAN

� Interconnect options?VLANs are extended via phy cable or virtual 802.1q trunk


SiSi


Device Partitioning

VDCsSDR (XR)FW Contexts

VLANsVRFs


L3 VPNs – MPLS VPNs, GRE, VRF-Lite, MPLS services (L2/L3) over GREL2 VPNs - AToM, Unified I/O, VLAN trunksEvolving – TRILL, 802.1ah, 802.1af

Device Pooling

Virtual Sw System (VSS)Virtual Port Channel (vPC)HSRP/GLBPStackwise

SiSi SiSi



Device Partitioning

VDCsSDR (XR)Virtual FW Contexts

VLANsVRFs


L3 VPNs – MPLS VPNs, VRF-Lite, MPLS VPN or VRF-Lite over IPL2 VPNs – PWE3, VPLS, L2 VPN over IP, L2TPv3, OTV (Overlay Transport Virtualization)Evolving Standards – Fat-PW, Virtual Ethernet, TRILL, MPLS-TP

Device Pooling

VSSStackwiseVirtual Port Channel (vPC)HSRP/GLBP

SiSi SiSi

TRILL - Transparent Interconnection of Lots of Links

WAN


Enterprise Virtualization End to End WAN Virtualization

Distribution Blocks

SiSiSiSiSiSiSiSi

SiSi

SiSi SiSi

SiSi

Internet

Campus

Yellow VRFGreen VRFRed VRF

Branch 1


Branch 2


Branch 3

Data Center 1 WAN

•Allow Virtualization over the WAN via any transport/media• support QoS and multicast•Offer variations of complexity and scale• Leverage industry standards








Today’s WAN Transport Options

Topologies� Point-point, multi-point� Full/partial mesh� Hub/Spoke or Multi-Tier

Media� Serial, ATM/FR, OC-x� Dark fiber, Lambda� Ethernet

VPN Services for Transport� L2 - Metro-E (p2p, p2mp)� L3 – Private IP VPN� L3 – Public (Internet)

Overlay Options� GRE� DMVPN� L2/L3 VPN over IP

WAN

LAN LAN


Self Deployed MPLS vs. SP L3 ManagedNetwork Virtualization Deployment Options

� Customer manages and owns:IP routing, provisioningTransport for PE-P, P-P, PE-CESLA’s, to “end” customerQoS, Traffic Engineering

� Allows customer full control E2E

� CE Routers owned by customer� PE Routers owned by SP� Customer “peers” to “PE” via IP� Exchanges routing with SP via routing protocol (or static route)

� Customer relies on SP to advertise routes to reach other customer CEs

Self Deployed MPLS

Customer MPLS Backbone

Site 2Site3

Site1

PE PE

CE

CE

CEPP

P

Customer Managed

Self Deployed MPLS Backbone

* No Labels are exchanged with the SP

Provider MPLS VPNSite 2

Site3

Site1

IP Routing Peer(BGP, static, IGP)

PE PE

SP Managed IP VPN Service

SP Demarcation

CE

CE

CE

Customer Managed

Customer Managed


Self Deployed MPLS Transport Options”WAN Transport” Dictates Virtualization Method

� MPLS over L2 (Serial/PoS, Ethernet) is the common SP deployment

� MPLS over “IP” requires enhanced “MPLS over IP” solutions� Desire in the Enterprise is to allow MPLS-VPN or VRF to be extended over an IP Service offering (i.e. L3 VPN service, Internet)

Layer 2(Serial/PoS, Ethernet)

IP Transport(IP VPN, Internet)

Layer 2VPN

** MPLS-VPN(LSP Tunnel)

AToM*, VPLS(LSP Tunnel)

SPTransportVPNRequired

MPLS-VPN, VRF Lite(IP Tunnel)AToM*, VPLS(IP Tunnel)

Layer 3VPN

* AToM – Any Transport over MPLS ** VRF-Lite is also an option and does not require BGP and LDP


GRE Tunnel Encapsulation (RFC 2784)Applicable over Any Layer 3 WAN Transport

Original IP header IP payloadGRE headerNew IP header20 bytes 20 bytes4 bytes

GRE packet with new IP header:protocol 47 (forwarded using new IP dst)

Original IP header IP payload20 bytes

Original IP datagram (before forwarding)

Bit 0: Check sumBit 1-12: ReservedBit 13-15: Version NumberBit 16-31: Protocol Type


IP WAN

Router A Router BGRE Tunnel

Can also leverage IPSec when IP encryption is required of an untrusted WAN


Self Deployed MPLS “over” SP L3 ManagedNetwork Virtualization Deployment Options

� CE Routers owned by customer� PE Routers owned by SP� Customer “peers” to “PE” via IP� Exchanges routing with SP� Add overlay of IP that allows self-deployed MPLS over an IP Service

Provider MPLS VPN

Site 2Site3

Site1

IP Routing to SP

PE PE

SP Managed IP VPN Service

SP Demarc

CE

CE

CE

Customer Managed

Customer Managed

X over GREVRF’s

Provider MPLS VPN

Site 2Site3

Site1

PE PE

L3 VPN over IP WAN Service

C-PE

C-PE

C-PE

Customer Managed VRF/MPLS over IP

Customer MPLS VPN

� CE routers become MPLS PE (c-PE)� VRFs or MPLS labels are encapsulated in IP

� Other options not as scalable or more complex:� Carrier Supporting Carrier� Back to Back VRFs (CE-PE)

X over GREIP Routing to SPVRF’s







© 2010 Cisco and/or its affiliates. All rights reserved. Cisco PublicPresentation_ID 23

VRF-Lite in the WAN


WAN

What is VRF Lite in the WAN?

VRFVRFVRF

Per VRF:Virtual Routing TableVirtual Forwarding Table

VRFVRFVRF

� Defines router supports routing (RIB), forwarding (FIB), and interface - per VRF !!

� Leverages “Virtual” encapsulation for separation:� ATM VCs, Frame Relay, Ethernet/802.1Q

� The routing protocol is also “VRF aware”� EIGRP, OSPF, BGP, RIP/v2, static (per VFR)

� Layer 3 VRF interfaces cannot belong to more than a single VRF

802.1q, DLCI, VPI/VCI, GRE


IGP per VRF IGP per VRF

WANTranspor

tBranch Site

Multi-VRF CE

IGP per VRF Enterprise Routing

VRF-Lite over Layer 2 TransportExtend Virtualization over WAN L2 Service

� Each Frame Relay VC contains a sub-interface� Routing protocol process created per VRF in both Branch/Campus� Offers virtualized segmentation within a single interface

FR Sub-Interfaces Data Center/HQ

PE

SharedVRF

Internet Campus

VRF-Lite or VPNv4 to campus

VRF-Lite or MPLSVPN in PE

Frame RelayFR VC’s


WANTranspor

tBranch Site

Multi-VRF CE

VRF-Lite over Layer 2 TransportExtend Virtualization over WAN L2 Service

FR Sub-Interfaces Data Center/HQ

PE

SharedVRF

Internet Campus



Frame RelayFR VC’s

!interface Serial11/0encapsulation frame-relay

!interface Serial11/0.1 point-to-pointip vrf forwarding blueip address 192.168.51.2 255.255.255.0frame-relay interface-dlci 100 !interface Serial11/0.2 point-to-pointip vrf forwarding greenip address 192.168.61.2 255.255.255.0frame-relay interface-dlci 200 !interface Serial11/0.3 point-to-pointip vrf forwarding yellowip address 192.168.71.2 255.255.255.0frame-relay interface-dlci 300 !

Configuration Tip:� Frame Relay encapsulation can be used to virtualize a leased line

� Enabling Frame Relay encap allows the use of sub-interfaces

� Then VRF forwarding can be enabled per sub-interface

� Allows VRF-Lite over leased-line


IP WAN

VRF-Lite over IP TransportVRF-Lite over GRE

VRFVRFVRF

Per VRF:Virtual Routing TableVirtual Forwarding Table

VRFVRFVRF

� VRF Lite can also leverage GRE tunnels for separation extension

� Each VRF uses a unique GRE tunnel

GRE TunnelGRE TunnelGRE Tunnel



IPv4Service

Branch SiteMulti-VRF CE

IGP per VRF

BGP/static BGP/static

Enterprise Routing

Routing to SP

VRF-Lite over the WANVRF-Lite per GRE Tunnels

� Each GRE tunnel contains a VRF for extension� Routing protocol process created per VRF (each end)� Offers virtualized segmentation within a single interface

mGRE Tunnel per VRF Data Center/HQ

PE

SharedVRF

Internet Campus



Configuration Note: Each GRE tunnel could require unique source/dest IP (platform dependent)


IPTranspor

t

Branch Site

VRF-Lite over Point-to-Point GRE Example for “blue” VRF (IOS)


Data Center/HQ

PE

SharedVRF

Internet


Campus

DC/HQ ConfigurationBranch Configurationinterface Loopback100ip address 172.16.100.50 255.255.255.255!interface Tunnel100Description GRE to PE router 201ip vrf forwarding blueip address 11.1.0.2 255.255.255.0tunnel source Loopback100tunnel destination 172.16.100.10!interface Ethernet0/0ip address 172.16.5.2 255.255.255.0!router eigrp 1!address-family ipv4 vrf blue autonomous-system 1network 11.0.0.0no auto-summaryexit-address-familyno auto-summary

interface Loopback100ip address 172.16.100.10 255.255.255.255!interface Tunnel100Description GRE to PE router 201ip vrf forwarding blueip address 11.1.0.1 255.255.255.0tunnel source Loopback100tunnel destination 172.16.100.50!interface Ethernet0/0ip address 172.16.6.2 255.255.255.0!router eigrp 1!address-family ipv4 vrf blue autonomous-system 1network 11.0.0.0no auto-summaryexit-address-familyno auto-summary

11.1.0.x

Physical: 172.16.5.2 (E0/0)

Lo0: 172.16.100.50

Manually Configured Tunnelip vrf bluerd 2:2

VRF Command applied perGRE Tunnel

Prefix advertised to SP


VRF-Lite over L2 and GRE TransportSummary� Leverages VRF in router (RIB/FIB, interface) and interface for segmentation

� No MPLS or BGP required� Optimal solution when VRF count is small (~ >8)� Scale usually dependent on routing protocol� Supports multicast and QoS solutions� Unique IP address’s needed per GRE tunnel (global space)� Most common deployments:

Branch Back-haul to campusBranch Back-haul to aggregation PE running full MPLS VPN

Sub interface per VRF Branch LAN


GRE Tunnel Modes“Stateful” vs. “Stateless”

� Source and destination requires manual configuration

� Tunnel end-points are stateful neighbors

� Tunnel destination is explicitly configured

� Creates a logical point-to-point “Tunnel”

Remote Site

CentralSite

Point-to-Point GRE

IP Network CentralSite

Multipoint GRE

Remote Sites

� Single multipoint tunnel interface is created per node

� Only the tunnel source is defined� Tunnel destination is derived dynamically through some control plane mechanism (i.e. BGP, NHRP)

� Creates an “encapsulation” using IP headers (GRE)

IP NetworkIP Tunnel


VRF-Lite over Multipoint GRE

� DMVPN is a Cisco IOS Software solution for building IPsec + GRE VPNs in an easy, dynamic and scalable manner

� Relies on two proven technologiesNext Hop Resolution Protocol (NHRP)

Creates a distributed (NHRP) mapping database of all the spoke’s tunnel to real (public interface) addresses

Multipoint GRE Tunnel InterfaceSingle GRE interface to support multiple GRE/IPsec tunnelsSimplifies size and complexity of configuration

This Topic Is Covered in Detail in the “DMVPN Session” – BRKSEC-4012

What is Dynamic Multipoint VPN ?


Dynamic Multipoint VPN—Example

Dynamic Spoke-to-spoke tunnels

Spoke A

Spoke B

192.168.2.0/24.1

192.168.1.0/24.1

192.168.0.0/24.1

. . .

. . .

Physical: 172.17.0.1Tunnel0: 10.0.0.1

Physical: dynamicTunnel0: 10.0.0.11

Physical: dynamicTunnel0: 10.0.0.12

Static Spoke-to-hub tunnels

Static knownIP address

Dynamicunknown IP addresses

LANs can have private addressing


Data Center/HQ

VRF-Lite over Dynamic Multipoint VPN (DMVPN)L3 Virtualization Extension over DMVPN

� Allows virtualization over DMVPN framework

� A Multipoint GRE (mGRE) interface is enabled per VRF (1:1)

� Solution allows spoke-to-spoke data forwarding per VRF

VRF-Lite or MPLSVPN in Campus

PE

RemoteBranches

Multi-VRF CE

Multipoint GRE tunnel per VRF

IPTranspor

t

Branch LAN

SharedVRF

Campus

C-PEC-PE

C-PE

Internet

GRE Tunnel per VRFThis Topic Is Covered in Detail in the “DMVPN

Session” BRKSEC-4012



IPv4ServiceBranch Site

IGP per VRF

BGP/static BGP/static

Enterprise Routing

Routing to SP

VRF-Lite over DMVPNMultipoint GRE per VRF

� Unique RIB, FIB, and mGRE interface per VRF� Routing to the provider is based on the “global” address space� Each VRF uses a unique network ID for each NHRP server

Per-VRF NHRPServer


PE

SharedVRF

Internet


CampusBranch Site mGRE Tunnel per VRF

mGRE Tunnel per VRF

Tunnels are Multipoint


IPTranspor

t


VRF-Lite over DMVPNExample (IOS)

Per-VRF NHRPServer


PE

SharedVRF

Internet


Campus

Hub Configurationip vrf blue!interface Loopback0ip address 10.126.100.1 255.255.255.255!interface Tunnel0description mGRE for blueip vrf forwarding blueip address 11.1.1.1 255.255.255.0no ip redirectsip nhrp map multicast dynamicip nhrp network-id 100tunnel source Loopback0tunnel mode gre multipoint

ip vrf blue!interface Loopback0ip add 10.123.100.1 255.255.255.255!interface Tunnel0description GRE to hub ip vrf forwarding blueip address 11.1.1.10 255.255.255.0ip nhrp network-id 100 ip nhrp nhs 11.1.1.1 tunnel source Loopback0tunnel destination 10.126.100.1!interface Vlan10description blue Subnetip vrf forwarding blueip address 11.1.100.1 255.255.255.0

Spoke Configuration

Unique “network-id” parameter per VRF

Branch Site mGRE Tunnel per VRF


IPTranspor

t



Per-VRF NHRPServer


PE

SharedVRF

Internet


Campus



Spoke Configuration

ip vrf Green!interface Loopback1ip add 10.123.101.1 255.255.255.255!interface Tunnel1description GRE to hub ip vrf forwarding Greenip address 11.1.2.10 255.255.255.0ip nhrp network-id 101 ip nhrp nhs 11.1.2.1 tunnel source Loopback0tunnel destination 10.126.101.1!interface Vlan10description Green Subnetip vrf forwarding Greenip address 11.1.101.1 255.255.255.0

ip vrf Green!interface Loopback1ip address 10.126.101.1 255.255.255.255!interface Tunnel1description mGRE for Greenip vrf forwarding Greenip address 11.1.2.1 255.255.255.0no ip redirectsip nhrp map multicast dynamicip nhrp network-id 101tunnel source Loopback0tunnel mode gre multipoint



IPTranspor

t



Per-VRF NHRPServer


PE

SharedVRF

Internet


Campus



Spoke Configuration

ip vrf Green!interface Loopback0ip add 10.123.101.1 255.255.255.255!interface Tunnel0description GRE to hub ip vrf forwarding Greenip address 11.1.2.10 255.255.255.0ip nhrp network-id 101 ip nhrp nhs 11.1.2.1 tunnel source Loopback0tunnel destination 10.126.101.1!interface Vlan10description Green Subnetip vrf forwarding Greenip address 11.1.101.1 255.255.255.0

ip vrf Green!interface Loopback0ip address 10.126.101.1 255.255.255.255!interface Tunnel0description mGRE for Greenip vrf forwarding Greenip address 11.1.2.1 255.255.255.0no ip redirectsip nhrp map multicast dynamicip nhrp network-id 101tunnel source Loopback0tunnel mode gre multipoint

ip vrf Yellow!interface Loopback2ip address 10.126.102.1 255.255.255.255!interface Tunnel2description mGRE for Yellowip vrf forwarding Yellowip address 11.1.3.1 255.255.255.0no ip redirectsip nhrp map multicast dynamicip nhrp network-id 102tunnel source Loopback2tunnel mode gre multipoint

ip vrf Yellow!interface Loopback2ip add 10.123.102.1 255.255.255.255!interface Tunnel2description GRE to hub ip vrf forwarding Yellowip address 11.1.3.10 255.255.255.0ip nhrp network-id 103 ip nhrp nhs 11.1.3.1 tunnel source Loopback2tunnel destination 10.126.102.1!interface Vlan10description Green Subnetip vrf forwarding Yellowip address 11.1.102.1 255.255.255.0



VRF-Lite over Dynamic Multipoint VPN (DMVPN)Summary

� Allows virtualization over DMVPN framework� Redundant Hub configurations can also be added for high availability

� Solution offers spoke-to-spoke traffic forwarding (bypass Hub), per VRF

� Multicast is supported, but must traverse hub (traffic pattern is source � hub � spoke)

� Ideal solution when spoke-to-spoke traffic patterns are required� Common QoS can be applied in VRF-Lite over DMVPN� Tunnels in different VRF’s cannot share the same source address

Branch LANMultipoint GRE Tunnel per VRF over DMVPN


VRF-Lite Solutions over the WANComparison Matrix

VRF-Liteover sub-interfaces

VRF-Liteover P2P GRE

VRF-Lite over DMVPN

Target Number for VRF’s < 8 < 8 < 8

Uses Dynamic Endpoint Discovery

No No Yes (NHRP)

Leverages Multipoint GRE tunnels

No No Yes

Avoids manual full-mesh GRE configurations

No No Yes

Ability to hide IP addresses transported

Yes Yes Yes

Supports VPN multicast (per VRF)

Yes Yes Yes (Hub sourced only)

Direct data path for PE-PE Multicast traffic (vs. through a Hub)

Yes Yes No


Multi-Protocol Label Switching (MPLS) over L2 in the WAN


Key VirtualizationMechanisms overAn IP Infrastructure

MPLS: Key “WAN” Virtualization EnablerAllows Vast Network “Service” Capabilities over an IP Backbone

� Layer 3 VPN/SegmentationVPN (RFC 2547bis)Provides Any-to-Any connectivity

� Maximize Link Utilization with Selective Routing/Path Manipulation

Traffic EngineeringOptimization of bandwidth and protection using Fast-ReRoute (FRR)

� Layer 2 VPN/TransportAToM (Any Transport over MPLS) i.e. “pseudo-wire”Layer-2 transport: Ethernet, ATM/FR, HDLC/PPP, interworkingLayer-2 VPN: VPLS for bridged L2 domains over MPLS

� QoS CapabilitiesDiffserv, Diffserv aware Traffic Engineering (DS-TE)

� Bandwidth Protection ServicesCombination of TE, Diffserv, DS-TE, and FRR

� IP Multicast (per VPN/VRF)� Transport of IPv6 over an IPv4 (Global Routing Table) Infrastructure � Unified Control Plane (Generalized MPLS)


MPLS Label EncapsulationsApplicable to Using MPLS over Layer 2 Transport

LabelPPP Header Layer 2/L3 PacketPPP Header(Packet over SONET/SDH)

Label MAC Header Layer 2/L3 PacketLAN MAC Label Header

One or More Labels Appended to the Packet

MAC HeaderMAC Header Label 1Label 1 Label 2Label 2 IP HeaderIP HeaderLabel Stacking(LAN example)

Outer Label

Inner LabelL3 VPNL2 VPN


MPLS VPN Technology—RefresherMPLS VPN Connection Model

PE Routers� MPLS Edge routers� Uses MPLS to P routers� Uses IP with CE routers (L3)� Distribute VPN information through MP-BGP to other PE routers with VPN-IPv4 addresses, extended community, labels

P Routers� P routers are in the core of the MPLS cloud

� P routers do not need to run BGP

� Do not have knowledge of VPNs

� Switches packets based on labels (push/pop) not IP

PE VPN Backbone IGP

MP-iBGP – VPNv4 Label Exchange

PEP P

P PVRF Blue

VRF Green EBGP, OSPF, RIPv2, Static

CE

CEVPN 1

VPN 2

CE Routers� VRF Associates to one or more interfaces on PE

� Has its own routing table and forwarding table (CEF)

� VRF has its own instance for the routing protocol

(static, RIP, BGP, EIGRP, OSPF)

See Session on MPLS VPN Deployments - BRKMPL-2102

Global Address Space


MPLS VPN Technology—Refresher Control Plane – MP-BGP Components

Multi Protocol BGP Update Components� Route Distinguisher (RD); VPNv4 route� Route Target (RT)� Label

8 Bytes

Route-Target

3 Bytes

Label

MP_REACH_NLRI attribute within MP-BGP UPDATE message

1:1

8 Bytes 4 Bytes

RD IPv4VPNv4

10.1.1.0


MPLS VPN Technology—Refresher Control Plane

1. PE1 receives an IPv4 update (eBGP/OSPF/ISIS/RIP/EIGRP)2. PE1 translates it into VPNv4 address

Assigns an RT per VRF configurationRewrites next-hop attribute to itselfAssigns a label based on VRF and/or interface

3. PE1 sends MP-iBGP update to other PE routers

10.1.1.0/24 Next-Hop=CE-1

MP-iBGP Update:RD:10.1.1.0Next-Hop=PE-1RT=Green, Label=100

1

310.1.1.0/24

PE1 PE2P

P P

PCE2CE1

MPLS Backbone

Site 1 Site 2


MPLS VPN Technology—Refresher Control Plane

4. PE2 receives and checks whether the RT=green (40:103, say) is locally configured within any VRF, if yes, then

5. PE2 translates VPNv4 prefix back into IPv4 prefix, Installs the prefix into the VRF routing tableUpdates the VRF CEF table with label=100 for 10.1.1.0/24Advertise this IPv4 prefix to CE2 (using EBGP/RIP/OSPF/ISIS/EIGRP)

5

10.1.1.0/24 Next-Hop=CE-1

MP-iBGP Update:RD:10.1.1.0Next-Hop=PE-1RT=Green, Label=100

10.1.1.0/24

MPLS Backbone

Site 1 Site 210.1.1.0/24 Next-Hop=PE-2

PE1 PE2P

P P

PCE2CE1


10.1.1.0/24

PE1 PE2

CE2CE1Site 1 Site 2

10.1.1.1

P

P P

P

10.1.1.110050

MPLS VPN Technology—Refresher Forwarding Plane

� PE2 imposes TWO labels for each packet going to the VPN destination 10.1.1.1

� The top label is LDP learned and derived from an IGP routeRepresents LSP to PE address (exit point of a VPN route)

� The second label is learned via MP-BGP Corresponds to the VPN address

10.1.1.110.1.1.1100

10.1.1.110025


PE VPN Backbone IGP

MP-iBGP – VPNv4 Label Exchange

PEP P

P P

MPLS VPN over L2Configuration Example (IOS)

VRF Blue

VRF Green EBGP, OSPF, RIPv2, Static

CE

CEVPN 1

VPN 2

! PE routerrouter bgp 65100neighbor 192.168.100.4 remote-as 65100!address-family vpnv4neighbor 192.168.100.4 activateneighbor 192.168.100.4 send-community extendedexit-address-family!address-family ipv4 vrf blueneighbor 172.20.10.1 remote-as 65111neighbor 172.20.10.1 activateexit-address-family!address-family ipv4 vrf greenneighbor 172.20.20.1 remote-as 65110neighbor 172.20.20.1 activateexit-address-family

! PE Router – Multiple VRFsip vrf bluerd 65100:10route-target import 65100:10route-target export 65100:10

ip vrf greenrd 65100:20route-target import 65100:20route-target export 65100:20

!interface GigabitEthernet0/1.10ip vrf forwarding blue

interface GigabitEthernet0/1.20ip vrf forwarding green

VRF Configuration (PE) MP-iBGP Configuration (PE)


MPLS VPN over L2Summary and Deployment Targets� Targets large-scale VRF’s and customers wanting control!

� Leverages standard based L2 transports (no overlay)� Target customers usually function as an “internal

Service Provider” for their company/agency� Allows full deployment of MPLS services

L2 VPN, QoS, Multicast, IPv6, MPLS TE, TE-FRR� Offers tight control for QoS Service Level requirements� Offers rapid deployment for virtualization “turn up”� Extremely scalable but requires a higher level of

Operational expertise


MPLS VPN over IP


Why Do We Need MPLS over IP?� Not all networks are MPLS

MPLS has not yet been deployed in the networkSP/Enterprise wants to turn a service on at the edge and no MPLS labeled service exists

� Transit over IP islandsSome networks not owned by Enterprise but service is neededIP VPN Service is only offering available (vs. L2)

� Extend MPLS Services over any IP TransportDesigner can utilize any “IP” transport that existsLeverage internet “reach” for access outside controlled area

In summary, the ingress and egress PE routers themselves supportMPLS, but transit routers do NOT need to support MPLS labels for forwarding. (Source: RFC 4797)


GRE (RFC 2784) with GRE+MPLS (RFC 4023)Packet Format

Original IP header IP payloadGRE headerNew IP header20 bytes 20 bytes4 bytes

GRE packet with new IP header:protocol 47 (forwarded using new IP dst)

Original IP header IP payload20 bytes

Original IP datagram (before forwarding)



Protocol Type (MPLS over GRE)Unicast: 0x8847Multicast: 0x8848

Protocol Version Number: 137Indicates an MPLS unicast packet


New IP header GRE Header

IP payload

GRE Tunnel Format with MPLS(Reference: RFC 4023)

20 bytes

Original IP header

Original MPLS/IP datagram (before forwarding)

Ethertype in the Protocol Type Field will indicatean MPLS label follows

VPN LabelTunnel LabelL2 Header

IP payloadOriginal IP header

20 bytes4 bytes

VPN LabelL2 Header

� MPLS Tunnel label (top) is replaced with destination PE IP address� Encapsulation defined in RFC 4023� Most widely deployed form of MPLS over GRE tunnels

VPN Label is signaled via MP-BGP . This is normal MPLS VPN control plane operation.

MPLS/IP datagram over GRE (after forwarding)


MPLS VPN over GRE Control Plane

� C-PE1 receives an IPv4 update (eBGP/OSPF/ISIS/RIP/EIGRP)� C-PE1 translates it into VPNv4 address� C-PE1 sends MP-iBGP update to other PE routers� C-PE2 receives and checks whether the RT=green (40:103, say) is locally configured within any VRF, if yes, then

� C-PE2 translates VPNv4 prefix back into IPv4 prefix, � All done over the GRE tunnel (point to point or DMVPN scenario)

10.1.1.0/24 Next-Hop=CE-1

MP-iBGP Update:RD:10.1.1.0Next-Hop = c-PE-1RT=Green, Label=100

10.1.1.0/24

C-PE1 C-PE2

CE2CE1

Customer MPLS overlay

Site 1 Site 2

IPv4 Cloud

MPLS/LDP over GRE Tunnel


10.1.1.0/24C- PE1

C-PE2

CE2CE1Site 1 Site 2

10.1.1.1

MPLS VPN over GREForwarding Plane

� c-PE2 normally imposes two labels for each packet going to the VPN destination 10.1.1.1, (1) top IGP derived label (2) VPN label

For MPLS over GRE Encapsulation Case…� The top label is replaced with an IP Tunnel Header to the destination of c-PE1� The 2nd label (inner) is the VPNv4 address learned via MP-BGP via GRE tunnel � On c-PE1, the GRE header is removed, exposing the VPN label for forwarding� From each c-PE view, the PE-PE connection is an implicit null (penultimate hop)

MPLS/LDP over GRE Tunnel

IPv4 Cloud

Internal PoP viaDe-encapsulatingOuter GRE Header

10.1.1.1100

10.1.1.1100C-PE1 IP

10.1.1.1


Data Center/HQ

MPLS over Point-to-Point GREMPLS over L3 Service Offering (Requiring IP Encapsulation)

� Tunnels carry:LDP, IGP and MP-BGP (VPNv4)

� Tunnel configuration is manual (no signaling)

� Supports all existing MPLS features (L2/L3 VPN, etc…)

� “Swiss Army Knife” of MPLS over GRE Transport ☺

� Ideal in core where smaller number of locations exist

PE

RemoteBranches

Single GRE tunnel

running LDP IPTranspor

t

SharedVRF

Campus

RR

C-PEC-PE

C-PE


Branch LAN

802.1q trunkPhysical cable

IP/MPLS/LDPand VPNv4

over GRE Tunnel

Internet


C- PE1 C-PE2

CE2CE1Site 1 Site 2

MPLS VPN over Point-to-Point GREExample is MPLS over point-to-point GRE tunnel

IPv4 CloudMPLS/LDP over GRE Tunnel

10.100.1.201 10.100.1.204

TunnelSrc: 172.16.1.2DST: 172.16.2.2IP addr: 10.0.0.198.98.98.98 99.99.99.99

ip vrf greenrd 1:1route-target export 1:1route-target import 1:1!mpls label protocol ldp!interface Tunnel0ip address 10.0.0.1 255.255.255.0ip mtu 1400mpls iptunnel source 172.16.1.2tunnel destination 172.16.2.2tunnel path-mtu-discovery!interface Loopback0ip address 10.100.1.201 255.255.255.255!

router eigrp 1network 10.0.0.0no auto-summary!router bgp 65000bgp router-id 10.100.1.201no bgp default ipv4-unicastbgp log-neighbor-changesneighbor 10.100.1.204 remote-as 65000neighbor 10.100.1.204 update-source Loopback0!address-family vpnv4neighbor 10.100.1.204 activateneighbor 10.100.1.204 send-community extendedexit-address-family!

Enables MPLS/LDP over GRE

Important: You must force the forwarding of the BGP next-hop over the GRE tunnel

Using 10.0.0.0/8 address space Forces Loopback 0 learning over GRE Tunnel


MPLS and MPLS-VPN over IP/GREOther Deployment Model Options

PEPE

MPLS VPN over IP PEPE

PE – to – PE

PEPE PPMPLSover IP

PE – to – P

PPMPLSover IPPP

P – to – P

PPMPLSPP

MPLS over IP

MPLS over IP

PEPE

PEPE

Hybrid – MPLS/IP

Common Enterprise Deployment


MPLS VPNs overMultipoint GRE (mGRE)


Data Center/HQ

MPLS over Dynamic Multipoint VPN (DMVPN)MPLS VPN over a DMVPN Framework

PE

RemoteBranches

Single mGRE tunnel

running LDP IPTranspor

t

SharedVRF

Campus

RR

C-PEC-PE

C-PE


Branch LAN

802.1q trunkPhysical cable

MPLS/LDPand VPNv4

over mGRE Tunnel

� Allows MPLS VPN to leverage a DMVPN framework

� Leverages NHRP for dynamic endpoint discovery

� Data path for spoke-to-spoke data transits the Hub (“P” function)

� QoS uses typical “best-practices”� Multicast replication is done at the Hub (even is source is at spoke)

� Solution is operational in customer networks today

Internet

This Topic Is Covered in Detail in the “DMVPN Session” BRKSEC-4012


Data Center/HQ

MPLS VPN over Multipoint GRE (mGRE)MPLS VPNs over Multipoint GRE Using BGP for End Point Discovery

� Offers MPLS-VPN over IP� Uses standards-based RFC 2547 MP-BGP control plane

� Offers dynamic Tunnel Endpoint Discovery via BGP

� Requires only a single IP address for transport over SP network

� Reduces configuration tasks and requires NO LDP, NO GRE conf

PE

RemoteBranches

Multipoint GRE

interfaceIP

Transport

SharedVRF

CampusInternet

RR

C-PEC-PE

C-PE

Branch LAN802.1q trunk

VPNv4 labelover mGRE encapsulation



IPv4 VPNService

MPLSCampus/MAN

c-PEBranch Site

BGP/static BGP/staticRouting to SP

MPLS VPN over Multipoint GRE (mGRE)Control Plane

� Leverages SP IP transport while overlaying self deployed MPLS� MP-iBGP neighbors are established over SP VPN cloud� i-BGP used to:

Advertise VPNv4 routes, exchange VPN labels, and learn tunnel end-points� E-BGP used to exchange routes with SP

IGP, LDP

mGRE

RR

Enterprise Routing

mGRE

c-PE

iBGPVPNv4 Routes Advertised via BGPVPN Labels Exchanged via BGP

Tunnel Endpoints Learned via BGP

mGRE iBGP


eBGP

AS 65000172.16.1.1

MPLSCampus/MAN

c-PE 4Branch Site


� 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 4 for e-BGP appears as CE to the SP� C-PE 4 for i-BGP functions as a PE in supporting MPLS-VPN over mGRE

RRc-PE

mGRE iBGP

SP CloudAS 1

MPLS-VPN over mGRE Overlay(AS 65000)

Service Provider IP Service (eBGP)

(AS 1)


eBGP

AS 65000172.16.1.1

MPLSCampus/MAN

c-PEBranch Site


RRc-PE

mGRE iBGP

SP CloudAS 1

Interface Loopback0ip address 10.100.1.201 255.255.255.255router bgp 65000no bgp default ipv4-unicastbgp log-neighbor-changesneighbor 10.100.1.204 remote-as 65000neighbor 10.100.1.204 update-source Loopback0neighbor 172.16.1.1 remote-as 1neighbor 172.16.1.1 update-source Ethernet0/0!address-family ipv4no synchronizationredistribute connected metric 1neighbor 172.16.1.1 activateno auto-summaryexit-address-family!address-family vpnv4neighbor 10.100.1.204 activateneighbor 10.100.1.204 send-community bothneighbor 10.100.1.204 route-map mgre_v4 inexit-address-family

eBGP peer to SP

Address family for eBGP to SP

iBGP peer for MP-BGP (VPNv4)

Address family for MPLS-VPN over IP (i-BGP)


MPLS VPN over Multipoint GRE (mGRE)Feature Concept

� mGRE is a multipoint unidirectional GRE tunnel� Control Plane is based on RFC 2547 using MP-BGP

Signaling VPNv4 routes, VPN labels, and tunnel endpoints� VPNv4 label and VPN payload is carried in mGRE tunnel encap� New encapsulation profile in CLI offers dynamic endpoint discovery:

(1) Sets IP encapsulation for next-hop, (2) Installs Rx prefixes to tunnel� Solution does NOT require manual GRE interfaces or the configuration of LDP on any interface(s)

IPService

PE1

PE2 PE3

PE4

PE5PE6

172.16.255.4

172.16.255.3172.16.255.2

172.16.255.1

172.16.255.5172.16.255.6

MultipointGRE Tunnel (mGRE)1

12

mGRE encapsulation of VPNv4 label + VPN payload3

Tunnel Endpoint

172.16.255.6172.16.255.5172.16.255.3172.16.255.2172.16.255.1

View for PE 44

34

2


interface Loopback0ip address 10.0.0.4 255.255.255.255!l3vpn encapsulation ip Vegas

transport ipv4 source Loopback0protocol gre key 123456

!router bgp 100. . . address-family vpnv4neighbor 10.0.0.1 activateneighbor 10.0.0.1 send-community extendedneighbor 10.0.0.1 route-map mgre_v4 inexit-address-family. . . ! route-map mgre_v4 permit 10set ip next-hop encapsulate l3vpn Vegas

MPLS VPN over Multipoint GRE (mGRE)(Configuration Example)

CE2PE1 PE4

eBGP eBGP

IPv4 Cloud

Lo0: 10.0.0.1 Lo0: 10.0.0.4

Target Address

Apply route-map to received advertisement from remote iBGP neighbor

Sets mGRE encapsulation “profile” for BGP next-hop(gre key support per platform)

Use IP encap (GRE) for next-hop and install prefix in VPN table as connected tunnel interface

CE1

10.0.9.9

Example for PE4


MPLS VPN over mGRETunnel Endpoint Database Creation

CE2PE1 PE4

eBGP eBGP

IPv4 Cloud

Lo0: 10.0.0.1 Lo0: 10.0.0.4

Target Address

CE1

1. Incoming MP-BGP update from PE1 to PE42. PE4 applies update to INCOMING route-map “mgre_v4”3. This sets the use of “transport tunnel” (i.e. GRE) when

forwarding to peer of 10.0.0.14. Route-map also extends “L3vpn encapsulation ip” for PE4 to

set the “source” of “loopback 0” for updates to other BGP peers5. Remote peers participating also configured with exact

command set

MP-BGP Update



Data Center/HQ

PE

SharedVRF

Internet


Campus

IPv4 VPNService

Branch Site

MPLS VPN over Multipoint GRE (mGRE)Data Plane

� Only a single IP address is required out of each PE for PE-PE communication (options: loopback, interface facing PE, etc…)

� No LDP or RSVP-TE is required for label distribution� mGRE interface provides “encapsulation” that is tunneless� mGRE is automatically enabled with “l3 encapsulation ip” command

mGRE

IP IP

GREVPN

IP

IP outerGREVPN

SP VPNSP LDP

IP

IP outerGREVPN

IP

c-PE

iBGP

Address used by iBGP and sent to SP

for transportIP outer

eBGPeBGP


MPLS VPN over Multipoint GRE (mGRE)Summary and Configuration Notes� Solution requires only a single IP address to SP for PE-PE operation

� Solution leverages standard MP-BGP control plane (RFC 4364)� Tunnel endpoint discovery is done via i-BGP� E-BGP can/is still used for route exchange with the SP� Solution does not requires NO GRE tunnel configuration or LDP� Supports multicast and IPv6 per MPLS VPN model (MDT and 6vPE)

� Platform SupportToday: 7600 – 12.2(33)SRERoadmap: ASR 1000 (2H-2010), ISR – 15.2(1)T (target release), high-end routers in discussion

Branch LAN

VPNv4 labelover mGRE encapsulation


MPLS VPN over GRE SolutionsComparison Matrix

MPLS VPN over mGRE

MPLS VPN over DMVPN

MPLS VPN over P2P GRE

Offers large scale MPLS VPN over any IP transport

Yes (> 8 VRFs) Yes (> 8 VRFs) Yes (> 8 VRFs)

Uses Dynamic Endpoint Discovery

Yes (BGP) Yes (NHRP) No

Avoids manual full-mesh GRE configurations (mGRE)

Yes Yes No

Ability to hide global addresses used for transport

No Yes Yes

Requires LDP over tunnel No Yes Yes

Direct data path for PE-PE traffic (vs. through a Hub)

Yes No Yes

Supports MVPN multicast Yes Yes Yes

Supports IPv6 VPN (6vPE) Yes No Yes


Cisco L3 VirtualizationPlatforms and Feature Support for WAN and Branch

Cisco ISR Cisco 7200 ASR 1000 Catalyst

6500 Cisco 7600

VRF Lite X X X X X

VRF Lite over GRE X X X X X

VRF Lite over DMVPN X X X X X

MPLS-VPN X X X X X

MPLS VPN over GRE (P2P) X X X X (SIP-400,

ES+)X (SIP-400,

ES+)MPLS VPN over DMVPN (mGRE) X X X X (SIP-400,

ES+)X (SIP-400,

ES+)MPLS VPN over mGRE (BGP)

R (Q3’10) X R (2H’10) R (Q1’11) X (SIP-400,

ES+)

PlatformFeature

X = Supported Today R = Roadmap








QoS in a Virtualized WAN


QoS with GRE, MPLS over GREToS Reflection

� 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

IP PayloadGRE Original IP HeaderOuter GRE IP HeaderGRE Header

ToS (IP Hdr) � EXP (MPLS Shim) � GRE IP Hdr

IP PayloadOriginal IP HeaderToSGREEXP MPLS

ShimOuter GRE IP HeaderToS

MPLS over GRE Header w/ ToS Reflection

MPLSShimEX

P

IP PayloadGRE Original IP HeaderToSOuter GRE IP HeaderToS

ToS (IP Hdr) � GRE IP HdrGRE Header w/ ToS Reflection


QoS Deployment Models in a Virtualized Environment� Aggregate ModelA common QoS strategy is used for all VRFs

i.e. same marking for voice, video, critical data, best effortThe aggregate of all markings is applied at the WAN Agg� Prioritized VRF ModelTraffic in some VRFs are prioritized over other VRFs (i.e. Production over Guest VRF)

QoS is Orthogonal to VirtualizationThe same approach should be used for a typical enterprise network design as a virtualized network


QoS Models

� Connection oriented service� Logical and physical connections� Logical could be a GRE tunnel� Point-to-point connection guarantees

VRF-Lite over P2P GREMPLS VPN over P2P GRE* VRF-Lite over DMVPN* 2547 over DMVPN

Remote Sites

CentralSite

CentralSite

Point-to-Cloud

Remote Sites

Point-to-Point

Serial 0

� No point-to-point (site-to-site) guarantees� Any site can transmit up to ICR into the

cloud� Any site can receive up to ECR from the

cloud� SLA offers guarantees for conforming

traffic– MPLS VPNs over mGRE

Virtual Links

ICR

ECR

ICR – Ingress Committed RateECR – Egress Committed Rate

* Using per tunnel QoS


Typical QoS Deployment – with/with-out Network VirtualizationPoint to Cloud Model

Branch 1

Campus

WANEdge

Branch 2

Branch 3

SiSi

SiSi

Classify and mark traffic at edge

IP VPNService

Voice

ScavangerBest EffortVideo

PhysicalAccess Lines ICR

1M

ECR2M

ECR – Egress Committed RateICR – Ingress Committed Rate

Green VRF

Red VRF

Green VRF

Red VRF

Green VRF

Red VRF

Green VRF

Red VRF

Relevant QoS model for customers Connecting to a IP VPN Service

Traffic is Queued, Shaped according to DSCP Values and branch destination

Voice




Typical QoS Deployment – Point to PointPoint-to-point Example (VRF over GRE): 2-Level Hierarchical QoS

Branch 1

CampusWANInt

Branch 2

Branch 3

SiSi

SiSi


Green VRF

Red VRF

Green VRF

Red VRF

Green VRF

Red VRF

Green VRF

Red VRF

Traffic is Queued, Shaped according to DSCP Values

Traffic marking is identical across VRFs (e.g. all Voice traffic uses same DSCP/ToS)

WAN

GRE Tunnel per VRF

Voice


� 1st Layer – GRE Tunnel (Parent)Shaper per GRE

� 2nd Layer - Service Queuing per GRE (child)Queuing determines order of packets sent

� Hierarchy applied on a per GRE tunnel (ASR1K)


QoS for Virtualization – Summary

� Aggregate QoS model is the simplest and straight forward approach – Recommended� Prioritized VRF model can be used to prefer

traffic originating in one VRF over another(e.g. guest access)

� The same QoS approach should be used for a non-virtualized and virtualized enterprise network design


MTU Considerationsin a

Virtualized WAN


MTU Considerations with GRE TunnelsIssues

� Fragmentation is unavoidable in some cases� The use of GRE tunnels increase the chances of MTU issues because of the increased size of the IP packet

� There can be a performance impact on the router when the tunnel destination router must re-assemble GRE headersPerformance impact includes packet re-assembly of fragmented packets

� Common Cases:Customer does not control IP path, and segment has MTU less that max packetRouter generates an ICMP message, but the ICMP message gets blocked by a router or firewall (between the router and the sender)

MTU=1000MTU=1500MTU=1500 MTU=1500 MTU=1500

S CR1 R2 R3 R4

MTU=1500MTU=1500--24=147624=1476

X


Path MTU Discovery (PMTUD) & GREMTU=1000MTU=1500MTU=1500 MTU=1500 MTU=1500

S CR1 R2 R3 R41. R1 needs to fragment but original IP

has DF=12. R1 sends ICMP unreachable to S

1. Upon receive of ICMP unreachable, S will send maximum 1476 bytes

2. 2nd IP packet is 1476 bytes long

GRE packet is too large and is further fragmented (DF=0)

1. R4 reassembles to reconstruct the GRE packet (R4 is the destination of GRE packets)

2. GRE packet is decapsulated3. The original IP datagram is forwarded

MTU=1500MTU=1500--24=147624=1476

IP L= 1500 DF = 1

IP L= 1476 DF = 1GR E L<=1500 D F=0

GR E L<=1000 D F=0IP L= 1476 DF = 1

IC M P M T U = 1476


MTU RecommendationsPoint to Point GRE�Avoid fragmentation ☺ (if at all possible)�Consider “tunnel path-mtu-discovery” command to allow the GRE interface to set its IP MTU dynamically

�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 hosts�MTU Setting options:

�Setting the MTU on the physical interface larger than the IP MTU

�Set IP MTU to GRE default (1476) + MPLS service label (4)

� Best to fragment prior to encapsulation, than GRE packet frag/reassembly

interface Ethernet 1/0. . .mtu 1500

interface Tunnel0. . .ip mtu 1472

Useboth


MTU RecommendationsMultipoint GRE�Multipoint GRE (mGRE) interfaces are “stateless”� “tunnel path-mtu-discovery” command is not supported on mGRE interfaces (defaults to DF=1 for MPLS VPN o mGRE)

�For the MPLS VPN over mGRE Feature, “ip mtu” is automatically configured to allow for GRE + MPLS VPN label overhead (4-bytes)

�Configure ip tcp adjust-mss for assist with TCP hosts�MTU Setting options:

�Setting the MTU on the physical interface larger than the IP MTU� Best to fragment prior to encapsulation, than GRE packet frag/reassembly

interface Tunnel 0. . .Tunnel protocol/transport multi-GRE/IP

Key disabled, sequencing disabledChecksumming of packets disabled

Tunnel TTL 255, Fast tunneling enabledTunnel transport MTU 1472 bytes

IP MTU Technical White Paper:http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

IP MTU defaults to 1472 when MPLS VPN over mGRE is used


Campus-to-WAN Virtualization Interconnect


Campus-to-WAN InterconnectionInterconnect Virtualization Policy WAN �� Campus

� Requirement is needed to integrate and connect the virtualization model between the campus and WAN

� Several options exist� Solution chosen evaluates scale and complexity� No solution is a one-size-fits-all

WANASBR

Distribution Blocks

SiSiSiSiSiSiSiSi

SiSi

SiSi SiSi

SiSi

C-PE 3

C-PE 2 AS 1(iBGP)

C-PE 3

C-PE 4

C-PE x

L3/L2WANService

mGREInterface

Extend Virtualization

Campus

GRE Tunnel

CampusASBR

WAN supporting MPLS VPN or VRF-Lite

Campus Running MPLS VPN or VRF Lite


Campus-to-WAN InterconnectionInter AS Option A (Back to Back VRF’s)

� One logical interface per VPN on directly connected ASBRs� Packet is forwarded as an IP packet between the ASBRs� Link may use any supported PE-CE routing protocol � Option A is easiest to provision and least complex� Considered when VRF count is low (~ < 8)

WANASBR

Distribution Blocks

SiSiSiSiSiSiSiSi

SiSi

SiSi SiSi

SiSi

C-PE 3

C-PE 2 AS 1(iBGP)

C-PE 3

C-PE 4

C-PE x

L3/L2WANService

mGREInterface

Unlabeled IP Packets

Campus

GRE Tunnel

CampusASBR

WAN Running MPLS BGP VPNs over mGRE

Campus Running VRF Lite

VRF Lite


Campus-to-WAN InterconnectionInter AS Option B (Medium/Large VRF Deployments)

� ASBRs exchange VPN routes using eBGP� ASBRs hold all VPNv4 routes needing exchange� Dedicated ASBR added in Campus� Recommended when VRF count is higher ( ~ >8)� More complex that Option A, but more flexible

WANASBR

Distribution Blocks

SiSiSiSiSiSiSiSi

SiSi

SiSi SiSi

SiSi

C-PE 3

C-PE 2

C-PE 3

C-PE 4

C-PE x

L3/L2WANService

mGREInterface

Campus

GRE Tunnel

Campus Running 2547

AS 1(iBGP) eBGP for VPNv4

Labels Exchangedbetween WAN & CampusASBR Routers Using eBGP

CampusASBR

AS 2(iBGP)P

Inter-AS MPLS Solution covered in Session BRKMPL-2105

WAN Running MPLS BGP VPNs over mGRE


Campus/WAN InterconnectRecommendations� < 8 VRF’s Back to Back VRF’s (Option A)

VRF lite in the campusBack to Back VRFs with a single AS between Campus and WANLow VRF count network-wide

� ~8 – 15 VRF’s Back to Back or Inter AS (Option B)VRF-Lite or RFC 4364 running in the CampusDedicate ASBR router in the campus (Core router/switch) to peer to WANSolution choice dictated by customers operational expertise, change frequency

� ~ > 15 VRF’s Inter-AS (Option B)RFC 4364 running in the CampusDedicate ASBR router in the campus (Core router/switch) to peer to WAN Inter-AS option “B” recommended

WAN extension solution (i.e. options discussed in this presentation) could also dictate choice of Inter-AS solution


Shared Services in a Virtualized WANServices that you don’t want to duplicate:

� Internet Gateway� Firewall and NAT - DMZ� DNS� DHCP� Corporate Communications - Hosted Content

Requires IP Connectivity between VRFsThis is usually accomplished through some type of Extranet Capability or Fusion Router/FWBest Methods for Shared ServicesFusion Router/FW – Internet Gateway, NAT/DMZExtranet – DNS, DHCP, Corp Communications


Data Center/HQ

PE

SharedVRF

Internet


Campus

WAN


Sharing ServicesRoute Import/Export between VRFs

� Provides access to services without requiring traffic to be enforced through the firewall front-ending each VPN

� Useful for sharing specific services (DHCP and DNS servers, for example)Services commonly deployed in a dedicated Shared VPNNot recommended to provide inter-VPN communication

� Leverage the BGP route-target mechanism for route leakingNo support for overlapping IP addresses across VPNs


Unprotected Services - Extranet Configuration

ip vrf Sharedrd 3:3route-target export 3:3route-target import 1:1route-target import 2:2

ip vrf Redrd 1:1route-target export 1:1route-target import 3:3

SiSi

SiSi SiSi

MP-BGP MP-BGP

PE2 PE3

PE1

PC Red PC Green

Shared Server

ip vrf Greenrd 2:2route-target export 2:2route-target import 3:3

MP-BGP


Unprotected Services - Extranet Verification

SiSi

SiSi SiSi

MP-BGP MP-BGP

PE2 PE3

PE1

PC Red10.137.12.0/24

PC Green10.137.22.0/24

Shared Subnet10.138.32.0/24

PE2#sh ip route vrf Red 10.138.32.0Routing entry for 10.138.32.0/24

Known via "bgp 100", distance 200, metric 0Last update from 192.168.100.100 00:29:47 ago

<snip>PE2#sh ip route vrf Red 10.137.22.0% Subnet not in table

PE3#sh ip route vrf Green 10.138.32.0Routing entry for 10.138.32.0/24


<snip>PE3#sh ip route vrf Green 10.137.12.0% Subnet not in table

Shared Server

PE1#sh ip route vrf Shared 10.137.12.0Routing entry for 10.137.12.0/24


<snip>PE1#sh ip route vrf Shared 10.137.22.0Routing entry for 10.137.22.0/24


<snip>

MP-BGP


Agenda� Network Virtualization Drivers and Building Blocks� Enterprise WAN Deployment Considerations� Deployment Solutions for a Virtualized WAN� Deployment Considerations and Caveats in a Virtualized WAN� Virtualized WAN Case Study� Summary


Case Study #1 – VRF Lite over GREExtending IP Virtualization from Branch to HQ

� Problems/Challenges3 different organizations at each branch within the same companyEach organization uses their own router/switch up to WAN aggregation router (internal IT owned)Refresh has become costlyDedicated routers only serve the purpose of segmentation (limited use for private policies per organizationAll require QoS (VoIP throughout company)

Data Center/HQ

VRF-Lite or MPLSVPN in

CampusPE

RemoteBranches

Multi-VRF CE

GRE tunnel per

VRF L2 or IPTransport

SharedVRF

Campus

C-PEC-PE

C-PE

Internet

� WAN Virtualization Solution ChosenUse VRF-lite over point-to-point GRE tunnels (3 VRF’s) aggregated at WAN edgeConsolidate each organization into a single “PE”router for WAN aggregation


Case Study #1 – VRF Lite over GREExtending IP Virtualization from Branch to HQ

� How solution solved the problemDeployment consolidates VRF technology on a single WAN edge routerEach org will manage their own L2/L3 switch (3750), uplinked to WAN edge

� Rational for chosen SolutionSmall number of VRF’s allows use of VRF-liteNot much in-house MPLS/BGP expertiseGRE allows overlay through IP VPN service (MPLS VPN used by SP)Can leverage company QoS model (only 3 queues used today)no increase of VRF count forseen

� Benefits of the Solution3:1 cost reduction for HW per branch (upgrade within normal refresh cycle)Each org still manages their own user domain with 3750’sIT group mandates QoS markings to org (matched with SP offering)IT group demarcation is up to 3750


Case Study #2 – MPLS VPN over mGREExtending Service demarcation to Branch

� Problems/ChallengesCompany IT manages a large amount of network services in-house and serves as “mini-SP” in orgServices include transport, security, web, Internet, WAN services for all organizationsMust offer L2 and L3 VPNsTraffic patterns for some agencies are any to anyCustomers exceed ~20 (20 VRFs needed)All require QoS (VoIP throughout company)WAN service to Branch is private IP VPN service

Data Center/HQ

PE

RemoteBranches

Multipoint GRE

interfaceIP

Transport

SharedVRF

CampusInternet

RR

C-PEC-PE

C-PE

VRF-Lite or MPLSVPN in

Campus

CORE MPLSBackbone

� WAN Virtualization Solution ChosenMPLS VPN over mGREMPLS VPNs between core sites for new requirementFull MPLS VPN network running in the core today for DC interconnect


Case Study #2 – MPLS VPN over mGREExtending Service Demarcation to Branch� How solution solved the problem

Deployment of MPLS VPN o mGRE allowed full MPLS VPN any to anyAllows MPLS VPN over the SP IP VPN service, allow any-to-anyAllows virtualization, QoS, multicast (future)Leverage Inter-AS for interconnect of MPLS VPN networks (different AS’s)

� Rational for chosen SolutionNumber of VRF’s planning to grow within the companySolid in-house MPLS/BGP expertise but solution reduces complexitySolution eliminates manual GRE tunnels, dynamically discovers end-points, and does not require LDP control planeASR 1000 will integration of solution with Group Encryption Tech (GET)

� Benefits of the SolutionSupported on broad platform set (ISRs, ASR 1000, 7600)Greatly simplifies overall configuration normally needed with GRESolution leverages QoS offering from SP to carry QoS SLA’s over IP VPNIntegrates well with existing MPLS VPN networks using Inter-AS


Agenda� Network Virtualization Drivers and Building Blocks� Enterprise WAN Deployment Considerations� Deployment Solutions for a Virtualized WAN� Deployment Considerations and Caveats in a Virtualized WAN� Virtualized WAN Case Study� Summary


WAN Virtualization—Key Takeaways� The ability for an enterprise to extend Layer 3 (L3) virtualization technologies over the WAN is critical for today’s applications

� MPLS service capabilities (VRF, MPLS VPN) is key to scalable L3 VPN extension to remote branch/WAN sites

� The ability to transport MPLS over IP allows flexible transport options given the growth of IP VPN service offerings

� Understanding key network elements (topology, traffic patterns, VRFs, scale, expansion) is vital to choosing the best solution for extending virtualization over the WAN

� Innovation for MPLS VPN over mGRE allows simpler deployment that reduces the need for LDP and manual GRE tunnel configs

� Understand the options for QoS and Inter-AS between WAN and campus, and impact of MTU when using GRE tunnels

� Leverage the technology but “Keep it Simple” when possible ☺


Reference Sessions� BRKCRS-2033 - Deploying a Virtualized Campus Network Infrastructure� BRKDCT – Overlay Transport Virtualization� BRKMPL-2102 – Deploying IP/MPLS VPNs� BRKSEC-4012 – Advanced Concepts of Dynamic Multipoint VPN (DMVPN)� BRKDCT-2840 - Data Center Networking: Taking Risk Away from Layer 2 Interconnects� BRKMPL-2105 – Inter-AS MPLS Solutions
