How MPLS Layer 3 VPN Works

The previous lesson ended on an open problem.

Two customers share the same provider network, and nobody coordinates their private address ranges.
That is what you are going to solve here.

One Routing Table Is Not Enough

Look at the four customer sites once more.

Figure 1 – Two customers share the same provider network

Three things to notice on this figure:

• Customer 1 uses 10.1.1.0/24 and 10.2.1.0/24

• Customer 2 uses 10.1.2.0/24 and 10.2.2.0/24

• Both companies land on the same two PE routers

Your PE router has a single routing table.
If both customers use the same private subnet, the routing table has no way to keep both routes distinct.

The two companies end up mixed together, and a provider selling private connectivity can never allow that.

One VRF per Customer

To solve this, each PE router keeps one VRF per customer: a separate routing table for every customer it connects.

Figure 2 – Each PE keeps one VRF per customer

• PE-1 and PE-2 each hold two independent tables, VRF C1 and VRF C2, one for each customer they serve.

• A VRF (Virtual Routing and Forwarding) instance is a routing table that sits beside the global routing table.

The CE exchanges routing information with the PE, and the PE stores those routes in the VRF dedicated to that customer.
Since each VRF is its own routing table, overlapping addresses are no longer a problem: every customer can advertise its private routes and use whatever address space it wants.

Your PE keeps the two customers apart locally.
But a table on PE-1 is useless to a branch office behind PE-2, at the other end of the core.

MP-BGP Between PE Routers

The IGP already runs on every router of the P-network and reaches all of them. Why not let it carry the customer routes too?
Two reasons stand in the way:

• the IGP cannot tell which route belongs to which customer, so identical subnets collide again

• every P router would start carrying customer prefixes

A provider can serve hundreds of customers over the same core, so the core IGP carries no customer routes at all and stays small enough to converge quickly.

The provider needs a protocol built to carry huge numbers of routes, with extra information attached to each one.
There is one obvious candidate for that job.

PE-1's VRF C1 and PE-2's VRF C1 have had no connection between them until now.
P1, P2 and P3 stay exactly as they are below — the new piece is that missing connection, at the edges.

Figure 3 – PE-1 and PE-2 open an MP-BGP session

In the figure above, PE-1 and PE-2 open an MP-BGP (Multiprotocol BGP) session that runs from one edge of the domain to the other, while P1, P2 and P3 take no part in it.

What Each PE Does

Each PE feeds the routes in its VRFs into that session.
The PE at the far end takes them back out and installs them in the matching VRF.

P routers in the middle keep doing exactly what they did in the previous lessons: swap labels, forward packets.

MP-BGP now connects your two PE routers, but the problem raised in the first section has not gone anywhere.

One RD per VRF

If both customers advertise 10.1.1.0/24, MP-BGP receives the same prefix twice with no way to tell them apart.
The provider fixes this before the route ever enters BGP.

Figure 4 – Each VRF has its own route distinguisher

In the figure above, each VRF carries a value of its own, RD (route distinguisher) 65000:1 for VRF C1 and 65000:2 for VRF C2, configured inside the VRF on the PE itself.

Check both values on PE-2:

PE-2# show ip vrf
  Name                             Default RD            Interfaces
  C1                               65000:1               Gi0/2
  C2                               65000:2               Gi0/3

Two VRFs, two RDs, and the customer-facing interface each one owns.
So what exactly did you just configure?

What the RD Is

An RD is 8 bytes long, written as two numbers separated by a colon.

It plays no part in the customer's own addressing, it only exists to make every route unique in the provider's BGP table.

Table 1 – The two parts of the route distinguisher 65000:1

Follow one single route from here on: it starts at the branch office of Customer 1, on the right of the figures, and it has to reach the head office on the left.

Leaving the Customer Site

Figure 5 – PE-2 learns 10.2.1.0/24 from CE-R2

In the figure above, CE-R2 advertises 10.2.1.0/24 to PE-2 with a static route or a standard routing protocol, over a link that runs no MPLS at all.

PE-2 installs the prefix in VRF C1, because that is the VRF owning the interface it arrived on, and at this stage the route is still a plain IPv4 prefix of 4 bytes with its mask.

Adding the RD

Before PE-2 hands the route over to MP-BGP, it places the RD of the VRF in front of the prefix, and the result is worth looking at closely.

Figure 6 – The RD is added in front of the route

In the figure above, 10.2.1.0/24 becomes 65000:1:10.2.1.0/24, because the 8 bytes of the RD are placed in front of the 4 bytes of the prefix to form a 12-byte address.
This new object is called a VPNv4 route.

Customer 2 receives exactly the same treatment with 65000:2, so both companies can advertise 10.1.1.0/24 and MP-BGP still holds two clearly distinct routes.

The route is unique and the session between your two PE routers is up, so the only thing left to do is to carry it across the core.

Across the Core

PE-2 sends the VPNv4 route to its only BGP neighbor, and nothing else inside the provider network takes part in that exchange.

Figure 7 – PE-2 sends the VPNv4 route to PE-1

In the figure above, 65000:1:10.2.1.0/24 travels inside the MP-BGP session from PE-2 to PE-1, and P1, P2 and P3 forward those packets without ever reading what they contain.

No P router installs a customer prefix at any point, so the core stays exactly as you built it in the previous lessons, with an IGP and LDP and nothing more.

Open the BGP table on PE-1 and look at what arrived:

PE-1# show bgp vpnv4 unicast all
BGP table version is 5, local router ID is 1.1.1.1

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65000:1 (default for vrf C1)
 *>i  10.2.1.0/24     2.2.2.2                  0    100      0 ?
Route Distinguisher: 65000:2 (default for vrf C2)
 *>i  10.2.2.0/24     2.2.2.2                  0    100      0 ?

There is your VPNv4 table: each VRF gets its own section, headed by its RD.
Even if both customers advertised the exact same prefix, the RD in front would keep the two entries apart.
Also note the next hop: 2.2.2.2 is PE-2 itself, not any P router in between.

Back to Plain IPv4

PE-1 knows which VRF to use thanks to the route target (RT), a tag PE-2 attached at the same moment as the RD, and that only VRF C1 on PE-1 accepts.
The RD keeps routes unique, the RT tells the PE where to install them.

PE-1 now holds a 12-byte route while the customer behind it runs plain IPv4, so something has to come off before the route can be handed over.

Figure 8 – PE-1 removes the RD and gives the route to CE-R1

In the figure above, PE-1 removes the RD, installs 10.2.1.0/24 in VRF C1 and advertises the prefix to the CE router of Customer 1 over the link they share.

The customer receives an ordinary IPv4 route, with no RD, no label and no trace of the shared backbone it just crossed.

From CE to CE

You just followed one prefix across the whole provider network, from Figure 5 to Figure 8:

• CE-R2 gives 10.2.1.0/24 to PE-2, which stores it in VRF C1

• PE-2 adds the RD 65000:1, and the route becomes a VPNv4 route

• MP-BGP carries it to PE-1, across a core that never reads it

• PE-1 removes the RD and hands a plain IPv4 route to the customer

Both customers crossed the same core and neither route ever touched the other, which means the control plane part of this service is now complete.

Test what you just learned.
Put the six steps of that route back in order to earn your flag: