Enterprise Network Virtualizationpalo/Rozne/cisco-expo-2009/Presentati… · 3. DHCP. DHCP server...

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 1

Enterprise Network Virtualization

Ing. Tomáš Ondovčí[email protected]

2

© 2009 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID

Agenda

1. What Is Network Virtualization?

2. Network Virtualization Components

3. Deploying Network Virtualization in the Campus

4. Extending VRFs Across the MAN/WAN

5. Q and A

3


Virtual Network

Merged NewCompany

Network VirtualizationCreation of Logical Partitions

1. Virtualization: one-to-many (one network supports many virtual networks)2. End-user perspective is that of being connected to a dedicated network

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

network

Actual Physical Infrastructure

OutsourcedIT Department

Virtual Network Virtual Network

Segregated Department(Regulatory Compliance)

4


Network VirtualizationProblem Definition

1. NV provides an answer to multiple business problems

Guest/partner access

NAC remediation

Merges/acquisitions

Regulatory compliance

…

2. Closed user groups Private

Secure

Independent policies

Media independent (wired/wireless)

3. End-to-end shared infrastructure

Employee Servers

Employee Partner Guest

Remediation ServersInternet

Unhealthy Posture

5


Agenda





5. Q and A

6


Network Virtualization Functional Architecture

Access Control Path Isolation Services Edge

WAN – 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

Shared

Dedicated

Apply policy per partition

Isolate application environments if necessary

7


Access Control Authentication, Authorization

1. Authentication—Who/what is requesting access?

Holistic control—Client-based, infrastructure integrated—802.1X

User-based control—Clientless—Web authentication

Device-specific control—MAC-address based

Static control—Physical security

2. Authorization—Where/how is the access granted?

Allow access to the network from a particular VLAN Edge Access Control

SiSi SiSi

8


Path IsolationFunctional Components

1. Device virtualizationControl plane virtualization

Data plane virtualization

Services virtualization

2. Data path virtualizationHop-by-Hop(VRF-Lite End-to-End)

Multi-Hop(VRF-Lite+GRE, MPLS-VPN)

VRFVRF

Global

IP

802.1q

VRF: Virtual Routing and Forwarding

Per VRF:Virtual Routing TableVirtual Forwarding Table

9


Services EdgeSharing Services Between VPNs

1. Services usually not duplicated per group

2. Economical

3. Efficient and manageable

4. 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 Server

Firewall and NAT

Hosted Content

Shared for All Groups:

10


Agenda



3. Deploying Network Virtualization in the CampusPath Isolation

Virtualizing the Campus Distribution Block

VRF-Lite End-to-End

VRF-Lite and GRE Tunnels

MPLS VPN


5. Q and A

11


Step 1: Definition of New VLANsMultitier Deployment

1. Campus best practice design is to keep VLANIDs unique per access layer switch

2. Total number of required VLANs is the product of the number of VRFsconfigured and the number of access layers switches

3. Requirement to plan for new VLANs and IP subnets allocation

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

Campus Core

Layer 2 Trunks

SiSiSiSi L3

VLAN 21 RedVLAN 22 GreenVLAN 23 Blue


12


Step 2: VLANs to VRF MappingMultitier Deployment

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

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

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

“Red” VLANs (21, 31) are mapped to the same “Red” VRF

4. The chosen path Isolation technique is deployed from the distribution layer toward the routed core


Campus Core

Layer 2 Trunks

Layer 2 Trunks

SiSiSiSi


L3

VRF Blue

VRF Green

VRF Red

13


Step 1: Definition of New VLANsRouted Access Deployment

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

2. Same VLAN IDs can be used on each access layer switch

3. Requirement to plan for new IP subnets allocation

4. No increase on control plane load

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

Campus Core

Layer 3 Links

SiSiSiSi L3



14


Step 2: VLANs to VRF MappingRouted Access Deployment

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


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

“Red” VLANs (21, 31) are mapped to the same “Red” VRF defined in the different switches

4. The chosen path isolation technique must be deployed from the access layer devices

Campus Core

Layer 3 Links

SiSiSiSi L3



VRF Blue

VRF Green

VRF Red

15


Step 1: Definition of New VLANsVirtual Switch System (VSS) Deployment

1. The two distribution layer devices (VSS pair) appear as a single logical entity

2. Multichassis EtherChannels(MECs) are used between each access layer switch and the VSS pair

Eliminate STP loops even when spanning VLANs across access layer switches

3. Minimum number of new VLANs and IP subnets to be provisioned

4. Reduces the load on control plan

No need for HSRP, GLBP, or VRRP

Campus Core

Layer 2 Trunks



16


Step 2: VLANs to VRF MappingVirtual Switch System (VSS) Deployment

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


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

“Red” VLANs (21, 31) are mapped to the same “Red” VRF

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

Campus Core

Layer 2 Trunks



VRF Blue

VRF Green

VRF Red

17


Virtualizing the Distribution BlockVLANs to VRF Mapping Configuration

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

18


Virtualizing the Distribution BlockVirtualization of Network Services

1. Need to verify the VRF ‘awareness’ of the network services usually deployed

2. First hop redundant protocolHSRP and VRRP are VRF-aware across all Catalyst platforms

GLBP is VRF-aware only for Cisco Catalyst 6500 Series (12.2(33)SXH release)

3. DHCPDHCP server on Cisco Catalyst switches is not VRF-aware

DHCP-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

4. ARP, PING, TracerouteVRF-aware for Cisco Catalyst 6500 Series and Cisco Catalyst 3000 Series

19


Agenda





VRF-Lite End-to-End


MPLS VPN


5. Q and A

20


VRF-Lite End-to-EndHow Does It Work?

1. Create L2 VLANs and trunk them to the first L3 device

2. Define VRFs at the first L3 device and map the L2 VLANs to the proper VRF

3. Define VRFs on all the other L3 devices in the network

4. Configure as trunks all the physical links connecting the L3 devices in the network

Create 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

VLAN 10VLAN 20

VLAN 11VLAN 21

VLAN 12VLAN 22

VLAN 13VLAN 23

VLAN 15VLAN 25

VLAN 16VLAN 26

VLAN 14VLAN 246. Enable a routing protocol in each VRF

IGPs

21


VRF-Lite End-to-EndGeneral Design Considerations

1. VRF-lite on all routed hops: core and distribution (sometimes access)

VLANs are not extended across the Campus network

2. Every physical link is virtualized to carry multiple logical routed links

802.1q tags provide single hop data path virtualization

3. These virtualized links do notextend VLANs throughout the campus

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

Virtualization of every network device and every physical link connecting them

Layer 3L2

L2

802.1q Tags

Routed HopNot Bridged

22


VRF-Lite End-to-EndTrunk with Switchports and SVIs

1. Links between L3 devices defined as L2 trunks with switchports

2. Unique VLANs used for global table, Green and Red traffic

3. Logical SVIs mapped to the Green and Red VRFs

Catalyst-1interface GigabitEthernet1/1description --- Trunk to Catalyst-2 ---switchport trunk encapsulation dot1qswitchport trunk allowed vlan 2000-2002switchport mode trunk spanning-tree portfast trunk!interface Vlan2000description --- Global table ---ip address 10.1.1.1 255.255.255.252!interface Vlan2001description --- Green VPN ---ip vrf forwarding Greenip address 11.1.1.1 255.255.255.252! interface Vlan2002description --- Red VPN ---ip vrf forwarding Redip address 12.1.1.1 255.255.255.252

Catalyst-2interface GigabitEthernet2/2description --- Trunk to Catalyst-1 ---switchport trunk encapsulation dot1qswitchport trunk allowed vlan 2000-2002switchport mode trunk spanning-tree portfast trunk!interface Vlan2000description --- Global table ---ip address 10.1.1.2 255.255.255.252!interface Vlan2001description --- Green VPN ---ip vrf forwarding Greenip address 11.11.1.2 255.255.255.252! interface Vlan2002description --- Red VPN ---ip vrf forwarding Redip address 12.1.1.2 255.255.255.252SVI: Switched Virtual Interface

Cisco Catalyst-1g1/1

g2/2

Cisco Catalyst-2

Cisco Catalyst-3

g1/2

g2/2Green VRFRed VRF

23


VRF-Lite End-to-EndTrunk with Routed Ports1. Links between L3 devices defined as routed

port with subinterfaces

2. Global table traffic is sent untagged

3. Each additional subinterface associated to an unique VLAN and mapped to a separate VRF

4. Easier migration: configuration on main interface (used for global traffic) remains unchanged

5. Currently supported on Cisco Catalyst 6500 Series only

Catalyst-1interface GigabitEthernet1/1description --- Global table ---ip address 10.1.1.1 255.255.255.252!interface GigabitEthernet1/1.2001description --- Green VPN ---encapsulation dot1q 2001ip vrf forwarding Greenip address 11.11.1.1 255.255.255.252!interface GigabitEthernet1/1.2002description --- Red VPN ---encapsulation dot1q 2002ip vrf forwarding Redip address 12.1.1.1 255.255.255.252

Catalyst-2interface GigabitEthernet2/2description --- Global table ---ip address 10.1.1.2 255.255.255.252!interface GigabitEthernet2/2.2001description --- Green VPN ---encapsulation dot1q 2001ip vrf forwarding Greenip address 11.1.1.2 255.255.255.252!interface GigabitEthernet1/1.2002description --- Red VPN ---encapsulation dot1q 2002ip vrf forwarding Redip address 12.1.1.2 255.255.255.252

Cisco Catalyst-1g1/1

g2/2

Cisco Catalyst-2

Cisco Catalyst-3

g1/2

g2/2Green VRFRed VRF

24


VRF-Lite End-to-EndHigh Availability Considerations

1. Recommendation is to deploy the Campus HA best practices design guidelines for the physical network

Build fully meshed connections between each distribution block and core

Deploy a fully meshed core

2. VRF-lite deployment consists in virtualizing every network devices and their interconnections

Creation of multiple instances of the same network infrastructure

3. Each logical network inherits the same HA characteristics of the physical network

4. Convergence under most failures scenarios is dictated by direct link failure detection

26


VRF-Lite End-to-EndVirtualizing the Routing Protocol

1. Recommendation is to use in each VRF the same routing protocol already leveraged in global table (usually EIGRPor OSPF)

2. Routing design principles adopted in global table can simply be replicated in each virtual networkSummarization boundaries

IGP timer tuning

Areas definition for OSPF

27


1. Each VRF instance needs a separate IGP process (OSPF) or address family (EIGRP, RIPv2)

Enabled on all L3 devices

2. Devices peer over separate routing instances

router ospf 1network 10.0.0.0 0.255.255.255 area 0passive-interface defaultno passive-interface vlan 2000!router ospf 100 vrf Greennetwork 11.0.0.0 0.255.255.255 area 0no passive-interface vlan 2001!router ospf 200 vrf Rednetwork 12.0.0.0 0.255.255.255 area 0no passive-interface vlan 2002

router eigrp 100network 10.0.0.0 0.255.255.255passive-interface defaultno passive-interface vlan 2000no auto-summary

!address-family ipv4 vrf Greennetwork 11.0.0.0 0.255.255.255no auto-summaryexit-address-family

!address-family ipv4 vrf Rednetwork 12.0.0.0 0.255.255.255no auto-summaryexit-address-family

Cisco Catalyst-2Cisco Catalyst-1

Green VRF

g1/1 g2/2

Red VRF

VLAN 2000–2002

VRFs IGP Peering

VRF-Lite End-to-EndVirtual Routing Processes

28


VRF-Lite End-to-EndMulticast

1. Simplest design choice is leveraging in each VRF the same multicast configuration already in place in global table

PIM mode, RP placement, RP advertisement protocol

2. 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)

3. 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)

29


VRF-Lite End-to-EndCisco Catalyst Platforms Support

1. VRF-lite supported on Cisco Catalyst platforms when running at least “IP Services” images (no support in IP base)

30


Deployment• End-to-End IP based Solution • Easy migration from existing campus architecture• Any to any connectivity within VPNs• Enterprise scale (up to 12 segments)• Supported on Catalyst 6500, 4500, 3700 families• Supported on Nexus 7000

Application and Services• Supports both wired and wireless networks• Multiple VRF-aware Services available

Learning Curve• Familiar routing protocols can be used• IP Alternative to MPLS

Management• Virtual Network Management (VNM) available

with LMS 3.2 (Summer 2009) • Provisioning, Troubleshooting and monitoring

for VRF network

VRF-Lite End-to-EndSummary

Layer 3L2

L2

802.1q Tags

Routed HopNot Bridged

31


Agenda





VRF-Lite End-to-End


MPLS VPN


5. Q and A

32


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 1–3 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

33


VRF-Lite and GRE Tunnels General Design Considerations

1. Recommended to providehub-and-spoke communication (guest access, NACremediation)

2. Point-to-point GRE interfaces on each spoke (spoke-to-spoke communication usually not required)

3. Point-to-point or multipoint GRE on the hub

4. GRE usually enabled on the first L3 hop (access or distribution layer switch depending on the campus deployment)

5. Routing protocol (EIGRP or OSPF) running in the context of each hub-and-spoke topology Green VRF

34


VRF-Lite and GRE TunnelsHigh Availability Considerations

1. The goal is leveraging the high availability embedded in the campus design

Redundant hub/spoke devicesRedundant paths between devices

2. Each spoke device establishes a GRE tunnel to each hub switch

3. Loopback interfaces are used as source and destination of each GRE tunnel

Loopbacks usually defined in global table

4. Traffic is load-balanced across the two GRE tunnels in both upstream and downstream directions

5. Hub/spoke failure can be detected by the routing protocol running in the overlay network

35


ip vrf Green!interface Loopback0ip address 10.126.100.1 255.255.255.255!interface Loopback1ip address 10.126.100.2 255.255.255.255!<snip>!interface Tunnel0description GRE to spoke 1ip vrf forwarding Greenip address 11.1.1.1 255.255.255.0no ip redirectstunnel source Loopback0tunnel destination 10.123.100.1!interface Tunnel1description GRE to spoke 2ip vrf forwarding Greenip address 11.1.2.1 255.255.255.0no ip redirectstunnel source Loopback1tunnel destination 10.123.100.3!<snip>

Hub Configurationip vrf Green!interface Loopback0ip add 10.123.100.1 255.255.255.255!interface Loopback1ip add 10.123.100.2 255.255.255.255!interface Tunnel0description GRE to hub 1ip vrf forwarding Greenip address 11.1.1.2 255.255.255.0tunnel source Loopback0tunnel destination 10.126.100.1!interface Tunnel1description GRE to hub 2ip vrf forwarding Greenip address 11.1.2.2 255.255.255.0tunnel source Loopback1tunnel destination 10.126.200.1!interface Vlan10description Green Subnetip vrf forwarding Greenip address 11.1.100.1 255.255.255.0

Spoke Configuration

VRF-Lite and GRE TunnelsConfigure p2p GRE Tunnels (Hub and Spokes)

36


NHRP: Next Hop Resolution Protocol*

ip vrf Green!interface Loopback0ip address 10.126.100.1 255.255.255.255

!interface Tunnel0description mGRE for Greenip vrf forwarding Greenip address 11.1.1.1 255.255.255.0no ip redirectsip nhrp map multicast dynamicip nhrp network-id 100tunnel source Loopback0tunnel mode gre multipoint

Hub Configuration

VRF-Lite and GRE TunnelsConfigure mGRE Interfaces (Hub Only)

ip vrf Green!interface Loopback0ip add 10.123.100.1 255.255.255.255!interface Loopback1ip add 10.123.100.2 255.255.255.255!interface Tunnel0description GRE to hub 1ip vrf forwarding Greenip address 11.1.1.2 255.255.255.0ip nhrp network-id 100 ip nhrp nhs 11.1.1.1 tunnel source Loopback0tunnel destination 10.126.100.1!interface Tunnel1description GRE to hub 2ip vrf forwarding Greenip address 11.1.2.2 255.255.255.0ip nhrp network-id 200 ip nhrp nhs 11.1.2.1tunnel source Loopback1tunnel destination 10.126.200.1!interface Vlan10description Green Subnetip vrf forwarding Greenip address 11.1.100.1 255.255.255.0

Spoke Configuration

37


VRF-Lite and GRE TunnelsVirtualizing the Routing Protocol

1. The routing protocol enabled in the hub-and-spoke overlay networks brings two advantagesRouting updates serve as GRE keepalives ensuring connectivityLoad balancing of traffic and resiliency are automatically achieved

2. Hub devices learn routes from all the spokes3. Spoke devices can simply install a default route in

routing table4. Different approach for EIGRP and OSPF for virtualizing the

routing protocolEIGRP leverages a single process and address-families associated

each defined VRFOSPF defines a separate process for each defined VRF

38


ip route vrf Green 0.0.0.0 0.0.0.0 11.2.1.10! ip access-list standard default-onlypermit 0.0.0.0!router eigrp 100passive-interface defaultno passive-interface Tunnel0no auto-summary

!address-family ipv4 vrf Greenredistribute static metric 1000 500 255 1 1500network 11.1.1.0 0.0.0.255distribute-list default-only outno auto-summaryautonomous-system 100exit-address-family

Hub Configurationrouter eigrp 100passive-interface defaultno passive-interface Tunnel0no passive-interface Tunnel1no auto-summary!address-family ipv4 vrf Greennetwork 11.1.1.0 0.0.0.255network 11.1.2.0 0.0.0.255network 11.1.100.0 0.0.0.255no auto-summaryautonomous-system 100exit-address-family

Spoke Configuration

VRF-Lite and GRE TunnelsConfigure EIGRP

39


VRF-Lite and GRE TunnelsConfigure OSPF

interface Tunnel0description mGRE tunnelip ospf network broadcast!ip route vrf Green 0.0.0.0 0.0.0.0 11.2.1.10! router ospf 1 vrf Greenlog-adjacency-changespassive-interface defaultno passive-interface Tunnel0network 11.1.1.0 0.0.0.255 area 0default-information originate

Hub Configuration

Spoke Configurationinterface Tunnel0description p2p GRE to hub 1ip ospf network broadcast!interface Tunnel1description p2p GRE to hub 2ip ospf network broadcast!ip access-list standard default-onlypermit 0.0.0.0!router ospf 1 vrf Greenlog-adjacency-changespassive-interface defaultno passive-interface Tunnel0no passive-interface Tunnel1network 11.1.1.0 0.0.0.255 area 0network 11.1.2.0 0.0.0.255 area 0network 11.1.100.0 0.0.0.255 area 200distribute-list default-only in

40


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• GRE supported in SW on Catalyst 4500• GRE supported in HW on Nexus 7000


Learning Curve• Familiar routing protocols can be used • IP Based solution

Management• Future support with Virtual Network Management

(VNM) • Provisioning, Troubleshooting and monitoring

hub-and-spoke topologies

VRF-Lite and GRE TunnelsSummary

Green VRF

41


Agenda





VRF-Lite End-to-End


MPLS VPN


5. Q and A

42


MPLS-VPN—RFC2547 VPNsHow Does It Work?

1. Create L2 VLANs and 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 all Layer 3 interface in the network Enable MPLS

Enable MPLS

PE

PE

PP4. Enable MP-BGP on the PE devices to

exchange VPN routesPEs become iBGP neighbors

iBGP

5. 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)

43


MPLS-VPN - RFC2547 VPNsGeneral Design Considerations

1. Highly scalableUsually deployed in large campus networks

requiring the definition of a large number of VRFs

2. Any to any connectivity per user group

User to cloud connectivity

3. VPN traffic is ‘tunneled’ across the MPLS core

4. Requires the deployment of another control protocol

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

5. Platform support currently restricted to Cisco Catalyst 6500 Series

Support for Cisco Catalyst 6500 Series running MPLS in VSS mode is planned for future release

P P

PP

PE PE PE PE PE PE

PE PE PE PE PE PE

44


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

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

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

2. 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

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

3. Configure LDP for performing label exchange with the neighbors

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

P P

45


Deploying MPLS-VPN in CampusStep 2: Configure MP-BGP Between PEs

1. Leverage route reflectors to improve overall scalability of the solution

2. RRs should be deployed out of the data path (no MPLS or VRF requirement)

Leverage standalone devices connected to the core routers

3. Establish MP-iBGP sessions by leveraging loopback interfaces (can leverage the same loopback used for LDP)

4. Avoid summarization of VPNroutes belonging to each campus distribution block

PE PE

RR2

P

iBGP

iBGP

iBGPSiSi SiSi

PE

RR1

iBGP

iBGP

iBGP

SiSiSiSi

SiSiSiSiPE

48


Deploying MPLS-VPN in Campus High Availability Considerations

1. Campus networks must today support a high degree of redundancy

Need to achieve HA for mission-critical application

Support of advanced technologies (like VoIP)

2. Goal would be to leverage this network redundancy also for VPNtraffic

Use of iBGP multipath load balancing

3. Load balancing VPN traffic minimize outages in PE failure scenarios

50% of flows are unaffected

PE PE

RR2

P

iBGP

iBGP

iBGPSiSi SiSi

PE

RR1

iBGP

iBGP

iBGP

SiSiSiSi

SiSiSiSiPE

50


Deploying MPLS-VPN in Campus Step 3: Configure Redundancy and Load Balancing

1. Configure a different route distinguisher value for the two PE devices belonging to the same distribution blockAllows the RR to “reflect” the prefixes

advertised by both the PEs belonging to the same distribution block

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

ip vrf Redrd 1:2route-target export 10:1route-target import 10:1

router bgp 100!address-family ipv4 vrf Redmaximum-paths ibgp 2 import 2

PE1 PE2

PE3/PE4

Enable iBGP equal cost multipath capabilities

PE3 PE4

RR2

P

iBGP

iBGP

iBGPSiSi SiSi

PE2

RR1

iBGP

iBGP

iBGP

SiSiSiSi

SiSiSiSiPE1

51


PE4

RR

P PSiSi SiSi

SiSiSiSi

PE1 PE2

10.137.12.0/24

loopback 10192.168.100.6

SiSiSiSi

loopback 10192.168.100.5

PE3

Redundancy and Load Balancing How Does It Work?

PE2

3 RR receives the two VPNv4 updates, realizes they are different and reflects both of them to P3 and P4

4 P3 and P4 have now a dual path to the remote subnet 10.137.12.0 (NHs are .5 and .6)

1 PE1 send a VPNv4 update to RR for prefix 10.137.12.0 (belonging to VPN Red)

10.137.12.0RD1

2 PE2 send a VPNv4 update to RR for the same prefix 10.137.12.0

10.137.12.0RD2

52


PE4

RR

P PSiSi SiSi

SiSiSiSi

PE1 PE2

10.137.12.0/24

loopback 10192.168.100.6

SiSiSiSi

g1/2 g1/3

Redundancy and Load Balancing VerificationPE3#sh ip route vrf Red 10.137.12.0Routing entry for 10.137.12.0/24Known via “bgp 100”, distance 200, metric 0, type internalLast update from 192.168.100.6 2w3d agoRouting Descriptor Blocks:192.168.100.6 (Default-IP-Routing-Table), from 192.168.100.1, 2w3d ago

Route metric is 0, traffic share count is 1AS Hops 0

192.168.100.5 (Default-IP-Routing-Table), from 192.168.100.1, 2w3d agoRoute metric is 0, traffic share count is 1AS Hops 0

PE3#sh mls cef vrf Red 10.137.12.0Codes: decap - Decapsulation, + - Push LabelIndex Prefix Adjacency 3219 10.137.12.0/24 Gi1/3 16(+),56(+) (Hash: 0001)

Gi1/2 16(+),39(+) (Hash: 0002)Gi1/3 16(+),55(+) (Hash: 0004)Gi1/2 16(+),37(+) (Hash: 0008)

PE3#sh mls cef 192.168.100.5 Codes: decap - Decapsulation, + - Push LabelIndex Prefix Adjacency 82 192.168.100.5/32 Gi1/3 55(+) (Hash: 0001)

Gi1/2 37(+) (Hash: 0002)PE3#sh mls cef 192.168.100.6Codes: decap - Decapsulation, + - Push LabelIndex Prefix Adjacency 84 192.168.100.6/32 Gi1/3 56(+) (Hash: 0001)

Gi1/2 39(+) (Hash: 0002)

loopback 10192.168.100.5

PE3

loopback 10192.168.100.1

VPN Label IGP Label

53


Deployment• MPLS based solution• Highly scalable L3 VPN solution (Hundreds)• Any-to- any connectivity within VPNs• Supported on Catalyst 6500

(Sup720 and Sup32)


Learning Curve• Longer learning curve for Enterprise

customers- MPLS- Multi-Protocol BGP

Management• Rich CLI and MIB support

P P

PP

PE PE PE PE PE PE

PE PE PE PE PE PE

MPLS-VPN—RFC2547 VPNsSummary

54


Agenda





5. Q&A

55


Extensibility Over the MAN/WAN

1. The private MAN/WAN

2. The Internet

LAN LAN

Tunnels, L2 or L3 VPNs: GRE, RFC2547, etc.

MAN/WAN

Groups Must Be Extensible Over:

56


MAN/WAN ExtensibilityDifferent Options Available

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

2. There are several technical alternatives; some examplesMPLS over L2 service

DMVPN per VRF

RFC2547 over DMVPN

Carrier-supporting-carrier (where the service is available)

3. The choice depends largely on the enterprise’s MAN/WAN contracts and platform support

4. Next-generation MPLS VPN MAN/WAN design guidehttp://www.cisco.com/en/US/netsol/ns656/networking_solutions_design_g

uidances_list.html#anchor13

http://www.cisco.com/en/US/netsol/ns656/networking_solutions_design_guidances_list.html�

http://www.cisco.com/en/US/netsol/ns656/networking_solutions_design_guidances_list.html�

57


Network VirtualizationPutting All Together

Servers

Mainframe

MAN/WAN

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

Virtualized Services:

Firewall, ACE

VLANsPartition

Server Farms

User Identification(Static/NAC/Identity)

Per User RoleL2 VLANs

L3 VRFs

Extending VPNs over MAN/WAN

cloud

58


Enterprise Network Virtualizationpalo/Rozne/cisco-expo-2009/Presentati… · 3. DHCP. DHCP server...

Documents

Transcript of Enterprise Network Virtualizationpalo/Rozne/cisco-expo-2009/Presentati… · 3. DHCP. DHCP server...