Inter-AS Option B
Last updated
Last updated
Load inter.as.l3vpn.option.b.init.cfg
RIP, EIGRP, 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 now only a single subinterface (VLAN 30).
Configure option B so that R9/10 and R7/R8 have reachability.
Inter-AS option B is more scalable than option A. In option B, only a single link exists between the ASBRs. These links are in the global table. The ASBRs run BGP VPNv4, and exchange VPNv4 routes between each other. The ASBRs no longer need to have the VRFs locally defined.
A few configurations are needed to allow this to work:
Each ASBR must disable the VPNv4 RT filter. By default, a router will only accept VPNv4 routes for which it has a VRF that imports the RT. This is disabled when the router is a RR. But in this case, the ASBRs are neither RRs nor have the VRFs locally defined.
The ASBR should set next-hop-self on routes advertised to the local RR. Otherwise, the nexthop will be unchanged, and will be the remote ASBR’s address. This happens by default when VRF IPv4 routes (learned from a CE) are imported into VPNv4. But in this case we are learning VPNv4 routes from an eBGP peer and advertising them as VPNv4 to the RR, so the default nexthop rule of leaving the nexthop unchanged takes place. (Alternatively, you could redistribute the NNI link into the IGP).
Lastly, we must have a /32 route for the eBGP peer in order to do label switching based on the VPNv4 label learned over the eBGP VPNv4 session. This happens by default when you activate the peer on IOS-XE. However, this does not happen on IOS-XR. We must instead use a static route.
On R1 we can see that a /32 route has automatically been added to the routing table, and a local label has been reserved. As far as I can see, this local label is not actually used, it seems to be an internal mechanism to allow label switching to VPNv4 routes learned from this peer. I believe there is an internal check that verifies there is an LSP to the /32 nexthop address for a VPNv4 route. (If you are leaving the nexthop unchanged, the local label is used because you will need to redistribute this /32 into the IGP).
IOS-XE automatically adds the command mpls bgp forwarding to the interface used for the eBGP VPNv4 peering.
Once the static route is added on IOS-XR, the router also allocates a local label in the LFIB.
The providers must collaborate on the RT values. Either they need to import each other’s RT values in addition to their local RT, or they must use the same RTs. In this lab, the init config already had the VRFs using the same RTs in each AS. This requirement makes option B less attractive in the real world.
Traceroute between two CEs in either AS. Notice that there are now three LSPs. There is one PE-ASBR LSP in each AS, plus a single hop LSP between the two ASBRs. The single hop LSP uses the VPNv4 label.
Three LSPs:
What is nice about option B is that extcommunity values from OSPF or EIGRP are retained. On R7, the 8.8.8.8/32 route is learned as an internal EIGRP route. In option A, it was an external route (unless you run EIGRP at the ASBR-ASBR link, which is ugly).
The downside to option B, is that while routes are no longer installed in the ASBR’s FIB (because the VRFs don’t actually exist on the ASBRs), a single label is used up for every VPNv4 prefix. If there are a large amount of routes learned over the eBGP VPNv4 session, this could quickly use up the local ASBR’s label space.
There is no option for a “per-vrf” label space, because these VPNv4 routes are not being imported into a VRF. On R1, notice that there is one label for every single VPNv4 route learned via the ASBR, and learned via the local PE.
Instead of using next-hop-self on the ASBR’s VPNv4 session with the local RR, we could advertise the remote ASBR’s /32 into the IGP, and leave the nexthop unchanged. This results in only two LSPs, one LSP from the PE to the remote ASBR, and one from the remote ASBR to its local PE.
This produces a traceroute with only two VPN labels (24011 and 24005):
Above, 24011 is XR1’s VPN label. 24005 is XR2’s VPN label. The diagram below shows the two LSPs when R7 sends traffic to R8:
When R8 sends traffic to R7, the LSPs are flipped. The first LSP is XR2 to R1, and then the second LSP is R1 to R2.
The advantage to leaving the nexthop unchanged on the VPNv4 route is that it cuts down on the number of entries in the local ASBR’s LFIB. If the local ASBR resets the nexthop to itself when advertising the VPNv4 route internally, it must have an entry for all local VPNv4 prefix, plus all remote VPNv4 prefixes. When leaving the nexthop unchanged, the ASBR now only has to have an entry for all local VPNv4 prefixes. All remote VPNv4 prefixes will have the same top transport label representing the /32 of the remote ASBR, which the local ASBR just pops off, revealing the remote ASBR’s VPN label.
IOS-XR also includes a protection mechanism for option B. The idea is that with option B, you are trusting that the remote provider won’t try to spoof MPLS packets. You can implement an rpf check which only permits received labeled packets with MPLS labels that have been locally allocated and advertised to the eBGP peer.
Compared to option A, option B is more scalable but requires trust and coordination between SPs. For this reason, option B is likely not used much in the real world unless there is a significant number of VPNs being exchanged over the L3 NNI.
Option B is more scalable because:
Only one link is used
In option A, one sub interface per VRF is needed
The VRFs do not need to be globally defined, which in turn means the VPNv4 prefixes are not installed into the FIB
However, at least the local VPNv4 prefixes are installed into the LFIB, as the ASBR terminates the LSP for these prefixes
The BGP extcommunities are retained end-to-end between ASes
Option B requires more work to setup:
Configuration
Disabling RT filter
Static /32 route for eBGP VPNv4 peer so that labeled traffic works
Next-hop-self on vpnv4 routes towards internal RR
Or leave the next-hop unchanged and redistribute the /32 of the eBGP peer into the IGP
Coordination between SPs
RT values
The RT is locally significant in option A, but is globally significant in option B
Option B lacks some scalability, because all VPNv4 prefixes must be entered into the LFIB on the ASBRs. Option C improves upon this as you will see next.
