Inter-AS Option C Multi-Homed

Load inter.as.l3vpn.option.c.multi.homed.init.cfg

#IOS-XE
config replace flash:inter.as.l3vpn.option.c.multi.homed.init.cfg
 
#IOS-XR
configure
load bootflash:inter.as.l3vpn.option.c.multi.homed.init.cfg
commit replace
y

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.

Answer

#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 remote-as 200
 neighbor 12.1.19.19 send-label
 neighbor 12.1.19.19 route-map XR1_OUTBOUND out
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-so lo0
 neighbor 3.3.3.3 next-hop-self
 neighbor 3.3.3.3 send-label
 !
 network 2.2.2.1 mask 255.255.255.255
 network 2.2.2.2 mask 255.255.255.255
 network 5.5.5.5 mask 255.255.255.255
!
router ospf 1
 redistribute bgp 100

#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

#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 remote-as 200
 neighbor 30.3.4.4 send-label
 neighbor 30.3.4.4 route-map R4_OUTBOUND out
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-so lo0
 neighbor 1.1.1.1 next-hop-self
 neighbor 1.1.1.1 send-label
 !
 network 2.2.2.1 mask 255.255.255.255
 network 2.2.2.2 mask 255.255.255.255
 network 5.5.5.5 mask 255.255.255.255
!
router ospf 1
 redistribute bgp 100
 
#R5
router bgp 100
 neighbor 20.20.20.20 remote-as 200
 neighbor 20.20.20.20 update-so lo0
 neighbor 20.20.20.20 ebgp-multihop
 add vpnv4
  neighbor 20.20.20.20 activate
  neighbor 20.20.20.20 next-hop-unchanged
  
  
#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 remote-as 100
 neighbor 30.3.4.3 send-label
 neighbor 30.3.4.3 route-map R3_OUTBOUND out
 neighbor 19.19.19.19 remote-as 200
 neighbor 19.19.19.19 update-so lo0
 neighbor 19.19.19.19 next-hop-self
 neighbor 19.19.19.19 send-label
 !
 network 6.6.6.1 mask 255.255.255.255
 network 6.6.6.6 mask 255.255.255.255
 network 20.20.20.20 mask 255.255.255.255
!
router isis
 redistribute bgp 200
 
#XR1
router static add ipv4 uni
 12.1.19.1/32 gi0/0/0/0.119
!
route-policy R1_OUTBOUND
  if destination in (6.6.6.6/32) then
    prepend as-path 200 2
  endif
  pass
end-policy
route-policy PASS
 pass
end-policy
!
router bgp 200
 add ipv4 uni
  network 6.6.6.1/32
  network 6.6.6.6/32
  network 20.20.20.20/32
  allocate-label all
 !
 neighbor 12.1.19.1
  remote-as 100
  add ipv4 label
   route-policy R1_OUTBOUND out
   route-policy PASS in
 !
 neighbor 4.4.4.4
  remote-as 200
  update-so lo0
  add ipv4 label
   next-hop-self
!
router isis 1
 add ipv4
  redistribute bgp 200

#XR2
route-policy PASS
 pass
end-policy
!
router bgp 200
 neighbor 5.5.5.5
  remote-as 100
  update-so lo0
  ebgp-multihop
  add vpnv4 uni
   next-hop-unchanged
   route-policy PASS in
   route-policy PASS out

#R6
int lo1
 ip add 6.6.6.1 255.255.255.255
!
vrf def VPN_A
 add ipv4
  bgp next-hop Lo1
!
router isis
 passive-int lo1

Explanation

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.

#R1
router bgp 100
 neighbor 12.1.19.19 remote-as 200
 neighbor 12.1.19.19 send-label
 !
 network 2.2.2.1 mask 255.255.255.255
 network 2.2.2.2 mask 255.255.255.255
 network 5.5.5.5 mask 255.255.255.255
!
router ospf 1
 redistribute bgp 100

#R3
router bgp 100
 neighbor 30.3.4.4 remote-as 200
 neighbor 30.3.4.4 send-label
 neighbor 30.3.4.4 route-map R4_OUTBOUND out
 !
 network 2.2.2.1 mask 255.255.255.255
 network 2.2.2.2 mask 255.255.255.255
 network 5.5.5.5 mask 255.255.255.255
!
router ospf 1
 redistribute bgp 100
 
#R5
router bgp 100
 neighbor 20.20.20.20 remote-as 200
 neighbor 20.20.20.20 update-so lo0
 neighbor 20.20.20.20 ebgp-multihop
 add vpnv4
  neighbor 20.20.20.20 activate
  neighbor 20.20.20.20 next-hop-unchanged
  
#R4
router bgp 200
 neighbor 30.3.4.3 remote-as 100
 neighbor 30.3.4.3 send-label
 neighbor 30.3.4.3 route-map R3_OUTBOUND out
 !
 network 6.6.6.1 mask 255.255.255.255
 network 6.6.6.6 mask 255.255.255.255
 network 20.20.20.20 mask 255.255.255.255
!
router isis
 redistribute bgp 200
 
#XR1
router static add ipv4 uni
 12.1.19.1/32 gi0/0/0/0.119
!
route-policy PASS
 pass
end-policy
!
router bgp 200
 add ipv4 uni
  network 6.6.6.1/32
  network 6.6.6.6/32
  network 20.20.20.20/32
  allocate-label all
 !
 neighbor 12.1.19.1
  remote-as 100
  add ipv4 label
   route-policy PASS out
   route-policy PASS in
!
router isis 1
 add ipv4
  redistribute bgp 200

#XR2
route-policy PASS
 pass
end-policy
!
router bgp 200
 neighbor 5.5.5.5
  remote-as 100
  update-so lo0
  ebgp-multihop
  add vpnv4 uni
   next-hop-unchanged
   route-policy PASS in
   route-policy PASS out

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.

#R1
router bgp 100
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-so lo0
 neighbor 3.3.3.3 next-hop-self
 neighbor 3.3.3.3 send-label

#R3
router bgp 100
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-so lo0
 neighbor 1.1.1.1 next-hop-self
 neighbor 1.1.1.1 send-label

#R4
router bgp 200
 neighbor 19.19.19.19 remote-as 200
 neighbor 19.19.19.19 update-so lo0
 neighbor 19.19.19.19 next-hop-self
 neighbor 19.19.19.19 send-label
 
#XR1
router bgp 200
 neighbor 4.4.4.4
  remote-as 200
  update-so lo0
  add ipv4 label
   next-hop-self

Verification

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.

PreviousInter-AS Option B Multi-HomedNextRusso Inter-AS

Last updated