[AUDIO LOGO]
So now that we've taken our customer route from the VRF
on the engress PE, put on a route distinguisher
to make it unique as it travels through the core, put it
into multiprotocol BGP, sent it through most likely our route
reflector, and now it's arrived at the egress PE,
well, now we're presented with our next problem.
How do we know which VRF on the egress
PE this route is supposed to go to so that it
gets to the correct customer?
And that's exactly the problem that we're going
to be addressing in this video.
So let's just go ahead and jump in
and see how this process is handled in our layer 3 VPN
core.
So once that multiprotocol BGP update
reaches the remote or egress PE router,
we come across our next issue, which
is that the correct prefixes have
to go to the correct customers.
Therefore, they have to be placed in the BGP table
for the correct customers in the correct VRF.
So the question becomes, how do we accomplish this?
Now, at this point, a lot of people ask,
couldn't we just use the route distinguisher?
If we use the same route distinguisher
for each location for a single customer-- like in our example
for customer A, we did 100:1.
If we use that same route distinguisher at every customer
location, couldn't we use that number
to know which VRF we should put the routes in?
And quite frankly, the answer is yes, we absolutely could have.
So then why didn't we?
Well, the answer is, if you remember a few videos ago
during our introduction, I discussed the fact that we
could have overlapping VPNs.
And we also have another type of VPN
we discussed and are going to discuss in more detail, which
is the central service VPN.
Those types of VPNs would not be very
easy to accomplish if all we had to work with
was the route distinguisher.
Therefore, we just decided not to use it.
So what do we do instead?
Well, let's take a look.
What we do instead is we simply use
yet another new number called the Route Target, or the RT.
Now, like the route distinguisher,
this is a 64-bit value.
Again, we wanted to ensure that there was plenty of space.
This one, rather than being part of the prefix,
like the route distinguisher is, this one is carried
in BGP extended communities.
Now, this does mean that BGP extended
communities have to be enabled.
This is also another reason why BGP was the perfect fit
for running our core.
This is part of that being able to carry extra information.
BGP communities are perfect just for this sort of thing.
Now, another very important consideration
here is an update can carry many route targets.
Again, they're just carried as communities.
And there's really no limit on the length of the community
string.
So we can put numerous route targets
on here, which, again, is what's giving us
the capability of doing things like simple VPNs
just for customer A and customer B, overlapping VPNs,
and things like central service VPNs.
This flexibility gives us a lot of control.
Now, the route targets, again, are configured per VRF.
And they can either be configured that we import
a particular route target.
We export particular route targets.
The ones we export, of course, are
the ones that are going to be added to the updates,
or we can do both.
Now, both is only a configuration term.
It's just a shortcut.
If we do a show run, it'll actually
list both import and export.
Now, when an update is being sent,
any and all route targets that are set to export in the VRF
will be added to that update.
So you can, of course, have more than one export route target.
That's the point.
On the opposite side, when an update is received,
the list of route targets on the update
are going to be compared to the route targets that
are being imported by each VRF on that particular PE.
And one of three things is going to happen.
First, if any VRF is set to import that route target,
that route is then going to be placed in the VRF that's
doing the import.
If no VRFs on the PE are set to import,
the update is simply going to be discarded.
Now, the third one here is a little bit more conditional.
This one is if the route target is modified.
So in other words, if you as the administrator go into a VRF
and add a new import route target, since that route
target wasn't being imported before,
it may have already been discarded.
I might have already received that earlier,
and I threw it away because no VRFs were importing it.
So since it may have already been discarded,
the PE will do a BGP route refresh message
to get that update sent again.
So as we've been doing, let's hop over to our diagram
and take a look at how this would all
fit in to the big picture.
So let's start here with a very, very simple example, just doing
simple VPNs for customer A and customer B.
To do that, we could do something
as simple as, on VRF A, we could simply say to export 100:100.
We would also say to import 100:100.
We would do the same thing over here.
So just as a very simple example here,
the update comes in from the customer into the VRF.
When we send it into BGP, we add the export route
target 100:100.
That route then passes through our multiprotocol BGP.
And when it gets over to the egress PE side,
we then look to see, is any VRF importing 100:100?
And we see that, in fact, VRF A is--
therefore, this route is brought into VRF A
and, ultimately, therefore sent up to the customer.
So this is the basic idea behind import and export route
targets.
We do not have to use the same import
and export route targets for a particular customer.
Commonly, that will be done, but we could also
do something like this.
I can export 100:200 and import 100:201.
Then all I have to do is when I'm
configuring the other sites, I basically just
have to mirror these.
And we'll have the exact same thing happen.
As long as one site is importing whatever I'm exporting,
this will work perfectly fine.
So let me clean this up a little bit.
What we have right now are two simple VPNs--
one for customer A and one for customer B. Well,
to do a more advanced VPN, an overlapping VPN, this
is how easy it is to do.
Let's say I wanted my customer A headquarters
to be able to talk to my customer B headquarters,
but not to the remote sites directly.
So all I want to do is link this CE headquarter's
router to this CE headquarter's router.
If the remote sites want to talk to the other remote sites,
maybe they can, but it would have
to go through headquarters.
I'm trying to explain why we would not just
want to import say the 100:100 down here because that
would include these routes that are being exported.
So what we do instead--
and I'll just write this as both since we're going
to use the same number here--
we'll use 100 colon--
we'll just make up a new number.
We'll just say 500.
And down here, we say both.
So now what we've done is effectively
made another VPN between customer A and customer B
headquarters.
This is the power of route targets.
We can make whatever routes show up
on whatever routers we want based on the route targets.
And, again, what that means is when
this update is sent from this CE to VRF A,
it's going to get both the 100:100 and the 100:500 put
on it.
That means that when it shows up over here,
we're going to be importing based on the 100:100.
And when it shows up at VRF B because this
will be processed locally as well,
we are importing the 100:500.
So this prefix ends up on both of these VRFs.
Now, just one quick note here, in this particular example,
these routers have overlapping IP space.
So that would still be a problem.
These customers would still have to do something like NAT
or something along those lines so that they could actually
communicate.
I'm just trying to explain at this point how the VPNs work.
I'm not worried about the overlapping address space
that both of these customers are sharing at this moment.
The important part is that this is
how we use route targets to control which routes show up
in which routing tables of which routers.
And at the end of the day, that's
what layer 3 VPN is all about.
So in this video, we discussed the problem we have
when our multiprotocol BGP update
arrives at the egress PE, how we determine
which VRF the route belongs to.
And, of course, the way we do that is with our 64-bit route
target.
The route targets completely control which
routes go into which VRFs.
And at the end of the day, that is really what a layer 3 MPLS
VPN is all about.
Now, earlier, we mentioned that we
have this special type of VPN, the central services VPN, which
is similar to what we did here with the overlapping VPNs
but handled it a little bit differently when
it comes to the route targets.
So that's what we're going to take a look at next.
Until then, I hope this has been informative for you.
And I'd like to thank you for viewing.