Inter-AS Option AB (D)

Load inter.as.l3vpn.option.ab.init.cfg

#IOS-XE (R2-R4, R7-R10)
config replace flash:inter.as.l3vpn.option.ab.init.cfg
 
#IOS-XR
configure
load bootflash:inter.as.l3vpn.option.ab.init.cfg
commit replace
y

Configure inter-AS option AB (also called option D) so that VPN_A traffic uses Gi12101, and VPN_B traffic uses Gi2.102. The ASBRs should exchange VPNv4 routes over a single eBGP session established on Gi2.34 between R3 and R4.

The L3VPN is already fully configured on the PEs (R2 and XR2).

Answer

#R3
vrf definition VPN_A
 rd 100:1
 route-target export 100:1
 route-target import 100:1
 route-target import 200:1
 !
 add ipv4
  inter-as-hybrid next-hop 10.101.34.4
!
vrf definition VPN_B
 rd 100:2
 route-target export 100:2
 route-target import 100:2
 route-target import 200:2
 !
 add ipv4
  inter-as-hybrid next-hop 10.102.34.4
!
interface GigabitEthernet2.101
 vrf forwarding VPN_A
 ip address 10.101.34.3 255.255.255.0
!
interface GigabitEthernet2.102
 vrf forwarding VPN_B
 ip address 10.102.34.3 255.255.255.0
!
router bgp 100
 neighbor 10.1.34.4 remote-as 200
 add vpnv4
  neighbor 10.1.34.4 activate
  neighbor 10.1.34.4 inter-as-hybrid

#R4
vrf definition VPN_A
 rd 200:1
 route-target export 200:1
 route-target import 200:1
 route-target import 100:1
 !
 add ipv4
  inter-as-hybrid next-hop 10.101.34.3
!
vrf definition VPN_B
 rd 200:2
 route-target export 200:2
 route-target import 200:2
 route-target import 100:2
 !
 add ipv4
  inter-as-hybrid next-hop 10.102.34.3
!
interface GigabitEthernet2.101
 vrf forwarding VPN_A
 ip address 10.101.34.4 255.255.255.0
!
interface GigabitEthernet2.102
 vrf forwarding VPN_B
 ip address 10.102.34.4 255.255.255.0
!
router bgp 200
 neighbor 10.1.34.3 remote-as 100
 add vpnv4
  neighbor 10.1.34.3 activate
  neighbor 10.1.34.3 inter-as-hybrid

Explanation/Verification

Option AB is essentially just option A but with an extra VPNv4 session in the global table. This gives you the traffic isolation of option A, which allows for QoS on a per-VRF basis, while still giving some scalability in terms of a single eBGP session between the ASBRs.

Option AB involves a nexthop “hack.” Under the VRF, you configure a nexthop rewrite for received VPNv4 routes from the eBGP peer. For example, on R3 for VRF VPN_A, you set the option AB nexthop as R4’s address on the 101 subinterface.

#R3
vrf definition VPN_A
 add ipv4
  inter-as-hybrid next-hop 10.101.34.4

The router knows to rewrite VPNv4 routes with the 10.101.34.4 nexthop based on a neighbor being defined with the keyword inter-as-hybrid.

#R3
router bgp 100
 add vpnv4
  neighbor 10.1.34.4 inter-as-hybrid

Additionally, the ASBRs must import the remote ASBR’s RT values. This is the same as with regular option B. The difference is that, because option A forwarding is used, the RT import is limited to only the ASBR. The ASBR will export the route to its iBGP peers using the local export RT. For example, below, R3 imports R4’s RT for VPN_A.

#R3
vrf definition VPN_A
 rd 100:1
 route-target export 100:1
 route-target import 100:1
 route-target import 200:1

When R3, acting as a PE, exports these VPN_A routes to R2, they will only have the 100:1 RT value. So all other routers in the AS do not need to be concerned with the remote AS’s RT values.

When you examine the VPNv4 routes on R3, the nexthop will still be 10.1.34.4, and the VPNv4 route will have a label associated with it:

However, the nexthop in the RIB will be re written to the value used in the VRF config. The router will also strip all MPLS labels, and forward as native IPv4, as in regular option A.

We can see that the VPNv4 label that R3 allocates for 10.10.10.10/32, when advertising the VPNv4 route to R2, has an outgoing action of no label:

When tracerouting between CEs, we should see that the path appears as in option A - unlabeled at the ASBR-ASBR link.

Summary

Option AB (also called option D), is a way to use option A but with only a single eBGP VPNv4 session between the ASBRs, as in option B. However, the labels associated with the VPNv4 routes are not used. Instead, the labels are “thrown away” and the outgoing packet is unlabeled. A RIB hack is used to rewrite the nexthop with the nexthop specified in the VRF using the command inter-as-hybrid nexthop. All VPNv4 routes learned from a peer tagged under BGP with inter-as-hybrid will have the nexthop replaced and will be forwarded without an MPLS label.

Note that this only works on IOS-XE. This does not appear to be supported on IOS-XR.

Last updated