# 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
```

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FrHSFtLzLVTlPLpNXbh99%2Fimage.png?alt=media&#x26;token=3d298803-c6d0-46b6-b7a0-3e1fc308814a" alt=""><figcaption></figcaption></figure>



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 <a href="#id-489c4cba-7219-4908-bf17-6457110a8775" id="id-489c4cba-7219-4908-bf17-6457110a8775"></a>

```
#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 unicast
```



## Explanation <a href="#id-2acb3923-461d-4afd-b4f8-8a231ae54662" id="id-2acb3923-461d-4afd-b4f8-8a231ae54662"></a>

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 out
```



We can verify this by doing a traceroute between the CEs. VPN\_A uses the R1-XR1 link:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F8RJV43tBwBXo8hLHuuNp%2Fimage.png?alt=media&#x26;token=0ce57104-6e79-49ed-9c5c-2cbfb09cc8bc" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FnxFKrjBM9wiS68yGQ0Uz%2Fimage.png?alt=media&#x26;token=dd3e3460-7dbb-4814-9f5a-e9a68d1fc8e0" alt=""><figcaption></figcaption></figure></div>



VPN\_B uses the R3-R4 link:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FNlXYxz6CcLLf8LmxdyAu%2Fimage.png?alt=media&#x26;token=6a6db7a3-9fb1-499d-b3e1-315e8931918b" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fw23tldoDVGCFQMoncFFw%2Fimage.png?alt=media&#x26;token=3b17bb72-89f2-4124-9e07-20180fcf2012" alt=""><figcaption></figcaption></figure></div>



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
```

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FUkXSH8bHmU5OG4U9tFN0%2Fimage.png?alt=media&#x26;token=da93bbe1-1a19-40f9-ac2b-c394407103b1" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FwQdKbYXEHDWiFicGFMiE%2Fimage.png?alt=media&#x26;token=78d5ef8b-18a8-46af-8c83-b71011ab7c1d" alt=""><figcaption></figcaption></figure></div>



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
```

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FOtD1o1WNSDrAZ5jc3vlR%2Fimage.png?alt=media&#x26;token=930afeeb-a686-453f-8e04-ac6394bc0d50" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FlEudDKNtABy1cK283R7A%2Fimage.png?alt=media&#x26;token=6ba70ade-2ae3-4728-8c5d-f7771d1d8001" alt=""><figcaption></figcaption></figure></div>



## Summary <a href="#id-935500bf-ceb9-43cd-bb8e-12e6c94a6fa8" id="id-935500bf-ceb9-43cd-bb8e-12e6c94a6fa8"></a>

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.
