MPLS VPN | Teleinf Edu

Introduction to BGP/MPLS VPNs

Consider "GlobalTech Inc." with offices in New York and London. Each office has its own internal network, and employees need access to servers at the other site. The connection uses a shared service-provider infrastructure. The technical question is how to keep routing contexts separate and forward many customers' traffic through the same core.

A Virtual Private Network (VPN)provides a logical connection between sites or users over shared infrastructure. Encryption depends on the selected technology, such as IPsec; BGP/MPLS VPN itself provides routing and forwarding separation rather than defining payload encryption. From GlobalTech's perspective, the two offices use one logical network even though packets cross many provider routers.

A provider can implement VPN service in several ways, including IPsec tunnels. A BGP/MPLS Layer 3 VPN uses a shared MPLS core and logically separate routing instances on PE routers. Customer CE routers exchange routes with PEs, while P routers carry packets through the core. This allows one provider network to serve many customers while keeping their routes, import and export policies, and data-plane labels separate across the backbone.

The Core Problem: Overlapping IP Addresses

A basic challenge for a VPN provider is overlapping address space. Many organizations use private ranges defined in RFC 1918, including $192.168.1.0/24$ and $10.0.0.0/8$ . The third reserved range is $172.16.0.0/12$ . These addresses have meaning inside the organization and can be reused by another customer.

Now, consider the ISP's challenge.

Their customer, GlobalTech Inc., uses the $192.168.1.0/24$ network in their offices.
Their other customer, "Innovate Solutions", also uses the $192.168.1.0/24$ network in their offices.

Both customers use the same ISP network. A GlobalTech packet destined for $192.168.1.50$ and an Innovate Solutions packet with the same destination require different outgoing interfaces. A shared global routing table has no customer context, so the single $192.168.1.0/24$ prefix cannot select the correct route by itself. BGP/MPLS VPNs address this with VRFs, RDs, RTs, and MPLS labels.

VRF: A Separate Routing Instance for a Customer

The first element is to isolate customer routing information on the Provider Edge (PE) router. BGP/MPLS VPN architecture uses Virtual Routing and Forwarding (VRF), a separate routing and forwarding instance for a customer context.

A VRF associates interfaces, routes, and forwarding entries with a particular routing instance. A PE router can therefore hold several routes to the same prefix when those routes belong to different VRFs. The VRF context is selected by the interface or another configured mechanism. VRF entries are not automatically placed in the global routing table, which preserves the customer context during a lookup.

A is a logical routing instance inside the router. When an ISP onboards a VPN customer, it creates a dedicated VRF on the PE routers connected to that customer's sites.

Each VRF has its own completely independent routing table and forwarding table.
The physical interface connecting to the customer's site (the CE router) is assigned to that customer's VRF.
Routing updates received from the customer's CE router are only installed into that specific VRF's routing table.

VRF solves the overlapping-address problem locally. The PE router can hold a route for $192.168.1.0/24$ in "GlobalTech_VRF" and a separate route for the same prefix in "Innovate_VRF". Each route is evaluated and used within its own context.

RD: Distinguishing VPN-IPv4 Routes

VRFs solve the problem on a single router. But how does that router advertise these overlapping routes to other PE routers across the ISP's core network? The core BGP process still cannot handle two identical $192.168.1.0/24$ prefixes.

To carry overlapping routes through BGP, the PE adds a 64-bit Route Distinguisher (RD) to the IPv4 prefix. The RD distinguishes VPN-IPv4 entries with the same IPv4 prefix in the BGP database.

An RD is 64 bits and is placed before the IPv4 prefix in a VPN-IPv4 address. For a full IPv4 address, the RD and address together occupy 96 bits. In encoded NLRI, the prefix consists of the RD followed by the IPv4 prefix, and the associated MPLS label is carried with that information. The operator configures RD values, so distinguishability depends on correct configuration. The RD is part of the VPN-IPv4 route key, but it does not determine forwarding.

Example: Making Prefixes Unique

For the GlobalTech VRF, the administrator configures an RD of $65000:100$ . When the PE learns the route $192.168.1.0/24$ from GlobalTech, it converts it into the VPNv4 prefix: $65000:100:192.168.1.0/24$ .
For the Innovate Solutions VRF, the administrator configures a different RD of $65000:200$ . When the PE learns the same route from them, it converts it into the VPNv4 prefix: $65000:200:192.168.1.0/24$ .

From the perspective of BGP in the ISP core, the entries with RDs 65000:100 and 65000:200 are different VPN-IPv4 routes even though their IPv4 prefixes match. BGP can advertise, select, and store them as separate NLRIs. The RD distinguishes routes; it does not by itself determine VRF import or the next hop in the data plane.

RT: Selecting Routes for VRF Import

The provider network now advertises unique routes. A receiving PE router must still determine which VPN and VRF should receive a route. Its import policy controls whether a customer can use that route.

This is controlled by another BGP attribute called the Route Target (RT). An RT is a BGP Extended Community attached to a route. Export policy adds RTs to routes, while a VRF's import policy determines which matching routes may be installed. Export and import RT sets can differ, which supports hub-and-spoke topologies.

The Export and Import Process

The export and import process follows the configured RT policies:

Export RT: When a PE router learns a route from a customer CE and creates VPN-IPv4 NLRI, it attaches one or more Export Route Targets before advertising it to other PEs.
Import RT: Each VRF on a PE router is configured with one or more Import Route Targets. These values are used by the VRF's import policy.
The Matching Rule: When a PE router receives a VPN-IPv4 route, it compares the RTs attached to the route with the import configuration of its local VRFs. A route is eligible for installation in a VRF when at least one route RT matches an Import Route Target configured for that VRF.

Example: Building the VPN

The PE router connected to GlobalTech's New York office is configured so that its VRF exports routes with $RT=65000:100$ and imports routes tagged with $RT=65000:100$ .

The PE router connected to GlobalTech's London office has the exact same VRF configuration.

Meanwhile, the VRFs for Innovate Solutions are configured with $RT=65000:200$ .

When the New York PE advertises GlobalTech's routes, they carry Export RT 65000:100. The London PE receives them, and its GlobalTech VRF has Import RT 65000:100, so the routes become eligible for installation after the remaining BGP and IGP decisions. The VRFs serving Innovate Solutions use RT=65000:200, so they do not import these routes. The routes can remain visible in the VPN BGP table without entering a nonmatching VRF.

The Data Plane: A Typical Two-Label Stack

The control plane now includes VRFs, RDs, and RTs. In typical BGP/MPLS VPN forwarding, the packet receives a two-label stack, although the exact label arrangement depends on the topology and implementation. MP-BGP distributes the VPN label, while the transport label comes from the LSP to the PE address. The P routers need only the transport LSP state.

The Inner (VPN) Label:
When PE routers exchange VPN-IPv4 routes through BGP, they also exchange a label associated with the route. This inner label is called the VPN label. At the Egress PE it identifies the customer context, such as the VRF or outgoing attachment circuit, according to the installed label entry. It is the local delivery instruction.
The Outer (Transport) Label:
This is the transport MPLS label that leads from the Ingress PE to the Egress PE. Core P-routers inspect only this outer label. They swap it according to the transport LSP and forward the packet toward the Egress PE identified by their IGP, without installing customer routes in their routing plane. PHP can remove this label at the penultimate hop before the packet reaches the Egress PE.

Packet Traversal Summary

Example packet path from GlobalTech's New York PC to its London server:

The IP packet arrives at the NYC Ingress PE router. The router does a lookup in the GlobalTech_VRF.
It finds a match and determines the Egress PE router (the one in London) and the VPN label that router advertised.
It pushes the inner VPN label onto the packet.
It then does a lookup for the Egress PE's address in its main table and finds the outer transport label for the LSP leading to London.
It pushes the outer transport label onto the packet.
The packet now has two labels and is sent into the MPLS core.
Core routers swap only the outer label at each hop. They never see the inner label.
The router just before the Egress PE (the penultimate hop) pops the outer label.
In this example, the Egress PE in London receives the packet with only the inner VPN label. It uses the label to select "GlobalTech_VRF" and the outgoing attachment circuit for the London office.
The Egress PE pops the VPN label, and the original IP packet is sent to the London CE router. The P-routers processed only the transport label and did not need a route to GlobalTech's private prefix.