Imagine a really good cook, and that cook,
as they look at the recipe, is going down the list.
And if they come across an item and they say,
I don't know what that is, or I don't have that ingredient,
it could be a big problem.
So in the world of MPLS Layer 3 VPNs, in this video,
we're going to take a look at the ingredient
list that goes into the recipe called MPLS Layer 3 VPNs.
[MUSIC PLAYING]
Let's start with our recipe list of the things that are needed.
And some things are needed by the customer,
and some things are needed by the provider. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and some things are needed by the provider.
You and I, in this video series, we're
going to play the role of the service provider,
and we'll have the customers play their own role.
So as far as what do the customers need to have, here
you go.
The customers, they need to have a routing protocol.
Any routing protocol could do.
In their environment, they could have OSPF.
They could be using IS-IS.
They could be using BGP.
They could be using RIP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They could be using RIP.
They could be using EIGRP.
It just really doesn't matter, as long as they have a routing
protocol that's allowing them, in their own space--
their company, their site--
to go ahead and do routing and share routes.
And that's what they're going to need.
Ta-da!
The customer is not running MPLS with us.
They are simply running a routing protocol.
And what they're going to do is they're going to peer.
So this device here, the CE, it's
an acronym for Customer Edge, regarding the edge
of the customer network.
Maybe they have other routers in here, and other networks,
and so forth. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and so forth.
And the PE is our router at the edge of our provider network.
So the customer is going to have a routing protocol
in their environment, and they're also
going to peer with us, the PE.
So there's going to be a CE-to-PE neighborship.
Now, neighborship's kind of formal.
If we're running RIP, we really don't have a neighborship.
But we are adjacent.
We're sharing routes back and forth.
So that's all the customer really needs--
a routing protocol that they can run internally, and also
a routing protocol that they could use to connect and share WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a routing protocol that they could use to connect and share
routes with us, the provider edge.
And, again, that could be any IGP.
It could even be BGP.
Doesn't matter, as long as they have a routing protocol.
So, that's it for the customers.
Check!
Done!
Now, what do we need here in the provider network
to make all of this work?
And we have a few things on our list.
So I'm going to put here, Provider Network.
Let's first of all identify some of these acronyms
that are on the screen.
PE stands for our Provider Edge, meaning the edge of our network
where we're going to interface or communicate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
where we're going to interface or communicate
with a customer edge.
So our router is here, which is R1,
and we're talking to this router up here at the customer site.
And so that's a PE.
And the P here, like R2, is a provider router,
meaning it's in our provider network.
It's not on the edge.
So the provider router simply is the router
in our own organization forwarding packets
nilly-willy based on a routing protocol
and based on MPLS forwarding.
But it's not interfacing with any customers,
so it's just a P. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so it's just a P.
And then, as we follow that logic along,
we have customer edges over here, and here, and here.
And a provider edge is always going
to be communicating with a customer edge.
All right.
On the provider network, here are some of the ingredients
that we are going to need.
We are going to need routing, and that
would include the routing from our provider edge,
like R4 to this guy right here, to the customer edge.
We'd also need routing inside our organization.
So, routing internally.
Internally, for our internal routing protocol, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Internally, for our internal routing protocol,
we're probably going to be using something like OSPF or IS-IS.
And at the same time, we can go ahead
and use a different routing protocol
to communicate from the PE to the CE.
So maybe here it's OSPF.
And maybe over here--
I have a joke I've used for years.
I think it's still funny.
It's "Friends don't let friends run RIP."
But maybe we have RIP running between our PE and Customer 2
Site 2.
Maybe we're running EIGRP between the PE and the CE WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Maybe we're running EIGRP between the PE and the CE
here at Customer 1 Site 2.
So it's really flexible.
As long as you have a common routing protocol
you can use to exchange routes between these two devices,
it doesn't have to be the same as the internal routing
protocol.
So OSPF here, perhaps, and EIGRP.
Or, if they were running OSPF out
here as well, we could run a second instance of OSPF
specific for that customer, and that would also
allow us to run, basically, any routing
protocol we want to with the customer edge.
All right.
So, routing PE to CE, routing internally.
Fantastic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Fantastic.
And part of the problem is how do we keep these customers
routes all separate?
Let's imagine that we have a whole bunch
of routes that are being advertised into this PE
from the CE.
And how do we keep them contained or logically separate
for just that customer, Customer 1?
And the answer is on our provider edge routers
we are going to use a VRF.
That's a Virtual Routing and Forwarding instance.
It's like a mini me version of the routing table.
And the way we do it is, basically, we create the VRF, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the way we do it is, basically, we create the VRF,
and then we tell this interface, Gig1/0
or whatever that interface is, hey, this interface
belongs to that VRF.
And then if we learn 2,000 routes
on that interface as part of that VRF,
all those routes that were learned
are now just in that small, little container
called a Virtual Routing and Forwarding instance, that VRF.
And that's one of the aspects that's
important as part of the solution
to keeping those routes all within a certain logical
container.
In this case, on the local router's PE,
it would be the VRF associated with that customer. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it would be the VRF associated with that customer.
So we'll add that to our list here.
We need VRFs for each of the customers
that we're going to be working with and supporting
their routes.
And if we have a route like the 33.0.0.0 network with a 24-bit
mask, if we had that route that was in this Customer 1 Site 2
and it got advertised to the PE--
so it got into the VRF--
the long game is that we are going
to take that route from that VRF and then
put it into BGP, which is our next step here coming up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
put it into BGP, which is our next step here coming up.
And once it's in BGP, we're going to mark it, and tag it,
and add some attributes to it.
And when we do that, that route, as it sits in BGP,
is referred to as a VPNv4 route.
Think of a VPN route inside of MPLS Layer 3 VPNs as a network,
a route, that's associated with a certain client
or has a certain purpose.
And that way, we can control at the other side of the network,
based on the details for that VPNv4 route, who
we're going to advertise it to. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we're going to advertise it to.
Are we going to advertise that route to Customer 1
Site 1, which we should because it belongs to Customer 1?
Are we going to advertise it down here to Customer 2?
Nope.
At least not accidentally, because Customer 2
does not need to have that route for the 33 network.
That would be a mistake.
So I wanted to just kind of point out the idea
that, once these routes get into our multi-protocol BGP
and they're being advertised in our service provider network,
they are referred to as VPNv4 routes.
And the VPNv4 part of it, the the v4
represents its IPv4-related routes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
represents its IPv4-related routes
that are being advertised and passed across our service
provider network.
So as we add our list of elements
here for the provider network, we're going to be using BGP.
And that BGP is not just any BGP.
It's going to be internal BGP between our PEs.
So this dotted line right here, this blue line,
this blue dotted line, iBGP between R1 and R4,
that represents the BGP neighborship between these PEs.
Now, in a large network with lots of PEs,
we don't want a full mesh of PEs with full adjacency, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we don't want a full mesh of PEs with full adjacency,
so we might have a route reflector
in the middle, or two, of our provider network.
But in a smaller network we could do it
without a route reflector, and we
need PEs to have an iBGP neighborship with each other
as part of our provider network.
And there's one other really critical aspect of MPLS Layer 3
VPNs, and I'd like you to think of what that might be.
It's the MPLS part of it.
In our previous set of videos on MPLS,
we talked about how we do label switching. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we talked about how we do label switching.
And we'll have a quick review here in a separate video
as part of these videos to review MPLS and how that works.
And the benefit of having an LSP--
an LSP is an acronym for the Label Switching Path--
between R1, which is the PE over here
on the left side of our network and R4,
which the PE over here on the right-hand side of our network,
is that, if we have a label switching path, if we ever
have packets that need to be forwarded from R1 to R4,
if we have label switching in the network, R2 and R3, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if we have label switching in the network, R2 and R3,
they never have to look at the layer 3 header information.
All they do is they take a look at the-- let's say
R2 had a local label for it.
This is 4.4.4.4.
That's the loopback on R4.
And this is 1.1.1.1.
That's the loopback on R1.
So if there was a packet that said,
oh, the next hop is 4.4.4.4, and that packet is sent here
and R1 imposes the label of 200.
And on R2 it says, oh, if I get a label of 200
I'm supposed to remove that, and I'm
going to swap it out with a label of 305, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to swap it out with a label of 305,
and then it forwards it.
And then R3, and its MPLS forwarding table,
says, oh, if I receive a packet with 305 I'm going to go ahead
and I'm going to pop off that label, and just forward it
up here.
The benefit here is that our provider routers,
they don't have to look at layer 3 information.
Well, specifically, R2 doesn't have
to look at any layer 3 information
because it has label forwarding all set up based on MPLS,
and it can just forward it.
Now, the real power here is that we
could have millions of rules that are being advertised WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
could have millions of rules that are being advertised
between R1 and R4, and these provider routers,
not only do they have to not run BGP,
but they also don't need to know about any
of those details on forwarding because all they're doing
is forwarding between two PEs in the same provider network.
So the benefit here is that these two provider routers
in the middle, they don't have to run BGP.
And they don't have to know about all the
possibly thousands and thousands of routes
that Customer 1 or Customer 2 might be advertising back WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that Customer 1 or Customer 2 might be advertising back
and forth because all they're doing
is forwarding packets between R1 and R4,
and they're not even having to look at the IP address
information to do that.
So in case of R2, it just sees, wow, I got another MPLS
label that's marked as 200.
I'm going to swap that out with label 305 and forward it.
And it doesn't care, and doesn't have
to look at anything at the IP header
or above because it's just doing label swapping at that point
and forwarding those frames, or those packets, as quickly WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and forwarding those frames, or those packets, as quickly
as possible.
So that's the ingredients list for MPLS Layer 3 VPNs.
In the next video, I just want to take a few minutes
and review with you a few of the basic concepts regarding MPLS
that we had in the previous section of videos,
just to make sure we're on the same sheet of music.
And then we'll proceed to VRFs in the next video,
and on and on and on.
All right.
So I'll see you in the next video in a few moments.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.