Inter-AS Option C - iBGP LU
Last updated
Last updated
Load inter.as.l3vpn.option.c.init.cfg in the EVE INE SPv4 topology.
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.
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.
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.
