Deploying MPLS L3VPN

Transcription

1 Deploying MLS L3VN Nurul Islam Roman 1 Abstract This session describes the implementation of I Virtual rivate Networks (I VNs) using MLS. It is the most common Layer 3 VN technology, as standardized by IETF RFC2547/4364, realizing I connectivity between VN site and MLS network. Service roviders have been using I VN to provide scalable site-to-site/wan connectivity to Enterprises/SMBs for more than a decade. Enterprises have been using it to address network segmentation (virtualization and traffic separation) inside the site e.g. Campus, Data Center. This technology realizes I connectivity between VN site and MLS network. The session will cover: I VN Technology Overview (RFC2547/RFC4364) I VN Configuration Overview I VN-based services (multihoming, Hub&Spoke, extranet, Internet, NAT, VRF-lite, etc.) Best ractices 2 1

2 Terminology Reference LSR: label switch router LS: label switched path The chain of labels that are swapped at each hop to get from one LSR to another VRF: VN routing and forwarding Mechanism in Cisco IOS used to build per-customer RIB and FIB M-BG: multiprotocol BG E: provider edge router interfaces with CE routers : provider (core) router, without knowledge of VN VNv4: address family used in BG to carry MLS-VN routes RD: route distinguisher Distinguish same network/mask prefix in different VRFs RT: route target Extended community attribute used to control import and export policies of VN routes LFIB: label forwarding information base FIB: forwarding information base 3 Agenda I/VN Overview I/VN Services Best ractices Conclusion 4 2

3 Agenda I/VN Overview Technology Overview (How It Works) Configuration Overview I/VN Services Best ractices Conclusion 5 I/VN Technology Overview More than one routing and forwarding tables Control plane VN route propagation Data or forwarding plane VN packet forwarding 6 3

4 I/VN Technology MLS I/VN Topology / Connection Model CE CE E MLS Network E CE CE E Routers Sit at the Edge Use MLS with routers Uses I with CE routers Distributes VN information through M- BG to other E routers M- ibg Session Routers Sit inside the network Forward packets by looking at labels and E routers share a common IG 7 I/VN Technology Overview Separate Routing Tables at E CE2 VN 2 E VN 1 MLS Network IG (OSF, ISIS) Customer Specific Routing Table Routing (RIB) and forwarding table (CEF) dedicated to VN customer VN1 routing table VN2 routing table Referred to as VRF table for <named VN> IOS: show ip route vrf <name> IOS-XR: sh route vrf <name> ipv4 NX-OS: sh ip route vrf <name> Global Routing Table Created when I routing is enabled on E. opulated by OSF, ISIS, etc. running inside the MLS network IOS: show ip route IOS-XR: sh route ipv4 unicast NX-OS: sh ip route 8 4

5 I/VN Technology Overview Virtual Routing and Forwarding Instance CE2 VN 2 VRF Green E VN 1 Ser0/0 VRF Blue MLS Network IG (OSF, ISIS) What s a Virtual Routing and Forwarding (VRF)? Representation of VN customer inside the MLS network Each VN is associated with at least one VRF VRF configured on each E and associated with E-CE interface(s) rivatize an interface, i.e., coloring of the interface No changes needed at CE IOS_E(conf)#ip vrf blue IOS_E(conf)#interface Ser0/0 IOS_E(conf)#ip vrf forwarding blue 9 I/VN Technology Overview Virtual Routing and Forwarding Instance EIGR, ebg, OSF, RIv2, Static CE2 VN 2 VRF Green E VN 1 Ser0/0 VRF Blue MLS Network IG (OSF, ISIS) E installs the internal routes (IG) in global routing table E installs the VN customer routes in VRF routing table(s) VN routes are learned from CE routers or remote E routers VRF-aware routing protocol (static, RI, BG, EIGR, OSF) on each E VN customers can use overlapping I addresses BG plays a key role. Let s understand few BG specific details

6 I/VN Technology Overview Control lane = Multi-rotocol BG (M-BG) 8 Bytes 4 Bytes 1: RD Iv4 VNv4 8 Bytes Route- Target 4 Bytes Label M- BG UDATE Message Showing VNv4 Address, RT, Label only M-BG Customizes the VN Customer Routing Information as per the Locally Configured VRF Information at the E using: Route Distinguisher (RD) Route Target (RT) Label 11 I/VN Technology Overview: Control lane M-BG UDATE Message Capture Visualize how the BG UDATE message advertising VNv4 routes looks like. Notice the ath Attributes. Reference Reference Route Target = 3:3 VNv4 refix 1:1: /30 ; Label =

7 I/VN Technology Overview: Control lane Route-Distinguisher (rd) 8 Bytes 4 Bytes 1: RD Iv4 VNv4 8 Bytes Route- Target 3 Bytes Label M- BG UDATE Message Showing VNv4 Address, RT, Label only VN customer Iv4 prefix is converted into a VNv4 prefix by appending the RD (1:1, say) to the Iv4 address ( , say) => 1:1: Makes the customer s Iv4 address unique inside the S MLS network. Route Distinguisher (rd) is configured in the VRF at E RD is not a BG attribute, just a field. * After 12.4(3)T, 12.4(3) 12.2(32)S, 12.0(32)S etc., RD Configuration within VRF Has Become Optional. rior to That, It Was Mandatory. IOS_E# ip vrf green rd 1:1 13 I/VN Technology Overview: Control lane Route-Target (rt) 8 Bytes 4 Bytes 8 Bytes 3 Bytes 1: :2 RD VNv4 Iv4 Route- Target Label Route-target (rt) identifies which VRF(s) keep which VN prefixes rt is an 8-byte extended community attribute. Each VRF is configured with a set of route-targets at E Export and Import route-targets must be the same for any-to-any I/VN Export route-target values are attached to VN routes in E->E M-iBG advertisements IOS_E# ip vrf green route- target import 3:3 route- target export 3:3 route- target export 10:3 14 7

8 I/VN Technology Overview: Control lane Label 8 Bytes 4 Bytes 8 Bytes 3 Bytes 1:1 RD VNv :2 50 Iv4 Route- Target Label E assigns a label for the VNv4 prefix;; Next-hop-self towards M-iBG neighbors by default i.e. E sets the NEXT-HO attribute to its own address (loopback) Label is not an attribute. E addresses used as BG next-hop must be uniquely known in IG Do not summarize the E loopback addresses in the core 15 I/VN Technology Overview: Control lane utting it all together Site / /24 Next- Hop=CE M- ibg Update: RD: Next- Hop=E- 1 RT=1:2, Label=100 E2 CE2 Site 2 MLS Backbone receives an Iv4 update (ebg/osf/isis/ri/eigr) translates it into VNv4 address and constructs the M-iBG UDATE message Associates the RT values (export RT =1:2, say) per VRF configuration Rewrites next-hop attribute to itself Assigns a label (100, say);; Installs it in the MLS forwarding table. sends M-iBG update to other E routers 16 8

9 I/VN Technology Overview: Control lane utting it all together Site / /24 Next- Hop=CE M- ibg Update: RD: Next- Hop=E- 1 RT=1:2, Label= /24 Next- Hop=E- 2 4 E2 5 CE2 Site 2 MLS Backbone E2 receives and checks whether the RT=1:2 is locally configured as import RT within any VRF, if yes, then E2 translates VNv4 prefix back to Iv4 prefix Updates the VRF CEF Table for /24 with label=100 E2 advertises this Iv4 prefix to CE2 (using whatever routing protocol) 17 I/VN Technology Overview Forwarding lane Site 1 Site /24 CE2 E2 MLS Backbone Customer Specific Forwarding Table Stores VN routes with associated labels VN routes learned via BG Labels learned via BG IOS:show ip cef vrf <name> NX-OS: show forwarding vrf <name> IOS-XR: show cef vrf <name> ipv4 Global Forwarding Table Stores next- hop i.e. E routes with associated labels Next- hop i.e. E routes learned through IG Label learned through LD or RSV IOS:show ip cef NX-OS: show forwarding ipv4 IOS-XR: show cef ipv4 18 9

10 I/VN Technology Overview: Forwarding lane acket Forwarding Site 1 Site /24 CE2 3 4 E I acket I acket MLS acket E2 imposes two labels (MLS headers) for each I packet going to site2 Outer label is learned via LD;; Corresponds to address (e.g. IG route) Inner label is learned via BG;; corresponds to the VN address (BG route) 1 does the enultimate Hop opping (H) retrieves I packet (from received MLS packet) and forwards it to. 19 I/VN Technology: Forwarding lane MLS I/VN acket Capture Reference Reference This capture might be helpful if you never captured an MLS packet before. Ethernet Header Outer Label Inner Label I acket 20 10

11 Agenda I/VN Overview Technology Overview Configuration Overview (IOS, IOS-XR and NX-OS) I/VN Services Best ractices Conclusion 21 MLS based I/VN Sample Configuration (IOS) Reference Reference VRF Definition Site /24 ip vrf VN-A rd 1:1 route-target export 100:1 route-target import 100:1 vrf definition VN-A rd 1:1 address-family ipv4 route-target export 100:1 route-target import 100:1 Se interface Serial0 ip address /24 ip vrf forwarding VN-A interface Serial0 ip address /24 vrf forwarding VN-A E- Configuration Interface Serial1 ip address mpls ip Se0 s1 router ospf 1 network area

12 MLS based I/VN Sample Configuration (IOS) Reference E: M- IBG Config RR E2 router bgp 1 neighbor remote-as 1 neighbor update-source loopback0 address-family vpnv4 neighbor activate neighbor send-community both RR: M- IBG Config RR E2 RR router bgp 1 no bgp default route-target filter neighbor remote-as 1 neighbor update-source loopback0 address-family vpnv4 neighbor route-reflector- client neighbor activate 23 MLS based I/VN Sample Configuration (IOS) Reference E- CE Routing: BG Site / router bgp 1 address-family ipv4 vrf VN-A neighbor remote-as 2 neighbor activate exit-address-family E- CE Routing: OSF Site / router ospf 1 router ospf 2 vrf VN-A network area 0 redistribute bgp 1 subnets

13 MLS based I/VN Sample Configuration (IOS) Reference E- CE Routing: RI Site / router rip address-family ipv4 vrf VN-A version 2 no auto-summary network redistribute bgp 1 metric transparent E- CE Routing: EIGR router eigrp 1 Site / address-family ipv4 vrf VN-A no auto-summary network autonomous-system 10 redistribute bgp 1 metric MLS based I/VN Sample Configuration (IOS) Reference E- CE Routing: Static Site /24 ip route vrf VN-A

14 MLS based I/VN Sample Configuration (IOS) Reference If E- CE rotocol Is Non- BG, then Redistribution of Local VN Routes into M- IBG Is Required (Shown Below) E- RR (VN Routes to VNv4) Site 1 RR router bgp 1 neighbor remote-as 1 neighbor update-source loopback 0 address-family ipv4 vrf VN-A redistribute {rip connected static eigrp ospf} Having familiarized with IOS based config, let s peek through IOS-XR and NX- OS config for VNs 27 MLS based I/VN Sample Config (IOS-XR) VRF Definition Site / GE0 vrf VN-A address-family ipv4 unicast import route-target 100:1 export route-target 100:1 router bgp 1 vrf VN-A rd 1:1 Reference Interface GigaEthernet0/0/0/0 ipv4 address vrf VN-A Reference E- Configuration GE0 GE1 mpls ldp route-id interface GigabitEthernet0/0/0/1 mpls oam router ospf

15 MLS based I/VN Sample Config (IOS-XR) Reference E: M- IBG Config RR E2 router bgp 1 router-id address-family vpnv4 unicast neighbor remote-as 1 update-source loopback0 address-family vpnv4 unicast RR: M- IBG Config RR E2 RR router bgp 1 router-id address-family vpnv4 unicast neighbor remote-as 1 update-source loopback0 address-family vpnv4 unicast route-reflector-client 29 MLS based I/VN Sample Config (IOS-XR) Reference E- CE Routing: BG Site / GE router bgp 1 vrf VN-A address-family ipv4 unicast neighbor remote-as 2 address-family ipv4 unicast route-policy pass-all in out E- CE Routing: OSF Site /24 GE router ospf 2 vrf VN-A redistribute bgp 1 area 0 interface GigabitEthernet0/0/0/

16 MLS based I/VN Sample Config (IOS-XR) Reference E- CE Routing: RI Site / GE0 router rip vrf VN-A interface GigabitEthernet0/0/0/0 redistribute bgp E- CE Routing: EIGR Site / GE0 router eigrp 1 vrf VN-A address-family ipv4 as 10 default-metric interface GigabitEthernet0/0/0/0 redistribute bgp MLS based I/VN Sample Config (IOS-XR) Reference E- CE Routing: Static Site / GE0 router static vrf VN-A address-family ipv4 unicast ip route /

17 MLS based I/VN Sample Config (IOS-XR) Reference If E- CE rotocol Is Non- BG, then Redistribution of Local VN Routes into M- IBG Is Required (Shown Below) E- RR (VN Routes to VNv4) Site 1 RR router bgp 1 vrf VN-A address-family ipv4 unicast redistribute {rip connected static eigrp ospf} 33 Agenda I/VN Overview I/VN Services 1. Load-Sharing for Multihomed VN Sites 2. Hub and Spoke Service 3. Extranet Service 4. Internet Access Service 5. I/VN over I Transport 6. Iv6 VN Service Best ractices Conclusion 34 17

18 I/VN Services: 1. Loadsharing of VN Traffic RR /24 E2 CE2 Site A 2 MLS Backbone Site B Route Advertisement VN sites (such as Site A) could be multihomed VN customer may demand the traffic (to the multihomed site) be loadshared 35 I/VN Services: 1. Loadsharing of VN Traffic: Two Scenarios 1 CE à 2 Es /24 Site A 1 2 RR MLS Backbone E2 CE2 Site B Traffic Flow 2 CEs à 2 Es RR /24 Site A CE2 1 2 MLS Backbone E2 CE2 Site B Traffic Flow 36 18

19 I/VN Services: 1. Loadsharing of VN Traffic: IOS Configuration Supported in IOS, and IOS- XR. Configure unique RD per VRF per E for multihomed site/interfaces Assuming RR exists Enable BG multipath within the relevant BG VRF address-family at remote E routers such as E2 (why E2?). 1 ip vrf green rd 300:11 route- target both 1:1 1 RR 2 router bgp 1 address- family ipv4 vrf green maximum- paths eibgp /24 Site A ip vrf green rd 300:12 route- target both 1:1 2 MLS Backbone 1 E2 CE2 ip vrf green rd 300:13 route- target both 1:1 Site B 37 I/VN Services: 1. VN Fast Convergence E-CE Link Failure Supported in IOS, and IOS- XR Traffic Is Dropped by 1 1 RR VN Traffic Redirected VN Traffic /24 Site A 2 MLS Backbone E2 CE2 Site B In a classic multi-homing case, 1, upon detecting the E-CE link failure, sends BG message to withdraw the VN routes towards other E routers. This results in the remote E routers selecting the alternate bestpath (if any), but until then, they keep sending the MLS/VN traffic to 1, which keeps dropping the traffic. Use IC Edge feature to minimize the loss due to the E-CE link failure from sec to msec

20 I/VN Services: 1. VN Fast Convergence E-CE Link Failure Supported in IOS, and IOS- XR Traffic Is Redirected by 1 1 RR VN Traffic Redirected VN Traffic /24 E2 CE2 Site A 2 MLS Backbone Site B BG IC Edge feature helps 1 to minimize the traffic loss from sec to msec, during local E-CE link failure 1 immediately reprograms the forwarding entry with the alternate BG best path (which is via 2) 1 redirects the bound traffic to 2 (with the right label) In parallel, 1 sends the BG withdraw message to RR/E2, which will run the bestpath algorithm and removes the path learned via 1, and then adjust their forwarding entries via 2 This feature is independent of whether multipath is enabled on E2 or not, however, dependent on VN site multihoming 39 Agenda I/VN Overview I/VN Services 1. Load-Sharing for Multihomed VN Sites 2. Hub and Spoke Service 3. Extranet Service 4. Internet Access Service 5. I/VN over I Transport 6. Iv6 VN Service Best ractices Conclusion 40 20

21 I/VN Services: 2. Hub and Spoke Service Many VN deployments need to be hub and spoke Spoke to spoke communication via Hub site only Despite MLS based I/VN s implicit any-to-any, i.e., full-mesh connectivity, hub and spoke service can easily be offered Done with import and export of route-target (RT) values Requires unique RD per VRF per E E routers can run any routing protocol with VN customer hub and spoke sites independently 41 I/VN Services: 2. Hub and Spoke Service Two configuration Options : 1. 1 E-CE interface to Hub & 1 VRF;; 2. 2 E-CE interfaces to Hub & 2 VRFs;; Use option#1 if Hub site advertises default or summary routes towards the Spoke sites, otherwise use Option#2 HDVRF feature* allows the option#2 to use just one E-CE interface * HDVRF Feature Is Discussed Later 42 21

22 Import and Export RT Values Must Be Different I/VN Services: 2. Hub and Spoke Service: IOS Configuration Option#1 Supported in IOS, NXOS and IOS- XR ip vrf green- spoke1 description VRF for SOKE A rd 300:111 route- target export 1:1 route- target import 2:2 Spoke A /24 CE- SA E- SA ip vrf HUB description VRF for HUB rd 300:11 route- target import 1:1 route- target export 2:2 E- Hub Eth0/0 Spoke B /24 CE- SB E- SB MLS VN Backbone CE- Hub ip vrf green- spoke2 description VRF for SOKE B rd 300:112 route- target export 1:1 route- target import 2:2 Note: Only VRF Configuration Is Shown Here 43 Import and Export RT Values Must Be Different I/VN Services: 2. Hub and Spoke Service: IOS Configuration Option#2 Supported in IOS, NXOS and IOS- XR ip vrf green- spoke1 description VRF for SOKE A rd 300:111 route- target export 1:1 route- target import 2:2 Spoke A /24 CE- SA E- SA ip vrf HUB- IN description VRF for traffic from HUB rd 300:11 route- target import 1:1 Spoke B /24 CE- SB ip vrf green- spoke2 description VRF for SOKE B rd 300:112 route- target export 1:1 route- target import 2:2 E- SB E- Hub MLS VN Backbone Eth0/0.1 Eth0/0.2 CE- Hub ip vrf HUB- OUT description VRF for traffic to HUB rd 300:12 route- target export 2:2 Note: Only VRF Configuration Is Shown Here 44 22

23 I/VN Services: 2. Hub and Spoke Service: Configuration Option#2 Supported in IOS, NXOS and IOS- XR If BG is used between every E and CE, then allowas-in and as-override* knobs must be used at the E_Hub** Otherwise AS_ATH looping will occur * Only If Hub and Spoke Sites Use the Same BG ASN ** Configuration for This Is Shown on the Next Slide 45 I/VN Services: 2. Hub and Spoke Service: Configuration Option#2 ip vrf green- spoke1 description VRF for SOKE A rd 300:111 route- target export 1:1 route- target import 2:2 Spoke A /24 CE- SA E- SA router bgp <ASN> address- family ipv4 vrf HUB- IN neighbor <CE> as- override ip vrf HUB- IN description VRF for traffic from HUB rd 300:11 route- target import 1:1 Supported in IOS, NXOS and IOS- XR Spoke B /24 CE- SB E- SB E- Hub MLS VN Backbone Eth0/0.1 Eth0/0.2 CE- Hub ip vrf green- spoke2 description VRF for SOKE B rd 300:112 route- target export 1:1 route- target import 2:2 ip vrf HUB- OUT description VRF for traffic to HUB rd 300:12 route- target export 2:2 router bgp <ASN> address- family ipv4 vrf HUB- OUT neighbor <CE> allowas- in

24 I/VN Services: 2. Hub and Spoke Service: Control lane (Option#2) Two VRFs at the E-Hub: VRF HUB-IN to learn every spoke routes from remote Es VRF HUB-OUT to advertise spoke routes or summary /16 routes to remote Es Supported in IOS, NXOS and IOS- XR VRF FIB and LFIB Destination NextHop Label /16 E- Hub /24 CE- SA MLS Backbone FIB I Forwarding Table LFIB MLS Forwarding Table Spoke A /24 CE- SA E- SA M- ibg Update /24 Label 40 Route- Target 1:1 VRF HUB- IN FIB and LFIB Destination NextHop Label /24 E- SA /24 E- SB 50 VRF FIB and LFIB /16 E- Hub /24 CE- SB Spoke B /24 CE- SB E- SB M- ibg Update /24 Label 50 Route- Target 1:1 M- ibg Update /16 Label 35 Route- Target 2:2 VRF HUB- IN E- Hub VRF HUB- OUT VRF HUB- OUT FIB Destination NextHop /16 CE- H1 CE- Hub 47 I/VN Services: 2. Hub and Spoke Service: Forwarding lane (Option#2) Supported in IOS, NXOS and IOS- XR This Is How the Spoke- to- Spoke Traffic Flows Spoke A / CE- SA E- SA MLS Backbone L Spoke B /24 CE- SB E- SB E- Hub L VRF HUB- IN CE- Hub VRF HUB- OUT L1 Is the Label to Get to E- Hub L2 Is the Label to Get to E- SA 48 24

25 I/VN Services: 2. What If Many Spoke Sites Connect to the Same E Router? If more than one spoke router (CE) connects to the same E router (within the same VRF), then such spokes can reach other without needing the hub. Defeats the purpose of hub and spoke L CE- SA1 E- Hub Half-duplex VRF is the answer Uses two VRFs on the E (spoke) router : CE- SA2 E- SA CE- SA3 A VRF for spoke->hub communication (e.g. upstream) A VRF for spoke<-hub communication (e.g. downstream) Note: 12.2(33) SRE Supports Any Interface Type (Eth, Ser, OS, Virtual- Access, etc.) 49 I/VN Services: 2. Hub and Spoke Service: Half-Duplex VRF ip vrf green-up description VRF - upstream traffic rd 300:111 route-target import 2:2 Spoke A /24 CE- SA S w GE0/0 E- SA ip vrf green-down description VRF - downstream traffic rd 300:112 route-target export 1:1 MLS Backbone ip vrf HUB-IN description VRF for traffic from HUB rd 300:11 route-target import 1:1 Hub Site Supported in IOS Spoke B /24 CE- SB E- Hub Interface GigEthernet 0/0 ip address ip vrf forward green-up downstream green-down.. CE- Hub ip vrf HUB-OUT description VRF for traffic to HUB rd 300:12 route-target export 2:2 Upstream VRF Downstream VRF 1. E- SA installs the Spoke routes only in downstream VRF i.e. green- down 2. E- SA installs the Hub routes only in upstream VRF i.e. green- up 3. E- SA forwards the incoming I traffic (from Spokes) using upstream VRF i.e. green- up routing table. 4. E- SA forwards the incoming MLS traffic (from Hub) using downstream VRF i.e. green- down routing table 50 25

26 Agenda I/VN Overview I/VN Services 1. Load-Sharing for Multihomed VN Sites 2. Hub and Spoke Service 3. Extranet Service 4. Internet Access Service 5. I/VN over I Transport 6. Iv6 VN Service Best ractices Conclusion 51 MLS-VN Services 3. Extranet VN MLS based I/VN, by default, isolates one VN customer from another Separate virtual routing table for each VN customer Communication between VNs may be required i.e., extranet External intercompany communication (dealers with manufacturer, retailer with wholesale provider, etc.) Management VN, shared-service VN, etc. Needs to share the import and export route-target (RT) values within the VRFs of extranets. Export-map or import-map may be used for advanced extranet

27 MLS-VN Services 3. Extranet VN Simple Extranet (IOS Config sample) Supported in IOS, NXOS and IOS- XR MLS Backbone VN_A Site# /16 E /16 VN_A Site# /16 VN_B Site#1 ip vrf VN_A rd 3000:111 route- target import 3000:111 route- target export 3000:111 route- target import 3000:222 ip vrf VN_B rd 3000:222 route- target import 3000:222 route- target export 3000:222 route- target import 3000:111 All Sites of Both VN_A and VN_B Can Communicate with Each Other 53 MLS-VN Services 3. Extranet VN Advanced Extranet (IOS Config sample) Supported in IOS, NXOS and IOS- XR MLS Backbone VN_A Site# /16 E /16 VN_A Site# /16 VN_B Site#1 ip vrf VN_A rd 3000:111 route- target import 3000:111 route- target export 3000:111 route- target import 3000:1 import map VN_A_Import export map VN_A_Export route- map VN_A_Export permit 10 match ip address 1 set extcommunity rt 3000:2 additive route- map VN_A_Import permit 10 match ip address 2 access- list 1 permit access- list 2 permit ip vrf VN_B rd 3000:222 route- target import 3000:222 route- target export 3000:222 route- target import 3000:2 import map VN_B_Import export map VN_B_Export route- map VN_B_Export permit 10 match ip address 2 set extcommunity rt 3000:1 additive route- map VN_B_Import permit 10 match ip address 1 access- list 1 permit access- list 2 permit Lack of Additive Would Result in 3000:222 Being Replaced with 3000:1. We Don t Want That. Only Site #1 of Both VN_A and VN_B Would Communicate with Each Other 54 27

28 Agenda I/VN Overview I/VN Services 1. Load-Sharing for Multihomed VN Sites 2. Hub and Spoke Service 3. Extranet Service 4. Internet Access Service 5. I/VN over I Transport 6. Iv6 VN Service Best ractices Conclusion 55 MLS-VN Services 4. Internet Access Service to VN Customers Internet access service could be provided as another value-added service to VN customers Security mechanism must be in place at both provider network and customer network To protect from the Internet vulnerabilities VN customers benefit from the single point of contact for both Intranet and Internet connectivity 56 28

29 MLS-VN Services 4. Internet Access: Design Options Four Options to rovide the Internet Service - 1. VRF specific default route with global keyword 2. Separate E-CE sub-interface (non-vrf) 3. Extranet with Internet-VRF 4. VRF-aware NAT 57 MLS-VN Services 4. Internet Access: Design Options 1. VRF specific default route 1.1 Static default route to move traffic from VRF to Internet (global routing table) 1.2 Static routes for VN customers to move traffic from Internet (global routing table) to VRF 2. Separate E-CE subinterface (non-vrf) May run BG to propagate Internet routes between E and CE 3. Extranet with Internet-VRF VN packets never leave VRF context;; issue with overlapping VN address 4. Extranet with Internet-VRF along with VRF-aware NAT VN packets never leave VRF context;; works well with overlapping VN address 58 29

30 I/VN Services: Internet Access 4.1 Option#1: VRF Specific Default Route Supported in IOS Site /16 SO MLS Backbone ASBR Internet # ip vrf VN-A rd 100:1 route-target both 100:1 Interface Serial0 ip address ip vrf forwarding VN-A Router bgp 100 no bgp default ipv4-unicast redistribute static neighbor remote 100 neighbor activate neighbor next-hop-self neighbor update-source loopback0 ip route vrf VN-A global ip route Serial Internet GW A default route, pointing to the ASBR, is installed into the site VRF at each E The static route, pointing to the VRF interface, is installed in the global routing table and redistributed into BG 59 I/VN Services: Internet Access 4.1 Option#1: VRF Specific Default Route (Forwarding) Supported in IOS, Site / : Global Routing/FIB Table Destination Label/Interface /32 Label= /16 Serial 0 I acket S0 : VRF Routing/FIB Table Destination Label/Interface / (Global) Site- 1 Serial MLS acket I acket ros Different Internet gateways Can be used for different VRFs E routers need not to hold the Internet table Simple configuration MLS Backbone MLS acket E2 I acket Cons S0 Using default route for Internet Internet ( /16) I acket E2: Global Table and LFIB Destination Label/Interface /32 Label= / /16 Serial 0 Routing does not allow any other default route for intra- VN routing Increasing size of global routing table by leaking VN routes Static configuration (possibility of traffic blackholing) 60 30

31 I/VN Services: Internet Access 4.2 Option#2: Separate E-CE Subinterfaces Site1 Supported in IOS, NXOS and IOS- XR /16 ip vrf VN-A rd 100:1 route-target both 100:1 Se0.1 Se MLS Backbone ibg E Internet GW Internet Internet Interface Serial0.1 ip vrf forwarding VN-A ip address frame-relay interface-dlci 100 Interface Serial0.2 ip address frame-relay interface-dlci 200 Router bgp 100 no bgp default ipv4-unicast neighbor remote-as has one sub- interface associated to a VRF for VN routing - CE has another subinterface (global) for Internet routing may have ebg peering with over the global interface and advertise full Internet routes or a default route to E2 must advertise VN/site1 routes to the Internet. 61 I/VN Services: Internet Access 4.2 Option#2: Separate E-CE Subinterfaces (Forwarding) Site /16 CE Routing Table VN Routes Serial0.1 Internet Routes Serial0.2 I acket S0.1 S MLS Backbone I acket MLS acket E E- Internet GW Internet Internet Supported in IOS, NXOS and IOS- XR Global Table and FIB Internet Routes Label=30 ros 1. CE is dual- homed and can perform Optimal Routing 2. Traffic Separation Done by CE Cons 1. E to Hold Full Internet Routes or default route via the Internet GW. BG Complexities Introduced at CE; May Need to Aggregate to Avoid AS_ATH Looping 62 31

32 I/VN Services: Internet Access 4.3 Option#3: Extranet with Internet-VRF Supported in IOS, NXOS and IOS- XR The Internet routes could be placed within the VRF at the Internet-GW i.e., ASBR VRFs for customers could extranet with the Internet VRF and receive either default, partial or full Internet routes Default route is recommended Be careful if multiple customer VRFs, at the same E, are importing full Internet routes Works well only if the VN customers don t have overlapping addresses 63 I/VN Services: Internet Access 4.4 Option#4: Using VRF-Aware NAT Supported in IOS, If the VN customers need Internet access without Internet routes, then VRFaware NAT can be used at the Internet-GW i.e., ASBR The Internet GW doesn t need to have Internet routes either Overlapping VN addresses is no longer a problem More in the VRF-aware NAT slides 64 32

33 Agenda I/VN Overview I/VN Services 1. Load-Sharing for Multihomed VN Sites 2. Hub and Spoke Service 3. Extranet Service 4. Internet Access Service 5. I/VN over I Transport 6. Iv6 VN Service Best ractices Conclusion 65 I/VN Services: 10. roviding MLS/VN over I Transport Reference Supported in IOS, NXOS and IOS- XR MLS/VN (rfc2547) can also be deployed using I transport No MLS needed in the core E-to-E I tunnel is used, instead of MLS tunnel, for sending MLS/VN packets MLS labels are still allocated for VN prefixes by E routers and used only by the E routers MLS/VN packet is encapsulated inside an I header I tunnel could be GRE, mgre etc

34 I/VN Services: 10. roviding MLS/VN over I Transport Reference Supported in IOS, NXOS and IOS- XR VRF GRE/I Tunnel I VRF E2 CE2 Src Add Dst Add Data I Header GRE/I header and VN label imposed on VN traffic by GRE Header VN Label VN traffic is forwarded towards egress E using I forwarding Egress E2 decapsulates, and uses VN label to forward packet to CE2 I acket Src Add Dst Add Data Src Add Dst Add Data Source Agenda I/VN Overview I/VN Services 1. Load-Sharing for Multihomed VN Sites 2. Hub and Spoke Service 3. Extranet Service 4. Internet Access Service 5. I/VN over I Transport 6. Iv6 VN Service Best ractices Conclusion 68 34

35 I/VN Services: 11. Iv6 VN Service Supported in IOS, NXOS and IOS- XR Similar to Iv4 VN, Iv6 VN can also be offered. Referred to as Iv6 VN rovider Edge (6VE). No modification on the MLS core Core can stay on Iv4 E-CE interface can be single-stack Iv6 or dual-stack Iv4 and Iv6 VNs can be offered on the same E-CE interface Config and operation of Iv6 VN are similar to Iv4 VN v4 and v6 VN A CE VN A v4 and v6 CE VN B v6 Only CE E E MLS/VN Network ibg Sessions in VNv4 and VNv6 Address- Families E E v4 and v6 CE v6 Only CE VN B VN A 69 I/VN Services: 11. Iv6 VN Service IOS_E# vrf definition v2 rd 2:2 address-family ipv6 route-target export 2:2 route-target import 2:2 router bgp 1 address-family vpnv6 neighbor activate neighbor send-community both address-family ipv6 vrf v2 neighbor 200::2 remote-as neighbor 200::2 activate IOS-XR_E# vrf v2 address-family ipv6 unicast route-target export 2:2 route-target import 2:2 router bgp 1 address-family vpnv6 unicast neighbor remote-as address-family vpnv6 unicast vrf v2 rd 2:2 address-family ipv6 unicast neighbor 200::2 remote-as address-family ipv6 unicast NXOS_E# vrf context v2 rd 2:2 address-family ipv6 unicast route-target export 2:2 route-target import 2:2 router bgp 1 neighbor remote-as 1 update-source loopback0 address-family vpnv6 unicast send-community extended vrf vpn1 neighbor 200::2 remote-as address-family ipv6 unicast Supported in IOS, NXOS and IOS- XR v4 and v6 VN A CE VN A v4 and v6 CE VN B v6 Only CE E E MLS/VN Network ibg Sessions in VNv4 and VNv6 Address- Families E E v4 and v6 CE v6 Only CE VN B VN A 70 35

36 Agenda I/VN Overview I/VN Services Best ractices Conclusion 71 Best ractices (1) 1. Use RR to scale BG;; deploy RRs in pair for the redundancy Keep RRs out of the forwarding paths and disable CEF (saves memory) 2. Choose AS/I format for RT and RD i.e., ASN: X Reserve first few 100s of X for the internal purposes such as filtering 3. Consider unique RD per VRF per E, Helpful for many scenarios such as multi-homing, hub&spoke etc. 4. Don t use customer names (V458:GodFatherNYC32ndSt) as the VRF names;; nightmare for the NOC. Consider v101, v102, v201, v202, etc. and Use VRF description for naming 5. Utilize S s public address space for E-CE I addressing Helps to avoid overlapping;; Use /31 subnetting on E-CE interfaces 72 36

37 Best ractices (2) 6. Limit number of prefixes per-vrf and/or per-neighbor on E Max-prefix within VRF configuration;; Suppress the inactive routes Max-prefix per neighbor (E-CE) within OSF/RI/BG VRF af 7. Leverage BG refix Independent Convergence (IC) for fast convergence <100ms (Iv4 and Iv6): IC Core IC Edge Best-external advertisement Next-hop tracking (ON by default) 8. Consider RT-constraint for Route-reflector scalability 9. Consider BG slow peer for E or RR faster BG convergence 73 Agenda I/VN Overview I/VN Services Best ractices Conclusion 74 37

38 Conclusion MLS based I/VN is the most optimal L3VN technology Any-to-any Iv4 or Iv6 VN topology artial-mesh, Hub and Spoke topologies also possible Various I/VN services for additional value/revenue I/VN paves the way for virtualization & Cloud Services Benefits whether S or Enterprise Cisco and/or its affiliates. All rights reserved. 38

39 Iv6 Addressing An Iv6 address is 128 bits long So the number of addresses are 2^128 = (39 decimal digits) =0xffffffffffffffffffffffffffffffff (32 hexadecimal digits) In hex 4 bit (nibble) is represented by a hex digit So 128 bit is reduced down to 32 hex digit Iv6 Address Representation Hexadecimal values of eight 16 bit fields - X:X:X:X:X:X:X:X (X=16 bit number, ex: A2FE) - 16 bit number is converted to a 4 digit hexadecimal number Example: - FE38:DCE3:124C:C1A2:BA03:6735:EF1C:683D Abbreviated form of address - 4EED:0023:0000:0000:0000:036E:1250:2B00-4EED:23:0:0:0:36E:1250:2B00-4EED:23::36E:1250:2B00 - (Null value can be used only once) 39

40 Iv6 addressing structure 128 bits Network refix Interface ID IS /32 Customer Site /48 End Site Subnet /64 Device 128 Bit Address Iv6 addressing model Iv6 Address type Unicast An identifier for a single interface RFC 4291 Anycast An identifier for a set of interfaces Multicast An identifier for a group of nodes 40

41 Addresses Without a Network refix Localhost ::1/128 Unspecified Address ::/128 Iv4-mapped Iv6 address ::ffff/96 [a.b.c.d] Iv4-compatible Iv6 address ::/96 [a.b.c.d] 81 Local Addresses With Network refix Link Local Address A special address used to communicate within the local link of an interface i.e. anyone on the link as host or router This address in packet destination that packet would never pass through a router fe80::/

42 Local Addresses With Network refix Unique Local Iv6 Unicast Address Addresses similar to the RFC 1918 / private address like in Iv4 but will ensure uniqueness A part of the prefix (40 bits) are generated using a pseudo-random algorithm and it's improbable that two generated ones are equal fc00::/7 Example webtools to generate ULA prefix Global Addresses With Network refix IV6 Global Unicast Address Global Unicast Range: ::/ ::/3 All five RIRs are given a /12 from the /3 to further distribute within the RIR region ANIC 2400:0000::/12 ARIN 2600:0000::/12 AfriNIC 2C00:0000::/12 LACNIC 2800:0000::/12 Ripe NCC 2A00:0000::/

43 Examples and Documentation refix Two address ranges are reserved for examples and documentation purpose by RFC 3849 For example 3fff:ffff::/32 For documentation 2001:0DB8::/32 85 Interface ID The lowest-order 64-bit field addresses may be assigned in several different ways: auto-configured from a 48-bit MAC address expanded into a 64-bit EUI-64 assigned via DHC manually configured auto-generated pseudo-random number possibly other methods in the future 43

44 EUI-64 Mac Address B 0 E C EUI-64 Address B 0 E C U/L bit F F F E Interface Identifier B 0 F F F E E C Iv6 Neighbor Discovery (ND) Iv6 use multicast (L2) instead of broadcast to find out target host MAC address It increases network efficiency by eliminating broadcast from L2 network Iv6 ND use ICM6 as transport Compared to Iv4 AR no need to write different AR for different L2 protocol i.e. Ethernet etc. 44

45 Iv6 Neighbor Discovery (ND) Solicited Node Multicast Address Start with FF02:0:0:0:0:1:ff::/104 Last 24 bit from the interface IV6 address Example Solicited Node Multicast Address IV6 Address 2406:6400:0:0:0:0:0000:0010 Solicited Node Multicast Address is FF02:0:0:0:0:1:ff00:0010 All host listen to its solicited node multicast address corresponding to its unicast and anycast address (If defined) Iv6 Neighbor Discovery (ND) Host A would like to communicate with Host B Host A Iv6 global address 2406:6400::10 Host A Iv6 link local address fe80::226:bbff:fe06:ff81 Host A MAC address 00:26:bb:06:ff:81 Host B Iv6 global address 2406:6400::20 Host B Link local UNKNOWN [Gateway if outside the link] Host B MAC address UNKNOWN How Host A will create L2 frame for Host B? 45

46 Iv6 Neighbor Discovery (ND) Iv6 autoconfiguration Is this address unique? 2001:1234:1:1/64 network Assign FE80::310:BAFF:FE64:1D Tentative address (link- local address) Well- known link local prefix +Interface ID (EUI- 64) Ex: FE80::310:BAFF:FE64:1D 1. A new host is turned on. 2. Tentative address will be assigned to the new host. 3. Duplicate Address Detection (DAD) is performed. First the host transmit a Neighbor Solicitation (NS) message to the solicited node multicast address (FF02::1:FF64:001D) corresponding to its to be used address 5. If no Neighbor Advertisement (NA) message comes back then the address is unique. 6. FE80::310:BAFF:FE64:1D will be assigned to the new host. 46

47 Iv6 autoconfiguration Send me Router Advertisement 2001:1234:1:1/64 network Router Advertisement FE80::310:BAFF:FE64:1D Assign 2001:1234:1:1:310:BAFF:FE64:1D 1. The new host will send Router Solicitation (RS) request to the all-routers multicast group (FF02::2). 2. The router will reply Routing Advertisement (RA). 3. The new host will learn the network prefix. E.g, 2001:1234:1:1/64 4. The new host will assigned a new address Network prefix+interface ID E.g, 2001:1234:1:1:310:BAFF:FE64:1D 2013 Cisco and/or its affiliates. All rights reserved. 47