Orhan Ergun 2 Comments

Inter-AS Option AB is also known as Option D or Hybrid Inter AS Option. It is called Hybrid because Inter-AS Option B uses the best capabilities of Inter-AS Option A and Inter-AS Option B. These capabilities will be explained throughout this post.

MPLS VPN providers often need to inter-connect different ASes to provide VPN services to customers.

Inter-AS Option AB first deployed by Cisco but today many vendors including Juniper provides Inter-AS Option AB feature.

But what are the best capabilities of the Inter-AS Option A and Inter-AS Option B ?

  • Inter-AS Option A is most secure, least scalable Inter-AS MPLS VPN solution. Since separate sub-interface is setup for each VPN and traffic between the ASBRs is IP traffic, QoS can be provided in much granular level compare to the other Inter-AS MPLS VPN Options (Option B and Option C). Also having separate sub-interface per VRF provides data plane isolation which brings security to the solution. Thus Inter-AS Option A is seen as most secure Inter-AS Option.

inter-as option a

Figure – 1 Inter-AS Option A

As you can see in Figure-1 Inter-AS Option A, separate sub-interface or physical interface is created for each customer VPN/VRF. Traffic is IP between the Service Providers. Between the ASBRs of the Service Providers BGP or IGP protocols advertise customer VPN prefixes. Creating and maintaining separate routing protocol for each sub-interface is not scalable if the number of Inter-AS MPLS VPN customer is too much.

For the Inter-AS Option A, conclusion is:

Having separate sub-interface is good for data plane isolation (Security) and QoS but bad for the scalability since separate routing protocol neighborship has to be maintained.

In contrast, Inter-AS Option B doesn’t require separate sub-interface per VRF. In fact, ASBRs don’t even have VRF per customer. Only the VPN prefixes are kept by the ASBRs. Single interface and single MP-BGP VPNv4 neighborship is enough to signal the customer prefixes between the Service Providers.


Figure-2 Inter-AS Option B

In Figure-2 there is only one EBGP session between the Service Providers.

Both control plane and the dataplane traffic passes through the interlink between the ASBRs.

How we can have very good QoS, good scalability, good security without advertising the Infrastructure prefixes (Internal prefixes) of the Service Providers to each other in Inter-AS MPLS VPNs ?

inter-as option ab (a.k.a option d)

Figure -3 Inter-AS Option AB (a.k.a Option D)

Answer is the Inter-AS Option AB. As you can see from Figure-3, on the ASBRs, separate sub-interface is created per VRF. This provides data plane isolation. Also QoS configuration can be applied per customer. Since customer traffic is isolated with VRF, better security is achieved as well compare to the single interface.

The difference between Inter-AS Option AB and the Inter-AS Option A is, customer prefixes is advertised through the single EBGP session between the ASBRs in Option AB. There is no separate EBGP session per VRF between the ASBRs as in the case of Inter-AS Option A.

Control plane traffic which is the routing advertisement and other routing protocol packets are sent through the single EBGP connection over the Global routing table.

Customer data plane traffic is sent as IP traffic without MPLS encapsulation.

Where Inter-AS Option AB can be used  ?

When the customer requires an MPLS VPN service from the two service providers with strict QoS SLA and the number of Inter-AS MPLS VPN customer is too much between the two service providers, it can be used.

At least, initially it is created for these reasons but in my opinion real applicability would be the migration from Inter-AS Option A to Inter-AS Option B.

During the migration from Option A to Option B, Inter-AS Option AB can be used as transition solution.

I haven’t seen or heard Inter-AS Option AB in real life design and would like to see your comment about it in the comment box below.

0.00 avg. rating (0% score) - 0 votes
  • Gleb

    Hello, Orhan!

    Am i right understand you, that in Option AB we need to create sub-interfaces per VRF, as it was in Option A, and ControlPlane information we transfer by VPNv4 single connection as in Option B?

    • Hi Gleb, Exactly. We reduce the control plane signalling and the number of MP-BGP VPNv4 sessions