[MUSIC PLAYING]
So the first issue we want to address with Layer 3 VPNs is,
how do we keep those customer routes that could, again,
be overlapping-- and very commonly will be--
how do we keep those separate on the PE router?
And the answer to that is we're going
to use Virtual Routers and Forwarders, or VRFs.
So in this video, we're going to jump in and take
a little bit of a detailed look at how the VRFs actually work,
and how they keep that traffic separate on the PE.
Let's go ahead and get started.
So given that one of our concerns
is keeping the customers separate, this could--
keyword, could-- have been done with
a couple different methods.
For example, we could have used, possibly,
ACLs, policy-based routing.
We could use route filtering.
Here's an expensive option.
How about a separate physical PE for each customer?
The problem with all of these solutions,
they would work just fine if our only concern was keeping
the customers' routes separate.
But none of these addressed the issue of the overlapping
IP addressing.
And keeping in mind that this is the customers'
internal routing.
A lot of these customers will be using RFC 1918 addresses inside
of their network.
Therefore, the chance of there being a network overlap
between hundreds or thousands of customers
is actually pretty high.
So this is definitely something we
have to take into consideration in our solution.
So again the problems here, aside from the one
I just mentioned, which would be the bottom choice here,
we already talked about this one--
that it's impossible to account for those overlapping IP
addresses.
But even more than that, this would
be very prone to human error.
Somebody has to do the ACLs, or the policy-based routing,
or the route filtering.
This would be the responsibility of, most likely, a human.
With automation today, there, of course,
could be exceptions to that.
But either way, this is something
that could be very, very prone to error.
Also, it would be difficult to separate routing protocols.
Now again, this may not be a huge concern,
particularly if we're only supporting BGP, for example.
But either way, these aren't great solutions.
So what we do instead is we have a Virtual Router and Forwarder.
So what this effectively does is creates a different PE
for each customer, which, if we think about it,
is really the best solution.
If it's a separate router, well then
we don't have to worry about routing tables intermingling,
or overlapping address space, or ACLs, or policy-based routing,
or any of that.
The problem is, a physical router for every customer
would be very expensive.
So instead of doing that, we're going
to do a separate routing table.
So essentially, it's a virtual router.
Remember, at the end of the day, a router
really is nothing more than interfaces, a routing table,
and generally some way to populate that routing table,
i.e.
a routing protocol.
So all we're really doing at this point is creating
a separate routing table.
The management plane itself will still be shared.
In other words, when you log into this device,
you do a show run.
You're going to see all of the configuration for all
of the VRFs.
We're not separating management at all.
We're separating the forwarding of traffic
and the maintenance of the routing tables.
Now, like we said, the router is just a routing table
with interfaces assigned to it.
So again, we have to assign interfaces
to the routing table.
We also mentioned that there's usually a routing protocol
to populate said routing table.
And what we're going to be doing is running those separately
for every VRF.
That way, they get populated on their own.
They're going to have their own neighbors, and so on,
with the various routing protocols.
So let's take a look at a diagram here real quickly,
and see how this fits into the big picture.
So this is just a conceptual drawing
that we'll use during our discussion of these MPLS
concepts.
It's not related to any of our topologies,
just so we're clear.
Now, in this drawing, we have two customers,
Customer A at the top, and Customer B at the bottom.
And of course, we have our MPLS core here in the middle.
Where the VRFs are going to be created is here on the PEs.
So each one of these little circles here represents a VRF.
So we would have a VRF for Customer A on the PEs connected
to Customer A, and a VRF for Customer B on the PEs connected
to Customer B This, of course, would keep the routes totally
separate, whether they're overlapping address space,
which, as you can see in our example here,
we are definitely going to be dealing
with overlapping address space.
We purposefully put both customers in here
with exactly the same addressing.
So we're going to be dealing with keeping
the routes separated, as well as dealing with this overlapping
address space.
Again, this is not a problem so far.
Because of our VRFs, we're going to receive the routes
from the customer.
And those routes are going to go into the respective VRFs
on each PE.
So for now, the customer routes have been handled.
So in this video, we talked about using VRFs on the PEs
to keep the customer traffic and routes completely separate.
This way, we don't have to involve things like ACLs,
or policy-based routing, or anything like that.
These are acting like physical routers,
in that they're completely and totally isolating
the customers.
But they're not.
They're virtual routers that are just really
instances of the routing table with assigned interfaces
and protocols on each PE.
Now that the customer routes are on the PE routers in the VRFs,
we now have to worry about getting
those routes to the other PEs.
That's going to be our next step.
And that's what we're going to talk about next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.