Option C L3NNI
Load russo.pl.course.inter-as.opt.c.init.cfg
Configure inter-AS option C using the following guidelines:
Globomantics is AS65001 and Wired Brain is AS65002
Globomantics has two ASBRs. Configure MED on XR11 and R2 so that R2 is used for ingress. R3 has bgp bestpath med missing-as-worst configured. Do not change this.
In AS65001, redistribute the BGP-LU routes into the IGP, and IGP routes into BGP-LU. Set the metric so that XR11 is the preferred egress point for remote loopbacks. Ensure that routing loops cannot occur.
In AS65002, use iBGP-LU for advertisement of transport labels for the remote PEs/RR
All IGP/BGP peerings are already setup (except for the ASBR-ASBR peerings for option C).
Answer
Explanation
Inter-AS option C provides even more scalability by removing the VPN tables on the ASBRs. Instead, the ASBRs simply share loopbacks of their PEs and RRs. This is used to extend BGP services between the ASs. The RRs form a BGP session to reflect service routes, and the PEs will have remote PEs loopbacks in their RIB in order to form end-to-end LSPs.
AS65002 is simpler, so we will start there. There is only one ASBR, which is R3. The AS will run iBGP-LU instead of having the ASBR redistribute the routes into the IGP. This is more scalable than poluting the IGP with external routes. Plus, AS65002 is using SR, so this would not work anyways, as the routers would not allocate a label for these redistributed prefixes.
Within AS65002, each PE and RR simply advertises its own loopback into BGP-LU. A label is allocated, but by default imp-null will be allocated, as the PE itself owns the prefix. However, this allows R3 to then allocate its own label for the prefix, as it is setting next-hop-self to the ASBRs on the NNI.
XR14 does the same, and enables IPv4/LU for the iBGP RR peers.
Next, AS65001 runs BGP-LU on the NNI as well. R2 sets the MED outbound to a lower number than XR11. This is done to demonstrate the need for the set mpls-label command on IOS-XE. When you use an outbound route-map on a BGP IPv4/LU peer, you must include this command. Otherwise, the MPLS label is stripped. You can however not use an outbound route-map without any issues. But if you do use an outbound route-map, you must include this set statement.
R2 and XR11 also redistribute loopbacks from the IGP into BGP. They deny tag 20 to prevent route redistribution loops.
Additionally, R2 and XR11 redistribute the BGP routes into the IGP directly. They set the tag which prevents route feedback when ISIS routes are advertised back into BGP. XR11 sets the metric lower so that egress traffic uses XR11 instead of R2.
Now that both ASs have each other’s loopbacks, the RRs can form an eBGP session and exchange any needed VPN service routes. Remember to use next-hop-unchanged so that the RRs are not inserted into the data path, and also do not allocate their own VPN labels.
Verification
Within AS65001, we see routes for the remote loopbacks via the IGP. XR11 is preferred as egress:
Within AS65002, the PEs and RRs know the remote loopbacks via BGP-LU.
The result is that traffic from AS65002 will be transported to R3 with a top label of 16003, and a bottom label of the BGP label that R3 allocated for each prefix.
However, traffic from AS65001 to AS65002 only needs a single transport label, as the loopbacks are redistributed directly into IGP, where LDP allocates labels. In AS65002, BGP-LU is essentially another service, so R8 needs to tunnel traffic to R3, as the AS65002 core is “BGP-LU free.”
Let’s now look at BGP services. R6 has VPNv4 and VPNv6 routes that have nexthops of R8 and R10. This is because the RR is doing next-hop-unchanged. This gives the “feel” of all PEs being within the same AS. Once you accomplish inter-AS loopback transport, VPN services simply resolve to the real PE loopbacks.
Similarly, R8 and R10 have routes pointing to XR12 (which is the bestpath due to lower MED advertised by R1 in L3A) and R6.
A traceroute from L3A to L3B reveals at most two labels. This is because AS65001 does not need to use an extra transport label in the core due to redistributing BGP-LU routes directly into the IGP.
A traceroute in the other direction produces a three-label stack within AS65002 due to the extra transport label.
Summary
Inter-AS option C is somewhat more simplistic than option B. The ASBRs are simply used to advertise PE/RR loopback reachability. This must have a label associated with it so that the LSP can work end-to-end. BGP-LU is used to allocate a label for each prefix. Just like option B, we must be careful to enable MPLS on the NNI. This involves a static route on IOS-XR, and ensuring the mpls bgp forwarding command exists on the NNI on IOS-XE.
Once the loopback reachability is established, the RRs run an eBGP session with the nexthop unchanged to propagate service routes between the ASs. From there, the PEs will preform normal VPN service operations, finding the service label from the BGP route, and transporting the traffic to the remote PE using either the IGP or BGP-LU to find the transport label.
As a summary:
Option A uses a per-VRF subinterface on the NNI. The ASBRs treat each other as CEs.
This is characterized by an unlabeled hop at the NNI.
Option B uses VPNv4/v6 sessions between the ASRBs. The ASBRs must allocate a local label for every VPN route advertised to the remote ASBR over the NNI.
This is characterized by a single-labeled hop at the NNI.
There are either two or three VPN labels in the end-to-end path. If the ASBR sets next-hop-self on the iBGP session to the RR, there are three VPN labels.
Option C uses BGP-LU sessions between the ASRBs. The ASBRs only need to allocate a local label per PE/RR which is very scalable. The RRs run an eBGP session with next-hop-unchanged. The PEs can then form a complete end-to-end LSP.
This is characterized by a double-labeled hop at the NNI.
The AS has the option to redistribute the remote BGP-LU prefixes into IGP, using LDP to bind labels, or extend iBGP-LU to all PEs. If extending iBGP-LU, you will see a three-label stack in that AS. Top label is transport to the ASBR. Middle label is service label for the iBGP-LU prefix representing the remote PE. Bottom label is the final VPN label learned from the remote PE.
Last updated
