We have a service provider cloud containing two internal routers
labeled P1 and P2.
And at the edge of this cloud, we, of course, have provider edge
routers labeled P1 and P2.
These each connect into our customer edge routers.
And we have four of those at the edge of our customer clouds.
You can see we have two companies with two different locations.
We have customer A, site 1, and site 2.
And we have customer B with site 1 and site 2.
Now the entire reason we use VPNs are that they allow us to emulate
point-to-point connections so that we don't require a dedicated link.
So this is much more cost effective and scalable.
Remember, MPLS uses labels to make forwarding decisions rather than
IP information. Within this topology.
we have an IGP running between all of our provider routers.
Now that could be OSPF, EIGRP, or they could even
be static routes.
But the goal is to have full connectivity between our entire
provider cloud. With MPLS,
let's say we look at customer A here who has two sites.
Let's suppose that both of these sites are using a local
network of 192.168.0.0/24.
So that
could potentially present a problem.
And what we want to do to correct that is to define some VRF
instances for each customer.
VRFs are virtual forwarding instances,
and they allow us to have multiple instances of a routing
table on a router.
So for example, on our PE1 router, we could have
multiple routing tables dedicated to each customer.
On our PE routers, you can see that if we create
a VRF for each site, that's going to allow us to
separate our customer traffic.
So customer A and B here would have two different VRF instances,
and PE1 would maintain two separate routing tables.
We could have one named VRF customer A and VRF customer B.
To share information between our provider edge routers,
we would use BGP to do that.
When PE1 receives an advertisement from customer A
through a routing protocol or through a static route,
the PE1 router will use Customer A's VRF to store that in its
dedicated routing table for the customer.
The PE will then redistribute everything into BGP and advertise
that to our other iBGP peer, which is of course PE2
in this topology.
Now again, the problem is, customer A has two sites using the same
local network address space.
So we need to make all of our learned prefixes unique.
And this is where the concept of a route distinguisher comes in.
Since they're both using the 192.168.0.0/24 network
internally, we need a way to keep track of those routes.
We do that with a unique number identifier called a route
distinguisher or an RD in the command line.
This is an eight-byte field that can really be any number you want,
but typically, most people follow the convention of the autonomous
system number followed by the site number,
and those are separated by a colon.
So for customer A, site 1, we might make that 100:1.
This route distinguisher is combined with the prefix
and that makes up what we call a VPNv4 route.
And these will be transmitted using multi-protocol
BGP or MPBGP.
Now we have a way to separate the prefixes of our customers and
their respective sites.
So we can create rd100:1 for customer A, site 1
and we can create rd 200:1 for customer B, site 1.
So even if these two sites are using the same prefix, we'll have a
different distinguisher, and these will have unique VPN version 4
routes advertised over MPBGP.
Now additionally, for each VRF, we need to designate
a route target, that's route-target in the command line.
This is another eight-byte unique identifier.
When PE2 receives these two VPN routes,
how will it know the correct VRF in which to place the route?
And that's why we use route targets.
We designate the route target inside of our MPBGP message so that
it gets imported correctly
on the other neighboring edge router.
It's common to set these to the same value as the route
distinguisher,
but that's certainly not required.
You can set those to any number you like.
So if we set the route targets also to 100:1
and 200:1,
PE1 will be able to place these routes into the correct VRF.
So again, just to reiterate,
both PE routers would be configured with a VRF
for each customer.
Let's take customer A, for example,
and we can see each of these PEs,
the provider edge routers, have a VRF called customer
A and customer B.
When PE1 receives a prefix from customer A, site 1,
it will add a route distinguisher and a route target that
we configure.
Let's suppose both of those are 100:1,
since we're using customer A, site 1. PE1 will add our RD and RT to all
of the VPN version 4 routes for VRF customer A.
This unique VPN version 4 route is advertised using
multi-protocol BGP,
which allows PE1 to advertise the VPN version 4
route to PE2.
PE2 is configured to export all VPN version 4 routes containing
route target 100:1 into its VRF for customer A,
which is also named the same as the VRF from PE1.
This is then redistributed into the VRF,
which allows the customer A, site 2 router on the other side of
our topology to learn the prefix.
So there are a lot of moving parts here,
and a lot of the combinations of the technologies and protocols
that we've been looking at throughout this series.
But again, you simply need to understand the function of a Layer 3
MPLS VPN and know the important components used
to configure that.
MPLS VPNs give us improved performance and traffic control,
and they also add an additional layer of security that isn't
possible over the normal public Internet.
It also helps to reduce bandwidth requirements and allows you to
much more easily scale your network.