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

CLI-based Configuration Guide - VPN

AR100, AR120, AR150, AR160, AR200, AR1200, AR2200, AR3200, and AR3600 V200R010

This document describes VPN features on the device and provides configuration procedures and configuration examples.
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).
Implementation

Implementation

VPN Label Distribution

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

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

    Each route in a VRF is assigned one label. When a large number of routes exist on the network, the Incoming Label Map (ILM) maintains a large number of entries, which requires high router capacity.

  • One label per instance

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

NOTE:

MP-BGP can allocate labels to private routes only after MPLS is enabled on the PE device.

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 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 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 find out 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 dependent route, because BGP guides packet forwarding based on the route. The process of finding 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 find the appropriate tunnels (except for local cross routes). Then tunnel iteration is 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 installed to VPN routing tables. Similarly, not all the routes received from the local CE devices and the local cross routes are injected into VPN routing tables.

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

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

If load balancing is configured, the PE device selects one route based on the following rules:

  • Preferentially selects the route from the local CE device. When one route from the local CE device and multiple cross routes exist, the PE device selects the route from the local CE 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 application, CE and PE devices are responsible for advertising VPN routes, whereas 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 whole route advertisement process is complete, the local and remote CE devices have reachable routes to each other, and VPN routes can 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, the Routing Information Protocol (RIP), the Open Shortest Path First (OSPF) protocol, the Intermediate System-to-Intermediate System (IS-IS) protocol, or BGP (Border Gateway Protocol). No matter which routing protocol is 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 egress PE device adds RDs to standard IPv4 routes. The routes are changed into VPN-IPv4 routes.

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

    • When the egress PE device receives the VPN-IPv4 routes and if the next hops are reachable, it 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 7-7 shows route advertisement from CE2 to CE1. In this example, BGP runs between CE and PE devices, and LSPs are used.

Figure 7-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 installs the route to the VPN routing table.

  3. The egress PE device allocates an MPLS label to the route. Then it adds the label and VPN-IPv4 routing information to the NLRI field and the export target to the extended community attribute field of the MP-IBGP Update message. After that, the egress PE device sends the Update message to the ingress PE device.

  4. After receiving the message, the ingress PE device performs VPN route cross. After the VPN route cross succeeds, the ingress PE device performs tunnel iteration based on the destination IPv4 address to find 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 installs 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 that CE1 and CE2 can communicate, CE1 also needs to advertise routes to CE2, of which 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 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 finds 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 how VPN packets can reach the remote CE device.

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

Figure 7-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 find the corresponding tunnel ID.

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

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

    Then the packet travels across 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 outer label is popped on the hop before the egress PE device, and the egress PE device receives the packet with only the inner label.

  4. At this time, the egress PE device can only identify the inner label. Finding the label is at the bottom of the label stack, and the egress PE device pops the inner label.

  5. The egress PE device sends the packet to CE2. At this time, the packet is an IP packet.

    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-08-07

Document ID: EDOC1100033725

Views: 141930

Downloads: 357

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