BGP/MPLS IP VPN Fundamentals
VPN Label Distribution
A PE device must distribute MPLS labels (VPN labels) to private routes before advertising private routes to other PE devices (on the backbone network through MP-BGP). Packets transmitted over the backbone network carry MPLS labels.
One label per route
Each route in a VRF is assigned one label. When many routes exist on the network, the Incoming Label Map (ILM) maintains these entries, requiring 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, reducing the number of labels required.
MP-BGP distributes labels to private routes only after MPLS is enabled on the PE device.
VPN Route Cross
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 denied by the BGP routing policy
The PE device matches the remaining routes with the import targets of VPN instances through a matching process 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 VPN1 site, and CE2 resides in VPN2 site. Both CE1 and CE2 connect to PE1. When PE1 receives VPN1 routes from CE1, PE1 also matches the routes with the import target of the VPN2 instance.
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 the 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
Tunnels need to be established on the public network to transmit the traffic of private networks across a 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. PE devices search for tunnels based on tunnel IDs in VPN packet forwarding.
VPN Route Selection Rules
Not all cross routes processed by tunnel iteration are added to VPN routing tables. Similarly, not all routes received from local CE devices and 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 route received from the local CE device is preferred.
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 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 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, while P devices only need to maintain routes of the backbone network without knowing VPN routes.
PE devices typically maintain all VPN routes advertised from the following:
- Local CE device to ingress PE device
- Ingress PE device to egress PE device
- Egress PE device to remote CE device
After the whole route advertisement process is complete, 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:
Local CE device to ingress PE device
After a neighbor or peer relationship is established between a CE device and the directly connected PE device, the CE device advertises the local IPv4 routes to the PE device. 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). Routes advertised by the CE device to the PE device are standard IPv4 routes, regardless of which routing protocol is used.
Ingress PE device to egress PE device
After learning VPN routes from a CE device, the egress PE device adds RDs to standard IPv4 routes. The routes change 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.
Egress PE device to remote CE device
The remote CE device learns 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. Routes advertised by the egress PE device to the remote CE device are standard IPv4 routes.
Figure 1 shows a networking example of route advertisement from CE2 to CE1.
In Figure 1, BGP runs between CE and PE devices, and LSPs are used in this example. The following explains the process of route advertisement from CE2 to CE1:
Interior Gateway Protocol (IGP) routes are imported into the BGP IPv4 unicast address family of CE2.
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 installs the route to the VPN routing table.
The egress PE device distributes an MPLS label to the route. It adds the label and VPN-IPv4 routing information to the Network Layer Reachability Information (NLRI) field. It also adds the export target to the extended community attribute field of the MP-IBGP Update message. Then the egress PE device sends the Update message to the ingress PE device.
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.
The ingress PE device advertises a BGP Update message with the IPv4 route to CE1.
CE1 injects the route to the BGP routing table after receiving it. CE1 imports the route to the IGP routing table by importing BGP routes to IGP.
CE1 must advertise routes to CE2 to ensure device communication. The process is similar to the preceding process.
Packet Forwarding in Basic BGP/MPLS IP VPN
- 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 reach the remote CE device.
Figure 2 shows a networking example of VPN packet forwarding from CE1 to CE2. In Figure 2, I-L indicates an inner label, and O-L indicates an outer label.
The following details the process of VPN packet forwarding from CE1 to CE2:
CE1 sends a VPN packet.
After receiving the packet on the interface bound to a VPN instance, the ingress PE device processes the packet through the following process:
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.
The packet then travels across the backbone network with double MPLS labels. Each P device on the backbone network swaps the outer label of the packet.
P2 receives the packet carrying double labels and sends it to the MPLS protocol module. Since penultimate hop popping (PHP) function is enabled, the MPLS protocol module removes the outer label (O-L2) and sends the packet carrying only the inner label to the egress PE.
The egress PE device then only identifies the inner label. Discovering it at the bottom of the label stack, the egress PE device pops the inner label.
The egress PE device sends the packet to CE2 and the packet is now 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.