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.
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.
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.