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

Reminder

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

upgrade

Configuration Guide - VPN

CloudEngine 12800 and 12800E V200R005C10

This document describes the configurations of VPN, including GRE, BGP/MPLS IP VPN, BGP/MPLS IPv6 VPN, VLL, PWE3, and VPLS.
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).
BGP/MPLS IP VPN Fundamentals

BGP/MPLS IP VPN Fundamentals

VPN Label Distribution

Before advertising private routes to other PE devices on the backbone network through MP-BGP, a PE device must distribute MPLS labels (VPN label) to the private routes. Packets transmitted over the backbone network carry MPLS labels.

A PE device distributes MPLS labels in either of the following ways:
  • One label per route

    Each route in a VRF is assigned one label. If a network contains a large number of routes, the Incoming Label Map (ILM) must maintain a large number of entries. In this case, the device capacity must be large enough to accommodate all entries.

  • One label per instance

    Each VPN instance is assigned one label. All the routes of a VPN instance share the same label, conserving label resources.

VPN Route Cross

The routes exchanged between two PE devices through MP-BGP are VPNv4 routes. A PE device checks received VPNv4 routes and drops the following routes:

  • VPNv4 routes with unreachable next hops

  • VPNv4 routes received from an RR with the cluster_id of the PE device in the cluster_list

  • VPNv4 routes that are denied by the BGP routing policy

The PE device matches the remaining routes with the import targets of local VPN instances. The matching process is called VPN route cross.

Some routes sent from local CE devices belong to different VPNs. The PE device also matches these routes with the import targets of local VPN instances if these routes have reachable next hops or can be iterated. The matching process is called local VPN route cross. For example, CE1 resides in a site of VPN1, and CE2 resides in a site of VPN2. Both CE1 and CE2 connect to PE1. When PE1 receives routes of VPN1 from CE1, PE1 also matches the routes with the import target of the instance of VPN2.

NOTE:

To correctly forward a packet, a BGP-enabled device must discover a directly reachable address, through which the packet can be forwarded to the next hop in the routing table. The route to the directly reachable address is called a dependent route. This name is given because BGP guides packet forwarding based on the route. The process of discovering a dependent route based on the next-hop address is called route iteration.

Public Network Tunnel Iteration

To transmit traffic of private networks across a public network, tunnels need to be established on the public network. After VPN route cross is complete, PE devices perform route iteration based on destination IPv4 prefixes to discover the appropriate tunnels (except for local cross routes). Tunnel iteration is then performed. The routes are injected into the VPN routing table only after tunnel iteration succeeds. The process of iterating routes to corresponding tunnels is called tunnel iteration.

After tunnel iteration succeeds, tunnel IDs are reserved for subsequent packet forwarding. A tunnel ID identifies a tunnel. In VPN packet forwarding, the PE devices search for tunnels based on tunnel IDs.

VPN Route Selection Rules

Not all the cross routes processed by tunnel iteration are injected into VPN routing tables. Similarly, not all the routes received from the local CE devices nor all the local cross routes are injected into VPN routing tables.

When multiple routes to the same destination are available and load balancing is not configured, a PE device selects one route based on the following rules:

  • If a route received from a local CE device and a cross route are destined to the same destination, the PE device selects the route received from the local CE device.

  • If a local cross route and a cross route received from another PE device are destined for the same destination, the PE device selects the local cross route.

When multiple routes to the same destination are available and load balancing is configured, the PE device selects one route based on the following rules:

  • If one route from a local CE device and multiple cross routes exist, the PE device selects the route from the local CE device.

  • The PE device performs load balancing between the routes from the local CE device or between the cross routes. The PE device does not perform load balancing between the routes from the local CE device and the cross routes.

  • The AS_Path attributes of the routes participating in load balancing must be the same.

Route Advertisement in BGP/MPLS IP VPN

In basic BGP/MPLS IP VPN applications, CE and PE devices are responsible for advertising VPN routes. Conversely, P devices only need to maintain routes of the backbone network without knowing VPN routes. Generally, PE devices maintain all VPN routes.

VPN routes are advertised from the local CE device to the ingress PE device, from the ingress PE device to the egress PE device, and from the egress PE device to the remote CE device. After the route advertisement process is complete, the local and remote CE devices have reachable routes to each other. VPN routes can then be advertised on the backbone network.

The route advertisement process is as follows:

  • Route advertisement from the local CE device to the ingress PE device

    After a neighbor or peer relationship is set up between a CE device and the directly connected PE device, the CE device advertises the local IPv4 routes to the PE device. The CE and PE devices can use static routes or dynamic routes learned through the Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), or BGP (Border Gateway Protocol). Regardless of whether static or dynamic routes are used, the routes advertised by the CE device to the PE device are standard IPv4 routes.

  • Route advertisement from the ingress PE device to the egress PE device

    • After learning VPN routes from a CE device, the ingress PE device adds RDs to standard IPv4 routes to change them into VPN-IPv4 routes.

    • The ingress PE device advertises MP-BGP Update messages containing VPN-IPv4 routes to the egress PE device. The Update messages contain export targets and MPLS labels.

    • If the next hops in received VPN-IPv4 routes are reachable, the egress PE device performs VPN route cross, tunnel iteration, and route selection to determine whether to inject the routes into the VRF. For the routes added to the VPN routing table, the local PE stores the tunnel IDs and MPLS labels carried in MP-BGP Update messages for subsequent packet forwarding.

  • Route advertisement from the egress PE device to the remote CE device

    The remote CE device can learn VPN routes from the egress PE device through static routes, RIP, OSPF, IS-IS, or BGP. Route advertisement from the egress PE device to the remote CE device is the same as that from the local CE device to the ingress PE device. The routes advertised by the egress PE device to the remote CE device are standard IPv4 routes.

Figure 2-7 shows route advertisement from CE2 to CE1. In this example, BGP runs between CE and PE devices, and LSPs are used.

Figure 2-7 Route advertisement from CE2 to CE1

  1. Interior Gateway Protocol (IGP) routes are imported into the BGP IPv4 unicast address family of CE2.

  2. CE2 advertises an EBGP Update message with routing information to the egress PE device. After receiving the message, the egress PE device converts the route to a VPN-IPv4 route, and then adds the route to the VPN routing table.

  3. The egress PE device distributes an MPLS label to the route. It then adds the label and VPN-IPv4 routing information to the NLRI field, and adds the export target to the extended community attribute field of the MP-IBGP Update message. Following this, the egress PE device sends the Update message to the ingress PE device.

  4. When the ingress PE receives the Update message, it performs VPN route cross. After the VPN route cross succeeds, the ingress PE device performs tunnel iteration based on the destination IPv4 address to discover the appropriate tunnel. If tunnel iteration succeeds, the ingress PE device stores the tunnel ID and label, and then adds the route to the VPN routing table of the VPN instance.

  5. The ingress PE device advertises a BGP Update message with the route to CE1. The advertised route is an IPv4 route.

  6. After receiving the route, CE1 adds the route to the BGP routing table. CE1 can import the route to the IGP routing table by importing BGP routes to IGP.

To ensure bidirectional communication between CE1 and CE2, CE1 must also advertise routes to CE2 (the process is similar to the preceding process).

Packet Forwarding in Basic BGP/MPLS IP VPN

In basic BGP/MPLS IP VPN applications (excluding inter-AS VPN), VPN packets are forwarded with outer and inner labels (double labels):
  • Outer label (public network label): is swapped on the backbone network, identifies an LSP from a PE device to a remote PE device, and enables VPN packets to reach the remote PE device through the LSP.
  • Inner label (VPN label): is used when VPN packets are sent from the remote PE device to a CE device, and identifies the site (or specifically, the CE device) to which VPN packets are sent. The remote PE device discovers the outbound interface for VPN packets according to the inner label.

If two sites of a VPN connect to the same PE device, the PE device only needs to know the routes to the remote CE device.

Figure 2-8 shows packet forwarding from CE1 to CE2. In Figure 2-8, I-L indicates an inner label, and O-L indicates an outer label.

Figure 2-8 Forwarding of a VPN packet from CE1 to CE2

  1. CE1 sends a VPN packet.

  2. After receiving the packet on the interface bound to a VPN instance, the ingress PE device processes the packet as follows:

    • Searches for the corresponding VPN forwarding table based on the RD of the VPN instance.

    • Matches the destination IPv4 prefix to discover the corresponding tunnel ID.

    • Adds I-L to the packet and discovers the tunnel based on the tunnel ID.

    • Sends the packet through the tunnel and adds O-L1 to the packet.

    The packet then traverses the backbone network with double MPLS labels. Each P device on the backbone network swaps the outer label of the packet.

  3. After receiving the packet with double labels, the egress PE device delivers the packet to MPLS for processing. MPLS pops the outer label. In this example, the final outer label of the packet is O-L2. If the PHP function is configured, the hop prior to the egress PE device pops the outer label. In this case, the egress PE device receives the packet with only the inner label.

  4. The egress PE device can identify only the inner label. The egress PE device finds the label at the bottom of the label stack and pops the inner label.

  5. The egress PE device sends the packet, which is now an IP packet, to CE2.

    The packet is successfully transmitted from CE1 to CE2. CE2 transmits the packet to the destination according to the IP forwarding process.

Translation
Download
Updated: 2019-04-03

Document ID: EDOC1100075353

Views: 14201

Downloads: 25

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