This is the third post based on my topology over here
The full name of this in Cisco’s terms is ‘MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels’ Let’s take a look at the topology again
R12 and R8 are route-reflectors in each AS. Option C allows you to get the route-reflectors to peer directly with each other over VPNv4. Note that these don’t HAVE to be route-reflectors, but it’s far more likely that they are.
The ASBRs of R13, R14, R5, and R6 are peering over regular IPv4. One slight difference is that they are sending labels as well.
If you though the Option B post was long, this post is going to be about twice as long so hopefully you won’t fall asleep.
I’ve removed all BGP config from the ASBR routers. At the moment R2 is peering with R12 over VPNv4 and R8 is peering with R9 over VPNv4. As always I’ll concentrate on a single ASBR, R13.
First let’s set up a regular eBGP session over to R14. I’ll also ensure we are sending labels:
router bgp 100 neighbor 10.13.14.14 remote-as 200 ! address-family ipv4 neighbor 10.13.14.14 activate neighbor 10.13.14.14 send-label exit-address-family
The next step is to get R12 and R8 to peer with each other. In order to peer, they need routes to each other. I’ll match R12’s loopback interface in a route-map and redistribute into BGP:
ip prefix-list PE_ADDRESS seq 5 permit 126.96.36.199/32 ! route-map LEAK_PE permit 10 match ip address prefix-list PE_ADDRESS ! router bgp 100 ! address-family ipv4 redistribute isis level-2 route-map LEAK_PE
I’ve done a similar config for R14. This means that R13 should see 188.8.131.52 as a BGP route:
R13#sh ip route 184.108.40.206 Routing entry for 220.127.116.11/32 Known via "bgp 100", distance 20, metric 3 Tag 200, type external Last update from 10.13.14.14 00:44:02 ago Routing Descriptor Blocks: * 10.13.14.14, from 10.13.14.14, 00:44:02 ago Route metric is 3, traffic share count is 1 AS Hops 1 Route tag 200 MPLS label: 23
Notice that I’ve also got a transport label to use. this was learned through BGP. We can verify R13 will use it when sending traffic to R8:
R13#sh mpls forwarding-table 18.104.22.168 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 24 23 22.214.171.124/32 46625 Gi1/0 10.13.14.14
R13 is not peering with R12 over BGP, so I need to get those BGP routes into the IGP. Always a good idea to use a route-map for this:
ip prefix-list AS200_PREFIXES seq 5 permit 126.96.36.199/32 ! route-map AS200_PREFIX_MAP permit 10 match ip address prefix-list AS200_PREFIXES ! router isis redistribute bgp 100 route-map AS200_PREFIX_MAP
Once this is also done on the ASBRs I should be able to ping between the route-reflectors:
R12#ping 188.8.131.52 so lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 184.108.40.206, timeout is 2 seconds: Packet sent with a source address of 220.127.116.11 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/29/36 ms
Route-Reflector VPNv4 set up
As the route-reflectors now have IP reachability, I can configure a VPNv4 session between them. Let’s concentrate on R12 for this example:
router bgp 100 no bgp default ipv4-unicast neighbor 18.104.22.168 remote-as 200 neighbor 22.214.171.124 ebgp-multihop 255 neighbor 126.96.36.199 update-source Loopback0 ! address-family vpnv4 neighbor 188.8.131.52 activate neighbor 184.108.40.206 send-community extended
The session should come straight up:
R12#show bgp vpnv4 unicast all sum | beg Nei Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 220.127.116.11 4 100 71 77 27 0 0 01:02:03 2 18.104.22.168 4 200 17 17 27 0 0 00:09:03 4
It has. And we are learning prefixes already so that’s all good. Let’s check R12’s CUS2 vrf table to see if we see R10’s loopback:
R12#sh ip route vrf CUS2 10.10.10.10 Routing Table: CUS2 % Subnet not in table
No. And the reason can be seen here. We had the same issue with the option B post if you remember.
R12#show bgp vpnv4 un all 10.10.10.10 BGP routing table entry for 22.214.171.124:2:10.10.10.10/32, version 7 Paths: (1 available, best #1, no table) Advertised to update-groups: 5 200 126.96.36.199 (metric 20) from 188.8.131.52 (184.108.40.206) Origin incomplete, localpref 100, valid, external, best Extended Community: RT:200:2 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.109.9:0 mpls labels in/out nolabel/27
The RT for this NLRI is 200:2. We are importing 100:2 on the ISP1 side. In my previous post we did a quick fix of getting the PE to import/export both targets, but let’s try another way.
I’d like R12 and R8 to change the RT value inbound. So if R12 learns a route with a RT value of 200:2, I want it replaced with 100:2. This can be done with a route-map:
ip extcommunity-list standard 200:1 permit rt 200:1 ip extcommunity-list standard 200:2 permit rt 200:2 ! route-map CHANGE_COMMUNITY permit 10 match extcommunity 200:1 set extcommunity rt 100:1 route-map CHANGE_COMMUNITY permit 20 match extcommunity 200:2 set extcommunity rt 100:2 ! router bgp 100 ! address-family vpnv4 neighbor 220.127.116.11 route-map CHANGE_COMMUNITY in
This should work:
R12#show bgp vpnv4 un all 10.10.10.10 | include Community Extended Community: RT:100:2 OSPF DOMAIN ID:0x0005:0x000000020200 Extended Community: RT:100:2 OSPF DOMAIN ID:0x0005:0x000000020200
Which means that 10.10.10.10/32 should be in the CUS2 VRF table:
R12#show ip route vrf CUS2 10.10.10.10 Routing Table: CUS2 Routing entry for 10.10.10.10/32 Known via "bgp 100", distance 20, metric 0 Tag 200, type external Redistributing via ospf 2 Advertised by ospf 2 subnets Last update from 18.104.22.168 00:01:31 ago Routing Descriptor Blocks: * 22.214.171.124 (default), from 126.96.36.199, 00:01:31 ago Route metric is 0, traffic share count is 1 AS Hops 1 Route tag 200 MPLS label: 27 MPLS Flags: MPLS Required
Let’s check is R7 can get to R10:
R7#ping 10.10.10.10 so lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds: Packet sent with a source address of 188.8.131.52 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/40/60 ms
Yes it can. However don’t be so quick. Let’s do a traceroute to see if all is okay:
R7#traceroute 10.10.10.10 so lo0 Type escape sequence to abort. Tracing the route to 10.10.10.10 1 10.0.127.12 4 msec 4 msec 8 msec 2 10.0.123.3 [MPLS: Labels 32/26/27 Exp 0] 32 msec 52 msec 40 msec 3 10.0.33.13 [MPLS: Labels 26/27 Exp 0] 88 msec 48 msec 52 msec 4 10.13.14.14 [MPLS: Labels 23/27 Exp 0] 48 msec 44 msec 52 msec 5 10.0.146.6 [MPLS: Labels 19/27 Exp 0] 40 msec 52 msec 28 msec 6 10.0.68.8 [MPLS: Label 27 Exp 0] 60 msec 12 msec 52 msec 7 10.0.68.6 [MPLS: Labels 16/24 Exp 0] 48 msec 40 msec 36 msec 8 10.0.109.9 [MPLS: Label 24 Exp 0] 16 msec 28 msec 36 msec 9 10.0.109.10 56 msec * 36 msec
The packets gets to R10 eventually, but check the path. the packet goes from R7 to R12, R3, R13, R14, R6, R8, back to R6, R9, R10
The reason this is happening is because R8 is setting the next-hop to iself when advertising the VPNV4 route over:
R12#show bgp vpnv4 un rd 184.108.40.206:2 10.10.10.10 BGP routing table entry for 220.127.116.11:2:10.10.10.10/32, version 7 Paths: (1 available, best #1, no table) Advertised to update-groups: 8 200 18.104.22.168 (metric 20) from 22.214.171.124 (126.96.36.199) Origin incomplete, localpref 100, valid, external, best Extended Community: RT:100:2 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.109.9:0 mpls labels in/out nolabel/27
Setting the next-hop to itself is the default behaviour when running eBGP VPNv4. What we need is to ensure that the route-reflectors do not change the next-hop to themselves when advertising. However if R8 advertises R9’s loopback as the next-hop, we need to adjust our earlier route-maps to allow 188.8.131.52/32 to come through as a route. I’ll show R13 here again. R14 is doing a very similar job.
ip prefix-list AS200_PREFIXES seq 10 permit 184.108.40.206/32 ip prefix-list PE_ADDRESS seq 10 permit 220.127.116.11/32
Now configure the route-reflectors not to change the next-hop:
router bgp 100 ! address-family vpnv4 neighbor 18.104.22.168 next-hop-unchanged
This should change the next-hop value:
R12#sh bgp vpnv4 unicast rd 22.214.171.124:2 10.10.10.10 BGP routing table entry for 126.96.36.199:2:10.10.10.10/32, version 7 Paths: (1 available, best #1, no table) Advertised to update-groups: 4 200 188.8.131.52 (metric 20) from 184.108.40.206 (220.127.116.11) Origin incomplete, localpref 100, valid, external, best Extended Community: RT:100:2 OSPF DOMAIN ID:0x0005:0x000000020200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.0.109.9:0 mpls labels in/out nolabel/24
So here we are at last. Let’s run this traceroute again:
R7#traceroute 10.10.10.10 so lo0 Type escape sequence to abort. Tracing the route to 10.10.10.10 1 10.0.127.12 8 msec 16 msec 4 msec 2 10.0.123.3 [MPLS: Labels 23/25/24 Exp 0] 36 msec 12 msec 32 msec 3 10.0.33.13 [MPLS: Labels 25/24 Exp 0] 52 msec 16 msec 24 msec 4 10.13.14.14 [MPLS: Labels 22/24 Exp 0] 20 msec 16 msec 32 msec 5 10.0.109.9 [MPLS: Label 24 Exp 0] 16 msec 24 msec 24 msec 6 10.0.109.10 24 msec * 24 msec
Much better. A route-reflector is often not in the transit path so it’s essential that this last step be done.