Inter-AS Option AB (D)
Last updated
Last updated
Load inter.as.l3vpn.option.ab.init.cfg
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).
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.
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.
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.
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.
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.
