CCIE Service Provider v3.0 Lab Workbook. Copyright Information. Copyright Internetwork Expert, Inc. All rights reserved.

Transcription

1 Copyright Information Copyright Internetwork Expert, Inc. All rights reserved. The following publication, CCIE Service Provider v3.0 Lab Workbook, was developed by Internetwork Expert, Inc. All rights reserved. No part of this publication may be reproduced or distributed in any form or by any means without the prior written permission of Internetwork Expert, Inc. Cisco, Cisco Systems, CCIE, and Cisco Certified Internetwork Expert, are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain countries. All other products and company names are the trademarks, registered trademarks, and service marks of the respective owners. Throughout this manual, Internetwork Expert, Inc. has used its best efforts to distinguish proprietary trademarks from descriptive names by following the capitalization styles used by the manufacturer. 1

2 Disclaimer The following publication, CCIE Service Provider v3.0 Lab Workbook, is designed to assist candidates in the preparation for Cisco Systems CCIE Service Provider Lab Exam. While every effort has been made to ensure that all material is as complete and accurate as possible, the enclosed material is presented on an as is basis. Neither the authors nor Internetwork Expert, Inc. assume any liability or responsibility to any person or entity with respect to loss or damages incurred from the information contained in this workbook. This workbook was developed by Internetwork Expert, Inc. and is an original work of the aforementioned authors. Any similarities between material presented in this workbook and actual CCIE lab material is completely coincidental. 2

3 R01 XR2 Fa0/0 POS0/7/0/ / /24 Fa1/0 POS0/6/0/0 R02 R03 R06 Fa0/0.619 XR1 Gig0/1/0/0.519 Fa0/0.23 Fa0/0.36 Gig0/1/0/ / / / /24 Fa0/0.46 Fa0/0.34 Fa0/ /24 Fa0/ / / / /24 R04 Fa0/0.45 R05 Fa0/0.519 CCIE Service Provider Version 3.0 Lab Workbook Base IPv4 Diagram INE Inc.

4 2.13 IS-IS BFD Configure BFD for IS-IS between R5 and XR1 so that if these is a failure of the link between them they begin reconvergence in less than one second. Configuration R5: interface FastEthernet0/0.519 bfd interval 250 min_rx 250 multiplier 3 isis bfd XR1: router isis 1 interface GigabitEthernet0/1/0/0.519 bfd minimum-interval 250 bfd multiplier 3 bfd fast-detect ipv4 Verification R5 and XR1 are BFD adjacenct via IS-IS, and are configured to detect a failure in 750ms. R05#show bfd neighbors detail NeighAddr LD/RD RH/RS State Int / Up Up Fa0/0.519 Session state is UP and using echo function with 250 ms interval. OurAddr: Local Diag: 0, Demand mode: 0, Poll bit: 0 MinTxInt: , MinRxInt: , Multiplier: 3 Received MinRxInt: , Received Multiplier: 3 Holddown (hits): 0(0), Hello (hits): 2000(544) Rx Count: 522, Rx Interval (ms) min/max/avg: 1/2004/1824 last: 856 ms ago Tx Count: 545, Tx Interval (ms) min/max/avg: 1/2000/1745 last: 1872 ms ago Elapsed time watermarks: 0 0 (last: 0) Registered protocols: CEF ISIS Uptime: 00:15:51 Last packet: Version: 1 - Diagnostic: 0 State bit: Up - Demand bit: 0 Poll bit: 0 - Final bit: 0 Multiplier: 3 - Length: 24 My Discr.: Your Discr.: 1 Min tx interval: Min rx interval: Min Echo interval:

5 RP/0/0/CPU0:XR1#show bfd ipv4 session detail Sat Mar 3 03:50: UTC I/f: GigabitEthernet0/1/0/0.519, Location: 0/1/CPU0, dest: , src: State: UP for 0d:0h:16m:3s, number of times UP: 1 Received parameters: Version: 1, desired tx interval: 1 s, required rx interval: 1 s Required echo rx interval: 250 ms, multiplier: 3, diag: None My discr: 1, your discr: , state UP, D/F/P/C/A: 0/0/0/0/0 Transmitted parameters: Version: 1, desired tx interval: 2 s, required rx interval: 2 s Required echo rx interval: 1 ms, multiplier: 3, diag: None My discr: , your discr: 1, state UP, D/F/P/C/A: 0/0/0/1/0 Timer Values: Local negotiated async tx interval: 2 s Remote negotiated async tx interval: 2 s Desired echo tx interval: 250 ms, local negotiated echo tx interval: 250 ms Echo detection time: 750 ms(250 ms*3), async detection time: 6 s(2 s*3) Local Stats: Intervals between async packets: Tx: Number of intervals=100, min=1669 ms, max=2001 ms, avg=1837 ms Last packet transmitted 351 ms ago Rx: Number of intervals=100, min=1507 ms, max=1996 ms, avg=1730 ms Last packet received 858 ms ago Intervals between echo packets: Tx: Number of intervals=100, min=251 ms, max=251 ms, avg=251 ms Last packet transmitted 22 ms ago Rx: Number of intervals=100, min=249 ms, max=252 ms, avg=251 ms Last packet received 21 ms ago Latency of echo packets (time between tx and rx): Number of packets: 100, min=0 us, max=2 ms, avg=540 us Session owner information: Client Desired interval Multiplier isis ms 3 69

6 R5 s interface is disabled at time index 03:56: XR1 detects this failure within 1 second at time index 03:56: Note that the carrier-delay 0 command is used on R5 so that there is no delay between when the interface is shutdown and when the link up/down message is generated. This allows us to see in real time that XR1 reacts to the change of the link status in less than 1 second. R05#config t Enter configuration commands, one per line. End with CNTL/Z. R05(config)#service timestamp log datetime msec R05(config)#int f0/0 R05(config-if)#carrier-delay 0 R05(config-if)#shut R05(config-if)# Mar 3 03:56:03.957: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down Mar 3 03:56:04.957: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down RP/0/0/CPU0:XR1# LC/0/1/CPU0:Mar 3 03:56: : bfd_agent[121]: %L2-BFD-6-SESSION_STATE_DOWN : BFD session to neighbor on interface GigabitEthernet0/1/0/0.519 has gone down. Reason: Echo function failed 70

7 2.16 IS-IS Route Leaking Configure IS-IS Route Leaking from Level 1 to Level 2 on the L1/L2 routers as follows: o R3 should advertise the L2 prefix /32 to its L1 routers. o R4 should advertise the L2 prefix /32 to its L1 routers. o XR1 should advertise the /32 and /32 prefixes to its L1 routers. Configure IS-IS Route Leaking from Level 2 to Level 1 on the L1/L2 routers as follows: o R3 should not advertise the L1 prefix /32 to its L2 routers. o R4 should not advertise the L1 prefix /32 to its L2 routers. Configuration R3: router isis redistribute isis ip level-1 into level-2 distribute-list 101 redistribute isis ip level-2 into level-1 distribute-list 100 access-list 100 permit ip host host access-list 101 deny ip host host access-list 101 permit ip any any R4: router isis redistribute isis ip level-1 into level-2 distribute-list 101 redistribute isis ip level-2 into level-1 distribute-list 100 access-list 100 permit ip host host access-list 101 deny ip host host access-list 101 permit ip any any XR1: route-policy ISIS_ROUTE_LEAKING if destination in ( /32, /32) then pass endif end-policy router isis 1 address-family ipv4 unicast propagate level 2 into level 1 route-policy ISIS_ROUTE_LEAKING end 85

8 Verification Previously R1 and R2 only knew their own L1 routes as well as a default route to the L1/L2 routes. Now the specific routes /32 and /32 are advertised via R3 and R4 respectively. R02#show ip route isis Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP + - replicated route, % - next hop override Gateway of last resort is to network i*l /0 [115/10] via , 03:41:01, FastEthernet0/0.24 [115/10] via , 03:41:01, FastEthernet0/ /32 is subnetted, 1 subnets i L [115/10] via , 03:41:54, FastEthernet1/ /32 is subnetted, 1 subnets i ia [115/158] via , 00:14:38, FastEthernet0/ /32 is subnetted, 1 subnets i ia [115/148] via , 00:11:21, FastEthernet0/0.24 Due to the longest match routing principle, traffic going to /32 will always prefer R3 as the exit point, while traffic going to /32 will always prefer R4. R01#traceroute Type escape sequence to abort. Tracing the route to msec 0 msec 0 msec msec 4 msec 0 msec msec 4 msec 0 msec msec * 0 msec R01#traceroute Type escape sequence to abort. Tracing the route to msec 0 msec 4 msec msec 0 msec 4 msec msec * 0 msec 86

9 In the case that one of these exit points are down, traffic will fall back to the least specific match of /0 that is installed due to the Attached (ATT) bit being set in the IS-IS LSDB. R01#show ip route Routing entry for /32 Known via "isis", distance 115, metric 158, type inter area Redistributing via isis Last update from on FastEthernet0/0, 00:00:01 ago Routing Descriptor Blocks: * , from , 00:00:01 ago, via FastEthernet0/0 Route metric is 158, traffic share count is 1 R01#traceroute Type escape sequence to abort. Tracing the route to msec 0 msec 4 msec msec 0 msec 0 msec msec * 0 msec R02#config t Enter configuration commands, one per line. End with CNTL/Z. R02(config)#int f0/0.24 R02(config-subif)#shut R02(config-subif)# R01#show ip route % Network not in table R01#traceroute Type escape sequence to abort. Tracing the route to msec 0 msec 4 msec msec 0 msec 0 msec msec Route leaking can also be used to filter routes as the are converted from L1 to L2. Previously R6 has equal longest matches to /32 and /32 via R3 and R4. After route leaking filtering is applied, R6 has only one possible path to each of these destinations. R06#show ip route Routing entry for /32 Known via "isis", distance 115, metric 30, type level-2 Redistributing via isis Last update from on FastEthernet0/0.36, 00:17:55 ago Routing Descriptor Blocks: * , from , 00:17:55 ago, via FastEthernet0/0.36 Route metric is 30, traffic share count is 1 87

10 R06#show ip route Routing entry for /32 Known via "isis", distance 115, metric 20, type level-2 Redistributing via isis Last update from on FastEthernet0/0.46, 00:01:12 ago Routing Descriptor Blocks: * , from , 00:01:12 ago, via FastEthernet0/0.46 Route metric is 20, traffic share count is 1 Unlike L2 to L1 route leaking, which allows traffic engineering based on longest match, but still allows for fallback to a default route, filtering of L1 to L2 origination via route leaking does not allow for redundancy. For example in this case that R3 loses its link to the L1 domain, the /32 prefix becomes unreachable because R4 is configured to deny origination of this prefix from L1 into L2. R06#show ip route Routing entry for /32 Known via "isis", distance 115, metric 30, type level-2 Redistributing via isis Last update from on FastEthernet0/0.36, 00:20:02 ago Routing Descriptor Blocks: * , from , 00:20:02 ago, via FastEthernet0/0.36 Route metric is 30, traffic share count is 1 R06#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms R06# R03#config t Enter configuration commands, one per line. End with CNTL/Z. R03(config)#int f0/0.23 R03(config-subif)#shut R03(config-subif)# R06#show ip route % Network not in table R06#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds:... Success rate is 0 percent (0/5) 88

11 Route leaking in IOS XR uses the same logic as regular IOS, however the matching of prefixes occurs through the usage of the Routing Policy Language (RPL). RP/0/0/CPU0:XR1#show rpl Sat Mar 3 02:55: UTC route-policy ISIS_ROUTE_LEAKING if destination in ( /32, /32) then pass endif end-policy RP/0/0/CPU0:XR1#show run router isis Sat Mar 3 02:55: UTC router isis 1 net address-family ipv4 unicast propagate level 2 into level 1 route-policy ISIS_ROUTE_LEAKING <snip> The result of this configuration is that XR2 learns the specific routes of /32 and /32 via XR1. RP/0/3/CPU0:XR2#show route isis Sat Mar 3 02:54: UTC i*l /0 [115/10] via , 03:52:07, POS0/7/0/0 i ia /32 [115/30] via , 00:13:51, POS0/7/0/0 i ia /32 [115/30] via , 00:13:51, POS0/7/0/0 89

12 To make this configuration more modular, the RPL policy could have called an external prefixset, similar to a prefix-list in regular IOS, that could be used to match the prefixes in question to be leaked. A configuration such as this could be written as follows: RP/0/0/CPU0:XR1#show rpl Sat Mar 3 02:59: UTC prefix-set ISIS_ROUTES /32, /32 end-set route-policy ISIS_ROUTE_LEAKING if destination in ISIS_ROUTES then pass endif end-policy RP/0/0/CPU0:XR1#show run router isis Sat Mar 3 02:59: UTC router isis 1 net address-family ipv4 unicast propagate level 2 into level 1 route-policy ISIS_ROUTE_LEAKING <snip> 90

13 2.18 Multi Topology IS-IS Configure IS-IS to run in Multi Topology mode on all devices. Change the IS-IS metric on the path from R2 to R3 to R6 to XR1 and back so that IPv4 traffic between R1 and XR2 prefers to use R4 and R5 in the transit path. Change the IS-IS metric on the path from R2 to R4 to R5 to XR1 and back so that IPv6 traffic between R1 and XR2 prefers to use R3 and R6 in the transit path. Configuration R01: router isis metric-style wide address-family ipv6 multi-topology R02: interface FastEthernet0/0.23 isis metric 20 interface FastEthernet0/0.24 isis ipv6 metric 20 router isis metric-style wide address-family ipv6 multi-topology R03: interface FastEthernet0/0.36 isis metric 20 router isis metric-style wide address-family ipv6 multi-topology R04: interface FastEthernet0/0.24 isis ipv6 metric 20 interface FastEthernet0/0.45 isis ipv6 metric 20 router isis metric-style wide address-family ipv6 multi-topology 103

14 R05: interface FastEthernet0/0.45 isis ipv6 metric 20 interface FastEthernet0/0.519 isis ipv6 metric 20 router isis metric-style wide address-family ipv6 multi-topology R06: interface FastEthernet0/0.36 isis metric 20 interface FastEthernet0/0.619 isis metric 20 router isis metric-style wide address-family ipv6 multi-topology XR1: router isis 1 address-family ipv4 unicast metric-style wide address-family ipv6 unicast metric-style wide no single-topology interface GigabitEthernet0/1/0/0.519 address-family ipv6 unicast metric 20 interface GigabitEthernet0/1/0/0.619 address-family ipv4 unicast metric 20 XR2: router isis 1 address-family ipv4 unicast metric-style wide address-family ipv6 unicast metric-style wide no single-topology 104

15 Verification In Multi Topology IS-IS, separate protocol stacks maintain separate database structures and use separate SPF runs, which means that one topology is independent of another. Mutli Topology IS-IS is most useful in practical IPv4 to IPv6 migration scenarios, where IPv6 is slowly introduced to the already existing IPv4 core. During migration the IPv4 and IPv6 topologies are kept separate from a database calculation point of view inside of IS-IS. Once the migration is complete and IPv4 and IPv6 run on a 1:1 basis with each other, Single Topology IS-IS can be enabled, which means that both IPv4 and IPv6 topology share the same database and SPF run. Note that this design is only possible if IPv4 runs on all interfaces that IPv6 runs on and vice-versa, otherwise database inconsistencies can occur which can result in loss of reachability in the network. Prior to making any changes to the previous example, R1 s IPv4 and IPv6 traffic follow the same path to reach XR2. R01#traceroute Type escape sequence to abort. Tracing the route to msec 0 msec 0 msec msec 4 msec 0 msec msec 4 msec 0 msec msec 0 msec 4 msec msec * 4 msec R01#traceroute 2000::20:20:20:20 Type escape sequence to abort. Tracing the route to 2000::20:20:20: :10:1:2::2 8 msec 0 msec 0 msec :20:2:3::3 8 msec 4 msec 0 msec :20:3:6::6 8 msec 12 msec 0 msec :20:6:19::19 4 msec 4 msec 0 msec ::20:20:20:20 8 msec 4 msec 4 msec 105

16 After the Multi Topology and metric changes, IPv4 traffic follows the path along the bottom of the topology through R4 and R5, while IPv6 traffic follows the path along the top of the topology through R3 and R6. R01#traceroute Type escape sequence to abort. Tracing the route to msec 0 msec 0 msec msec 4 msec 0 msec msec 4 msec 0 msec msec 4 msec 4 msec msec * 4 msec R01#traceroute 2000::20:20:20:20 Type escape sequence to abort. Tracing the route to 2000::20:20:20: :10:1:2::2 0 msec 0 msec 0 msec :20:2:3::3 4 msec 0 msec 0 msec :20:3:6::6 4 msec 0 msec 0 msec :20:6:19::19 4 msec 4 msec 0 msec ::20:20:20:20 0 msec 4 msec 0 msec RP/0/3/CPU0:XR2#traceroute Sat Mar 3 14:44: UTC Type escape sequence to abort. Tracing the route to msec 4 msec 2 msec msec 2 msec 2 msec msec 2 msec 2 msec msec 3 msec 2 msec msec * 3 msec RP/0/3/CPU0:XR2#traceroute 2000::1:1:1:1 Sat Mar 3 14:45: UTC Type escape sequence to abort. Tracing the route to 2000::1:1:1: :10:19:20::19 7 msec 4 msec 2 msec :20:6:19::6 2 msec 3 msec 3 msec :20:3:6::3 3 msec 3 msec 3 msec :20:2:3::2 4 msec 4 msec 2 msec :10:1:2::1 4 msec 5 msec 10 msec 106

17 When we look at the detailed view of the IS-IS database we can see that the IPv6 information is encoded as MT for Multi Topology, and that separate IPv4 and IPv6 metrics can exist. Note that Wide Metric Style is required in order to encode the Multi Topology information in the database. RP/0/3/CPU0:XR2#show isis database detail Sat Mar 3 14:46: UTC IS-IS 1 (Level-2) Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL R x x313d 696 0/0/0 Area Address: MT: Standard (IPv4 Unicast) MT: IPv6 Unicast 0/0/0 NLPID: 0xcc NLPID: 0x8e Hostname: R01 IP Address: IPv6 Address: 2000::1:1:1:1 Metric: 10 IS-Extended R02.03 Metric: 10 MT (IPv6 Unicast) IS-Extended R02.03 Metric: 0 IP-Extended /32 Metric: 10 IP-Extended /24 Metric: 10 MT (IPv6 Unicast) IPv6 2000:10:1:2::/64 Metric: 0 MT (IPv6 Unicast) IPv6 2000::1:1:1:1/128 R x x66a /0/0 Area Address: MT: Standard (IPv4 Unicast) MT: IPv6 Unicast 0/0/0 NLPID: 0xcc NLPID: 0x8e Hostname: R02 IP Address: IPv6 Address: 2000::2:2:2:2 Metric: 10 IS-Extended R02.03 Metric: 10 IS-Extended R02.02 Metric: 20 IS-Extended R03.01 Metric: 20 MT (IPv6 Unicast) IS-Extended R02.02 Metric: 10 MT (IPv6 Unicast) IS-Extended R02.03 Metric: 10 MT (IPv6 Unicast) IS-Extended R03.01 Metric: 0 IP-Extended /32 Metric: 10 IP-Extended /24 Metric: 20 IP-Extended /24 Metric: 10 IP-Extended /24 Metric: 10 MT (IPv6 Unicast) IPv6 2000:20:2:3::/64 Metric: 20 MT (IPv6 Unicast) IPv6 2000:20:2:4::/64 Metric: 10 MT (IPv6 Unicast) IPv6 2000:10:1:2::/64 Metric: 0 MT (IPv6 Unicast) IPv6 2000::2:2:2:2/128 R x f 0x /0/0 Metric: 0 IS-Extended R02.00 Metric: 0 IS-Extended R04.00 R x x /0/0 Metric: 0 IS-Extended R02.00 Metric: 0 IS-Extended R01.00 <snip> 107

18 Note Load the Base OSPF and LDP Initial Configurations prior to starting this section. 4.2 MPLS L3 VPN with Static Routing Configure a VRF on R2 and XR1 as follows: o VRF Name: VPN_A o Route Distinguisher: 100:1 o Route Target Import: 100:1 o Route Target Export: 100:1 o Assign the VRF to the links connecting to R1 and XR2 respectively. Configure routing for the VRF as follows: o R1 should have a default route pointing towards R2. o R2 should have a static route for /32 pointing towards R1. o XR1 should have a static route for /32 pointing towards XR2. o XR2 should have a default route pointing towards XR1. Configure BGP on R2 and XR1 as follows: o Use BGP AS 100. o R2 and XR1 should be ibgp peers for the VPNv4 Address Family. o Use their Loopback0 interfaces as the source of the BGP session. o Advertise the static routes towards R1 and XR2 into BGP on R2 and XR1 respectively. Once complete R1 and XR2 should have reachability to each others Loopback0 interfaces when sourcing traffic from their own Loopback0 interfaces. 144

19 Configuration R1: ip route R2: vrf definition VPN_A rd 100:1 route-target export 100:1 route-target import 100:1 address-family ipv4 exit-address-family interface FastEthernet1/0 vrf forwarding VPN_A ip address router bgp 100 no bgp default ipv4-unicast neighbor remote-as 100 address-family vpnv4 neighbor activate neighbor send-community extended exit-address-family address-family ipv4 vrf VPN_A network mask exit-address-family ip route vrf VPN_A

20 XR1: vrf VPN_A address-family ipv4 unicast import route-target 100:1 export route-target 100:1 interface POS0/6/0/0 vrf VPN_A ipv4 address router static vrf VPN_A address-family ipv4 unicast / router bgp 100 address-family vpnv4 unicast neighbor remote-as 100 update-source Loopback0 address-family vpnv4 unicast vrf VPN_A rd 100:1 address-family ipv4 unicast network /32 XR2: router static address-family ipv4 unicast /

21 Verification show vrf detail is useful to quickly verify configured VRFs names, RDs, RT import and export policy, and assigned links. R02#show vrf detail VRF VPN_A (VRF Id = 1); default RD 100:1; default VPNID <not set> Interfaces: Fa1/0 Address family ipv4 (Table ID = 1 (0x1)): Export VPN route-target communities RT:100:1 Import VPN route-target communities RT:100:1 No import route-map No export route-map VRF label distribution protocol: not configured VRF label allocation mode: per-prefix Address family ipv6 not active. RP/0/0/CPU0:XR1#show vrf VPN_A detail Tue Mar 6 19:43: UTC VRF VPN_A; RD 100:1; VPN ID not set Description not set Interfaces: POS0/6/0/0 Address family IPV4 Unicast Import VPN route-target communities: RT:100:1 Export VPN route-target communities: RT:100:1 No import route policy No export route policy Address family IPV6 Unicast No import VPN route-target communities No export VPN route-target communities No import route policy No export route policy 147

22 Note that in IOS XR, once an interface is removed from the global routing table and assigned to a VRF table, it no longer appears in the show ip interface brief output, as seen below. Instead, interfaces can be verified with the command show ipv4 vrf all interface brief. RP/0/0/CPU0:XR1#show ip interface brief Tue Mar 6 20:26: UTC Interface IP-Address Status Protocol Loopback Up Up MgmtEth0/0/CPU0/0 unassigned Up Up MgmtEth0/0/CPU0/1 unassigned Up Up MgmtEth0/0/CPU0/2 unassigned Up Up GigabitEthernet0/1/0/0 unassigned Up Up GigabitEthernet0/1/0/ Up Up GigabitEthernet0/1/0/ Up Up GigabitEthernet0/1/0/1 unassigned Up Up GigabitEthernet0/1/0/2 unassigned Up Up GigabitEthernet0/1/0/3 unassigned Up Up RP/0/0/CPU0:XR1#show ipv4 vrf all interface brief Tue Mar 6 20:26: UTC Interface IP-Address Status Protocol Vrf-Name Loopback Up Up default MgmtEth0/0/CPU0/0 unassigned Up Up default MgmtEth0/0/CPU0/1 unassigned Up Up default MgmtEth0/0/CPU0/2 unassigned Up Up default GigabitEthernet0/1/0/0 unassigned Up Up default GigabitEthernet0/1/0/ Up Up default GigabitEthernet0/1/0/ Up Up default GigabitEthernet0/1/0/1 unassigned Up Up default GigabitEthernet0/1/0/2 unassigned Up Up default GigabitEthernet0/1/0/3 unassigned Up Up default POS0/6/0/ Up Up VPN_A 148

23 In this example, the CE routers R1 and XR2 simply have default routes pointing to the PE routers R2 and XR1, resulting in one of the simplest MPLS L3VPN designs. From the CE routers perspective these are just normal static routes in the global routing table. R01#show ip route Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP + - replicated route, % - next hop override Gateway of last resort is to network S* /0 [1/0] via /32 is subnetted, 1 subnets C is directly connected, Loopback /8 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, FastEthernet0/0 L /32 is directly connected, FastEthernet0/0 RP/0/3/CPU0:XR2#show route ipv4 Tue Mar 6 20:28: UTC Codes: C - connected, S - static, R - RIP, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, su - IS-IS summary null, * - candidate default U - per-user static route, o - ODR, L - local, G - DAGR A - access/subscriber Gateway of last resort is to network S* /0 [1/0] via , 00:55:16 C /24 is directly connected, 01:24:13, POS0/7/0/0 L /32 is directly connected, 01:24:13, POS0/7/0/0 L /32 is directly connected, 01:24:14, Loopback0 149

24 From the PE routers R2 and XR1 s perspective, their static routes to the customers exist in the VRF table. R02#show ip route vrf VPN_A static Routing Table: VPN_A Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP + - replicated route, % - next hop override Gateway of last resort is not set /32 is subnetted, 1 subnets S [1/0] via RP/0/0/CPU0:XR1#show route vrf VPN_A ipv4 static Tue Mar 6 20:30: UTC S /32 [1/0] via , 00:53:58 R2 and XR1 then advertise these static routes into the VPNv4 BGP topology. In this case it is done with the network statement, but it could also be done with redistribution. R02#show bgp vpnv4 unicast all BGP table version is 4, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf VPN_A) *> / i *>i / i 150

25 RP/0/0/CPU0:XR1#show bgp vpnv4 unicast Tue Mar 6 20:31: UTC BGP router identifier , local AS number 100 BGP generic scan interval 60 secs BGP table state: Active Table ID: 0x0 BGP main routing table version 5 BGP scan interval 60 secs Status codes: s suppressed, d damped, h history, * valid, > best i - internal, r RIB-failure, S stale Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf VPN_A) *>i / i *> / i Processed 2 prefixes, 2 paths Note that R2 and XR1 use the Loopback0 interfaces of each other as the next-hop value for the VPNv4 learned routes, since this is the update-source of the ibgp session. In addition to the next-hop value, the VPN label derived from VPNv4 BGP can be seen in the below output. This is the label value that the PE routers use to find the final customer route in the VRF. R02#show bgp vpnv4 unicast all /32 BGP routing table entry for 100:1: /32, version 4 Paths: (1 available, best #1, table VPN_A) Not advertised to any peer Local (metric 4) from ( ) Origin IGP, metric 0, localpref 100, valid, internal, best Extended Community: RT:100:1 mpls labels in/out nolabel/16003 RP/0/0/CPU0:XR1#show bgp vrf VPN_A ipv4 unicast /32 Tue Mar 6 20:33: UTC BGP routing table entry for /32, Route Distinguisher: 100:1 Versions: Process brib/rib SendTblVer Speaker 5 5 Last Modified: Mar 6 19:37: for 00:56:34 Paths: (1 available, best #1) Not advertised to any peer Path #1: Received by speaker 0 Local (metric 4) from ( ) Received Label 16 Origin IGP, metric 0, localpref 100, valid, internal, best, import-candidate, imported Extended community: RT:100:1 151

26 R2 and XR1 then combine this VPN label with the transport label used to reach each others Loopback0 interfaces. In this case the transport label is derived from OSPF + LDP. The transport label is used to tell the MPLS core what the exit PE is out of the network. R02#show ip route Routing entry for /32 Known via "ospf 1", distance 110, metric 4, type intra area Last update from on FastEthernet0/0.24, 01:10:13 ago Routing Descriptor Blocks: * , from , 01:10:13 ago, via FastEthernet0/0.24 Route metric is 4, traffic share count is , from , 01:10:13 ago, via FastEthernet0/0.23 Route metric is 4, traffic share count is 1 R02#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface /32 0 Fa0/ /32 0 Fa0/ RP/0/0/CPU0:XR1#show route ipv Tue Mar 6 20:36: UTC Routing entry for /32 Known via "ospf 1", distance 110, metric 4, type intra area Installed Mar 6 19:06: for 01:29:35 Routing Descriptor Blocks , from , via GigabitEthernet0/1/0/0.519 Route metric is , from , via GigabitEthernet0/1/0/0.619 Route metric is 4 No advertising protos. RP/0/0/CPU0:XR1#show mpls forwarding prefix /32 Tue Mar 6 20:36: UTC Local Outgoing Prefix Outgoing Next Hop Bytes Label Label or ID Interface Switched /32 Gi0/1/0/ /32 Gi0/1/0/

27 The two of these together, the VPN label and the transport label, make up the full label stack that is imposed when the PE routers receive traffic from the CE. This can be verified in the CEF table on the PE routers. The below cef table output of R2 indicates that the VPN label is 16003, and the transport label is either 21 or 22, depending which interface the traffic is CEF switched to. R02#show ip cef vrf VPN_A detail /32, epoch 0, flags rib defined all labels recursive via label nexthop FastEthernet0/0.23 label 21 nexthop FastEthernet0/0.24 label 22 The full label stack can also be verified in the data plane through the debug mpls packet output. Note that the transport label changes on a hop-by-hop basis, but the VPN label remains the same end-to-end. R3 is the Penultimate hop for R2, so the top label 17 is being removed for packets going to R2. Likewise on the other side R6 is the Penultimate hop for XR1, as the transport label 22 is being popped for traffic going towards XR1. R01#ping source repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to , timeout is 2 seconds: Packet sent with a source address of Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms R03#debug mpls packet Packet debugging is on MPLS turbo: Fa0/0.23: rx: Len 126 Stack { } { } - ipv4 data MPLS turbo: Fa0/0.36: tx: Len 126 Stack { } { } - ipv4 data MPLS turbo: Fa0/0.36: rx: Len 126 Stack { } { } - ipv4 data MPLS turbo: Fa0/0.23: tx: Len 122 Stack { } - ipv4 data R03#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface / Fa0/ R03#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 17 Pop Label / Fa0/

28 R06#debug mpls packet Packet debugging is on MPLS turbo: Fa0/0.36: rx: Len 126 Stack { } { } - ipv4 data MPLS turbo: Fa0/0.619: tx: Len 122 Stack { } - ipv4 data MPLS turbo: Fa0/0.619: rx: Len 126 Stack { } { } - ipv4 data MPLS turbo: Fa0/0.36: tx: Len 126 Stack { } { } - ipv4 data R06#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 22 Pop Label / Fa0/ R06#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface / Fa0/ /32 0 Fa0/ The final result is that even though the devices in the core, i.e. R3, R4, R5, & R6, do not have routes for the customer VRF VPN_A, they are able to transport label switched packets that go between the PE routers of R2 and XR1. R03#show ip route % Network not in table R03#show ip route % Subnet not in table R04#show ip route % Network not in table R04#show ip route % Subnet not in table R05#show ip route % Network not in table R05#show ip route % Subnet not in table R06#show ip route % Network not in table R06#show ip route % Subnet not in table RP/0/3/CPU0:XR2#ping source Tue Mar 6 20:48: UTC Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/5 ms 154

29 Note Load the Base OSPF and LDP Initial Configurations prior to starting this section. 4.5 MPLS L3 VPN with BGP Configure a VRF on R2 and XR1 as follows: o VRF Name: VPN_A o Route Distinguisher: 100:1 o Route Target Import: 100:1 o Route Target Export: 100:1 o Assign the VRF to the links connecting to R1 and XR2 respectively. Configure BGP on R2 and XR1 as follows: o Use BGP AS 100. o R2 and XR1 should be ibgp peers for the VPNv4 Address Family. o Use their Loopback0 interfaces as the source of the BGP session. Configure BGP on R1 and XR2 as follows: o Use BGP AS 1. o R1 and R2 should peer EBGP. o XR1 and XR2 should peer EBGP. o Advertise the Loopback0 interfaces of R1 and XR2 into BGP. Once complete R1 and XR2 should have reachability to each others Loopback0 interfaces when sourcing traffic from their Loopback0 networks. 173

30 Configuration R1: router bgp 1 network mask neighbor remote-as 100 R2: vrf definition VPN_A rd 100:1 route-target export 100:1 route-target import 100:1 address-family ipv4 exit-address-family interface FastEthernet1/0 vrf forwarding VPN_A ip address router bgp 100 no bgp default ipv4-unicast neighbor remote-as 100 address-family vpnv4 neighbor activate neighbor send-community extended exit-address-family address-family ipv4 vrf VPN_A neighbor remote-as 1 neighbor as-override exit-address-family 174

31 XR1: vrf VPN_A address-family ipv4 unicast import route-target 100:1 export route-target 100:1 interface POS0/6/0/0 vrf VPN_A ipv4 address route-policy PASS pass end-policy router bgp 100 address-family vpnv4 unicast neighbor remote-as 100 update-source Loopback0 address-family vpnv4 unicast vrf VPN_A rd 100:1 address-family ipv4 unicast neighbor remote-as 1 address-family ipv4 unicast route-policy PASS in route-policy PASS out as-override XR2: route-policy PASS pass end-policy router bgp 1 address-family ipv4 unicast network /32 neighbor remote-as 100 address-family ipv4 unicast route-policy PASS in route-policy PASS out 175

32 Verification BGP as the PE-CE routing protocol uses one global BGP process, with the VRF specific peers defined under the address-family ipv4 vrf in regular IOS, and under the vrf BGP submode in IOS XR. Two things should be noted about this specific configuration. The first is that since the IOS XR routers are EBGP neighbors with each other, a Routing Policy is required in order to define which prefixes are allowed to be advertised and received. This is a fairly obvious requirement of IOS XR s configuration, because if the peering is committed without the RPL policy applied, a log message appears saying that the configuration is not functional without RPL. This can be seen as follows. RP/0/3/CPU0:XR2#show run router bgp Tue Mar 6 22:42: UTC router bgp 1 address-family ipv4 unicast network /32 neighbor remote-as 100 address-family ipv4 unicast route-policy PASS in route-policy PASS out RP/0/3/CPU0:XR2#config t Tue Mar 6 22:42: UTC RP/0/3/CPU0:XR2(config)#no router bgp 1 RP/0/3/CPU0:XR2(config)#commit RP/0/3/CPU0:Mar 6 22:42: : config[65736]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco@admin'. Use 'show configuration commit changes ' to view the changes. RP/0/3/CPU0:XR2(config)#router bgp 1 RP/0/3/CPU0:XR2(config-bgp)# address-family ipv4 unicast RP/0/3/CPU0:XR2(config-bgp-af)# network /32 RP/0/3/CPU0:XR2(config-bgp-af)# RP/0/3/CPU0:XR2(config-bgp-af)# neighbor RP/0/3/CPU0:XR2(config-bgp-nbr)# remote-as 100 RP/0/3/CPU0:XR2(config-bgp-nbr)# address-family ipv4 unicast RP/0/3/CPU0:XR2(config-bgp-nbr-af)#commit RP/0/3/CPU0:Mar 6 22:42: : config[65736]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco@admin'. Use 'show configuration commit changes ' to view the changes. RP/0/3/CPU0:XR2(config-bgp-nbr-af)#end RP/0/3/CPU0:Mar 6 22:42: : config[65736]: %MGBL-SYS-5-CONFIG_I : Configured from console by cisco@admin RP/0/3/CPU0:XR2#RP/0/3/CPU0:Mar 6 22:42: : bgp[139]: %ROUTING-BGP-5- ADJCHANGE : neighbor Up (VRF: default) RP/0/3/CPU0:Mar 6 22:42: : bgp[139]: %ROUTING-BGP-6-NBR_NOPOLICY : No inbound IPv4 Unicast policy is configured for ebgp neighbor No IPv4 Unicast prefixes will be accepted from the neighbor until inbound policy is configured. RP/0/3/CPU0:Mar 6 22:42: : bgp[139]: %ROUTING-BGP-6-NBR_NOPOLICY : No outbound IPv4 Unicast policy is configured for ebgp neighbor No IPv4 Unicast prefixes will be sent to the neighbor until outbound policy is configured. 176

33 If you were to miss this log message, for example if logging is disabled, you would also see it when you verify the BGP peering status with the neighbor as follows. RP/0/3/CPU0:XR2#show bgp ipv4 unicast summary Tue Mar 6 22:43: UTC BGP router identifier , local AS number 1 BGP generic scan interval 60 secs BGP table state: Active Table ID: 0xe BGP main routing table version 2 BGP scan interval 60 secs BGP is operating in STANDALONE mode. Process RcvTblVer brib/rib LabelVer ImportVer SendTblVer StandbyVer Speaker Some configured ebgp neighbors (under default or non-default vrfs) do not have both inbound and outbound policies configured for IPv4 Unicast address family. These neighbors will default to sending and/or receiving no routes and are marked with '' in the output below. Use the 'show bgp neighbor <nbr_address>' command for details. Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd :00:55 0 RP/0/3/CPU0:XR2# The second portion of this config that should be noted is the as-override keyword used on the PE s peering sessions towards the CEs. In cases where multiple customer sites are using the same BGP AS number, the default BGP filtering rule to not allow prefixes with the router s own AS number in the AS-Path will prevent prefixes from being exchanged between sites. The asoverride feature prevents prefixes from being filtered by editing the AS-Path information to remove the customer s Autonomous System. Without AS Override, prefixes are denied from being received, as seen in the following output. R2 removes the AS Override feature configured to its CE router, R1. R02#config t Enter configuration commands, one per line. End with CNTL/Z. R02(config)#router bgp 100 R02(config-router)#address-family ipv4 vrf VPN_A R02(config-router-af)#no neighbor as-override R02(config-router-af)#end R02#clear ip bgp * out R02# When new UPDATE messages are received in on R1 from R2 they contain the AS 1 in the path, which means that R1 cannot accept them. 177

34 R01#debug ip bgp updates BGP updates debugging is on for address family: IPv4 Unicast BGP(0): rcv UPDATE about /32 -- withdrawn BGP(0): rcv UPDATE w/ attr: nexthop , origin i, originator , merged path 100 1, AS_PATH, community, extended community, SSA attribute BGPSSA ssacount is 0 BGP(0): rcv UPDATE about /32 -- DENIED due to: AS-PATH contains our own AS; BGP: TX IPv4 Unicast Net global /32 Changed. BGP(0): no valid path for /32 BGP: net global:ipv4 Unicast:base /32 RIB-INSTALL Attempting to install. BGP: net global:ipv4 Unicast:base /32 RIB-INSTALL No bestpath. BGP: topo global:ipv4 Unicast:base Remove_fwdroute for /32 BGP: TX IPv4 Unicast Net global /32 RIB done. <snip> Even though R2 is still advertising /32 to R1, R1 cannot install it. R02#show bgp vpnv4 unicast vrf VPN_A neighbors advertised-routes BGP table version is 7, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf VPN_A) *>i / i Total number of prefixes 1 R01#show ip bgp BGP table version is 6, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path *> / i 178

35 Another alternative solution to this problem would be to configure the CE routers to allow prefixes that have their own AS in the path, such as the following. R01#debug ip bgp update BGP updates debugging is on for address family: IPv4 Unicast R01#config t Enter configuration commands, one per line. End with CNTL/Z. R01(config)#router bgp 1 R01(config-router)#neighbor allowas-in 1 R01(config-router)#end R01# %SYS-5-CONFIG_I: Configured from console by console BGP(0): rcvd UPDATE w/ attr: nexthop , origin i, merged path 100 1, AS_PATH BGP(0): rcvd /32 BGP: TX IPv4 Unicast Net global /32 Changed. BGP: net global:ipv4 Unicast:base /32 RIB-INSTALL Attempting to install. BGP: net global:ipv4 Unicast:base /32 RIB-INSTALL Built route type: 1024, flags: , tag: 64, metric: 0 paths: 1. BGP: net global:ipv4 Unicast:base /32 RIB-INSTALL Path 1, type: DEF, gw: , idb: N/A, topo_id: 0, src: , lbl: , flags: 0. BGP: net global:ipv4 Unicast:base /32 RIB-INSTALL Installing 1 paths, multipath limit 1 (from 1). BGP: net global:ipv4 Unicast:base /32 RIB-INSTALL Install successful. <snip> Even though the prefix /32 contains R1 s own AS number in the path, the allowasin command permits an exception for this. R01#show ip bgp BGP table version is 11, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path *> / i *> / i R01#show ip bgp BGP routing table entry for /32, version 11 Paths: (1 available, best #1, table default) Not advertised to any peer from ( ) Origin IGP, localpref 100, valid, external, best 179

36 The final result should be that R1 and XR2 have reachability to each others Loopbacks, but only when sourcing traffic from the Loopbacks, as the transit links from the PE-CEs have not been advertised. R01#ping Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds:... Success rate is 0 percent (0/5) R01#ping source Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to , timeout is 2 seconds: Packet sent with a source address of Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms 180