MPLS Layer 3 VPN Explained

In previous lessons I explained the basics of MPLS:

• Introduction to MPLS
• MPLS Labels and Devices
• MPLS LDP
• VRF

In this lesson we will look at MPLS L3 VPNs and we will build upon the things you learned in previous lessons. By now you should know what MPLS is about. What about the L3 VPN part? Here’s what it is about:

• Layer 3: the service provider will participate in routing with the customer. The customer will run OSPF, EIGRP,  BGP or any other routing protocol with the service provider, these routes can be shared with other sites of the customer.
• VPN: routing information from one customer is completely separated from other customers and tunneled over the service provider MPLS network.

Let’s look at an example:

Above we have two customers connected to a service provider network. Customer A and B each have two sites and you can see that they are using the same IP ranges.

Customer A might use OSPF between their sites and customer B could use EIGRP between their sites. Everything from these customers is completely separated by the service provider.

In this lesson you will learn everything that is required to build a MPLS L3 VPN network. Let’s get started!

VRF (Virtual Routing and Forwarding)

Let’s start with VRFs. This is the first step in separating traffic from different customers. Instead of using a single global routing table, we use multiple routing tables. Each customer of the service provider will use a different VRF. Let’s take a closer look:

Above we have our PE1 router with the two customer sites. Each customer will use a different VRF so the overlapping address space is no problem. Now you might be wondering, why don’t we use VRFs everywhere instead of MPLS? We could but there’s one downside to using VRFs. Take a look at the following picture:

The problem with VRFs is that you have to create them everywhere. When our goal is to have connectivity between CE1 and CE3 then we will have to add a VRF on the PE1, P and PE2 router. Also, all the service provider routes will have to participate with routing. For example, when customer A wants to run OSPF between their two sites then it means that we have to configure OSPF on the PE1, P and PE2 router of the service provider for their VRF.

When customer B wants to run EIGRP between their sites, we have to participate…we’ll have to configure EIGRP on all service provider routers for the VRF of customer B.

This is not a scalable solution so it’s not going to happen. Instead, we will configure the VRFs only on the PE routers. The core of the service provider network (P router) will only do switching based on labels.

To share information about VRFs between PE routers, we will use BGP.

MP-BGP (Multi Protocol BGP)

We will use BGP between the PE routers so that they can share information from the VRFs. Here’s how it works:

• One of the CE routers advertises something to the PE router, this can be done through OSPF, EIGRP, BGP or any other routing protocol (static routing is also possible).
• The PE router uses a VRF for the customer so it will store everything it learns in the routing table of the customer’s VRF.
• The PE router will then redistribute everything in BGP.
• The PE router will advertise to to the other PE router through iBGP.

There’s a couple of problems though. First of all, our two customers are using overlapping address space. Let’s say that our PE1 router is advertising 192.168.1.0 /24 from customer A to the PE2 router on the other side. Here’s what happens:

The PE2 router will learn 192.168.1.0 /24 from the PE1 router but it has no clue to what customer it will belong. There is no way to differentiate if something belongs to customer A or B.

What we need is something to make all prefixes that we learn unique.

RD (Route Distinguisher)

To fix this issue, we will use a RD (Route Distinguisher). We will add something to the prefix of the customer so that it will become unique:

The RD is a 8 byte (64 bit) field. You can use any value you want but typically we use the ASN:NN format where ASN is the service provider’s AS number and NN is a number we pick that identifies the site of the customer.

The RD and the prefix combined is what we call a VPNv4 route. We now have a method to differentiate between the different prefixes of our customers. Here’s an example:

Let’s say that we use RD 123:10 for customer A and RD 123:20 for customer B. By adding these values, we have unique VPNv4 routes.

How do we advertise these VPNv4 routes? That’s what we need MP-BGP for.

MP-BGP supports IPv4 unicast/multicast, IPv6 unicast/multicast and it has support for VPNv4 routes. To exchange VPNv4 routes, MP-BGP uses a new NLRI (Network Layer Reachability Information) format that has the following attributes:

• RD (Route Distinguisher)
• IPv4 prefix
• Next Hop
• VPN Label

This is how PE routers exchange VPNv4 routes with each other. This NRLI also has an attribute called the VPN label, we’ll get back to this one later in this lesson.

RT (Route Target)

When a PE router learns these VPNv4 routes, what will it do with it? Take a look at the picture below:

Our PE2 router has learned the two VPNv4 routes, one for each customer. You might think that the PE2 router will automatically export each VPNv4 route in the correct customer VRF but that’s not going to happen.