Deploying a Virtualized Campus Network Infrastructure

BRKCRS-2033

Deploying a Virtualized Campus Network Infrastructure

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

Cisco Live & Networkers VirtualSpecial Offer Save $100Cisco Live has a well deserved reputation as one the industrys 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.


Agenda What Is Network Virtualization? What are the Virtualization Components? How can you Deploying Network Virtualization in the Campus?

How do you Extend VRFs Across the MAN/WAN? What are some Additional Virtualized Services? Q&A


Before Network Virtualization (BNV)Problem Definition

Everything is both physically and logically connected Guest/partner access All departments Telephony systems Building control and video surveillance

Security Policies are difficult to implement HIPAA/PCI compliance

Service differentiation is almost impossible! The same application on different

VLANs

Resources

Dept A Partner Guest

Internet

Dept B


After Network Virtualization (ANV)Problem Solution

Groups and services are logically separated Guest/partner access Departments Telephony systems Building control and video surveillance

Security Policies are unique to each virtual group/service HIPPA/PCI compliance

Service differentiation is configured per group/service The same application can be unique

per group/service

Resources


Internet

Dept B


Guest Access

Virtual Network

Network VirtualizationCreation of Logical Partitions Virtualization: one-to-many (one network supports many virtual networks) End-user perspective is that of being connected to a dedicated network

(security, independent set of policies, routing decisions) Must have a rock-solid campus design in place before adding virtualization to the

network

Actual Physical Infrastructure

Virtual Network

Merged Company

Virtual Network

Segregated Department


Agenda What Is Network Virtualization? What are the Virtualization Components? How can you Deploying Network Virtualization in the Campus?



Network Virtualization Functional Architecture

Access Control Path Isolation Services EdgeWAN MAN Campus

Functions

Branch Campus Data Center Internet Edge Campus

VRFs

GRE MPLS

Authenticate client (user, device, app) attempting to gain network access

Authorize client into a partition (VLAN)

Deny access to unauthenticated clients

Maintain traffic partitioned over Layer 3 infrastructure

Transport traffic over isolated Layer 3 partitions

Map Layer 3 isolated path to VLANs in access and services edge

Provide access to services

SharedDedicated

Apply policy per partition Isolate application

environments if necessary

Service

Internet


Access Control Authentication, Authorization

AuthenticationWho/what is requesting access?

Holistic controlClient-based, infrastructure integrated 802.1XUser-based controlClientlessWeb authenticationDevice-specific controlMAC-address basedStatic controlPhysical security

AuthorizationWhere/how is the access granted?

Allow access to the network from a particular VLAN

Edge Access Control

Resources


Internet

Dept B


Path IsolationFunctional Components

Device virtualizationControl plane virtualizationData plane virtualizationServices virtualization

Data path virtualizationHop-by-Hop(VRF-Lite End-to-End)Multi-Hop(VRF-Lite+GRE, MPLS-VPN)

VRFVRF

Global

IP802.1q

VRF: Virtual Routing and Forwarding

Per VRF:Virtual Routing TableVirtual Forwarding Table


Services EdgeSharing Services Between VPNs

Services usually not duplicated per group Economical Efficient and manageable Policies centrally deployed

Blue VPN

Green VPN

Red VPN

Resources

Campus Core

Red User

Shared Resource

Green UserBlue User

Internet/Shared

Internet Gateway

IPSecGateway

DHCP

Video ServerFirewall and NATHosted Content

Shared for All Groups:


Agenda What Is Network Virtualization? What are the Virtualization Components? How can you Deploying Network Virtualization in the Campus?Access ControlPath IsolationServices Edge



Access ControlGeneral Design Considerations

The end goal is to provide differentiated access to various entities independently from the client specific characteristics

Wired or wireless Managed or unmanaged

VLAN assignment is the current mechanism to associate a session to a logical segment

Subsequent mapping between edge VLANs and L3 VPNs to extend logical isolation end-to-end across the campus network

Access Control Path Isolation Services EdgeWAN MAN Campus Branch Campus Data Center Internet

Edge Campus

VRFs

GRE MPLS

Internet


Access ControlWired Clients Static VLAN Assignment

Lack of mobility, risk of unutilized ports, less secureUsually applicable to the initial phase of NV deployment

Dynamic VLAN AssignmentCisco NAC ApplianceIdentity Technologies (802.1X, MAC-Auth Bypass, etc.)Web-base proxy-authentication with VLAN assignment

For More Discussion on Campus NAC Appliance Design: BRKSEC-2041For More Discussion on Campus 802.1X Deployment: BRKSEC-2005


Access ControlCisco WLAN Controller Deployments

**CAPWAP: Control And Provisioning of Wireless Access Points protocol

For More Discussion on WLAN Design Principle: BRKEWN-2010

*SSID: Service Set IDentifier

CAPWAP CAPWAPCore Network

Green BlueRed Green BlueRed

Green VLANGreen VLANRed VLANRed VLAN BlueVLAN

BlueVLAN

CAPWAP** encapsulates original Ethernet frames and transport them across L3 boundaries

Same CAPWAP tunnel used for data traffic of different SSIDs

Data traffic bridged by WLAN controller on a unique VLAN corresponding to each SSIDAlternatively, users associating with a common SSIDs can be assigned to separate VLANs leveraging 802.1X authorization

Use of CAPWAP and VLANs logically isolate traffic for different users

Wireless users associate to an access point by using a specific SSID*

SSID may have a unique authentication method


Internet

DC or CampusServices Block

Access ControlSummaryWired and Wireless Clients

Traffic isolation achieved via CAPWAP and VLANs is valid from the AP to the WLAN controller (centralized deployment is recommended)

The Challenge Extending logical isolation end-to-

end across the routed network domain

CAPWAP

CAPWAP

Logical isolation provided by VLANs ceases to exist at the first L3 hop device (usually the distribution layer device)

Wired users belonging to different groups are deployed into separate VLANs

Static VLAN Configuration Cisco NAC Appliance Identity (802.1X, MAB, Web-Auth)


Agenda What Is Network Virtualization? Network Virtualization Components Deploying Network Virtualization in the Campus

Access ControlPath IsolationServices Edge

Extending VRFs Across the MAN/WAN Additional Virtualized Services Q and A


Path IsolationGeneral Considerations

Path Isolation leverages the use of VRFs to virtualize the data and control plane

Overcome the limitations of traditional approaches based on the use of distributed ACLs

First step is the virtualization of the campus distribution block

L2, first-hop L3 devices, and network services

Second step is the end-to-end extension of the logical isolation using different techniques

VRF-Lite and GREVRF-Lite End-to-EndMPLS VPNInternet


VLANs provide separation at the data plane



Path IsolationVirtualizing the Campus Distribution BlockVRF-Lite and GRE TunnelsVRF-Lite End-to-EndMPLS VPN



Step 1: Definition of New VLANsMultitier Deployment

Campus best practice design is to keep VLAN IDs unique per access layer switchCampus

Core

Layer 2 Trunks

L3

VLAN 21 RedVLAN 22 GreenVLAN 23 Blue


For More Discussion on Campus Design Principles: BRKCRS-2031

Total number of required VLANs is the product of the number of VRFs configured and the number of access layers switches

Requirement to plan for new VLANs and IP subnets allocation

Increase control plane load for protocols like STP, HSRP, etc.


Step 2: VLANs to VRF MappingMultitier Deployment

Define VRFs on the distribution layer devices (first L3 hop in a campus multitier design)Campus Core

Layer 2 Trunks

L3



One VRF dedicated to each virtual network (Red, Green, etc.)

Multiple VLANs defined at the access layer map to the same VRF

Example: Red VLANs (21, 31) are mapped to the same RedVRF

The chosen Path Isolation technique is deployed from the distribution layer toward the routed core


Step 1: Definition of New VLANs Routed Access Deployment

Move the boundaries between L2 and L3 domains down to the access layer

For More Discussion on Campus Routed Access Deployment: BRKCRS-3036

Campus Core

Layer 3 Links

L3



Same VLAN IDs can be used on each access layer switch

Requirement to plan for new IP subnets allocation

No increase on control plane load

No need for HSRP/GLBP/VRRP or STP between access and distribution layer devices


Step 2: VLANs to VRF MappingRouted Access Deployment

Define VRFs on the access layer devices (first L3 hops in a campus routed access design)Campus Core

Layer 3 Links

L3



VRF Blue

VRF Green

VRF Red


Each VLAN defined at the Access Layer maps to the corresponding VRF

Red VLANs are mapped to the Red VRF defined in the different access layer switches

The chosen Path isolation technique must be deployed from the access layer devices


Step 1: Definition of New VLANsMultichassis EtherChannel Deployment

The two distribution layer devices appear as a single logical entity from a layer 2 perspective

For More Discussion on Campus VSS Deployment: BRKCRS-3035For More Discussion on Nexus vPC Deployment: BRKDCT-2951

Campus Core

Layer 2 Trunks



SiSi SiSi

Multichassis EtherChannels (MECs) are used between each access layer switch and the distribution switch pair

Eliminate STP loops even when spanning VLANs across access layer switches

Minimum number of new VLANs and IP subnets to be provisioned

Reduces the load on control plane No need for HSRP, GLBP, or VRRP


Step 2: VLANs to VRF MappingMultichassis EtherChannel Deployment

Define VRFs on the logical VSS pair (first L3 hop in a campus VSS design)Campus Core

Layer 2 Trunks



SiSi SiSi

VRF Blue

VRF Green

VRF Red


VLANs defined at the access layer map to the same VRF

Example: Red VLANs (21) are mapped to the same Red VRF

The chosen path isolation technique is deployed from the VSS pair toward the routed core


Campus Core

Layer 2 Trunks



VRF BlueVRF GreenVRF Red

Virtualizing the Distribution BlockVLANs to VRF Mapping Configuration (Old IOS CLI)ip vrf Redrd 1:1

!ip vrf Greenrd 2:2

!vlan 21 name Red_access_switch_1

!vlan 22name Green_access_switch_1

!interface Vlan21description Red on Access Switch 1ip vrf forwarding Redip address 10.137.21.1 255.255.255.0

!interface Vlan22description Green on Access Switch 1ip vrf forwarding Greenip address 10.137.22.1 255.255.255.0

Defining the VRFs

Defining the VLANs (L2 and SVI) and Mapping Them to the VRFs


Campus Core

Layer 2 Trunks




Virtualizing the Distribution BlockVLANs to VRF Mapping Configuration (New IOS CLI)

vrf definition Redrd 1:1address-family ipv4

!vrf definition Greenrd 2:2address-family ipv4

!vlan 21 name Red_access_switch_1


!interface Vlan21vrf forwarding Redip address 10.137.21.1 255.255.255.0

!interface Vlan22vrf forwarding Greenip address 10.137.22.1 255.255.255.0

Defining the VRFs


Currently available only on Catalyst 6500 (12.2(33)SXI release and later)


Campus Core

Layer 2 Trunks




Virtualizing the Distribution BlockVLANs to VRF Mapping Configuration (NX-OS CLI)vrf context Red!vrf context Green!vlan 21 name Red_access_switch_1


!interface Vlan21description Red on Access Switch 1vrf member Redip address 10.137.21.1 255.255.255.0

!interface Vlan22description Green on Access Switch 1vrf member Greenip address 10.137.22.1 255.255.255.0

Defining the VRFs


Currently available only on Nexus 7000 (4.0 release and later)


Virtualizing the Distribution BlockVirtualization of Network Services

Need to verify the VRF awareness of the network services usually deployed

First hop redundant protocolHSRP and VRRP are VRF-aware across all Catalyst platformsGLBP is VRF-aware only for Cisco Catalyst 6500 Series (12.2(33)SXH release)

DHCPDHCP server on Cisco Catalyst switches is not VRF-awareDHCP-relay functionality is not VRF-aware but ip helper-address applied to an SVI mapped to a VRF allows to feed address to hosts belonging to that specific VPN

ARP, PING, TracerouteSupported across all Catalyst platforms (requires 12.2(50)SG on 4500)


VRF-Lite and GRE TunnelsHow Does It Work?1. Create L2 VLAN and trunk it to the first

L3 device

Internet

3. Create GRE interface at the first L3 device and map it to the VRF

2. Define the VRF at the first L3 device and map the SVI to it

4. Repeat steps 13 on the remote device

5. Enable a routing protocol in the created overlay network

6. Traffic is now tunneled across the core devices (no VRF definition required in the core)

IGP


S3R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

router eigrp 1network 192.168.0.0 0.0.255.255no auto-summary

(VRF-Lite and GRE) IGP Configuration


S3R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24


S1#show ip routeGateway of last resort is not set

C 192.168.12.0/24 is directly connected, GigabitEthernet5/1D 192.168.23.0/24 [90/307200] via 192.168.12.2, 00:06:00, GigabitEthernet5/1D 192.168.34.0/24 [90/332800] via 192.168.12.2, 00:05:47, GigabitEthernet5/1

192.168.0.0/32 is subnetted, 6 subnetsC 192.168.0.101 is directly connected, Loopback1C 192.168.0.102 is directly connected, Loopback2C 192.168.0.103 is directly connected, Loopback3D 192.168.0.141 [90/460800] via 192.168.12.2, 00:05:27, GigabitEthernet5/1D 192.168.0.142 [90/460800] via 192.168.12.2, 00:05:27, GigabitEthernet5/1D 192.168.0.143 [90/460800] via 192.168.12.2, 00:05:27, GigabitEthernet5/1

(VRF-Lite and GRE) IGP Configuration Create Loopback Interfaces S1


S3R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24



D 192.168.12.0/24 [90/332800] via 192.168.34.3, 00:07:31, GigabitEthernet5/2D 192.168.23.0/24 [90/307200] via 192.168.34.3, 00:07:31, GigabitEthernet5/2C 192.168.34.0/24 is directly connected, GigabitEthernet5/2

192.168.0.0/32 is subnetted, 6 subnetsD 192.168.0.101 [90/460800] via 192.168.34.3, 00:07:31, GigabitEthernet5/2D 192.168.0.102 [90/460800] via 192.168.34.3, 00:07:31, GigabitEthernet5/2D 192.168.0.103 [90/460800] via 192.168.34.3, 00:07:31, GigabitEthernet5/2C 192.168.0.141 is directly connected, Loopback1C 192.168.0.142 is directly connected, Loopback2C 192.168.0.143 is directly connected, Loopback3

(VRF-Lite and GRE) IGP Configuration Create Loopback Interfaces S4


S3R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24



C 192.168.12.0/24 is directly connected, GigabitEthernet5/2C 192.168.23.0/24 is directly connected, GigabitEthernet5/1D 192.168.34.0/24 [90/307200] via 192.168.23.3, 00:06:36, GigabitEthernet5/1

192.168.0.0/32 is subnetted, 6 subnetsD 192.168.0.101 [90/409600] via 192.168.12.1, 00:06:49, GigabitEthernet5/2D 192.168.0.102 [90/409600] via 192.168.12.1, 00:06:49, GigabitEthernet5/2D 192.168.0.103 [90/409600] via 192.168.12.1, 00:06:49, GigabitEthernet5/2D 192.168.0.141 [90/435200] via 192.168.23.3, 00:06:16, GigabitEthernet5/1D 192.168.0.142 [90/435200] via 192.168.23.3, 00:06:16, GigabitEthernet5/1D 192.168.0.143 [90/435200] via 192.168.23.3, 00:06:16, GigabitEthernet5/1

(VRF-Lite and GRE) IGP Configuration Create Loopback Routes


S3R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24



D 192.168.12.0/24 [90/307200] via 192.168.23.2, 00:07:13, GigabitEthernet5/2C 192.168.23.0/24 is directly connected, GigabitEthernet5/2C 192.168.34.0/24 is directly connected, GigabitEthernet5/1

192.168.0.0/32 is subnetted, 6 subnetsD 192.168.0.101 [90/435200] via 192.168.23.2, 00:07:13, GigabitEthernet5/2D 192.168.0.102 [90/435200] via 192.168.23.2, 00:07:13, GigabitEthernet5/2D 192.168.0.103 [90/435200] via 192.168.23.2, 00:07:13, GigabitEthernet5/2D 192.168.0.141 [90/409600] via 192.168.34.4, 00:06:53, GigabitEthernet5/1D 192.168.0.142 [90/409600] via 192.168.34.4, 00:06:53, GigabitEthernet5/1D 192.168.0.143 [90/409600] via 192.168.34.4, 00:06:53, GigabitEthernet5/1

(VRF-Lite and GRE) IGP Configuration


S3R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

vrf definition BLUrd 1:3address-family ipv4!vrf definition GRNrd 1:2address-family ipv4!vrf definition REDrd 1:1address-family ipv4

vrf definition BLUrd 1:3address-family ipv4

!vrf definition GRNrd 1:2address-family ipv4

!vrf definition REDrd 1:1address-family ipv4

interface GigabitEthernet1/1vrf forwarding REDip address 172.16.5.1 255.255.255.0!interface GigabitEthernet1/2vrf forwarding GRNip address 172.17.6.1 255.255.255.0!interface GigabitEthernet1/3vrf forwarding BLUip address 172.18.7.1 255.255.255.0

interface GigabitEthernet1/1vrf forwarding REDip address 172.16.8.4 255.255.255.0

!interface GigabitEthernet1/2vrf forwarding GRNip address 172.17.9.4 255.255.255.0

!interface GigabitEthernet1/3vrf forwarding BLUip address 172.18.10.4

255.255.255.0

(VRF-Lite and GRE) VRF Configuration


S3R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

interface Tunnel1vrf forwarding REDip address 172.16.14.4 255.255.255.0tunnel source Loopback1tunnel destination 192.168.0.101

!interface Tunnel2vrf forwarding GRNip address 172.17.14.4 255.255.255.0tunnel source Loopback2tunnel destination 192.168.0.102

!interface Tunnel3vrf forwarding BLUip address 172.18.14.4 255.255.255.0tunnel source Loopback3tunnel destination 192.168.0.103

interface Tunnel1vrf forwarding REDip address 172.16.14.1 255.255.255.0tunnel source Loopback1tunnel destination 192.168.0.141!interface Tunnel2vrf forwarding GRNip address 172.17.14.1 255.255.255.0tunnel source Loopback2tunnel destination 192.168.0.142!interface Tunnel3vrf forwarding BLUip address 172.18.14.1 255.255.255.0tunnel source Loopback3tunnel destination 192.168.0.143

(VRF-Lite and GRE) Tunnel ConfigurationVRF to Tunnel Mapping


S3G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S2

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

S1#show ip route vrf REDC 172.16.14.0 is directly connected, Tunnel1D 172.16.8.0 [90/297270016] via 172.16.14.4, 00:27:55, Tunnel1C 172.16.5.0 is directly connected, GigabitEthernet1/1

S1#show ip route vrf GRNC 172.17.14.0 is directly connected, Tunnel2D 172.17.9.0 [90/297270016] via 172.17.14.4, 00:29:26, Tunnel2C 172.17.6.0 is directly connected, GigabitEthernet1/2

S1#show ip route vrf BLUC 172.18.14.0 is directly connected, Tunnel3D 172.18.10.0 [90/297270016] via 172.18.14.4, 00:29:51, Tunnel3C 172.18.7.0 is directly connected, GigabitEthernet1/3

(VRF-Lite and GRE) Tunnel ConfigurationVRF Routes S1

R4S4R1S1


S3R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

S4#show ip route vrf REDC 172.16.14.0 is directly connected, Tunnel1C 172.16.8.0 is directly connected, GigabitEthernet1/1D 172.16.5.0 [90/297270016] via 172.16.14.1, 00:31:17, Tunnel1

S4#show ip route vrf GRNC 172.17.14.0 is directly connected, Tunnel2C 172.17.9.0 is directly connected, GigabitEthernet1/2D 172.17.6.0 [90/297270016] via 172.17.14.1, 00:31:32, Tunnel2

S4#show ip route vrf BLUC 172.18.14.0 is directly connected, Tunnel3C 172.18.10.0 is directly connected, GigabitEthernet1/3D 172.18.7.0 [90/297270016] via 172.18.14.1, 00:31:49, Tunnel3

(VRF-Lite and GRE) Tunnel ConfigurationVRF Routes S4


S3R1 G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

GRE headeradded

GRE headeradded

GRE encapsulation represent 24 extra bytes or 28 if a key is present.

GRE headerremoved

GRE headerremoved

20 Byte IP Header 20 Byte IP Header

GRE Header 4/8

Bytes

GRE Header 4/8

BytesOriginal PacketOriginal Packet

(VRF-Lite and GRE) Packet Flow


VRF-Lite and GRE TunnelsSummary

Blue VRF

Deployment Recommended for hub-and-spoke requirements Limited scale for single or few VPN applications (guest access, NAC remediation) GRE supported in HW on Catalyst 6500 and Nexus 7000Application and Services Supports both wired and wireless networks Multiple VRF-aware Services availableLearning Curve Familiar routing protocols can be used IP Based solution

Internet



VRF-Lite End-to-EndHow Does It Work?1. Create L2 VLANs and trunk them to the

first L3 device2. Define VRFs at the first L3 device and

map the L2 VLANs to the proper VRF3. Define VRFs on all the other L3 devices in

the network4. Configure as trunks all the physical links

connecting the L3 devices in the networkCreate VLAN interfaces or subinterfaces and map them to the corresponding VRF

5. Define unique VLANs on each trunk to be associated to each VRF

7. Traffic is now carried end-to-end across the network maintaining logical isolation between the defined groups

6. Enable a routing protocol in each VRF

VLAN 10VLAN 20

VLAN 11VLAN 21

VLAN 12VLAN 22

VLAN 13VLAN 23

VLAN 15VLAN 25

VLAN 16VLAN 26

VLAN 14VLAN 24

IGPs


VRF-Lite End-to-EndGeneral Design Considerations VRF-lite on all routed hops: core and distribution (sometimes access)

VLANs are not extended across the Campus network

Layer 3L2

L2

Routed HopNot Bridged

Every physical link is virtualized to carry multiple logical routed links

802.1q tags provide single hop data path virtualization

These virtualized links do notextend VLANs throughout the campus

The relationship of physical to logical networks is a matter of replication

Virtualization of every network device and every physical link connecting them





VRF-Lite End-to-EndMulticast Simplest design choice is leveraging the same multicast configuration already in place in global table in each VRF

PIM mode, RP placement, RP advertisement protocol

InternetData CenterMulticast Sources Multicast Receivers

Multicast Receivers Multicast Receivers Multicast Receivers

Simple deployment when multicast source and receivers are part of the same VRF

Alternative is to deploy the multicast source as a shared resource (Services Edge)

Multicast VRF functionality supported across all Catalyst platforms

Support for Catalyst 4000 family limited to Sup6E supervisors (modular) or 4900M models (12.2(50)SG IOS release)


VRF-Lite End-to-EndMulticastConfiguration Example

2. Configure the RP in the VRF using Anycast RP

1. Enable multicast routing globally and on each L3 interface

ip multicast-routing!interface TenGigabitEthernet1/1description 10GE to core (Global)ip pim sparse-mode

ip multicast-routing vrf Red!interface TenGigabitEthernet1/1.10description 10GE to core (VRF red)ip vrf forwarding Redip pim sparse-mode

interface Loopback0description Anycast RP Globalip address 10.122.5.200 255.255.255.255ip pim sparse-mode

!interface Loopback1description MSDP Peering interfaceip address 10.122.5.250 255.255.255.255ip pim sparse-mode

!ip msdp peer 10.122.5.251 connect-source loopback 1ip msdp originator-id loopback 1!ip pim rp-address 10.122.5.200access-list 10 permit 239.0.0.0 0.255.255.255

Global Table VRF Red

Example Valid for PIM Sparse Mode Deployment, Leveraging Anycast RP for RP Redundancy

interface Loopback10description Anycast RP VRF Redip vrf forwarding Redip address 10.122.15.200 255.255.255.255ip pim sparse-mode!interface Loopback11description MSDP Peering interface VRF redip vrf forwarding Redip address 10.122.15.250 255.255.255.255ip pim sparse-mode!ip msdp vrf Red peer 10.122.15.251 connect-source loopback 11ip msdp vrf Red originator-id loopback 11!ip pim vrf Red rp-address 10.122.15.200access-list 11 permit 239.192.0.0 0.0.255.255

VRF RedGlobal Table


(VRF-Lite) VRF Definition Configuration

R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S3S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24


! vrf definition GRNrd 1:2address-family ipv4

! vrf definition REDrd 1:1address-family ipv4

router eigrp 1!address-family ipv4 vrf REDnetwork 172.16.0.0autonomous-system 10!address-family ipv4 vrf GRNnetwork 172.17.0.0autonomous-system 20!address-family ipv4 vrf BLUnetwork 172.18.0.0autonomous-system 30


802.1Q or

physical interfaces

802.1Q or

physical interfaces

R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

S3S2

(VRF-Lite) VRF Interface ConfigurationInterface GigabitEthernet1/1vrf forwarding REDip address 172.16.5.1 255.255.255.0!interface GigabitEthernet1/2vrf forwarding GRNip address 172.17.6.1 255.255.255.0!interface GigabitEthernet1/3vrf forwarding BLUip address 172.18.7.1 255.255.255.0

Interface GigabitEthernet1/1vrf forwarding REDip address 172.16.8.4 255.255.255.0

!interface GigabitEthernet1/2vrf forwarding GRNip address 172.17.9.4 255.255.255.0

!interface GigabitEthernet1/3vrf forwarding BLUip address 172.18.10.4 255.255.255.0

interface GigabitEthernet5/2.10encapsulation dot1Q 10vrf forwarding REDip address 172.16.12.2 255.255.255.0!interface GigabitEthernet5/2.20encapsulation dot1Q 20vrf forwarding GRNip address 172.17.12.2 255.255.255.0!interface GigabitEthernet5/2.30encapsulation dot1Q 30vrf forwarding BLUip address 172.18.12.2 255.255.255.0

interface GigabitEthernet5/2.10encapsulation dot1Q 10vrf forwarding REDip address 172.16.34.4 255.255.255.0

!interface GigabitEthernet5/2.20encapsulation dot1Q 20vrf forwarding GRNip address 172.17.34.4 255.255.255.0

!interface GigabitEthernet5/2.30encapsulation dot1Q 30vrf forwarding BLUip address 172.18.34.4 255.255.255.0


R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

S3S2

(VRF-Lite) IGP Routing Information

S1#show ip route vrf REDD 172.16.34.0 [90/332800] via 172.16.12.2, 01:30:07, GigabitEthernet5/2.10D 172.16.23.0 [90/307200] via 172.16.12.2, 01:30:07, GigabitEthernet5/2.10C 172.16.12.0 is directly connected, GigabitEthernet5/2.10D 172.16.8.0 [90/358400] via 172.16.12.2, 01:25:26, GigabitEthernet5/2.10C 172.16.5.0 is directly connected, GigabitEthernet1/1

S1#show ip route vrf REDD 172.16.34.0 [90/332800] via 172.16.12.2, 01:30:07, GigabitEthernet5/2.10D 172.16.23.0 [90/307200] via 172.16.12.2, 01:30:07, GigabitEthernet5/2.10C 172.16.12.0 is directly connected, GigabitEthernet5/2.10D 172.16.8.0 [90/358400] via 172.16.12.2, 01:25:26, GigabitEthernet5/2.10C 172.16.5.0 is directly connected, GigabitEthernet1/1S1#show ip route vrf GRND 172.17.34.0 [90/332800] via 172.17.12.2, 01:32:04, GigabitEthernet5/2.20D 172.17.23.0 [90/307200] via 172.17.12.2, 01:32:04, GigabitEthernet5/2.20C 172.17.12.0 is directly connected, GigabitEthernet5/2.20D 172.17.9.0 [90/358400] via 172.17.12.2, 01:27:23, GigabitEthernet5/2.20C 172.17.6.0 is directly connected, GigabitEthernet1/2

S1#show ip route vrf REDD 172.16.34.0 [90/332800] via 172.16.12.2, 01:30:07, GigabitEthernet5/2.10D 172.16.23.0 [90/307200] via 172.16.12.2, 01:30:07, GigabitEthernet5/2.10C 172.16.12.0 is directly connected, GigabitEthernet5/2.10D 172.16.8.0 [90/358400] via 172.16.12.2, 01:25:26, GigabitEthernet5/2.10C 172.16.5.0 is directly connected, GigabitEthernet1/1S1#show ip route vrf GRND 172.17.34.0 [90/332800] via 172.17.12.2, 01:32:04, GigabitEthernet5/2.20D 172.17.23.0 [90/307200] via 172.17.12.2, 01:32:04, GigabitEthernet5/2.20C 172.17.12.0 is directly connected, GigabitEthernet5/2.20D 172.17.9.0 [90/358400] via 172.17.12.2, 01:27:23, GigabitEthernet5/2.20C 172.17.6.0 is directly connected, GigabitEthernet1/2S1#show ip route vrf BLUD 172.18.34.0 [90/332800] via 172.18.12.2, 01:32:56, GigabitEthernet5/2.30D 172.18.23.0 [90/307200] via 172.18.12.2, 01:32:56, GigabitEthernet5/2.30C 172.18.12.0 is directly connected, GigabitEthernet5/2.30D 172.18.10.0 [90/358400] via 172.18.12.2, 01:28:15, GigabitEthernet5/2.30C 172.18.7.0 is directly connected, GigabitEthernet1/3


R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

S3S2

(VRF-Lite) IGP Routing Information

S4#show ip route vrf REDC 172.16.34.0 is directly connected, GigabitEthernet5/2.10D 172.16.23.0 [90/307200] via 172.16.34.3, 00:04:39, GigabitEthernet5/2.10D 172.16.12.0 [90/332800] via 172.16.34.3, 00:01:41, GigabitEthernet5/2.10C 172.16.8.0 is directly connected, GigabitEthernet1/1D 172.16.5.0 [90/358400] via 172.16.34.3, 00:01:41, GigabitEthernet5/2.10

S4#show ip route vrf REDC 172.16.34.0 is directly connected, GigabitEthernet5/2.10D 172.16.23.0 [90/307200] via 172.16.34.3, 00:04:39, GigabitEthernet5/2.10D 172.16.12.0 [90/332800] via 172.16.34.3, 00:01:41, GigabitEthernet5/2.10C 172.16.8.0 is directly connected, GigabitEthernet1/1D 172.16.5.0 [90/358400] via 172.16.34.3, 00:01:41, GigabitEthernet5/2.10S4#show ip route vrf GRNC 172.17.34.0 is directly connected, GigabitEthernet5/2.20D 172.17.23.0 [90/307200] via 172.17.34.3, 00:06:31, GigabitEthernet5/2.20D 172.17.12.0 [90/332800] via 172.17.34.3, 00:03:33, GigabitEthernet5/2.20C 172.17.9.0 is directly connected, GigabitEthernet1/2D 172.17.6.0 [90/358400] via 172.17.34.3, 00:03:33, GigabitEthernet5/2.20

S4#show ip route vrf REDC 172.16.34.0 is directly connected, GigabitEthernet5/2.10D 172.16.23.0 [90/307200] via 172.16.34.3, 00:04:39, GigabitEthernet5/2.10D 172.16.12.0 [90/332800] via 172.16.34.3, 00:01:41, GigabitEthernet5/2.10C 172.16.8.0 is directly connected, GigabitEthernet1/1D 172.16.5.0 [90/358400] via 172.16.34.3, 00:01:41, GigabitEthernet5/2.10S4#show ip route vrf GRNC 172.17.34.0 is directly connected, GigabitEthernet5/2.20D 172.17.23.0 [90/307200] via 172.17.34.3, 00:06:31, GigabitEthernet5/2.20D 172.17.12.0 [90/332800] via 172.17.34.3, 00:03:33, GigabitEthernet5/2.20C 172.17.9.0 is directly connected, GigabitEthernet1/2D 172.17.6.0 [90/358400] via 172.17.34.3, 00:03:33, GigabitEthernet5/2.20S4#show ip route vrf BLUC 172.18.34.0 is directly connected, GigabitEthernet5/2.30D 172.18.23.0 [90/307200] via 172.18.34.3, 00:08:41, GigabitEthernet5/2.30D 172.18.12.0 [90/332800] via 172.18.34.3, 00:05:46, GigabitEthernet5/2.30C 172.18.10.0 is directly connected, GigabitEthernet1/3D 172.18.7.0 [90/358400] via 172.18.34.3, 00:05:46, GigabitEthernet5/2.30


S1 S4S3S2

No additional layer 3 encapsulation is required.

(VRF-Lite) Packet Flow


VRF-Lite End-to-EndCisco Catalyst Platforms Support

VRF-lite not supported with IP Base software licenseMinimum IP Services required for Catalyst platforms Minimum Enterprise required for Nexus 7000 platforms


VRF-Lite End-to-EndSummary

Deployment End-to-End IP based Solution Easy migration from existing campus architecture Any to any connectivity within VPNs Enterprise scale (recommended 8 or less segments) Supported on Catalyst 6500, 4500, 3700 families Supported on Nexus 7000Application and Services Supports both wired and wireless networks Multiple VRF-aware Services availableLearning Curve Familiar routing protocols can be used IP Alternative to MPLS Virtual Network Management (VNM) available with LMS 3.2

Layer 3L2

L2

802.1q Tags



1. Create L2 VLANsand trunk them to the first L3 device

2. Define VRFs at the first L3 devices (PE)and map the L2 VLANs to the proper VRF

3. Enable MPLS on allLayer 3 interfaces in the network

4. Enable MP-BGP on thePE devices to exchange VPN routes

PEs become iBGP neighbors5. VPN traffic is now carried end-to-end

across the network, maintaining logical isolation between the defined groups

Each frame is double-tagged (IGP label + VPN label)

Enable MPLS

Enable MPLS

PE

PE

PPLabel Switch Router (LSR)

MPLS VPNHow Does It Work?


InternetData CenterWAN

PP

PEPEPEPEPEPE

PEPEPEPEPE PE

MPLS-VPNRFC2547 VPNsGeneral Design Considerations Highly scalable

Usually deployed in large campus networks requiring the definition of a large number of VRFs

Any to any connectivity per user groupUser to cloud connectivity

VPN traffic is tunneled across the MPLS core

Requires the deployment of another control protocol

MP-BGP is used in addition to the IGP already deployed in the Campus global table

Platform support currently restricted to Cisco Catalyst 6500 Series

Support for Cisco Catalyst 6500 Series running MPLS in VSS mode availablefrom 12.2(33)SXI2 release


PE



MPLS Core

PE

Deploying MPLS-VPN in CampusStep 1: Enabling MPLS on PE and P Devices

PE usually deployed on the first L3 hop devices at the distribution layer

No CE in multitier campus design (L2 in the access)

P devices usually build the campus core

interface Loopback10description LDP identifierip address 192.168.100.10 255.255.255.255end!mpls ldp router-id Loopback10 force!interface TenGigabitEthernet1/1description 10GE to coreip address 10.122.5.31 255.255.255.254mtu 9216mpls ip

3 Configure LDP for performing label exchange with the neighbors

Use a loopback interface as source to leverage the physical path redundancy

P P

Enable MPLS switching

1. Enable MPLS switching on core-facing interface and on the transit link

2. Enable jumbo frame support on the MPLS-enabled interfaces to deal with the increased IP packet size


S3R1 R4G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24


S1# show ip route

D 192.168.43.0/24 [90/332800] via 192.168.21.2, 00:14:54, GigabitEthernet5/1C 192.168.21.0/24 is directly connected, GigabitEthernet5/1

192.168.0.0/32 is subnetted, 4 subnetsC 192.168.0.1 is directly connected, Loopback0D 192.168.0.2 [90/409600] via 192.168.21.2, 00:14:56, GigabitEthernet5/1D 192.168.0.3 [90/435200] via 192.168.21.2, 00:14:54, GigabitEthernet5/1D 192.168.0.4 [90/460800] via 192.168.21.2, 00:14:54, GigabitEthernet5/1D 192.168.32.0/24 [90/307200] via 192.168.21.2, 00:14:56, GigabitEthernet5/1

MPLS VPNIGP Configuration

G5/1S1


S3R1 R4G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24


route-target export 1:3route-target import 1:3

! vrf definition GRNrd 1:2address-family ipv4route-target export 1:2route-target import 1:2! vrf definition REDrd 1:1address-family ipv4route-target export 1:1route-target import 1:1

MPLS VPNVRF Configuration

G5/1S1vrf definition BLUrd 1:3address-family ipv4

route-target export 1:3route-target import 1:3

! vrf definition GRNrd 1:2address-family ipv4route-target export 1:2route-target import 1:2! vrf definition REDrd 1:1address-family ipv4route-target export 1:1route-target import 1:1


S3R1 R4G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

router bgp 1neighbor 192.168.0.1 remote-as 1neighbor 192.168.0.1 update-source Loopback0!address-family vpnv4neighbor 192.168.0.1 activateneighbor 192.168.0.1 send-community extended!address-family ipv4 vrf REDredistribute connected!address-family ipv4 vrf GRNredistribute connected!address-family ipv4 vrf BLUredistribute connected

MPLS VPNMP-BGP Configuration

G5/1S1router bgp 1neighbor 192.168.0.4 remote-as 1neighbor 192.168.0.4 update-source Loopback0!address-family vpnv4neighbor 192.168.0.4 activateneighbor 192.168.0.4 send-community extended!address-family ipv4 vrf REDredistribute connected!address-family ipv4 vrf GRNredistribute connected!address-family ipv4 vrf BLUredistribute connected


S3R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

interface GigabitEthernet5/1mpls ip


S1# show mpls forwarding-tableLocal Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 16 192.168.43.0/24 0 G5/1 192.168.21.2 17 17 192.168.0.3/32 0 G5/1 192.168.21.2 18 Pop tag 192.168.32.0/24 0 G5/1 192.168.21.2 19 Pop tag 192.168.0.2/32 0 G5/1 192.168.21.2 20 19 192.168.0.4/32 0 G5/1 192.168.21.2 21 Aggregate 172.16.5.0/24[V] 43885816 22 Aggregate 172.17.6.0/24[V] 4064826896 23 Aggregate 172.18.7.0/24[V] 31869760

MPLS VPNLDP Configuration

S1


S3R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24



S2# show mpls forwarding-tableLocal Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 192.168.43.0/24 0 G5/1 192.168.32.3 17 Pop tag 192.168.0.3/32 0 G5/1 192.168.32.3 18 Pop tag 192.168.0.1/32 4705398774 G5/2 192.168.21.1 19 19 192.168.0.4/32 4864903330 G5/1 192.168.32.3


S1


S3R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24



S3# show mpls forwarding-tableLocal Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 192.168.21.0/24 0 G5/2 192.168.32.2 17 Pop tag 192.168.0.2/32 0 G5/2 192.168.32.2 18 18 192.168.0.1/32 4869059999 G5/1 192.168.32.2 19 Pop tag 192.168.0.4/32 4709412559 G5/1 192.168.43.4


S1


S3R1 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24



S4# show mpls forwarding-tableLocal Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 16 192.168.21.0/24 0 G5/2 192.168.43.3 17 17 192.168.0.2/32 0 G5/2 192.168.43.3 18 Pop tag 192.168.32.0/24 0 G5/2 192.168.43.3 19 Pop tag 192.168.0.3/32 0 G5/2 192.168.43.3 20 18 192.168.0.1/32 0 G5/2 192.168.43.3 21 Aggregate 172.16.8.0/24[V] 43886024 22 Aggregate 172.17.9.0/24[V] 4078506120 23 Aggregate 172.18.10.0/24[V] 31869968


S1


S3 R4G5/1 G5/2 G5/2 G5/2G5/1 G5/1G1/1G1/2

G1/3

G1/1G1/2

G1/3

S1 S2 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

VPN LabelVPN LabelIGP LabelIGP Label

VPN LabelVPN LabelIGP LabelIGP Label

VPN LabelVPN Label

MPLS VPN packet format

MPLS VPNPacket Flow


S3S2R1 R4S1 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

N * (N-1) / 2 = 8 * 7 / 2 = 28

MPLS VPNBGP Scalability iBGP Neighbor Relationships

iBGP requires a full mesh of neighbors


S3S2R1 R4S1 S4

172.16.5.0/24

172.17.6.0/24

172.18.7.0/24

172.16.8.0/24

172.17.9.0/24

172.18.10.0/24

Route Reflector Route Reflector

MPLS VPNBGP Scalability Route Reflectors


ip vrf Greenrd 1:1route-target export 10:10route-target import 10:10!router bgp 100no bgp default ipv4-unicastneighbor 192.168.100.1 remote-as 100neighbor 192.168.100.1 update-source Loopback10neighbor 192.168.100.2 remote-as 100neighbor 192.168.100.2 update-source Loopback10!address-family vpnv4neighbor 192.168.100.1 activateneighbor 192.168.100.1 send-community extendedneighbor 192.168.100.2 activateneighbor 192.168.100.2 send-community extendedexit-address-family!address-family ipv4 vrf Greenredistribute connectedmaximum-paths ibgp 2 import 4no auto-summaryno synchronizationexit-address-family

Inject VPN Subnets into BGP (Directly Connected Subnets in Multitier Design)

Configure iBGP Sessions with the Route Reflectors

The above configuration can be replicated on all the PEs defined in the Campus (rd value may vary between distribution layer peers)

PE ConfigurationConfigure the route-target values

MPLS VPNPE Configuration with RR


router bgp 100no bgp default ipv4-unicastneighbor RR-clients peer-groupneighbor RR-clients remote-as 100neighbor RR-clients update-source Loopback10neighbor 192.168.100.3 peer-group RR-clientsneighbor 192.168.100.4 peer-group RR-clientsneighbor 192.168.100.5 peer-group RR-clientsneighbor 192.168.100.6 peer-group RR-clients!address-family vpnv4neighbor RR-clients activateneighbor RR-clients send-community extendedneighbor RR-clients route-reflector-clientneighbor 192.168.100.3 peer-group RR-clientsneighbor 192.168.100.4 peer-group RR-clientsneighbor 192.168.100.5 peer-group RR-clientsneighbor 192.168.100.6 peer-group RR-clientsexit-address-family

Configure the VPNv4 address-family to activate the MP-BGP sessions with the various PEs

Configure RR clients as part of a peer group

Only the RR configuration needs to be modified when deploying new PE devices

RR Configuration

MPLS VPNRR Configuration


Multicast VRF (MVRF)Per VRF multicast routing and forwarding (aka Multicast over VRF-Lite)PIM/IGMP/MSDP and other multicast protocols running in the context of the VRF

Multicast Distribution Tree (MDT)One or more multicast forwarding trees built across the core network and used to connect the same MVRF sitting on different PEsCan be of 2 types, based on the way how its created: Default and Data MDT

MDT Tunnel (aka Multicast Tunnel Interface MTI)Its the interface from which the PE connect to the other PE in the network, on a given MVRFOne MDT Tunnel interface is created per MVRFAll PE routers on which the same MDT configuration is present are seen as PIM neighbors on the MDT TunnelNot configurable - takes properties from interface used for BGP peeringTunnel source address same as BGP peering address

MPLS VPN and MulticastTerminology Fundamentals


Campus MPLSCampus MPLSCore Core

PEPE

PEPE

PEPE

PEPE

Join highbandwidth source

Join highbandwidth source

MPLS VPN and Multicast Concept and Fundamentals

First step is to enable multicast in the Campus coreNo difference from a normal multicast deployment

High bandwidth multicast source

Receiver 1Receiver 1

Receiver 2Receiver 2

DefaultDefaultMDTMDTFor low

Bandwidth & control

traffic only.DataDataMDTMDTFor High Bandwidth traffic only.

ip multicast-routing vrf red!ip vrf redrd 3:3mdt default 232.0.0.1 mdt data 232.0.1.0 0.0.0.255 threshold 500

A default MDT for each VRF is established between PEs

A High-bandwidth source for that customer starts sending traffic

Interested receivers 1 & 2 join that High Bandwidth source

Data-MDT is formed between PEs for this High-Bandwidth source


InternetData CenterWAN

PP

PEPEPEPEPEPE

PEPEPEPEPE PE

MPLS-VPNRFC2547 VPNsSummary

Deployment MPLS based solution Highly scalable L3 VPN solution (Hundreds) Any-to- any connectivity within VPNs Supported on Catalyst 6500 (Sup720 and Sup32) Support for VSS from release 12.2(33)SXI2Application and Services Supports both wired and wireless networks Multiple VRF-aware Services availableLearning Curve Longer learning curve for Enterprise customers

- MPLS- Multi-Protocol BGP



Access ControlPath IsolationServices Edge



Access Control Path Isolation Services EdgeWAN MAN Campus Branch Campus Data Center Internet

Edge Campus

VRFs

GRE MPLS

Internet

Services EdgeGeneral Design Considerations

The default state of a VPN is to be totally isolated from other VPNsVPNs actually mimic physically separate networks

It is desirable for these VPNs to share certain services (such as Internet access, DHCP, and DNS services or server farms)

These services are usually located outside of the different VPNs(or in a VPN of their own)

Sometimes may also be required to enable inter-VPN communication


6500 Chassis

Services EdgeProtected Services Traffic leaving a specific virtual network is steered to the services edge

Red VPN

BlueVPN

GreenVPN

Campus Core

Shared ServicesE-mailStorageWeb Deployment of a fusion router in the

services edge to provide:Inter-VPN connectivityProtected access to shared resources

Positioning of a firewall front-ending each VPNVPN isolation/protectionApplication of per VPN policiesLeverage the multi-context functionality available with Cisco FWSM, PIX, and ASA

Routing between VRFs and Fusion Router depends on the FW mode of operation

FW in Transparent Mode IGP or eBGPFW in Routed Mode Static Routing or eBGP


Protected ServicesDeploying Firewall Contexts in Transparent Mode Firewall contexts in transparent mode act as L2 bridges

Red VPN

BlueVPN

GreenVPN

Campus Core

Shared ServicesE-mailStorageWeb

L2 L2 L2

EIGRP, OSPF, eBGP, Static (no ISIS)

Fusion router establishes routing peering with the various VRFs

The fusion router has complete knowledge of all the routes existing in the defined VRFs

The peering protocol may vary depending on the path isolation strategy

Use IGP (EIGRP or OSPF) for VRF-lite deploymentsUse eBGP for MPLS VPN scenarios

The fusion router could typically advertise only a default route into the various VRFs

A dedicated Fusion VRF may be used in place of an external fusion router device


Protected ServicesDeploying Firewall Contexts in Routed Mode Firewall contexts in routed mode act as L3 hop routing traffic between interfaces

No routing protocol support on FW deployed in multi-context mode

Red VPN

BlueVPN

GreenVPN

Campus Core

Shared ServicesE-mailStorageWeb

L3 L3 L3

eBGP The only recommended peering protocol is eBGP, independently from the Path Isolation technique adopted in the Campus

Configuring static routing is possible but not recommended

The fusion router could typically advertise only a default route into the various VRFs

A dedicated Fusion VRF may be used in place of an external fusion router device


Protected ServicesGlobal Table Integration Options

The global table is considered as another VPN (in fact can be usually considered thedefault VPN) and it is front-ended by its ownsecurity device

The global table is treated as a sharedservice: access to the global table from eachVPN is subject to the policy enforcementprovided by the Services Edge

Red VPN

BlueVPN

GreenVPN

Shared Services

Red VPN

BlueVPN

GreenVPN

Global Table


Connecting a DC to a Virtualized Campus

VRF termination on DC edge VDCs/VRFs on the Nexus 7K Virtualized FW and SLB VLANs maintain separation within the DC

FCOE consolidates physical infrastructure

VSANs provide logically separate storage

Nexus 1000V, VN-Link, and Vmware virtualize applications

VirtualizedCampus

Virtual Device Contexts (VDC)


Agenda What Is Network Virtualization? Network Virtualization Components Deploying Network Virtualization in the Campus Extending VRFs Across the MAN/WAN Additional Virtualized Services Q&A


Extensibility Over the MAN/WAN The private MAN/WAN The Internet

LAN LAN

Tunnels, L2 or L3 VPNs: GRE, RFC2547,

MPLSoDMVPN etc.

MAN/WAN

Groups Must Be Extensible Over:


MAN/WAN ExtensibilityDifferent Options Available

The virtual networks may need to be extended over the MAN/WAN

There are several technical alternatives; some examplesMPLS over L2 serviceDMVPN per VRFRFC2547 over DMVPNCarrier-supporting-carrier (where the service is available)

The choice depends largely on the enterprises MAN/WAN contracts and platform support

Next-generation MPLS VPN MAN/WAN design guidehttp://www.cisco.com/en/US/netsol/ns656/networking_solutions_design_guidances_list.html#anchor13

For More Discussion on WAN NV Deployment: BRKRST-2043


Agenda What Is Network Virtualization? Network Virtualization Components Deploying Network Virtualization in the Campus Extending VRFs Across the MAN/WAN Additional Virtualized Services

Unicast Shared ServicesMulticast Shared ServicesQoS

Q&A


Sharing Unicast ServicesRoute Leaking 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 leaking

No support for overlapping IP addresses across VPNs

Unprotected access usually achieved with two models

Multi-device deployment Single device deployment

Red VPN

BlueVPN

GreenVPN

Shared ServicesRouteLeaking


Sharing Unicast Services Model 1: Multi-Device Deployment

Usually utilized in conjunction with the use of MPLS VPN as path isolation strategy

Requires the deployment of MP-BGP to exchange VPN routes between devices

Leverage MP-BGP route-targetattribute to determine the type of connectivity achieved

Hub-and-spoke is usually deployed to provide access to shared services

Route leaking is performed on the PE devices receiving BGP updates

No routes exchanged between Red and Green

Red and Green devices remain isolated from each other

PC Red PC Green

MP-BGP MP-BGP

PE2 PE3

PE1

Shared Server

MP-BGP


Sharing Unicast Services Model 1: Configuration

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

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

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

MP-BGP MP-BGP

PE2 PE3

PE1

Shared Server

MP-BGP


MP-BGP MP-BGP

PE2 PE3

PE1

Shared Subnet10.138.32.0/24

MP-BGP

Sharing Unicast Services Model 1: Verification

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

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


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

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


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


Red Subnet10.137.12.0/24

Green Subnet10.137.22.0/24


Sharing Unicast Services Model 2: Single Device Deployment

Applicable to VRF-Lite End-to-End scenarios

Configuration of a local BGP process to enable the route leaking mechanismNo BGP neighbor relationships are established since BGP is required only on the local device

Shared routes locally leaked to Red and Green VRFs

The Shared routes locally leaked into the Red and Green VRFs can be advertised to other devices via the IGP running in the context of each VRF

Red and Green devices can reach the Shared server but remain isolated from each other

Note: Local Route Leaking only supported on Catalyst 6500 with Advanced SW licenses

PE2 PE3

PE1

Shared Server

IGP IGP

Local Route Leaking (BGP)


PE2 PE3

PE1

Shared Server


ip vrf Redrd 100:100route-target export 1:1route-target import 3:3!ip vrf Greenrd 200:200route-target export 2:2route-target import 3:3!ip vrf Sharedrd 300:300route-target export 3:3route-target import 1:1route-target import 2:2

router bgp 100!address-family ipv4 vrf Redredistribute eigrp 100no synchronizationexit-address-family!address-family ipv4 vrf Greenredistribute eigrp 100no synchronizationexit-address-family!address-family ipv4 vrf Sharedredistribute connectedno synchronizationexit-address-family

router eigrp 100!address-family ipv4 vrf Redredistribute bgp 100 metric 100000 1 255 1 1500network 10.0.0.0no auto-summaryautonomous-system 100exit-address-family!address-family ipv4 vrf Greenredistribute bgp 100 metric 100000 1 255 1 1500network 10.0.0.0no auto-summaryautonomous-system 100exit-address-family

Sharing Unicast Services Model 2: Configuration


PE2 PE3

PE1

IGP IGP


Sharing Unicast Services Model 2: Verification

Red Subnet10.137.12.0/24

Green Subnet10.137.22.0/24

Shared Subnet10.138.32.0/24

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

Known via "bgp 100", distance 20, metric 0Redistributing via eigrp 100, bgp 100Routing Descriptor Blocks:* directly connected, via Vlan32

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

Known via "bgp 100", distance 20, metric 0Redistributing via eigrp 100, bgp 100Routing Descriptor Blocks:* directly connected, via Vlan32

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

Known via "eigrp 100", distance 90, metric 3840

R2#sh ip route vrf Red 10.137.22.0% Subnet not in table

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

Known via "eigrp 100", distance 90, metric 3840

R3#sh ip route vrf Green 10.137.12.0% Subnet not in table




Q&A


Sharing Multicast Services

Deployed today by Financial Service Providers to deliver Market Data

May be used by Enterprises for Corporate Communications, MoH, etc

Originally designed for use with MPLS-VPN and mVPN Supported only with VRF-Lite deployments

12.2(33)SXI2 release or newer is required for Catalyst 6500

= MC Src VRF = MC Rcv VRFs

Single MC stream

Leaf device performing MC replication


Sharing Multicast Services

Configuration to enable the multicast extranet replication is recommended on the leaf device

Independent from the path isolation strategy adopted (VRF-Lite or MPLS VPN)

Multicast replication performed in HW (data plane) On the control plane, it is important to ensure that RPF check is successful across VRFs in order for multiicast streams to cross the VRF boundaries

Option 1: perform route-leaking between Src and Rcv VRFsOption 2: leverage the VRF Fallback functionality (recommended)

MC Src VPN


MC Src VPN

Sharing Multicast ServicesOption 1 Route Leaking

ip vrf mc-srcrd 1:1route-target export 1:1route-target import 2:2route-target import 3:3!ip vrf mc-rcv1rd 2:2route-target export 2:2route-target import 1:1!ip vrf mc-rcv2rd 3:3route-target export 3:3route-target import 1:1!ip multicast-routing vrf mc-src ip multicast-routing vrf mc-rcv1 ip multicast-routing vrf mc-rcv2

Rcv110.138.13.11

Rcv210.138.23.11

Shared Src10.137.12.211

ip pim vrf mc-src rp-address 10.137.233.233ip pim vrf mc-rcv1 rp-address 10.137.233.233ip pim vrf mc-rcv2 rp-address 10.137.233.233!router bgp 100!address-family ipv4 vrf mc-srcredistribute eigrp 100no synchronizationexit-address-family!address-family ipv4 vrf mc-rcv2redistribute connectedno synchronizationexit-address-family!address-family ipv4 vrf mc-rcv1redistribute connectedno synchronizationexit-address-family

RP10.137.233.233


Sharing Multicast ServicesOption 2 VRF Fallback (Recommended)

ip vrf mc-srcrd 1:1!ip vrf mc-rcv1rd 2:2!ip vrf mc-rcv2rd 3:3!ip multicast-routing vrf mc-src ip multicast-routing vrf mc-rcv1 ip multicast-routing vrf mc-rcv2!ip pim vrf mc-src rp-address 10.137.233.233ip pim vrf mc-rcv1 rp-address 10.137.233.233ip pim vrf mc-rcv2 rp-address 10.137.233.233!ip mroute vrf mc-rcv1 10.137.0.0 255.255.0.0 fallback-lookup vrf mc-srcip mroute vrf mc-rcv2 10.137.0.0 255.255.0.0 fallback-lookup vrf mc-src

MC Src VPN

Rcv110.138.13.11

Rcv210.138.23.11

Shared Src10.137.12.211

RP10.137.233.233


Sharing Multicast ServicesVerification

Leaf_Device#sh ip mroute vrf mc-src 239.192.241.100IP Multicast Routing Table

(*, 239.192.241.100), 00:09:32/stopped, RP 10.137.233.233, flags: SJCEIncoming interface: GigabitEthernet1/2.1, RPF nbr 10.122.5.42, Partial-SCOutgoing interface list: NullExtranet receivers in vrf mc-rcv2:

(*, 239.192.241.100), 00:01:56/stopped, RP 10.137.233.233, OIF count: 1, flags: SJCExtranet receivers in vrf mc-rcv1:

(*, 239.192.241.100), 00:01:56/stopped, RP 10.137.233.233, OIF count: 1, flags: SJC(10.137.12.211, 239.192.241.100), 00:00:58/00:02:59, flags: JTEIncoming interface: GigabitEthernet1/2.1, RPF nbr 10.122.5.42, RPF-MFDOutgoing interface list: NullExtranet receivers in vrf mc-rcv1:(10.137.12.211, 239.192.241.100), 00:00:58/00:02:59, OIF count: 1, flags: Extranet receivers in vrf mc-rcv2:(10.137.12.211, 239.192.241.100), 00:01:00/stopped, OIF count: 1, flags:

MC Src VPN

Rcv110.138.13.11

Rcv210.138.23.11

Shared Src10.137.12.211

RP10.137.233.233




Q&A


Aggregate ModelA common QoS strategy is used for all VRFsSame classification/queuing strategy for voice, video, critical data, best effortQoS is Orthogonal to Network Virtualization

Prioritized VRF ModelTraffic in some VRFs are prioritized over other VRFs (i.e. Production over Guest VRF)Classification/queuing of VRF traffic is done independently fromthe specific application (i.e. Voice traffic in a Guest VRF is always marked as best effort)

QoS and Network VirtualizationDeployment Models


Branch 1

Campus

Branch 2

Branch 3

Voice

ScavangerBest EffortVideo

Voice


Queue traffic in the

Campus core

Classify and mark traffic at edge

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

WAN

Typical QoS DeploymentBefore Network Virtualization


Branch 1

CampusVoice

ScavangerBest EffortVideo WAN

Int

Branch 2

Branch 3

Voice


Voice



Green VRF

Red VRF

Green VRF

Red VRF

Green VRF

Red VRF

Traffic is Queued, Shaped according to DSCP Values

Traffic is aggregated across VRFs (e.g. all Voice traffic is queued together)

WAN

Aggregate Model

QoS and Network VirtualizationAggregate Model

Red VRF

Queue traffic in the

Campus core

Green VRF


Branch 1

CampusVoice

ScavengerBest EffortVideo WAN

Int

Branch 2

Branch 3

Voice


ScavangerBest Effort Classify and mark traffic

at edge


Green VRF

Red VRF

Green VRF

Red VRF

Green VRF

Red VRF

Green VRF

Red VRF

Traffic is Queued, Shaped according to DSCP Values

WAN

Prioritized VRF

Green VRF is Guest. All traffic is marked as Best Effort or Scavenger

QoS and Network VirtualizationPrioritized VRF Model


Network VirtualizationPutting All Together

VRF-Lite + GRE, VRF-Lite End-to-End, MPLS VPN

VLANsPartition

Server Farms

User Identification(Static/NAC/Identity)

L3 VRFs

Extending VPNs over MAN/WAN

cloud

InternetData Center

WAN

Virtualized Services:

Firewall, ACE

Per User RoleL2 VLANs


Documentation


Network VirtualizationWhere to Go for More Information

www.cisco.com/go/networkvirtualization


BRKCSR-2033 Recommended Reading

Technology

Deploying a Virtualized Campus Network Infrastructure