Dynamic routing protocols have been around for a long time.
And in this video, we're going to take a look
at the use of dynamic routing protocols
to share routing information between the VRF
on the provider edge and the customer edge.
[MUSIC PLAYING]
So here's the play by play.
If we have lots of routes--
hundreds of routes up here at Customer 1 Site 1,
and we have hundreds of routes over here at Customer 1 Site 2,
we would need to get that information to the provider WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we would need to get that information to the provider
edges so the provider edge can communicate
those routes through the provider network
and then correctly send those routes to the other site
for that same customer.
So effectively, Customer 1 is going
to have their own VPN in this case.
Customer 2 is going to have their own VPN, which basically
means keeping one customer's routes
separate from the other customer.
And also, when in transit traffic comes in--
like data plane traffic--
that if somebody on this site, like Bob, wants
to reach a server over here, that packet,
once it enters the server's provider network, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
once it enters the server's provider network,
hopefully it's forwarded over the provider network
and ends up in the right interface
egress wise and makes it up to the CE here so
it can be forwarded to that server and the response coming
back as well.
So that's the goal is to make sure we have
the right routes that show up and also make
sure the data plane also works.
So it's the control plane and the data plane.
They both have to be in sync and functioning.
So [LAUGHS] I got excited.
What was I talking about?
Oh, yeah.
OK, so routing-- how do we communicate these routes
from this customer edge router to our provider edge router? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
from this customer edge router to our provider edge router?
And the answer is a dynamic routing protocol.
On these CEs, the customer edge, it just
looks like normal routing protocols.
Nothing specific, nothing special, and nothing too weird.
We could use OSPF on this edge.
And then what we'd do is we'd run
OSPF associated with this VRF.
And all of the routes that we learn via OSPF
from this customer edge at the provider edge,
they would be associated with the VRF for that customer.
So that's going to be a common theme for all these provider WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that's going to be a common theme for all these provider
edges with their customer edges.
So it could be OSPF.
It could be RIP [LAUGHS] if you want.
It could be EIGRP.
It could be ISIS.
Although it's not likely your customers
are going to want to do ISIS on their edges.
However, they could, or they could use BGP.
So we can have a BGP neighborship.
It doesn't matter what routing protocol we use,
as long as we get the routes from the CE.
They come in on the interface, especially with VRF
at the provider edge.
And then the provider edge does its magic
with the exporting of those routes out of the VRF WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with the exporting of those routes out of the VRF
into multiple protocol BGP as VPNv4 routes shares them
with the other side and, then based on route targets, imports
the correct routes into the associated VRF
so the other side can see those routes.
And if you're wondering how do they know which one to do,
and how do we keep track of it all,
that magic is still coming.
So we're just building this piece by piece.
And this portion, I just wanted to communicate
that we need to have a routing protocol between the customer
edge and the provider edge.
So for the demo, I just used a couple of simple options--
really simple options. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
really simple options.
I think I'm going to use up here on Customer 1 Site 1,
we'll use EIGRP.
We'll use autonomous system 1.
And over at Customer Edge 2-- it doesn't
have to be the same routing protocol at both sites.
You could use each EIGRP over here and OSPF over here.
And at Site 2 for Customer 1, I'm going to also use EIGRP.
Just for grins, I'm going to use EIGRP autonomous system
number 3.
I'm just going to mix it up a little bit.
Because the relationship there on the routing
is only really between the edge of the provider network.
This is not a Layer 2 path for customers over here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is not a Layer 2 path for customers over here
and customers over here.
This is a Layer 3 VPN, meaning we are peering
with the provider edge router.
And so any protocol that we want to use
that is supported both by the customer edge and the provider
would work.
And then down here, even though we have all of these options,
I'm going to choose an easy one.
Let's use RIP.
[LAUGHS] It's like, I never thought I'd have to RIP again.
It's just an example of an easy to configure
routing protocol just to communicate
the routes from Customer 2 Site 1 to the provider edge. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the routes from Customer 2 Site 1 to the provider edge.
And also we'll use RIP over here as well
to communicate the routes from Customer 2
Site 2 over to the VRF on R4, which is the provider
edge has the VRF for Customer 2 that we're
interfacing with there.
And as part of the demo, I'm going
to be introducing and sharing with you
what may be not so familiar on the PE side of the house
as far as using address families and associating routing
protocols with specific VRFs, which if you haven't used VRFs
before, it's a slightly different process.
So that's when I show you this routing protocol interaction WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that's when I show you this routing protocol interaction
between the CEs and PEs.
So we'll use this topology.
We'll use the routing protocols that I just listed.
And we'll then verify that the routing is working
between the CEs and the PEs.
So as we continue, I'm just using the configuration
that we left from the previous video, which
was that we created our VRFs.
If we do a show IP VRF.
So I've got the two VRFs, Customer 1 and Customer 2
with their associated interfaces.
Same thing on R1 right there.
Great.
So we've got our VRFs already created.
Let's go ahead and enable the protocols. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's go ahead and enable the protocols.
And I've also got that in a cheat sheet
so this won't be a typing exercise.
So here's R1.
And let's go take a look at the routing section.
We'll get to BGP in a separate video here.
Here we go.
So this configuration right here, router EIGRP 100.
Let me go ahead and highlight this.
In fact, let me make this a little bit bigger.
So router EIGRP 100, that's autonomous system 100.
But if we specify address family IPv4 and then VRF Customer 1,
what this does it takes us into a logical configuration
for EIGRP that's just associated with that VRF WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for EIGRP that's just associated with that VRF
not the global routing table.
And what this net 0.0.0.0 says for EIGRP is all interfaces,
you're in.
Now because we're in this VRF configuration for Customer 1,
it's all interfaces in that VRF get to participate in EIGRP.
And then I'm specifying autonomous system 1.
Now what does that mean?
Well, router EIGRP 100 is the parent process, if you will.
But within this address family for IPv4
for the VRF called Customer 1, we
are going to use autonomous system 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are going to use autonomous system 1.
That means from the customer's perspective,
all they know is that it's autonomous system 1.
And they're going to neighbor with us,
and it's going to be great.
And that way we can have several different address families
for different VRFs and use unique autonomous system
numbers if we wanted to.
So this is the number right here, the autonomous system
number 1 that's going to need to match on the customer edge.
And this part right here, redistribute BGP 6783 1 1 1 1,
what that's doing, that's taking the VPNv4 routes-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
what that's doing, that's taking the VPNv4 routes--
the ones that match the correct route target for the VRF--
and that's going to import them from multiple protocol BGP
as VPNv4 routes into the VRF.
So I'll cover that piece a little later as we take
a look at the bigger solution.
But I wanted to point out that that's there,
and that's why it's there.
And we'll touch on that again.
So that's for the benefit of Customer 1 Site 1.
And if we scroll down a little bit more--
and again, this is on R1, the PE router.
And this part right here, RIP, is for the benefit
of Customer 2 at Site 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of Customer 2 at Site 1.
And so we're going to route a RIP.
And then, we're specifying address family IPv4
VRF Customer 2.
So this is saying I want to enable RIP routing protocol
for this VRF specifically, the one called Customer 2.
The redistribution is very similar to what
it was with EIGRP.
We're taking routes out of multiple protocol BGP
and putting them into RIP based on the import route targets.
And again, we'll cover that in more detail in a separate video
as part of this set of videos.
And then the network 172.16 simply
says I want any interfaces that are part of the VRF Customer 2 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
says I want any interfaces that are part of the VRF Customer 2
that begin with 172.16 because it's a class B address
space to be included.
And that's enough to enable RIP on gig 2/0
on R1, which is interfacing over to Customer 2 at Site 1.
Specifying version 2, no auto-summary, and then exit.
And that's basically configuring routing protocols, EIGRP
and RIP respectively within those two specific VRFs.
So let me take that and copy it.
And let me scroll up, make sure I didn't miss anything. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let me scroll up, make sure I didn't miss anything.
Yep, we're good.
And then we'll go to R1.
Go into configuration mode, [LAUGHS]
and we'll paste that in.
Awesome.
And then we have a similar treatment on R4.
So on R4, if we take a look at R4s configuration regarding
routing protocols with CEs.
We've already got the VRFs assigned.
Here's BGP.
We'll get to that in a moment.
All right, there's our EIGRP 100. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, there's our EIGRP 100.
And on Customer 1 Site 2, I'm using autonomous--
or we will be using autonomous system number 3.
So that's what we're going to specify here
as part of the routing protocol for EIGRP inside that VRF.
And then RIP is very similar as it was on the other side
as well.
So we'll take those two sections of routing protocols
for those two different VRFs, copy, and then go to R4.
Oops, I dragged R4 out of frame.
Right there.
All right.
Then go to R4, config t, and we'll paste that in. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Then go to R4, config t, and we'll paste that in.
Now to verify that that's working,
we'd also need to configure the routing protocols respectively
on the customer edges, meaning Customer 1 Site 1, Customer
2, Site 1, and on the right-hand side of our network also.
So let's do that.
Let's go to Customer 1 Site 1 and just get my bearings.
So up here we're running EIGRP autonomous system 1,
and we're going to pair with the PE.
So let's do that.
So back to Customer 1 Site 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So back to Customer 1 Site 1.
Show IP protocols.
All right, no dynamic routing protocols running.
Config t, router EIGRP, autonomous
system 1, net 0.0.0.0.
And great, we got a neighborship.
Yeah, I've got some kind of snafu with the labs.
Anyway, if you get to a situation
where you're trying to do a normal command like config t, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
where you're trying to do a normal command like config t,
and it doesn't work, just type in exit.
And this may or may not come up in the final lab
I'm going to provide for you, but if you
have to type in "exit," and you just type in "Bob,"
that takes you right back to where you were.
So all your stuff is going to work then.
So now we'll show IP protocols.
And EIGRP is running.
And let's see if we have-- so I already
saw the neighbor message.
Show IP EIGRP neighbors.
Yep, so we're appearing with our good buddy, the PE router.
And let's go to customer edge 1 site 2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's go to customer edge 1 site 2.
And that, just to make sure we're
on the same sheet of music, is this guy right here.
He's running EIGRP autonomous system 3.
That's what we configured on R4.
So let's go to that guy, config t.
We'll do router EIGRP 3 network.
And then if we go back to our routers-- let's go to R4--
and do a show IP route VRF Customer 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and do a show IP route VRF Customer 1.
Yeah, there's the routing table for Customer 1 in that VRF.
And there's the 33.33.33.33, which
happens to be a loopback on Customer 1 Site 2.
So if we did a ping VRF Customer 1,
and then we pinged to 33.33.33.33--
all right.
And if we did a ping from the global routing table, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if we did a ping from the global routing table,
it wouldn't have a route, and it would just time out.
So there we go.
And then let's go ahead and finish off with Customer 2
Site 1, which is just RIP.
That's pretty simple.
Config t router RIP, version 2, network--
let's see here, 172.16.
That's the first 16 bits of the network between the customer
edge and the provider edge.
And let's also do no auto-summary.
And let's also bring in the loopback.
I've got to-- let's verify.
Do show IP interface brief. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Do show IP interface brief.
Yep, I've got 22.
Let's do network 22.
[LAUGHS] Yeah, RIP isn't very smart,
so you have to kind of put it in classful boundaries,
and then it gets everything under that address space.
So let's go to Customer 2 Site 1.
So let's go to R1, and let's do a show IP route
for Customer 2 VRF Customer 2.
And they're the route.
Fantastic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Fantastic.
RIP learned route.
And let's also finish it off by going to Customer 2 Site 2.
And this is also running RIP-- or it should be.
Router RIP-- I can do this!
I can do this!
Router RIP, network.
And we'll do 172.16.
And we'll also do network--
it's got a loopback of 44--
44 something, which you'll catch that class A address range.
And let's do no auto-summary and version 2 because-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's do no auto-summary and version 2 because--
and then if we look at R4-- let me just get my stuff straight.
So we just did Customer 2 Site 2.
If we take a look at R4 with this VRF for Customer 2,
we should see the loopback that's being advertised VR RIP.
That's my theory.
That's my theory!
Let's check it out.
So we'll do a show IP route for VRF customer 2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll do a show IP route for VRF customer 2.
Oh, I'm on the customer edge.
It says I have no idea what VRFs are.
I don't know what MPLS is.
I know nothing.
Let's take a look at R4 and do that same command.
So show IP route VRF Customer 2.
All right, and there is our RIP learned route.
And if we wanted to ping it, we need
to ping it from VRF Customer 2.
There we go, Customer 2.
All right, so in this video, we've WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, so in this video, we've
taken a look at one of the legs of our journey
and that is dynamic routing between the customer
edge and the provider edge.
Customer edge straight up the way we've always done it,
global routing table.
No problem.
For the provider edge, we need to do the routing protocol,
whether it's OSPF or whether it's RIP or EIGRP,
we need to do it in association with the VRF associated
with that customer.
Now to do that, the configuration
is slightly different.
We did two here with RIP and EIGRP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We did two here with RIP and EIGRP.
But the configuration for doing that based
on whatever routing protocol you want to use is an easy lookup.
So just follow the examples for doing OSPF or even BGP.
You can also do BGP peering between the customer
edge and the provider edge.
And that's another way of exchanging those routes
as well.
It's also good.
And the next video, we're going to take a look
at the language of love for communicating VPNv4 routes
inside the provider network.
And that school bus-- that mechanism
that's carrying all those VPNv4 rounds with the included route WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's carrying all those VPNv4 rounds with the included route
distinguisher and the route targets as extended communities
is internal BGP, which is the topic
for our next leg of the journey, which we'll
cover in the very next video.
So 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.