Inter AS Option A Design Considerations and Comparison

Inter AS Option A is the easiest, most flexible, most secure Inter autonomous system MPLS VPN technology.

I am explaining this topic in deep detail in my Onsite CCDE  Live/Webex CCDE  and  Self Paced CCDE  course.

In the below topology VPN Customers A and B are connected to two different service providers via MPLS Layer 3 VPN. In order to have end to end MPLS VPN service, Service Providers use special mechanisms. In this article, I will explain the most basic one which is Inter-AS Option A, though there are many other things you need to know about Inter-AS Option A.

Our aim is to carry all the customer routes between the service providers.

There are many different ways of handling this case. In this post, I will explain Inter AS Option A MPLS/VPN, also known as VRF-to-VRF approach.



option a


 Figure 1: Inter-AS OptionA

I will use the topology depicted in fig. 1 throughout this post to explain Inter AS Option A operation.

In the above diagram, we have two service providers and the two customers which require Inter-AS MPLS VPN service.

The PE routers that connect the two providers are also known as ASBR (Autonomous System Boundary Router).

Inter AS Option A: an ASBR router in one Autonomous System attaches directly to an ASBR router in another Autonomous System.

The two ASBR routers are attached to multiple sub-interfaces; at least one of the VPNs whose routes need to be passed from one AS to the other AS is attached. In addition, those sub interfaces associate with the VRF table.

For each customer, service providers could use separate physical connection, instead of sub interface. However, doing that would not produce optimal result for resource utilization.

PE routers connected to the CE devices run MP-IBGP, either through full mesh or through RR (route reflector).


Inter AS Option A allows ASBR routers to keep all the VRFs for customers who require Inter AS service.


SP-A and SP-B ASBR routers maintain VPN forwarding table in LFIB. Furthermore, they keep routing information in RIB and FIB.

Compared to other AS options, ASBRs have high memory usage in Inter AS Option A.

However, other Inter AS VPN options do not have these capabilities.

ASBRs can either run the same routing protocol with the customer on the VRFs or use just EBGP.

For example if the requirement for customer A, is to keep routing information, such as metric end to end, SP-A and SP-B runs  same routing protocol on the ASBRs and the PE devices where the Customer CE device is attached to.

SP-A and SP-B: Inter AS Option A will have to manage redistribution at the ASBRs because the routes appear to the ASBR as BGP route from remote PEs. For customer A, those routes need to be redistributed  from BGP to Customer A PE-CE Routing protocol, and from the Customer A PE-CE routing protocol to BGP.

ASBRs associate each such sub-interface with a VRF.

Inter AS Option A does not require MPLS at the ASBRs unlike the other Inter AS options.

Since we need to have a separate VRF and sub interface for each customer VPN, separate routing protocol, dealing with redistribution for each protocol,  it is operationally cumbersome thus hard to scale.

Among all other Inter AS options since there is only IP routing between the AS, Option A is considered as most secure one.

In addition, it is the easiest option to implement between the AS because Option A does not require another control plane mechanism between service provider ASBRs such as LDP, BGP+label, or BGP-VPNv4.

Between the service providers on ASBRs, either IGP protocols or EBGP is used.

More importantly, other Inter AS Options (Inter AS Option B and Inter AS Option C) require additional control-plane protocols to advertise the customer or infrastructure prefixes between the ASBRs.

Since only IP traffic passes (Not MPLS) between the service providers, most granular QoS implementation is achieved with Option A. (Per sub-interface and IP DSCP vs. MPLS EXP)

For all Inter AS Options, it is very common that customers have to trust to the service provider for data integrity, confidentiality, and availability.

MPLS does not encrypt the packets because if a customer need end-to-end encryption, the user can deploy an IPSEC.

Below Inter AS MPLS VPN Options Comparison Table gives you most comprehensive analysis. In real life and also for the design exams it will be very useful since the comparison are done from the design point of view.



Inter AS MPLS VPN Options Comparison


Do you use MPLS VPN service? Is it from one provider or multiple providers?

Let’s talk about your design in the comment section.


To have a great understanding of SP Networks, you can check my new published “Service Provider Networks Design and Perspective” Book. It covers the SP network Technologies with also explaining in detail a factious SP network.  Click here

21 Replies to “Inter AS Option A Design Considerations and Comparison”

  1. This is the most common preferred solution but it still limited by the number of vlan ( 2^8) i mean that we can’t go above (4096 minus reserved vlan) vrf between two service providers.
    In real life i dont think that two SP could go abouve this number 🙂

    1. Correct. But QinQ might be used in that case. Thats why Inter AS Option B and C is much more scalable.Can you imagine 4K vrf , redistribution IGP to BGP for each customer. Large scale deployment should have either B or C.

  2. As you said sub-interfaces required for each customers belong to ASBR’s, should EVC concept can be useful to overcome limitation of vlan and QinQ….

    Nice Article Inter-AS Option A let me move on 🙂

  3. As you said sub-interfaces required for each customers belong to ASBR’s, should EVC concept can be useful to overcome limitation of vlan and QinQ….

    Nice Article Inter-AS Option A let me move on 🙂

  4. what if we have ASBR1 running EBGP with ASBR2 for customer A. Do we need redistribution in this case from EBGP to MPBGP(ipv4 address-family to vpnv4 address-family vice-versa)

    1. @Haroon , You don’t need to redistribute EBGP to VPNV4 or vice versa. If you use BGP between ASes for the Option A case , similar to single AS MPLS L3VPN case , no need for redistribution.

  5. what if we have ASBR1 running EBGP with ASBR2 for customer A. Do we need redistribution in this case from EBGP to MPBGP(ipv4 address-family to vpnv4 address-family vice-versa)

  6. Excellent post Orhan! I like that it is straight to the point and covers all the needed information on 10-A. Seems simpler when you explain it 🙂

  7. I am investigating available strategies/methods two different ISPs can employ to peer their Layer 3 mpls vpns in order to provider a customers an end-to-end connection between its two sites, where site 1 is connected to ISP 1 and site 2 is connected to ISP 2. With emphasis on how the class of service would be handled across both ISP’s network for guaranteed service level ?

  8. Orhan, you post really valuable and interesting information but it would be really nice if you would let someone to proofread the articles before publishing. Some parts look like they have been google-translated.
    Otherwise thank you very much for your work.

    1. Alex, Thanks for the comment and agree 🙂 I did it for my Workbook and has been considering for the website as well. Do you know anyone who can be volunteer in the exchange of something from me 🙂

  9. Hi,

    I am designing and implementing a prototype Inter-AS Layer-3 MPLS VPN with end-to-end QoS for my Dissertation and I would appreciate you advise please. I am expected to test for the QoS.

  10. Yes please I would appreciate you advice on which option is most suitable for me to used and achieve my goal, considering it is a Lab based project.

    Although I thinking of using Inter-AS Option B with full mesh between iBGP peers as my network design has only 8 routers, 3 for each IPS and 1 CE for the two customer sides.
    But I would like to know what you think about my choice and advice me better.

    Also I will need your advice on the QoS strategy I should deploy. as I am thinking of generating traffic across the network and deploying voice service between the two sites to test for the QoS. But am not sure if that is good enough and even if it is, I don’t know what exactly I will be looking for when I test to be sure I have achieved my objective.

Leave a Reply

Your email address will not be published.