Inter-AS Option C - iBGP LU

Load inter.as.l3vpn.option.c.init.cfg in the EVE INE SPv4 topology.

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

RIP, EIGRP, IGPs, LDP, and VPNv4 is already pre-configured. The route targets for the VRFs have been changed to match between each provider. The ASRB-ASBR link is a single subinterface.

Use inter-AS option C to create a single end-to-end LSP for VPN routes between R2 and R6. Only leak the minimum necessary routes at the ASBR eBGP session. All loopbacks are in the format X.X.X.X/32 where X=router number. Do not redistribute BGP routes into the IGP.

Answer

#R1
router bgp 100
 neighbor 5.5.5.5 remote-as 100
 neighbor 5.5.5.5 update-so lo0
 neighbor 5.5.5.5 send-label
 neighbor 5.5.5.5 next-hop-self
 neighbor 12.1.19.19 remote-as 200
 neighbor 12.1.19.19 send-label
 !
 network 2.2.2.2 mask 255.255.255.255
 network 5.5.5.5 mask 255.255.255.255

#R2
router bgp 100
 add ipv4
  neighbor 5.5.5.5 activate
  neighbor 5.5.5.5 send-label

#R3
router bgp 100
 neighbor 5.5.5.5 remote-as 100
 neighbor 5.5.5.5 update-so lo0
 neighbor 5.5.5.5 send-label

#R5
router bgp 100
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-so lo0
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-so lo0
 neighbor 20.20.20.20 remote-as 200
 neighbor 20.20.20.20 update-so lo0
 neighbor 20.20.20.20 ebgp-multihop
 !
 add ipv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-label
  neighbor 1.1.1.1 route-reflector-client
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-label
  neighbor 2.2.2.2 route-reflector-client
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 send-label
  neighbor 3.3.3.3 route-reflector-client
 add vpnv4
  neighbor 20.20.20.20 activate
  neighbor 20.20.20.20 next-hop-unchanged

#R4
router bgp 200
 neighbor 20.20.20.20 remote-as 200
 neighbor 20.20.20.20 update-so lo0
 neighbor 20.20.20.20 send-label

#R6
router bgp 200
 add ipv4
  neighbor 20.20.20.20 act
  neighbor 20.20.20.20 send-label

#XR1
route-policy PASS
 pass
end-policy
!
router bgp 200
 add ipv4 uni
  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 labeled-unicast
   route-policy PASS in
   route-policy PASS out
 !
 neighbor 20.20.20.20
  remote-as 200
  update-so lo0
  add ipv4 labeled-unicast
   next-hop-self
!
router static add ipv4 uni
 12.1.19.1/32 gi0/0/0/0.119

#XR2
route-policy PASS
 pass
end-policy
!
router bgp 200
 neighbor 19.19.19.19
  remote-as 200
  update-so lo0
  add ipv4 labeled-unicast
   route-reflector-client
 !
 neighbor 4.4.4.4
  remote-as 200
  update-so lo0
  add ipv4 labeled-unicast
   route-reflector-client
 !
 neighbor 6.6.6.6
  remote-as 200
  update-so lo0
  add ipv4 labeled-unicast
   route-reflector-client
 !
 neighbor 5.5.5.5
  remote-as 100
  update-so lo0
  ebgp-multihop
  add vpnv4 uni
   route-policy PASS in
   route-policy PASS out
   next-hop-unchanged

Explanation/Verification

In inter-AS option C, the ASBRs must leak the loopbacks of the RR and PEs. You have two options to distribute these BGP-learned remote prefixes into the local AS. You can either redistribute BGP into IGP (which is the easier option, and was seen in the last solution), or you can distribute these using BGP IPv4 labeled-unicast within the AS.

Using BGP might be desirable so that your IGP stays “cleaner” and there are no routes redistributed into the IGP. But when using BGP, we must run an additional IPv4 LU session within the iBGP mesh. Note that the transit routers, R3 and R4 in this example, technically do not need to run IPv4 LU because they will only see a transport top label of either the PE or ASBR.

This time, when R1 receives 20.20.20.20/32 and 6.6.6.6/32 from XR1, it does not redistribute these prefixes into the IGP. Instead, R1 advertises these to R5, which is the RR. R1 runs IPv4-LU with R5 using the send-label command. R5 then reflects this route to all other iBGP peers. Make sure to set next-hop-self on R1, so that the nexthop is changed to R1’s loopback.

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

Because R1 is setting next-hop-self, it allocates its own local label for these prefixes. The incoming label in the LFIB entry was allocated from BGP, and the outgoing label was learned from XR1 via eBGP IPv4-LU.

R2 learns the route for 6.6.6.6/32 with a label attached. The route points to 1.1.1.1/32. Therefore, two labels are used to forward transport traffic to R6. A top label to get to R1, and R1’s transport label for 6.6.6.6/32 learned via BGP IPv4-LU.

When we do a traceroute from R7 to R8, we now see a three label stack. The top label, 16, is the IGP label for R1. The second label, 21, is the BGP label for 6.6.6.6/32 that was allocated by R1. This is technically a second transport label. The third label, 26, is R6’s VPNv4 label for 8.8.8.8/32.

Notice that the VPN LSP is still end-to-end as before. The only difference is whether the remote PE loopbacks are redistributed into the IGP, or distributed via BGP IPv4-LU.