A link has been added between R3 and R4. Configure a multi-homed inter-AS option C setup, so that R7/R8 and R9/R10 have reachability. Everything has been preconfigured except for the inter-AS setup.
Use R1-XR1 as the primary link for VPN_A, and R3-R4 as the primary link for VPN_B. In the case of link failure, the other remain link should provide backup.
This is a difficult lab, as there are a few gotchas to watch out for. First, we must notice that we need to have VPN_A traffic use the R1-XR1 link, and VPN_B traffic use the R3-R4 link. The issue is that both VPNs terminate on the same PEs (R2 and R6). Because the LSP is end-to-end in option C, we can’t simply use BGP techniques to influence VPN_A traffic differently from VPN_B traffic. At the inter-AS links, the traffic is simply a transport label representing 2.2.2.2 or 6.6.6.6. Both VPN_A and VPN_B traffic uses these loopback IPs.
The solution is to create a new loopback on R2 and R6. We create Lo1 with x.x.x.1/32 on R2 and R6. IOS-XE has a handy command to control which loopback is the source address as the nexthop for VPNv4 updates.
#R2
int lo1
ip add 2.2.2.1 255.255.255.255
ip ospf 1 area 0
!
vrf def VPN_A
add ipv4
bgp next-hop Lo1
#R6
int lo1
ip add 2.2.2.1 255.255.255.255
!
vrf def VPN_A
add ipv4
bgp next-hop Lo1
!
router isis
passive-int lo1
On IOS-XR, there does not seem to be an equivalent for bgp next-hop Lo1. If the PE was IOS-XR, I believe you would have to use a route-policy to change the nexthop for VPNv4 routes with the associated RD or RT to the new loopback.
Next, we configure option C as normal. The ASBRs advertise all PE loopbacks plus the RR loopback. The RRs form a multihop eBGP VPNv4 session and leave the nexthop unchanged. The remote loopbacks learned at the ASBRs are redistributed into IGP. These are all items seen in the regular option C lab.
To influence traffic for VPN_A and VPN_B to go the desired path, we use outbound route policies to prepend the AS path. You could also use LP as we have in previous labs, but this lab chooses to use an outbound policy to demonstrate a quirk on IOS-XE when using outbound route-maps with BGP IPv4-LU. If you omit the set mpls-label command in a route-map statement, the router will not advertise any routes at all for routes matching that statement. It is extremely easy to run into this problem and not understand why routes are not being advertised!
The below route-maps prepend the AS for the R2 or R6 loopback which should not traverse the link. So R1 prepends 2.2.2.2/32 which is for VPN_B, and R3 prepends 2.2.2.1/ which is for VPNA. Likewise, XR1 prepends 6.6.6.6/32 and R4 prepends 6.6.6.1/32.
#R1
ip prefix-list R2_VPN_B_NEXTHOP permit 2.2.2.2/32
!
route-map XR1_OUTBOUND
match ip address prefix-list R2_VPN_B_NEXTHOP
set as-path prepend 100 100
set mpls-label
route-map XR1_OUTBOUND permit 20
set mpls-label
!
router bgp 100
neighbor 12.1.19.19 route-map XR1_OUTBOUND out
#R3
ip prefix-list R2_VPN_A_NEXTHOP permit 2.2.2.1/32
!
route-map R4_OUTBOUND
match ip address prefix-list R2_VPN_A_NEXTHOP
set as-path prepend 100 100
set mpls-label
route-map R4_OUTBOUND permit 20
set mpls-label
!
router bgp 100
neighbor 30.3.4.4 route-map R4_OUTBOUND out
#R4
ip prefix-list R6_VPN_A_NEXTHOP permit 6.6.6.1/32
!
route-map R3_OUTBOUND
match ip address prefix-list R6_VPN_A_NEXTHOP
set as-path prepend 200 200
set mpls-label
route-map R3_OUTBOUND permit 20
set mpls-label
!
router bgp 200
neighbor 30.3.4.3 route-map R3_OUTBOUND out
#XR1
route-policy R1_OUTBOUND
if destination in (6.6.6.6/32) then
prepend as-path 200 2
endif
pass
end-policy
!
router bgp 200
neighbor 12.1.19.1
add ipv4 label
route-policy R1_OUTBOUND out
Lastly, the ASBRs need to run an iBGP session between each other. Otherwise, they will always choose their eBGP route, even though it is prepended, because no other competing BGP route exists. By running iBGP, it allows R1 to choose R3 as a bestpath to 6.6.6.6/32, etc.
First we’ll verify that routes are learned at the ASBRs as we expect. On R1, we learn three loopbacks from XR1. The 6.6.6.6/32 loopback is prepended, so we prefer R3 for this. Due to this, our iBGP route would have an AD of 200. But R3 is redistributing BGP into OSPF, so R1 uses the OSPF route, and hence the 6.6.6.6/32 is marked as rib-failure.
We see the same thing on R3 for 6.6.6.1/32. This loopback is used for VPN_A traffic, which we want to use the R1-XR1 link.
Similarly on XR1, we see 2.2.2.2/32 prepended. Oddly, even though this route is not marked as rib failure, the route is known via ISIS.
On R4 we see the same thing for 2.2.2.1/32.
We can now confirm that CE to CE traffic is taking the correct path. VPN_A traffic should use the R1-XR1 link:
Traffic for VPN_B should be taking the R3-R4 link:
When we shut down the R1-XR1 link, VPN_A traffic should take the R3-R4 link:
#R1
int gi2.119
shut
#XR1
int gi0/0/0/0.119
shut
Likewise, if we bring the R1-XR1 link back up and bring down the R3-R4 link, VPN_B traffic should take the R1-XR1 link:
#R3, R4
int gi2.30
shut
Summary
This lab is a bit intimidating due to how involved it is. But when you break it down it is not too bad.
Regular inter-AS option C is setup, with an additional BGP IPv4-LU session between R3 and R4
This involves ASBRs leaking prefixes using BGP IPv4 LU
On IOS-XR, you must add a static /32 route for the BGP IPv4 LU peer
The RRs peer using an eBGP multihop VPNv4 session and leave the nexthop unchanged
To influence traffic, we created an additional Lo1 on R2 and R6. We set VPN_A to use Lo1 as the nexthop in VPNv4 outbound updates, instead of Lo0.
At the ASBRs, we prepended the PE’s Lo0 or Lo1 traffic to influence traffic according to the goals. (VPN_A traffic needed to use R1-XR1 as primary, and VPN_B traffic needed to use R3-R4 as primary).
We had to remember to use set mpls-label in the outbound route-map on IOS-XE to ensure that the router still advertises a label with the IPv4 update. If you instead were to use LP on an inbound route-map, you wouldn’t need to worry about this.
