Inter-AS Option A
Last updated
Last updated
Load inter.as.l3vpn.option.a.init.cfg
RIP, EIGRP, LDP, and VPNv4 is already pre-configured. The inter-AS configuration between R1 and XR1 is not configured yet. Use option A so that CEs R9/R10, and R7/R8 have reachability. Use VLAN 30 for VPN_A, and VLAN 40 for VPN_B.
Inter-AS option A is the most basic inter-AS solution. In fact, its simplicity and lack of information sharing between SPs is why it is the most widely deployed inter-AS solution.
In inter-AS option A, each ASBR treats the other ASBR as a CE. One subinterface per VRF is required. The SPs can reuse the IP addresses on each subinterface if desired, as each subinterface is in a different VRF.
The drawbacks to this option are:
Lack of scalability
One subinterface per VRF
Each VRF needs to be defined on the ASBR, even if no other CEs connect to this router
The routes for each VRF are installed in the FIB
Loss of extcommunities for OSPF and EIGRP routes. These routes will appear as external between CEs in different SPs, because the extcommunity attributes that have encoded the OSPF/EIGRP attributes are lost at the ASBR-ASBR link.
The ASBR-ASBR link is regular IPv4 traffic, not MPLS labeled. One benefit of this is that it is easy to do per-customer QoS on the ASBR-ASBR link. (This ASBR-ASBR link is also called an “NNI” - network-to-network interface).
SPs like option A because there is a complete lack of information sharing between each AS. The SPs don’t have to coordinate on the RT values, leak PE or RR loopbacks, etc, like in option B and C.
Traceroute between two CEs in either AS. Notice that there are two LSPs, plus a native IPv4 routed link in the middle at the ASBR-ASBR link.
At each ASBR, we are learning all prefixes via VPNv4 from the internal PE, and via IPv4 unicast in the VRF from the other ASBR.
There is a lack of scalability in this option, not only because one subinterface is needed for each VPN, but also because all of these prefixes must be installed in the FIB.
Also notice that the EIGRP CEs (R7 and R8) see routes to each other as EIGRP External routes. If these CEs were attached to the same service provider, these routes could instead be installed as internal EIGRP routes. At R1 we can see that the EIGRP attributes are attached to the route learned from R2. However, these are lost when the route must be translated into a regular IPv4 unicast BGP update.
Interestingly, if we use EIGRP as the ASRB-ASBR routing protocol instead of BGP, we can retain these values. However, this is definitely not something that would typically be done in the real world. Nevertheless it’s interesting to lab:
The EIGRP routes are now internal instead of external:
