In this video, we're going to take a look
at the component in MPLS layer 3 VPNs called internal BGP, which
takes those routes from the VRFs and places them
into multi-protocol BGP as VPNv4 routes.
And as a quick review, here is a school bus, or any kind of bus.
And we're going to call this bus multi-protocol BGP.
Now, it's called multi-protocol because it can support WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, it's called multi-protocol because it can support
more than just like IPv4.
We can support VPNv4 routes, VPNv4.
What a VPNv4 route is it's a route
that has been advertised by a customer edge
and it's in a VRF.
And we've taken that route, along
with the route distinguisher.
And we've exported it out of that VRF
and put it into multi-protocol BGP as a VPNv4 route.
So if somebody walked up to us and said,
hey, what is exactly a VPNv4 route?
We can say, well, in the context of MPLS layer 3 VPNs, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We can say, well, in the context of MPLS layer 3 VPNs,
a VPN is a set of routes for a specific purpose,
or in this case, a specific customer.
And as those routes are exported out of VRFs
and they have the information added, such as a route
distinguisher, and they also have
route targets that are added as part of those attributes.
Those are now VPNv4 routes.
And they're all in multi-protocol BGP.
If they further said, well, if all those routes are in there,
how does the PE at the edge-- how's he
know which routes to take out and put
into the VRF for customer 1 and which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
into the VRF for customer 1 and which
ones to take out of multi-protocol BGP
as VPNv4 routes and put into the VRF for customer two site one?
And the answer is route targets.
So if the route target is XYZ, and this VRF says, hey, go
ahead and import route target XYZ,
that's what makes those routes come off of the bus,
be put into the VRF, and then advertised
to the respective customer edge.
So to make all that work one of things
we need to have is BGP, internal BGP,
set up between the provider edges. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
set up between the provider edges.
So in this case, it can be between R1 and R4,
as represented by this little dotted line between R1 and R4.
In a fairly small network, you could
have direct iBGP neighborships between the provider
edges, all of them.
Or if you have like dozens and dozens or hundreds of provider
edges, and you don't want to do a full mesh of connections,
from the perspective of internal BGP,
then we could implement a route reflector
and have less pairings, or a couple route
reflectors and have less pairings.
But the concept's the same.
The information, including the VPNv4 routes,
are going to be advertised and communicated WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are going to be advertised and communicated
via iBGP so that all the provider edges that need it,
all the provider edges that have customer 1 or customer 2
or customer 3, et cetera, will have available those routes
those VPNv4 routes so they can extract the ones that they
need, and then advertise them through the VRF
to the respective customer.
So to make that work, we're going to have iBGP pairing.
And for our example, let's use autonomous system 6, 7, 8, 3.
And if that is your autonomous system on the internet today,
thank you for letting--
thank you for letting me borrow it for this lab. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
thank you for letting me borrow it for this lab.
So it's going be an internal BGP neighborship.
Also, we're going to have some fault tolerance, usually,
in our service provider network.
So instead of just peering from our egress interface,
let's go ahead and also peer from our loopback.
So we'll do 1.1.1.1.
We'll peer with 4.4.4.4.
And that way, if we had a multiple pass
and we'd lost a connection somewhere, as long as there's
still a path to the IP address instead of our network,
we won't lose our neighborship.
What else do we want to do?
We also want to set next-hop-self. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We also want to set next-hop-self.
And that way when these two provider edge routers
are advertising routes, including VPNv4 routes,
they can show the next hop for this transit network.
They can show their own IP address.
So we're also going to do next-hop-self just to make sure
that happens no matter how the configuration changes.
And then also we need to do is we need to activate, which
is a fancy word of saying, we need
to tell both BGP speakers that we
are going to support VPNv4, which effectively means
we're going to support the advertisement
and sharing with each other of VPNv4 routes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and sharing with each other of VPNv4 routes.
And again, that's just a route that's
been advertised by a customer in through a VRF.
And then we've exported it out of that VRF
into multi-protocol BGP.
And when we do so, we're also including the route
distinguisher, and also the associated export route
targets, which become part of extended communities associated
with those routes.
So another thing we're going to want to do in that light
is we're going to want to enable extended communities
so that the route targets can be advertised along
with those respective routes as they're shared via iBGP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with those respective routes as they're shared via iBGP.
And there is one other aspect that I'd
like to chat about here when we're talking about BGP.
And that is the export.
Now, when you hear the word export,
I'd like you to think of export is referring to taking
something out of the VRF.
Think of the VRF as like the center of the universe
just for this concept.
And the VRF, if we're taking routes out of that VRF,
and putting it into multi-protocol BGP
as a VPNv4 route, we're exporting it.
So whenever you hear the words import or export,
think of it from the context of the VRF itself. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
think of it from the context of the VRF itself.
So if we want to take the routes out of VRFs and place it
into multi-protocol BGP as VPNv4 routes,
what we're going to do in BGP in the BGP configuration is we are
going to redistribute the routes from--
in this case, let's see.
We're running-- what are we running?
EIGRP up here.
So if each EIGRP autonomous system three that we're
running in this VRF.
In BGP, we'd say, I want to redistribute--
I want to pull in EIGRP routes from this VRF
into multi-protocol BGP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
into multi-protocol BGP.
And that's what causes those routes that
were learned from the customer to be
injected as VPNv4 routes inside of multi-protocol BGP.
So from the perspective of BGP, if we say redistribute,
that means pull into BGP.
It's pulling out of the VRF.
And that's an export.
Again, think of the keyword of export or import
in terms of the VRF itself.
So a BGP redistributing from a VRF
would be the export of those routes into BGP.
So here's our plan.
In this video, we've taken a look at BGP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In this video, we've taken a look at BGP
and its role it plays in the implementation of MPLS layer 3
VPNs on the provider edges.
So what I'd like to do is in the next video, let's go ahead
and do a demonstration of implementing
those commands for BGP, and also verifying that they work.
So all that's waiting for us in the very next video.
I'll see you there in just a moment.
Meanwhile, I hope this has been informative for you.
And I'd like to thank you for viewing.