Option B L3NNI
Load russo.pl.course.inter-as.opt.b.init.cfg
Configure inter-AS option B using the following guidelines:
Globomantics is AS65001 and Wired Brain is AS65002
Globomantics has two ASBRs. Setup the BGP advertisements so that optimal convergence is used within the AS.
Wired Brain only has one ASBR. Setup the BGP advertisements for ease of configuration/troubleshooting.
XR11 must be preferred for egress from AS65001 into AS65002 but R2 must be preferred for ingress from AS65002 into AS65001
Only configure policies on XR11 to accomplish this using MED and LP
Only use RPLs that take parameters
All IGP/BGP peerings are already setup (except for the ASBR-ASBR peerings for option B).
Answer
Explanation
Inter-AS option B introduces scalability at the ASBRs. The ASBRs no longer hold a VRF for every single customer VRF. Instead, the ASBRs exchange VPNv4/v6 routes directly. The NNI link is now MPLS enabled. To accomplish this, we must tweak a few settings:
The ASBR must accept all VPN prefixes even though it is not a RR, nor does it have the local VRFs
Must disable the RT fitler
The ASBR must enable MPLS forwarding for BGP prefixes on the NNI link
The ASBR must set next-hop-self on the VPN routes advertised towards the RR, or redistribute the NNI into the IGP
This task asks us to achieve optimal convergence within AS65001. This is accomplished by redistributing the NNI link into the IGP. This allows for slightly faster convergence when the link goes down. The IGP can react faster than BGP withdrawls/updates. This does not manifest itself until you are at large scale (which is why you might be choosing option B in the first place, though). The ASBR would have to withdraw many 1000s of prefixes upon a link down event. Instead, all PEs can detect the single /32 route dissapearing from the IGP and immediately invalidate all associated BGP routes.
On R2 we redistribute the connected prefix pointing to R3. This /32 connected route is automatically created on IOS-XE when an eBGP peer is established for VPNv4/v6 or IPv4/v6/LU.
On XR11 we must create a static /32 route to resolve labels in the LFIB. We redistribute this static route into the IGP using a parameterized RPL.
AS65002 only has one single ASBR, so this optimization is not needed. Instead, R3 just sets nexthop to itself. This simplifies operations, and keeps the IGP from having E2 routes. We will see later that this has an impact on the VPN label allocation.
The BGP peerings are fairly simple, so we won’t go over them in detail. Instead we’ll look at XR11’s policies. XR11 sets LP high on received routes from AS65002. XR11 also sets MED high, in order to influence AS65002 to use R2 as the preferred ingress point. R2 is sending a default MED of 0, so R3 should prefer R2 over XR11’s higher MED.
On R2, we see that the bestpath for these L3VPN prefixes is via XR11 due to the higher LP.
On R3, we see that the routes via R2 are best due to the lower MED. (Missing is 0 and is best by default).
The RTs have already been set to match between both ASs. Let’s traceroute from AS65001 to AS65002:
Above, we see that XR11 is the preferred egress point. Also, because XR11 is not setting next-hop-self, there are only two VPN labels - one allocated by R8 and one allocated by R3. Each time a router sets next-hop-self (which happens automatically at eBGP peerings), the router must terminate the LSP and allocate a new VPN label. This is because the router is setting its own IP address as the final nexthop for the route. When XR11 does not set next-hop-self, the final destination is R3, so XR11 can simply act as a transit node.
When we trace from AS65002 to AS65001 we see three VPN labels. This is because R3 is setting next-hop-self, so it must allocate its own local label for every VPN prefix. Also notice that R2 is the preferred ingress point for AS65002.
What characterizes option B is the single MPLS label at the NNI. The ASBRs must enable MPLS forwarding for BGP learned prefixes. This is accomplished on IOS-XE with the automatic mpls bgp forwarding command that is added to the NNI link. This is automatically added to the running configuration when the eBGP peer comes up.
On IOS-XR, this is automatically accomplished when running a VPN or LU address-family with an eBGP peer. There is no command added to the config, but MPLS is enabeld on the link for BGP VPNv4.
A closer look at eBGP VPNv4/v6 operations
Let’s examine the VPN behavior at the ASBRs more closely. Traffic from AS65001 to AS65002 is simpler because there are only two VPN labels.
R8 advertises the VPN route for 192.0.2.2/32 to the RR with service label 8004. Normally, only PEs that import the RT attached to the VPN route will import this route into their own VRF. These PEs would not allocate a label for that prefix, because these PEs are operating as an ingress PE. The PE will never be transit, so it doesn’t need to accept a certain incoming label and swap it to the egress PE’s VPN label.
However, the ASBR in this situation is different. This ASBR will never act as ingress PE for the VPN traffic, only a transit PE. It must allocate a local label so that it can receive labeled traffic inbound and swap it to the original VPN label and transport it to the egress PE. In this case, since R3 is setting nexthop self (by default as its an eBGP peering), R3 must allocate a service label (3005) so that R2 has some label to use to keep the LSP intact.
Summary
While inter-AS option A’s distinguishing characteristic is an unlabeled hop at the NNI, inter-AS option B’s distinguishing characteristic is a VPN label swap at the NNI. We will see in inter-AS option C that the VPN label is carried end-to-end, offering the greatest scalability.
Last updated
