No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


Feature Description - VPN 01

NE05E and NE08E V300R003C10SPC500

This is NE05E and NE08E V300R003C10SPC500 Feature Description - VPN
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Inter-AS VPN

Inter-AS VPN

With the wide application of MPLS VPN solutions, different MANs of a carrier or collaborating backbone networks of different carriers frequently span multiple ASs.

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 other ASs. To exchange VPN information between different ASs, the inter-AS MPLS VPN model is introduced. The inter-AS MPLS VPN model is an extension of the MPLS VPN framework. This model allows label and route prefix information to be advertised over the links between different carrier networks.

Relevant standards present the following inter-AS VPN solutions:

  • Inter-Provider Backbones Option A (inter-AS VPN Option A)

    ASBRs manage VPN routes through dedicated interfaces for VPNs that traverse different ASs. This solution is also called VRF-to-VRF.

  • Inter-Provider Backbones Option B (inter-AS VPN Option B)

    ASBRs advertise labeled VPN-IPv4 routes to each other using the Multiprotocol External Border Gateway Protocol (MP-EBGP). This solution is also called EBGP redistribution of labeled VPN-IPv4 routes.

  • Inter-Provider Backbones Option C (inter-AS VPN 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 does not need to run between ASBRs. In this mode, ASBRs of two ASs are directly connected and function as PEs in the ASs. Each ASBR views the peer ASBR as its CE and advertises IPv4 routes to the peer ASBR through EBGP or another routing protocol.

Figure 5-15 Networking diagram for Inter-Provider Backbones Option A

In Figure 5-15, for ASBR1 in AS100, ASBR2 in AS200 is a CE. Similarly, for ASBR2, ASBR1 is a CE.

Inter-Provider Backbones Option B

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

Figure 5-16 Networking diagram for Inter-Provider Backbones Option B

In Option B, an ASBR receives all inter-AS VPN routes within the local AS and from the outside ASs and then advertises 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. Therefore, an ASBR can be configured with VPN instances whose routes need to pass the ASBR but no interface is bound to VPN instances. If an 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. 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. A VPN cannot exchange VPN-IPv4 routes with public networks or MP-EBGP peers with which there is no trust agreement.

    All the traffic is forwarded by the ASBR. The traffic is easy to control, but inflicts a heavy traffic load on the ASBR.

  • BGP routing policies, such as the policy filtering routes based on VPN targets, are used to control the transmission of VPN-IPv4 routes.

Inter-Provider Backbones Option C

In the preceding two inter-AS VPN modes, ASBRs need to maintain and distribute VPN-IPv4 routes. When each AS needs to exchange a large number of VPN routes, ASBRs may hinder network expansion.

Option C is a solution to the problem by allowing PEs to directly exchange VPN-IPv4 routes with each other (ASBRs do not maintain or advertise VPN-IPv4 routes). In Option C:

  • ASBRs advertise labeled IPv4 routes to PEs in local 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. As a result, a 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 5-17 Networking diagram for Inter-Provider Backbones Option C

To improve the expansibility, you can specify a 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 peer relationships with each other and advertise VPN-IPv4 routes.

Figure 5-18 Networking diagram for Inter-Provider Backbones Option C with RRs

The following solutions can be used to implement Inter-Provider Backbones Option C:

  • Solution 1: After learning the labeled BGP routes of the public network in the remote AS from the remote ASBR, the local ASBR allocates labels for these routes, and advertises these routes to the Internal Border Gateway Protocol (IBGP) peer that has the label switching capability. In this manner, a complete LSP is established.
  • Solution 2: An ASBR learns the labeled public BGP routes of the remote AS from the peer ASBR. These labeled public BGP routes are then imported to the IGP to trigger the establishment of an LDP LSP. In this manner, a complete LDP LSP can be established between the two PEs. In this solution, the IBGP peer relationship between the PE and ASBR is not needed.

Comparison of the Three Options

Table 5-1 Comparison of the three options

Inter-AS VPN


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 ASBRs. 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. This option poses high requirements for ASBRs. 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 restricted by the number of links between ASBRs.

VPN routing information is stored on and forwarded by ASBRs. If a great number of VPN routes exist, the overburdened ASBRs are likely to become bottlenecks. 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 and egress PEs. The routes do not need to be stored or forwarded by intermediate devices.

The exchange of VPN routing information involves only PEs. Ps and ASBRs are only responsible for packet forwarding. The intermediate devices need to support only MPLS forwarding rather than MPLS VPN services. In this situation, 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 of Option C lies in the high-cost management of an end-to-end connection between PEs.

Updated: 2019-01-14

Document ID: EDOC1100058940

Views: 18723

Downloads: 34

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Previous Next