[AUDIO LOGO]
So now that we've learned the customer routes
in the appropriate VRFs on the appropriate PE,
it's now time to get those routes through the core
to the other PEs that need the routes
for that particular customer.
Now, we've already mentioned that to do this,
we're going to be using multiprotocol BGP.
Well, in this video, we're going to discuss why
we call it multiprotocol BGP.
And we're going to address our next issue, which are
sort of one and the same thing.
We need to keep these routes with overlapping address space
unique as they're carried through BGP in the core.
We can't just take overlapping routes
from the customers, which we were keeping separate
in our VRFs, and just send them to the other side,
hoping that the other side knows how to separate them again.
They're overlapping routes.
We would just see it as two paths to the same destination.
So we need to deal with that issue
as we move the routes to the other side.
So like we did with VRFs, let's take a look at some things that
possibly could have been done but don't really work out
so well, just so we understand a little better why they
chose the solution they did.
Then, of course, we'll talk about that solution
and how it works.
So let's go ahead and get started.
So as we mentioned during the introduction,
VRFs do a really good job on the PE
routers to keep the customer routes separate.
However, we now need to get the routes between the VRFs
on different PEs.
And this, again, is going to have different problems.
So let's first talk about the ways that possibly could have
been used but weren't chosen.
So first, we could have used a different routing protocol
or at least instance of that routing protocol
for each customer.
Now, there's really two major problems with this solution.
One is it, of course, does not scale at all.
The core routers, or the P routers,
would have had to have run every instance of every protocol
for every customer.
So just totally impractical.
And part of the reason this would have had to have happened
is IGPs are not meant to run between nonconnected neighbors,
which is what the PEs are.
The PEs are not connected to each other.
The P routers are in the middle.
So you can't exactly neighbor OSPF
to another router that far away.
Now, theoretically-- I just put a little note here--
EIGRP OTP, which stands for Over The Top,
could theoretically have been used.
Again, we're not going to pursue this a whole lot,
because there are, of course, other solutions, which
is what we're talking about in this video.
But EIGRP OTP can actually run between nonconnected neighbors.
So theoretically, it could have been a possibility.
But there's a lot of issues with that.
Again, we don't have to go too far down that path,
because, well, we're not using it.
The other choice, of course, is we
could have used VRFs to separate this on every P router.
But this, of course, does not scale, not even a little bit,
because, again, the core routers would have to maintain
a VRF for every customer.
This is not going to scale anymore
than the IGP solution right above would have scaled.
Last but not least, we could have used traditional tunnels.
Now, the problem with traditional tunnels, of course,
once again, these don't scale either,
and really sort of defeats the purpose of the entire MPLS
environment.
If we really think about it, ISPs, service providers,
have been doing tunnels between customers for years.
The idea behind all of this was sort of to get away from that.
So yeah, we could have just done traditional maybe GRE or L2TP
tunnels, that sort of thing.
But it really doesn't meet this model.
The idea was to not have the service provider
have to set up all these different tunnels for all
the different customers.
That's why we like layer 3 MPLS VPN.
It's because we don't have to do that.
So clearly, given everything we just said,
we needed a better solution.
And that better solution really should meet these criteria.
Number one, it should be a single routing protocol.
We don't want to have to support multiple routing protocols.
It's also going to have to be very scalable because, again,
it has to handle all the routes from all the customers.
It also needs to be easily extensible.
We need this to be able to support additional information.
We'll see why we need to support that additional information
as we go.
And it also needs to be designed to run
between those nonconnected neighbors.
It just so happens that we have a routing protocol that
meets all of these criteria.
And of course, that would be BGP.
Now, there is one thing not addressed by this yet.
And that is if we use one protocol--
again, BGP-- this really does not
solve the problem of allowing customers to have
those overlapping IP addresses.
Again, if we tried to do overlapping address spaces,
even with BGP, the routers would just see this as multiple paths
to the same destination.
And theoretically, they might try to do multipathing.
That probably wouldn't work out too well.
Imagine if we start doing load sharing between customer A
and B. Each customer gets half of their own traffic
and half the competitor's traffic, possibly.
So this would definitely be a problem.
So we still need a way to deal with overlapping address space.
So how exactly are we going to do that?
Well, to support the overlapping addresses,
we're going to have to modify those routes in order
to make them unique.
They can't be the same anymore.
So yes, we're going to carry them
in BGP, as we've already said.
But they need to be unique before we send them into BGP.
The way we do this is with a new number that
is going to be prepended to the front of the address.
And we're going to call this a Route Distinguisher, or an RD.
Now, some attributes of that route distinguisher-- first,
it is a 64-bit number.
We wanted to make sure that we weren't going to run out.
So we've given it plenty of bit space.
This is going to be configured in the VRF.
We use it for both IPv4 and IPv6.
But here's the thing.
If you take 64 bits and you add that
to the front of either 32 bits for IPv4
or 128 bits for IPv6 addresses, what do you end up with?
You end up with a route that is either 96 bits, of course,
for IPv4 or 192 bits for IPv6.
And guess what.
That means that those prefixes are no longer IPv4 four or IPv6
routes, because IPv4 routes are 32 bit.
And IPv6 routes are 128 bit.
So as soon as we modify them, they're not routes
for those protocols anymore.
So instead, we come up with a new name for them.
And they are called VPNv4 and VPNv6 routes.
And of course, those are 96 and 192 bits respectfully.
And just in case you didn't put this together yet,
this is why it's multiprotocol BGP in the core,
because it's not carrying standard IPv4 or IPv6 routes,
although it still can.
We can do things like internet handoff inside the MPLS core
and some things like that, where we may still want to carry
standard IPv4 and IPv6 routes.
But for our current topic, they're
going to be VPNv4 and VPNv6 routes.
And to support all of those things,
well, that sounds like more than one protocol to me,
so it's multiprotocol BGP.
So I'm pretty sure that's what we just said.
Since we're carrying VPNv4 and VPNv6,
it's Multiprotocol, or MP, BGP.
So again, this will be carrying the VPNv4 and the VPNv6 routes
specifically between the PEs in the core.
Also, sort of important here is the next hop
on these updates will be set to the advertising PE's address,
usually and preferably a loopback interface on that PE.
So let's go ahead and jump back over to our topology
and take a look at how this would work
in a practical environment.
So here we have our environment.
As we discussed before, we have our VRFs A and B
that we put in here in our previous video.
So what we're going to be doing is
running a multiprotocol BGP session between the two PE
routers.
Now, keep in mind, this is just a logical discussion right now.
In the real world, this multiprotocol BGP session
would most likely be running through a route reflector
or a pair of route reflectors in the service provider core.
I'm not going to draw this on the diagram,
just because we have a lot of things we're
going to talk about on here.
But realistically, we're not going
to be peering the PE routers directly
to each other with multiprotocol BGP.
Again, there would be a route reflector.
In our next skill, we are actually
going to be implementing this on the command line.
And we will be using a route reflector when we do that.
So on a practical scale, yes, this
would be using route reflectors, preferably
redundant route reflectors.
But here we're just going to draw it as
if they're directly connected.
Now, keep in mind, the other thing we discussed
is we also need root distinguishers.
So for example, maybe for customer A,
we would give this customer a route distinguisher of 100:1.
And maybe for customer two, we give them
a route distinguisher of 100:2.
So what happens now, when this address is advertised up
to the PE router and the PE router redistributes this
into BGP--
which we'll be talking about this process coming up.
But when customer B's network actually
shows up in multiprotocol BGP in the core,
it's actually going to look like this.
It's going to be 100:2:10.1.1.0/24.
And again, this is a VPNv4 route.
But the main point here is that the route distinguisher
is put in front of the customer's prefix
that they're advertising.
Of course, customer A's network over here would look like
100:1:10.1.1.0/24.
And hopefully, we can all see that because of this 2 right
here and this 1 right here, these
are no longer overlapping addresses.
They are now unique.
So now we can pass the routes from the VRFs
into multiprotocol BGP and keep them unique
and not cause overlapping address problems.
So in this video, we talked about how
to get the customer routes between the PEs in the service
provider core.
Two main aspects that we have to worry about here.
Number one is the routing protocol.
Well, we know we're going to run multiprotocol BGP.
And we know that that's going to follow
a typical BGP-type architecture, using, most likely,
route reflectors.
The other thing we have to worry about, of course,
is that overlapping address space.
The way we handle that is by assigning a 64-bit route
distinguisher to each VRF.
Now, as you can see in our example here,
we used the same route distinguisher
for each side of the same customer.
We just kept it unique between customers.
And you can certainly do that, although a lot of service
providers simply provide a unique route distinguisher
for each customer's each location.
So they're pretty much all different.
But either way, this 64-bit number
now makes the addresses unique so
that they can travel through BGP without BGP thinking
it's just doing multipathing.
Now, the next problem comes in when this BGP
update reaches the other PE.
How does the other PE know, by looking at these updates, which
VRF to put the route in?
Well, that's what we have to talk about next.
But until then, I hope this has been informative for you,
and I'd like to thank you for viewing.