Table of Contents

Cisco CCDE v3 Training

71:39:25 Hours
226 Lectures
Expert

$799

MPLS Zero to Hero Training

30:07:04 Hours
52 Lectures
Intermediate

$150

Cisco CCIE Service Provider Training

96:02:27 Hours
242 Lectures
Expert

$799

Inter AS Option C – Design Considerations and Comparison

Inter AS Option C is the most complex, insecure, uncommon, but extremely scalable inter provider MPLS VPN solution.

I am explaining this topic in deep detail in my Self Paced CCDE course.

In this post, I will explain how service providers can use Inter AS Option C to assist customers to have an end-to-end MPLS VPN service.

In the Inter AS Option B post, I explained that ASBR routers between the service providers do not keep a VRF table for the VPN customers.

As depicted in the fig.1 (shown below), as for Inter AS Option B, MP-BGP VPNv4 session is set up between service providers’ ASBR PEs.

Inter-AS Option B

Figure 1: Inter-AS Option B

As for Inter AS Option B, ASBR routers – the provider-edge devices between the service providers – maintain only the VPN prefixes of the customers in the BGP table.

In fact, I have shown that VPNv4 BGP session has been set up between the ASBRs.

The high-level operational differences between Inter AS Option C and Inter AS Option B are in two folds: one is that ASBRs do not have VRF table; the other is that unlike Inter AS Option B, Inter AS Option C do not keep VPN prefixes for the customer on the ASBR.

ASBR is the edge routers which are used to connect the Service Provider each other.

As depicted in fig. 2 (shown below), as for Inter AS Option C, the VPNv4 BGP session is set up between route reflectors of the service providers.

Inter AS Option C

Figure-2 Inter AS Option C

In fig.2, there are two service providers: service provider A and service provider B.

Service Provider A:

Service provider A has two customers: customer A and B

For scaling purposes, all the provider-edge routers run VPNv4 BGP session with VPNv4 route reflector.

Service provider B:

Service provider B has two customers: customer A and B

A and B are companies which require Inter AS MPLS VPN service.

Service provider B runs IS-IS internally ( It could run other IGP protocols as well for sure)

PE-CE routing protocols are enabled on the VRF; thus service provider A has two separate VRF table.

For scaling purposes, all the provider-edge routers run VPNv4 BGP session with VPNv4 route reflector.

Inter AS Option C runs by enabling VPNv4 BGP session between the Route Reflectors of the Service Providers.

Provider-edge routers of service providers do not set up VPNv4 neighborship neither with AS nor between ASes.

In order to use the route reflectors to setup VPNv4 neighborship, they should move towards each other. i.e. BGP runs over TCP.

For reachability, route reflector loopback interfaces are advertised on the global routing table of service providers.

As for AS Option C depicted in fig. 3, ASBR PEs of the service providers run IPv4 BGP session between them.

Over IPv4 BGP session, loopback interfaces of route reflectors and internal PEs are advertised. Next, I will explain why you need to advertise internal PE loopback addresses, not just route reflectors.

ASBR PEs know the loopback address of Route reflector through OSPF in the Service Provider A network, through IS-IS in the Service Provider B network.

Since the VPNv4 EBGP neighborship is set up between VPNv4 RR of the service provider, the next hop for the VPN route is the route reflector.

Traffic trombones on the RR unless ” no bgp next-hop unchanged ” configured on the Route Reflectors. This is one of the important caveats in Inter AS MPLS VPN Option C.

Once this feature is enabled, route reflector does not change the next hop to itself even though the peering is EBGP VPNv4, between the RRs. ( Whenever there is an EBGP session between two BGP speaker, next hop is changed since they are not client of each other but regular EBGP neighborship, otherwise RR doesn’t change the next hop in IBGP)

In this case, because internal PEs continue to be a next hop for the customer prefixes, internal PE loopback is advertised on IPv4 BGP session between ASBRs.

As for the VPN next hop, transport label should be assigned to MPLS VPN to work efficiently, and MPLS label is assigned to the IPv4 unicast routes, which are the loopback of RRs and Internal PEs of ASBR.

Inter-AS Option C Design Objectives:

  • Inter AS Option C is unique, since it requires internal addressing advertisement between the service providers.
  • Those addresses are leaked into the global routing table of the providers, a process that providers dislike.
  • It can still be used in large scale design if the company has multiple autonomous system. (Not between the service providers).
  • This is just a network design option. Please note that it is not the only option.
  • Inter AS Option C is very difficult to implement because it requires meticulous redistribution at the edge of the networks, VPNv4 neighborship between the route reflectors, IPv4 BGP neighborship between the ASBRs, label advertisement, route target agreement between the service providers, and so on.
  • It is insecure because the internal address leaks between the providers.

I know you must have thought whether AS design is common between the service providers in real life.

In reality, I helped two times Inter-AS MPLS VPN design of the Service Providers, both of them concluded with Inter AS Option A.

To have a great understanding of SP Networks, you can check my new published “Service Provider Networks Design and Architecture Perspective” Book.

Created by
Orhan Ergun

Orhan Ergun, CCIE/CCDE Trainer, Author of Many Networking Books, Network Design Advisor, and Cisco Champion 2019/2020/2021

He created OrhanErgun.Net 10 years ago and has been serving the IT industry with his renowned and awarded training.

Wrote many books, mostly on Network Design, joined many IETF RFCs, gave Public talks at many Forums, and mentored thousands of his students.  

Today, with his carefully selected instructors, OrhanErgun.Net is providing IT courses to tens of thousands of IT engineers. 

View profile