Inter-AS Option A Multi-Homed
Load inter.as.l3vpn.option.a.multi.homed.init.cfg
#IOS-XE
config replace flash:inter.as.l3vpn.option.a.multi.homed.init.cfg
#IOS-XR
configure
load bootflash:inter.as.l3vpn.option.a.multi.homed.init.cfg
commit replace
y
A link has been added between R3 and R4. Configure a multi-homed inter-AS option A setup, so that R7/R8 and R9/R10 have reachability. Everything has been preconfigured except for the inter-AS setup.
Use R1-XR1 as the primary link for VPN_A, and R3-R4 as the primary link for VPN_B. In the case of link failure, the other remaining link should provide backup.
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
!
int Gi2.30
vrf forwarding VPN_A
ip add 30.1.19.1 255.255.255.0
int gi2.40
vrf forwarding VPN_B
ip add 40.1.19.1 255.255.255.0
!
route-map SET_LP_110
set local-pref 110
!
router bgp 100
neighbor 3.3.3.3 remote-as 100
neighbor 3.3.3.3 update-so lo0
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 update-so lo0
!
add vpnv4
neighbor 3.3.3.3 activate
neighbor 2.2.2.2 activate
!
add ipv4 vrf VPN_A
neighbor 30.1.19.19 remote-as 200
neighbor 30.1.19.19 route-map SET_LP_110 in
add ipv4 vrf VPN_B
neighbor 40.1.19.19 remote-as 200
#R2
router bgp 100
neighbor 3.3.3.3 remote-as 100
neighbor 3.3.3.3 update-source Loopback0
!
address-family vpnv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extended
#R3
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
!
int Gi2.30
vrf forwarding VPN_A
ip add 30.3.4.3 255.255.255.0
int gi2.40
vrf forwarding VPN_B
ip add 40.3.4.3 255.255.255.0
!
route-map SET_LP_110
set local-pref 110
!
router bgp 100
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-so lo0
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 update-so lo0
!
add vpnv4
neighbor 1.1.1.1 activate
neighbor 2.2.2.2 activate
!
add ipv4 vrf VPN_A
neighbor 30.3.4.4 remote-as 200
add ipv4 vrf VPN_B
neighbor 40.3.4.4 remote-as 200
neighbor 40.3.4.4 route-map SET_LP_110 in
#R4
vrf def VPN_A
rd 200:1
route-target both 200:1
address-family ipv4
!
vrf def VPN_B
rd 200:2
route-target both 200:2
address-family ipv4
!
int Gi2.30
vrf forwarding VPN_A
ip add 30.3.4.4 255.255.255.0
int gi2.40
vrf forwarding VPN_B
ip add 40.3.4.4 255.255.255.0
!
route-map SET_LP_110
set local-pref 110
!
router bgp 200
neighbor 19.19.19.19 remote-as 200
neighbor 19.19.19.19 update-so lo0
neighbor 20.20.20.20 remote-as 200
neighbor 20.20.20.20 update-so lo0
!
add vpnv4
neighbor 19.19.19.19 activate
neighbor 20.20.20.20 activate
!
add ipv4 vrf VPN_A
neighbor 30.3.4.3 remote-as 100
add ipv4 vrf VPN_B
neighbor 40.3.4.3 remote-as 100
neighbor 40.3.4.3 route-map SET_LP_110 in
#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
!
int gi0/0/0/0.30
no ipv4 add
vrf VPN_A
ipv4 add 30.1.19.19/24
!
int gi0/0/0/0.40
no ipv4 add
vrf VPN_B
ipv4 add 40.1.19.19/24
!
route-policy PASS
pass
end-policy
!
route-policy SET_LP_110
set local-pref 110
end-policy
!
router bgp 200
vrf VPN_A
rd 200:1
add ipv4 unicast
!
neighbor 30.1.19.1
remote-as 100
add ipv4 unicast
route-policy SET_LP_110 in
route-policy PASS out
!
vrf VPN_B
rd 200:2
add ipv4 unicast
!
neighbor 40.1.19.1
remote-as 100
add ipv4 unicast
route-policy PASS in
route-policy PASS out
#XR2
router bgp 200
neighbor 4.4.4.4
remote-as 200
update-source Loopback0
address-family vpnv4 unicastExplanation
This configuration looks quite complex but in reality it’s not too difficult. All ASBRs treat each other as CEs, as they always do in option A. Because we want VPN_A to use the R1-XR1 link primarily, and VPN_B to use the R3-R4 link primarily, we use LP on all ASBRs to enforce this.
#R1
router bgp 100
add ipv4 vrf VPN_A
neighbor 30.1.19.19 remote-as 200
neighbor 30.1.19.19 route-map SET_LP_110 in
add ipv4 vrf VPN_B
neighbor 40.1.19.19 remote-as 200
#R3
router bgp 100
add ipv4 vrf VPN_A
neighbor 30.3.4.4 remote-as 200
add ipv4 vrf VPN_B
neighbor 40.3.4.4 remote-as 200
neighbor 40.3.4.4 route-map SET_LP_110 in
#R4
router bgp 200
add ipv4 vrf VPN_A
neighbor 30.3.4.3 remote-as 100
add ipv4 vrf VPN_B
neighbor 40.3.4.3 remote-as 100
neighbor 40.3.4.3 route-map SET_LP_110 in
#XR1
router bgp 200
vrf VPN_A
rd 200:1
add ipv4 unicast
!
neighbor 30.1.19.1
remote-as 100
add ipv4 unicast
route-policy SET_LP_110 in
route-policy PASS out
!
vrf VPN_B
rd 200:2
add ipv4 unicast
!
neighbor 40.1.19.1
remote-as 100
add ipv4 unicast
route-policy PASS in
route-policy PASS outWe can verify this by doing a traceroute between the CEs. VPN_A uses the R1-XR1 link:
VPN_B uses the R3-R4 link:
If we shutdown the ASBR-ASBR link for R1-XR1, we can see that VPN_A traffic fails over to use the R3-R4 link.
#R1
int gi2.30
shut
int gi2.40
shut
#XR1
int gi0/0/0/0.30
shut
int gi0/0/0/0.40
shut
Likewise, if we bring this link back up and shutdown the R3-R4 links, VPN_B traffic fails over to use the R1-XR1 link.
#R3, R4
int gi2.30
shut
int gi2.40
shut
Summary
Dual-homing with inter-AS option A is really no different than dual-homing with IPv4 or VPNv4 CEs in general. We can use any BGP techinque such as LP, AS path prepending, MED, etc. to create primary and backup routes. This scenario is a popular choice among SPs because option A involves the least amount of coordination, and dual homing in this manner is an easy way to achieve redundancy.
Many situations may not have a primary/backup circuit, instead just using the default IGP lowest cost path to determine the best route. In fact, in our lab, if we remove all LP configuration, all traffic will use R3-R4 as primary due to the shortest IGP cost to the nexthop from the PEs R2 and XR2.
Last updated