1 2 Previous Next 19 Replies Latest reply: Sep 21, 2019 12:40 AM by Diki Muhammad RSS

    Inter-AS Option A



      One of the most useful and popular application of MPLS technology is MPLS L3 VPN service. The architecture defines a VPN peer model in which customers send their routes to the SP in order to transport them to remote locations. In this model, the complexity of route transportation is offloaded by the customer to the SP offering the service.


      When the customer has dispersed remote locations that want to interconnect and there is not a unique SP that has full coverage to be able to interconnect by its own resources that locations, some help may be needed by a third (or more) SPs.


      The basic methods for chaining SPs together are defined in RFC 4364 as Inter-AS options A, B and C. This discussion covers basic aspects of Option A, with its main advantages, disadvantages and applicability.






      Option A is the simplest of the interconnection options. The ASBR of each AS defines an interface or sub-interface per VRF. Once defined, the ASBR will instantiate the VRF assigning the sub-interface to the VPN. This need to be done per VPN requiring Inter-AS service.


      The sub-interfaces facing the other AS doesn’t transport labeled traffic, only regular IP traffic. In order to exchange routing information with the remote ASBR, any routing protocol can be used.


      From the ASBR point of view, the remote AS is seen like any other regular CE device.






      In this case, the MPLS L3 VPN service is not extended, it’s simply chained. Each AS of the Inter-AS interconnection can select freely the IGP and label distribution protocol of their choice.

      This solution works very well when the number of VPN and number of routes to transfer are small. Some of the Option A advantages are:


      • Easy to understand, deploy and troubleshoot
      • Clearly defined demarcation points between providers (SLA demarcation)
      • Policing, filtering and accounting per-VPN over one single point (sub-interface VRF)
      • Flexibility in the protocol selection per-AS and between ASBR


      But, the real limitation of Option A is the scalability of the solution. The isolation of VRFs per VPN at the ASBR is accomplished by defining:


      • One sub-interface per VRF
      • One VRF per VPN (the VRF needs to be instantiated on the ASBR)
      • One EBGP (if BGP is used) routing session per VRF


      …and that has a HUGE impact on scalability as the number of VPNs to extend grows.




      Control and Data planes


      In order to keep things as simple as possible, the next figure illustrates the fundamental control and data plane operation for a route advertised by customer GREEN site CE5 (AS #65002) to site CE2 (AS #65001).





      • The two MPLS L3 VPN services are chained together to provide end-to-end service
      • Neither LSPs neither VPN labels used by the two SP need to be the same
      • The link between ASBR transports regular IP traffic
      • The extended communities must be removed in the BGP peering between ASBRs to avoid importing routing information in the wrong remote VRF (RT)






      Inter-AS option A has some advantages that make this option very popular:


      • Simplicity
      • Flexibility
      • Defines clear demarcation points between MPLS L3 VPN service providers
      • Easy of deployment


      But it has as well some disadvantages that may lead to consider using another option that better suits your needs:


      • Poor scalability
      • Hard to support enterprise QoS transparency



      I hope you find it useful.

        • 1. Re: Inter-AS Option A

          A very well written and structured article Juan. Thanks for sharing.

          • 2. Re: Inter-AS Option A

            Thank you sarah, I'm glad you liked it !

            • 3. Re: Inter-AS Option A
              Joe Mendola

              Juan, this is an excellent explanation and i want to highlight this important statement:

              • The extended communities must be removed in the BGP peering between ASBRs to avoid importing routing information in the wrong remote VRF (RT)
              • 4. Re: Inter-AS Option A

                Hi Joe,


                I agree, it's an important point to remember because failing to do it can end up in a very serious security problem. If the Inter-AS is done between enterprises with their own self deployed MPLS service, perhaps the security incident has a reduced impact, but between SPs, it would be a very serious nightmare.


                Thanks for reading.

                • 5. Re: Inter-AS Option A

                  Hi Juan,
                  thanks for sharing this with us.   A great article again.
                  I'm not sure if the RT is imported from an eBGP IPv4 session into the MP-BGP process on the the ASBR.     I need to update my VIRL license to test it.
                  Thanks for sharing :-)

                  • 6. Re: Inter-AS Option A
                    Joe Mendola

                    If you don't use the "send-community both", the IPv4 eBGP update won't contain neither the standard communities nor the extended ones (it will reach the other peer on the inter-link AS, as a native IPv4 packet); the update sent by the ASBR will hit the other ASBR peer and in essence, the prefix will embrace the new RD and the corresponding RT, becoming again a VPNv4 route, for the new AS.
                    However if you enable that command, the IPv4 eBGP update will carry standard/extended communities: for instance, it will be able to carry the extended communities that will be used to reassemble the eigrp composit metric: in this way the metric will be retained moving from one AS to another, transparently.

                    • 7. Re: Inter-AS Option A

                      Hi Joe, Juan,
                      I did a simulation of Inter-AS on my VIRL installation.
                      I send a prefix on the sub-interface for customerA via eBGP session to the ASBR2 in another domain.
                      The ASBR of my domain is configured with send-community both. The BGP update will be send with RT as extended community.

                      Aug 26 12:13:48.095: BGP(4): (base) send UPDATE (format), next, metric 0, path Local, extended community RT:65555:100

                      The receiving ASBR2 has this RT definition for customerA in his configuration:

                      vrf definition customerA

                      rd 65555:9

                      route-target export 65555:900

                      route-target import 65555:900

                      The ASBR2 is receiving the BGP update on a sub-interface that is configured for the vrf customerA. The update is installed in the BGP table of the receiving vrf context and the RT value is overwritten by the local configuration. The prefix is assigned to the correct vrf table:

                      ASBR2#sh ip bgp vpnv4 vrf customerA

                      BGP routing table entry for 65555:9:, version 49

                      Paths: (1 available, best #1, table customerA)

                        Not advertised to any peer

                        Refresh Epoch 1


                 (via vrf customerA) from (

                            Origin incomplete, localpref 100, valid, external, best

                            Extended Community: RT:65555:900

                            rx pathid: 0, tx pathid: 0x0

                      * From my point of view Inter-AS Option A doesn't require a RT rewrite.

                      (I can provide the topology file for VIRL if you are interested.)


                      Thanks and best regards

                      • 8. Re: Inter-AS Option A

                        Hi Christian


                        Different vendors may implement functionality in a different way. That doesn't mean one of them is correct and the other is wrong. The stuff in charge of the OAM must be aware of that and translate the design to the platform taking into account the specifics of each one.


                        About the point under discussion here... what happens if the BGP attribute is not overwritten and you're dealing with two different SPs?. Probably, at least, you'll end up loosing the isolation among different customer VPNs and probably with legal problems and customers lost.


                        It's important to know about the configurations and even know how to implement it if you're working as an operations engineer, but IMO, we need to think about the big picture here. What this kind of design scenario solves, what are the advantages, disadvantages and possible use cases.



                        • 9. Re: Inter-AS Option A

                          Thanks for your feedback Juan,


                          I don't think that is a vendor specific implementation. From my point of view a received BGP IPv4 update with RT as extended community will always be overwritten when the vpnv4 update will be generated.

                          Otherwise always on a PE router a RT rewrite will be required if you deploy a unmanaged L3VPN service (and customer accidentally send RT values with the extended community).
                          I can't find a RFC that describes the function but Daniel mentioned it also in his blog:  

                          I agree on the big picture


                          Thanks and best regards

                          • 10. Re: Inter-AS Option A

                            Hi Christian


                            RFC4360 defines the extended communities attribute in BGP: https://tools.ietf.org/html/rfc4360


                            About the implementation details, vendors are free to follow or not some recommendation when the RFC does NOT specify a MUST. SHOULD and MAY are some examples you can find in the RFC about the operational procedures after receiving the extended community from a BGP peer.


                            Best regards!

                            • 11. Re: Inter-AS Option A

                              Hi Juan,

                              yes the RFC describes the RT format for BGP.

                              We both agree that in Option B the RT rewrite will be done on the ASBR and in Option C on the RR. 


                              Thanks for your feedback. I appreciate it.



                              • 12. Re: Inter-AS Option A

                                You're welcome!

                                • 13. Re: Inter-AS Option A
                                  Ahmed E A Elsayed

                                  Hi , This is really informative.

                                  A small correction on the drawing , it should say NH:CE5 and Not NH:PE1


                                  • 14. Re: Inter-AS Option A

                                    You're right. There is a small bug there that should be fixed. Probably because at that time I copy/pasted that arrow from the left side of the picture.


                                    Thanks Ahmed !

                                    1 2 Previous Next