Home / Cisco SP / Service Provider MPLS : Inter-AS MPLS Options

Service Provider MPLS : Inter-AS MPLS Options

Today I am going to talk about the Inter-AS MPLS or you can say that Inter-provider MPLS option. So in this case i am taking the example on the Cisco devices. To maintain the continuity of MPLS VPN services across multiple service providers, mainly for customers who span world wide on different service providers, IETF described 3 types of options. These options are 
  • Option A
  • Option B 
  • Option C
 Inter-AS or Inter-Provider MPLS VPN solutions, while Cisco implemented three options (1, 2 and 3) with Cisco IOS (these options are also known in Cisco documents as 10A, 10B and 10C).

Lets start with all these option one by one. The first option is called as VRF to VRF connection between two different AS border routers and the explanation is as below.

Option A: VRF-to-VRF connections at the AS (Autonomous System) border routers
In this procedure, a PE router in one AS attaches directly to a PE router in another. The two PE routers will be attached by multiple sub-interfaces, at least one for each of the VPNs whose routes need to be passed from AS to AS. 
Fig 1.1- Inter-AS option A

Each PE will treat the other as if it were a CE router. That is, the PEs associate each such sub-interface with a VRF, and use EBGP to distribute un-labeled IPv4 addresses to each other.
  • So for the option A, the RD, RT, PE addresses separated at the AS border.
  • In the Option A, Per VPN IP based filtering and diffserv re-marking possible.
  • Option A will give you route capping and/or summarization available per VPN.
  • Fits existing operational processes for ‘on-net VPN services.
  • Supports traffic load balancing and inter-provider path optimization.
  • Scaling issues associated to per VRF Attachment Circuit BGP sessions.
  • Layer 2 separation may be difficult, especially when no direct connectivity between ASBRs
  • Difficult to support enterprise QoS transparency or you can say the dependent on L2 media.
The Second option is called as EBGP redistribution of labeled VPN-IPv4 from AS to neighboring AS. It is described as below:

Option B: EBGP redistribution of labeled VPN-IPv4 routes from AS to neighboring AS
In this procedure, the PE routers use IBGP to redistribute labeled VPN-IPv4 routes either to an Autonomous System Border Router (ASBR), or to a route reflector of which an ASBR is a client. The ASBR then uses EBGP to redistribute those labeled VPN-IPv4 routes to an ASBR in another AS, which in turn distributes them to the PE routers in that AS, or perhaps to another ASBR which in turn distributes them.
When using this procedure, VPN-IPv4 routes should only be accepted on EBGP connections at private peering points, as part of a trusted arrangement between SPs. VPN-IPv4 routes should neither be distributed to nor accepted from the public Internet, or from any BGP peers which are not trusted. An ASBR should never accept a labeled packet from an EBGP peer unless it has actually distributed the top label to that peer.

Fig 1.2- Inter-AS option B

If there are many VPNs having sites attached to different Autonomous Systems, there does not need to be a single ASBR between those two ASes which holds all the routes for all the VPNs; there can be multiple ASBRs, each of which holds only the routes for a particular subset of the VPNs.This procedure requires that there be a label switched path leading from a packet’s ingress PE to its egress PE. Hence the appropriate trust relationships must exist between and among the set of ASes along the path. Also, there must be agreement among the set of SPs as to which border routers need to receive routes with which Route Targets.

ttlbits_PE#   sh ip bgp vpnv4 vrf A labels
Network          Next Hop      In label/Out label
Route Distinguisher: 100:1 (A)
10.10.10.10/32   192.168.10.10   10/12
  • Scaling of ASBR control and data plane.
  • Support for enterprise QoS Transparency.
  • Requires agreement and coordination of  Route Target values across SPs
  • Trust required between SPs as MPLS based ‘global’ interface exposures.
  • No per VPN IP packet handling capability at the ASBR
  • Loss of per VPN packet filtering
  • Loss of per VPN Diffserv remarking
  • No per VPN route capping and/or summarization.
  • Operational process separation issues.
  • Difficult to support traffic load balancing and inter-provider path optimization.
The third and the last option is called as multihop EBGP redistribution of labeled VPN-IPv4 routes between source and destination if AS's. Below is the full description of the same.

Option C: Multihop EBGP redistribution of labeled VPN-IPv4 routes between source and destination ASes, with EBGP redistribution of labeled IPv4 routes from AS to neighboring AS
In this procedure, VPN-IPv4 routes are neither maintained nor distributed by the ASBRs. An ASBR must maintain labeled IPv4 /32 routes to the PE routers within its AS. It uses EBGP to distribute these routes to other ASes. ASBRs in any transit ASes will also have to use EBGP to pass along the labeled /32 routes. This results in the creation of a label switched path from the ingress PE router to the egress PE router. Now PE routers in different ASes can establish multi-hop EBGP connections to each other, and can exchange VPN-IPv4 routes over those connections.

Fig 1.3- Inter-AS option C

If the /32 routes for the PE routers are made known to the P routers of each AS, everything works normally. If the /32 routes for the PE routers are NOT made known to the P routers (other than the ASBRs), then this procedure requires a packet’s ingress PE to put a three label stack on it. The bottom label is assigned by the egress PE, corresponding to the packet’s destination address in a particular VRF. The middle label is assigned by the ASBR, corresponding to the /32 route to the
egress PE. The top label is assigned by the ingress PE’s IGP Next Hop, corresponding to the /32 route to the ASBR.

To improve scalability, one can have the multi-hop EBGP connections exist only between a route reflector in one AS and a route reflector in another. (However, when the route reflectors distribute routes over this connection, they do not modify the BGP next hop attribute of the routes.) The actual PE routers would then only have IBGP connections to the route reflectors in their own AS.
This procedure is very similar to the “Carrier’s Carrier” procedures described in section 9. Like the previous procedure, it requires that there be a label switched path leading from a packet’s ingress PE to its egress PE.

This solution has its strong and weak points:
  • The ASBRs do not store external routing information
  • Resource conservation as the external information is not duplicated on the ASBRs. The RRs already store the routes.
  • Multi-hop EBGP VPNv4 for VPN routes
  • EBGP labeled IPv4 for internal routes
  • Advertising of PE addresses to another AS is not always a good decision
  • VPN context doesn’t exist at ASBRs
  • Not possible to perform policing, filtering or accounting with per VPN granularity at ASBR