Inter-AS Option A
Load inter.as.l3vpn.option.a.init.cfg
#IOS-XE (R1-R4, R7-R10)
config replace flash:inter.as.l3vpn.option.a.init.cfg
#IOS-XR (XR1, XR2)
configure
load bootflash:inter.as.l3vpn.option.a.init.cfg
commit replace
y
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.
Answer
#R1
vrf definition VPN_A
rd 100:1
route-target export 100:1
route-target import 100:1
!
address-family ipv4
exit-address-family
!
vrf definition VPN_B
rd 100:2
route-target export 100:2
route-target import 100:2
!
address-family ipv4
exit-address-family
!
interface GigabitEthernet2.30
vrf forwarding VPN_A
ip address 30.1.19.1 255.255.255.0
!
interface GigabitEthernet2.40
vrf forwarding VPN_B
ip address 40.1.19.1 255.255.255.0
!
router bgp 100
add ipv4 vrf VPN_A
neighbor 30.1.19.19 remote-as 200
add ipv4 vrf VPN_B
neighbor 40.1.19.19 remote-as 200
#XR1
vrf VPN_A
address-family ipv4 unicast
import route-target
200:1
!
export route-target
200:1
!
!
!
vrf VPN_B
address-family ipv4 unicast
import route-target
200:2
!
export route-target
200:2
!
interface GigabitEthernet0/0/0/0.30
no ipv4 add
vrf VPN_A
ipv4 address 30.1.19.19 255.255.255.0
!
interface GigabitEthernet0/0/0/0.40
no ipv4 add
vrf VPN_B
ipv4 address 40.1.19.19 255.255.255.0
!
route-policy PASS
pass
end-policy
!
router bgp 200
vrf VPN_A
rd 200:1
add ipv4 uni
neighbor 30.1.19.1
remote-as 100
add ipv4 uni
route-policy PASS in
route-policy PASS out
!
vrf VPN_B
rd 200:2
add ipv4 uni
neighbor 40.1.19.1
remote-as 100
add ipv4 uni
route-policy PASS in
route-policy PASS outExplanation
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.
Verification
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:
#R1
router eigrp CUSTOMER
add ipv4 vrf VPN_B autonomous 1
network 40.1.19.1 0.0.0.0
topology base
redistribute bgp 100 metric 100000 1 255 1 1500
!
router bgp 100
add ipv4 vrf VPN_B
no neighbor 40.1.19.19 remote-as 200
redistribute eigrp 1
#XR1
route-policy BGP_TO_EIGRP
set eigrp-metric 10000 1 255 1 1500
end-policy
!
router eigrp CUSTOMER
vrf VPN_B
address-family ipv4
autonomous-system 1
redistribute bgp 200 route-policy BGP_TO_EIGRP
interface GigabitEthernet0/0/0/0.410
!
router bgp 200
vrf VPN_B
rd 200:2
address-family ipv4 unicast
redistribute eigrp 1
!
no neighbor 40.1.19.1The EIGRP routes are now internal instead of external:
Last updated