Inter-AS Option C
Load inter.as.l3vpn.option.c.init.cfg
#IOS-XE (R1-R10)
config replace flash:inter.as.l3vpn.option.c.init.cfg
#IOS-XR (XR1-XR2)
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 (VLAN 119).
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.
Answer
#R1
router bgp 100
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
!
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
#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
!
router isis 1
add ipv4 unicast
redistribute bgp 200
!
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 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-unchangedExplanation/Verification
In inter-AS option C, the ASBRs run IPv4 labeled unicast (BGP-LU) instead of VPNv4. This is more scalable, as the ASBRs no longer have to hold VPNv4 routes and terminate VPNv4 LSPs. The ASBRs only leak loopbacks to allow the RRs to peer, and allow end-to-end LSPs between PEs in each AS.
In this lab, R1 only needs to leak R5’s loopback and R2’s loopback. R5 is the RR and R2 is the only PE in AS100.
#R1
router bgp 100
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.255XR1 only needs to leak XR2’s loopback and R6’s loopback.
#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 outOnce the BGP session comes up, we see the same log message on IOS-XE as we saw in option B. The router will automatically add the command mpls bgp forwarding to the interface facing the eBGP IPv4 labeled-unicast peer, and add a connected route for the peer. This results in a local label for the /32 address of the peer.
On XR1, we must add a static route again.
#XR1
router static add ipv4 uni
12.1.19.1/32 gi0/0/0/0.119Now the ASBRs should learn IPv4 routes from each other with a label. We can verify this using show bgp ipv4 uni labels.
We must now redistribute these /32s into the local IGP. This will allow R2 and R6 to form an end-to-end transport LSP. (An alternative would be to run iBGP-LU, where the RR distributes BGP-LU routes instead of redistributing these remote loopbacks into the IGP).
#R1
router ospf 1
redistribute bgp 100
#XR1
router isis 1
add ipv4 unicast
redistribute bgp 200We should see LFIB entries for the PEs now:
The transport LSP between R2 and R6 uses IGP at each AS, and BGP IPv4 labels at the ASBR-ASBR link. The ASBRs automatically swap the incoming LDP label for the outgoing BGP label. As an example let’s look at 6.6.6.6/32. R1 allocates label 21 which is advertised via LDP to R3. R1 swaps this for 24004 which was learned via BGP IPv4 labeled unicast from XR1.
The final step is for the RRs to exchange VPNv4 routes with each other. They additionally should set next-hop-unchanged so that they are not in the forwarding path. This allows the RRs to not have to reserve a VPN label for every VPNv4 prefix, which we saw was the case for the ASBRs in option B. This makes option C more scalable than option B.
#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
#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
route-policy PASS in
route-policy PASS out
next-hop-unchangedLike in option B, the VPNv4 updates are globally significant, so the RTs must match between the SPs, and the BGP extcommunity values are carried end to end.
When tracing between two CEs, the VPNv4 label should be end-to-end, and the RRs should not be in the forwarding path.
The RRs do not have any state in the LFIB for the VPNv4 entries. The only routers in the topology with LFIB state for the VPNv4 entries are the PEs themselves. This makes option C very scalable. (Note that on IOS-XE, I do see VPNv4 entries in the LFIB for R5, but this does not appear to be needed).
Let’s examine what happens when the RRs do not set next-hop-unchanged. The default behavior is that the nexthop is set to the peering address, as it would be for any other eBGP session.
#R5
router bgp 100
add vpnv4
no neighbor 20.20.20.20 next-hop-unchanged
#XR2
router bgp 200
neighbor 5.5.5.5
add vpnv4 uni
no next-hop-unchangedThe RRs are now terminating the VPNv4 LSP, so they must allocate a unique label per VPNv4 prefix. Notice that the traceroute now goes through the RR. There are also two service labels now: 24007 which is allocated by XR2, and 26 which is allocated by R6.
Because XR2 is now terminating the VPNv4 LSP, it must allocate labels for each VPNv4 prefix:
If we turn next-hop-unchanged back on, these VPNv4 prefix entries in the LFIB will be removed.
Summary
Inter-AS option C is much more scalable than option B, but requires even more coordination and trust between SPs. The SPs must leak loopbacks of their PEs and RRs so that an inter-AS RR VPNv4 session can form, and end-to-end transport LSPs between PEs can work.
Inter-AS option C is somewhat more simple to configure than option B in my opinion. In option B, you have to remember to disable the RT filter, which is not required in option C. In option C, the RRs are peering directly, and an RR automatically disables the RT filter. Additionally, we had to run a VPNv4 session between the ASRBs, which does not seem as natural as running the ebgp multihop VPNv4 session between the RRs. The RRs are already running VPNv4 anyways, and the ASBRs may not be. The ASBRs, in option B, then need to install LFIB entires for every single VPNv4 entry which does not make as much sense as simply propagating the unchanged VPNv4 route end-to-end between the ASes.
In summary, these are the configuration steps for inter-AS option C:
Run eBGP IPv4 labeled unicast between ASBRs and leak the necessary /32 loopbacks of the PEs and RRs.
Redistribute these BGP prefixes into the IGP. The ASBRs will automatically install an LFIB entry which swaps the IGP label with the label learned via BGP. Alternatively, run iBGP-LU.
Form an eBGP multihop VPNv4 session between the RRs, and leave the nexthop unchanged. This will allow and end-to-end LSP to form between the PEs.
Last updated