Option AB - Inter-AS MPLS VPN - The whole story (5) - Updated Dec 2008

In late 2007, Cisco introduced a new Inter-AS option; Option AB - This feature was introduced in the 12.2(33)SRC code. This feature combines the the best aspects of Option 1 (10A) and Option 2 (10B) (named type a and type b as per RFC4364 section 10 "Multi-AS Backbone").

Remember that type a (Option 1 AKA 10A) was not scalable, since a separate interface/subinterface and an eBGP session are required per each VRF on the ASBR, while it is simple, secure and per VRF QoS capable (per VRF interface/subinterface).

On the other hand type b (Option 2 AKA 10B) despite being scalable, it doesn't provide perfect VRF isolation or reasonable QoS, since it is now only one interface forwarding labeled packets.

This option is described in the following Cisco document:
MPLS VPN Inter-AS Option AB

To well understand this option we must focus on what really happens in the control plane and the forwarding/data plane levels separately.

Lets start first by examining the control plane. With Option AB a single MP-eBGP session is used to carry the control plane traffic, offering simple configuration with less overload on the ASBRs. This MP-eBGP session signals the VPN prefixes between the two ASBRs for each virtual routing and forwarding (VRF) instance. But this MP-eBGP session operates in the complete unique manner described below.

NOTE The VRFs configured on the ASBRs are called “Option AB VRFs" and the eBGP peers on the ASBRs are called “Option AB Peers”.

The inter-as-hybrid next-hop x.x.x.x command is used under the VRF configuration to configure the VRF as an Option AB VRF, and the neighbor x.x.x.x inter-as-hybrid command is explicitly used to configure the MP-eBGP peer router (ASBR) as an Inter-AS Option AB peer under the address-family vpnv4, in order to change the overall implementation behavior as described below:

• The local PE routers advertise the VPN prefixes to its local ASBR via MP-iBGP - Normal MP-iBGP operation.

• The local ASBR imports each prefix into its VRF normally using the RTs and replaces the received RD with the local RD configured for this VRF (consider the ASBR a normal PE router in this step).

• The local ASBR advertises the VPN prefixes with the export RTs configured locally for each VRF instead of the original RTs received from the original PE routers.

• The remote ASBR receives the VPN prefixes and imports each prefix into its VRF normally using the RTs and replaces the received RD with the local RD configured for this VRF (again, as if the ASBR is a normal PE router).

• When the remote ASBR imports the prefixes it sets the next-hop to be the IP address of the VRF interface on the facing (local) ASBR, and the next-hop table ID is also set to the relative VRF - Remember this step when we tackle the forwarding/data plane operation.

• Another thing that the remote ASBR does is that when it installs the MPLS forwarding entry for the VPN prefixes it discards the outgoing label, forcing the traffic between the ASBRs to be IP traffic rather than labeled traffic - Remember this step also when we tackle the forwarding/data plane operation.

NOTE In the case of a CSC scenario, we must use the mpls bgp forwarding command under the per VRF interfaces in order to instruct the BGP to enable MPLS forwarding on connected interfaces for VRFs that must support MPLS traffic, and also we must add the csc keyword to the inter-as-hybrid command under the VRF configuration to simply install the relative outgoing MPLS label.

• The remote ASBR then advertises the imported VPN prefixes over its MP-iBGP to its local PE router(s) using the local configured RTs rather than the originally received RTs.

• The remote ASBR sets itself as the next-hop for these prefixes and also allocates local labels that is signaled with the prefixes.

• Finally the remote PE routers imports the VPN prefixes into the appropriate VRFs using the RTs and replaces the received RD with the local RD configured for the VRFs.

After discussing the control plane, lets go into the forwarding/data plane operation. The data plane traffic is exchanged on a per VRF interfaces/subinterfaces model between the ASBRs. This traffic can either be IP or MPLS (in the case of CSC over Inter-AS MPLS). As illustrated in the control plane operation steps discussed earlier this is achieved by the fact that the next-hops of the VPN prefixes exchanged between the ASBRs are adjusted to be the IP addresses of the VRF interfaces on the facing (local) ASBR, and the next-hop table ID is also set to the relative VRF, thus when an ASBR receives traffic from a local PE router destined to a destination in the remote AS, it will use the relative VRF interface rather than the global interface over which the MP-eBGP session is established.

Isolating the data plane traffic on a per-VRF basis offers security and reasonable QoS between ASBRs to maintain customers' SLAs, as was the case with Option 1/Type a while still using only one BGP session to exchange all the VPN prefixes offering optimized scalability as was the case with Option2/Type b, accordingly this model has perfectly combined the benefits of both earlier options.

To be able to achieve the described behavior, practically there should be two types of interfaces/subinterfaces between the ASBRs, the first is per VRF interface/subinterface, and the second is an interface in the global routing table for the MP-eBGP peering between the ASBRs.

There is no need for the mpls bgp forwarding command neither LDP on the ASBR-to-ASBR interface/subinterface (in both directly connected or multihop using loopback scenarios) since there are no labeled packets forwarded over the non-VRF interface, it is only used for the MP-eBGP session - in this option the VPN traffic is sent as pure IP packets over the VRF specific interfaces/subinterfaces between the ASBRs - The only exception of this case is the CSC over Inter-AS scenario using Option AB, in such case the mpls bgp forwarding command is required under the per VRF interface/subinterface.

ASBR configuration example:

!
ip vrf test
 rd 1:1
 route-target export 1:1
 route-target import 1:1
 inter-as-hybrid next-hop 192.168.34.2
!
ip vrf test2
 rd 2:2
 route-target export 2:2
 route-target import 2:2
 inter-as-hybrid next-hop 192.168.34.6
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface ATM1/0.1 point-to-point
 description Connection to P1
 ip address 10.10.23.3 255.255.255.0
 ip router isis
 mpls ip
!
interface ATM2/0.1 point-to-point
 description Connection to ASBR2
 ip address 10.10.34.3 255.255.255.0
!
interface ATM2/0.10 point-to-point
 ip vrf forwarding test
 ip address 192.168.34.1 255.255.255.252
!
interface ATM2/0.20 point-to-point
 ip vrf forwarding test2
 ip address 192.168.34.5 255.255.255.252
!
router isis
 net 49.0001.0030.0300.3003.00
 is-type level-2-only
 metric-style wide
 log-adjacency-changes
 passive-interface Loopback0
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 10.10.34.4 remote-as 2
 no auto-summary
!
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
  neighbor 10.10.34.4 activate
  neighbor 10.10.34.4 send-community extended
  neighbor 10.10.34.4 inter-as-hybrid
  exit-address-family
!

I hope that I've been informative.

BR,
Mohammed Mahmoud.