VRFs-- virtual routing and forwarding tables--
when I think of those, I think of, like,
the mini-me version of the routing table on a Cisco
router.
[MUSIC PLAYING]
And here's the idea behind the VRFs as part of that layer
3 VPN solution, is that we want to create VRFs on the PEs that
are for the specific customers.
So let's go-- because I'm right-handed,
I'm going to use it over here, but we need to do on both
sides--
so for on R4, because it's supporting Customer 1 at Site 2 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so for on R4, because it's supporting Customer 1 at Site 2
and Customer 2 at Site 2.
What we would do is we create two VRFs, So VRF--
let me color-code these two.
That'd be good.
All right, let me color-code these based
on the actual customer site.
So we create a VRF that represents Customer 1.
We'd create a VRF that represents Customer 2.
And then what we would do is we would assign these interfaces
to each of those VRFs.
So we'd take Gig 1/0 or whatever that interface is
that's interfacing with the customer edge WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's interfacing with the customer edge
and doing the routing protocol, and we'd
associate that interface, along with its network,
into that little container, that routing container,
for that specific VRF.
And we do the same thing for the VRFs for Customer 2.
We would create it and then associate the interface
that we're using to communicate with Customer 2
at the provider edge with that VRF.
And that way, if there is like 11,000 routes that are all
being advertised or communicated from this CE
down into the router, they all get WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
down into the router, they all get
tucked in that little mini-me version
of the routing table, just that VRF, for that Customer 1.
Same thing over here, if we have 22,000 routes--
that's a lot of routes, by the way.
Who makes 22,000 routes?
And they get advertised to the PE,
they all come in on this interface, which
is associate with this VRF, and as a result,
they're all contained in that specific VRF for that customer.
So that's the basic concept of a VRF--
a virtual routing forwarding instance
that we can use in association with each of our VPNs,
each of our separate customers, which respectively have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
each of our separate customers, which respectively have
each of their VPNs or their own group of networks
that they want to share with their other sites.
Now, as part of this game, what's going to happen
is there's going to be a process called an export.
And whenever you think of the word export,
I'd like to think of export out of VRF.
So an export means we're taking these routes--
these 11,000 routes that are in this VRF on the PE--
and we're going to export them into something.
And that something is called multi-protocol BGP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that something is called multi-protocol BGP.
So on R4, it has an IBGP neighborship with R1,
and as part of that, we're also supporting VPN routes.
We'll take a closer look at that when we get to BGP.
But the export out of that VRF is
going to go into this multi-protocol BGP.
Think of it like--
think of it like a--
OK, I'm going to do my--
I used to be--
yeah, not much better.
Think of it like a bus.
All the routes get on the bus, like, OK, we're
going to put all the routes on this multi-protocol BGP bus. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to put all the routes on this multi-protocol BGP bus.
They become VPNv4 routes and then
they can be shipped over to R1, who can then learn about them
and redistribute them back into the appropriate VRFs based
on the customer.
Well, what happens if Customer 1 has a network of, let's say,
it's 10.1.0.0 with a 22-bit mask,
and Customer 2 has a network of 10.1.0.0 with a 22-bit mask.
I mean, it's an RFC1918 address space. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I mean, it's an RFC1918 address space.
It's a free country.
It's a free world, man.
So it would be important as those routes get on the bus--
you with me?
We need to keep them separate somehow.
So the way we do that in multi-protocol BGP with VRFs
is we are going to use what's called a route
distinguisher, or RD for short.
So for this VRF, if we said, hey, the route distinguisher
is going to be 11:33, and then we said for this VRF
that the route distinguisher sure
is going to be, say, 22:44, basically WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is going to be, say, 22:44, basically
what that means is that these two routes, the 10.1.0.0
and this 10.1.0.0, if we include the route distinguisher there,
as they become VPNv4 routes, which
is what's going to happen, they're
different because even though the IPv4 prefix type is
the same, the route distinguisher is added
as part of the information for that specific route
and all the routes coming from Customer 1
when they go into multi-protocol BGP as VPNv4 routes.
So route distinguishers, as part of a definition for a VRF,
are used to uniquely identify routes, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are used to uniquely identify routes,
even if they happen to be the same network--
the route distinguisher is different,
and that distinguishes this route--
why is this route different from any other route--
and that's because the route distinguisher for this network
is different than the route distinguisher for that network.
And that all becomes part of the attributes for those routes
in multi-protocol BGP.
So there is one other challenge.
Let's imagine that we have now 33,000 routes, all
inside a multi-protocol BGP.
They're all VPNv4 routes and some have route distinguisher WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They're all VPNv4 routes and some have route distinguisher
as 11:33, some have route distinguisher as 22:44,
and we have all these different routes.
When it comes time for this PE over here on the left-hand side
to start taking those routes out of BGP and putting them
in the respective VRFs--
let me bring those VRFs on this side
now-- so this PE1 has a VRF for Customer 1.
This PE also has a VRF for Customer 2,
and so out of all these 33,000 routes, which ones should WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
he advertise to the respective sites?
Now, at first glance, we might say, well,
why don't we just take all the routes that
have this route distinguisher of 11:33 and bring them in?
But that-- the route distinguisher-- is not
what controls which routes will be taken off this BGP bus
and put into the respective VRFs.
To identify in this PE which of all those routes
that are currently in this big pool called
the VPNv4 routes pool inside of BGP--
in order for it to identify which routes
do we put into the VRF for Customer 1 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
do we put into the VRF for Customer 1
and which routes to be put into the VRF for Customer 2,
the method we're going to use is something
called a route target.
And here's how a route target works--
a route target is associated with a VRF.
So over here at Customer 2, let's imagine we specified
an export--
let me make sure I'm not writing under my face--
an export route target of 33:33, and that's
identified as part of the VRF, which basically means WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
identified as part of the VRF, which basically means
every time this router takes routes out of the VRF,
exports them, and puts them into BGP,
it's going to go ahead and add this extended community, which
is a BGP attribute of 33:33.
Now what we can do over here on R1
is we can say, hey, regarding this VRF,
go ahead and let's use route target import of 33:33.
So what that does, it tells this router
to look at all the routes on the bus.
Anything that has a route target of 33:33,
import those into this VRF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
import those into this VRF.
So what one side exports as a route target,
the other PE is going to import and bring into the VRF
at the other edge of the network.
So that's how route targets work.
So we could say here we want to export 33:33, and for this VRF,
we want to import 11:11--
like that-- so over here on this VRF on the other side,
we'd say route target export 11:11.
So let that sink in for a moment.
What that means is that when these routes here in the VRF WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
What that means is that when these routes here in the VRF
get put on the bus, they'll be associated
because they were exported out of the VRF off into BGP.
They were given the route target of 11:11.
And then over in this PE, it's taking all the route targets
of 11:11 and it's importing them into the VRF
here so it can advertise them up to the customer.
So what one side exports with the route target to there
for the export will be used by the route target
imports on the other side of the network and vise-versa.
And the reason I made them different,
I've seen some examples where they use the same route WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I've seen some examples where they use the same route
target for both sides.
It's like, wow, well which route target are you going to use?
Just use the same number, it'll be OK.
But I want to make it clear regarding
which routes a PE router is going to bring into the VRF
is all based on the route targets.
So, in this discussion, the concept
was VRFs and that we need to have them and create them,
but I also wanted to explain what the route distinguishers
do, as well as the route targets, before we implement
them because when we create the VRFs,
we're going to define the route distinguishers, which
keep all those routes unique inside of multi-protocol BGP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
keep all those routes unique inside of multi-protocol BGP
as VPNv4 routes, and also identify in the VRFs
the route targets.
So I'd like to do is give you a demonstration of creating
the VRFs and we'll do that here on PE1, using
these same numbers, and also here on PE4,
so you can see it in action.
And also, if you're just hankering for a chance
to practice this, no worries.
Once I've walked you through all the pieces-- the VRFs,
and the IBGP and the redistribution and everything
else--
at the very end, I'll give you an opportunity
with a full-blown lab where you can practice any or all parts WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with a full-blown lab where you can practice any or all parts
of this that you want to.
So let me walk you through a demonstration of setting up
the VRFs on R1, which is our PE--
provider edge router here on the left,
and also on R4, which is our provider edge
router over here on the right.
All right, let's do it.
And to make this less of a typing exercise,
I have a little document here that I'm going to leverage in
and then it have the same document for you
at the end of this set of videos so you
can do the whole configuration, and this text document
can help you get there.
So on R1, the provider edge router, here
is where we are creating our two VRFs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is where we are creating our two VRFs.
So VRF definition Customer 1-- now,
there's two ways of creating VRFs.
There's IP VRF, if you're just going to do just IPv4 VRFs
and there's also the option of VRF definition,
and the VRF definition allows you to do IPv4 or IPv6.
So I'm just going to demonstrate the more flexible one
with the VRF definition.
Here's my route distinguish for this VRF, for Customer 1.
Then I'm going to go in to address family for IPv4,
and that's because we're using the VRF definition option.
So now I'm specifying, hey, regarding IPv4, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now I'm specifying, hey, regarding IPv4,
here's what I want to do.
And this says, hey Mr. BGP, when you're
taking the routes out of the VRF and you're putting them
into multi-protocol BGP as VPNv4 routes,
go ahead and add an extended community of 11:11
because that's what, really, route targets are,
they're BGP extended community attributes.
And then we're telling the same provider edge router, hey,
you know what?
When you're bringing in routes from multi-protocol BGP,
bringing in the VPNv4 routes, go ahead and only WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
bringing in the VPNv4 routes, go ahead and only
bring in the routes that are tagged
with the extended community of 33:33.
So I'm going to flip these two values on the other router.
On the other router, it'll be exporting 33:33
and importing 11:11.
So I'm doing the similar treatment
for Customer 2 using a different route distinguisher
for their routes so they can both have the 10.1.0.0
network if they want to.
Their route distinguisher are going to be different.
And then-- this is also very important--
I'm going to the interfaces and I'm
going to do VRF forwarding Customer 1.
So what that says is this interface Gig 1/0-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what that says is this interface Gig 1/0--
let me show you that interface, it is right here--
this is R1, so it's Gig 1/0 interface
right there that's going up to Customer 1 Site 1.
We're going to associate that interface
and its directly connected network with that VRF.
And this is a little bit of a gotcha--
once you do that, it actually wipes off
the IP address of that interface and then
what I'm following it up with is putting the IP address back
on the interface.
And then the same thing for Gig 2/0,
which goes to Customer 2 Site 1, again, on the left-hand side. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which goes to Customer 2 Site 1, again, on the left-hand side.
And we're assigning that interface to the VRF
called Customer 2 and then we're exiting.
All right, so let's do that up to that point.
So we'll do a config t--
we'll grab all the way down to assigning
the VRFs to the interface.
I'll right-click on that.
We'll bring back multi-tab PuTTY.
We're on R1-- make sure you're on the right router--
and we'll paste it in.
There we go.
So that's done. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that's done.
And then we do a show vrf--
and then we do a show ip vrf and press Enter.
There's our two VRFs and there's the associated interfaces
with those VRFs.
And if we go to R4, let's bring up the R4 part of this config--
which I put some separators here, these eights--
and these create the VRFs and they associate them
with their respective two interfaces.
And we'll continue BGP when we get to that section. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we'll continue BGP when we get to that section.
So right-click-- so right-click, Copy on R4, paste that in,
and we are done.
Show ip vrf, there's our VRFs.
Now, check this out-- if we do a show IP interface brief,
look at this interface right here-- these two interfaces.
172.16.3.4 and 4.4, they both have 24-bit masks.
But if we-- and they both show as up-- but if we do this,
show ip route--
and let's just say connected to make it simpler--
look at our connected routes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
look at our connected routes.
We don't have a 172.16 anything.
And that's because those routes are in the VRFs--
Customer 1 and Customer 2 VRFs.
We're looking at the global routing table.
That's the commands we've done forever.
By looking at the global routing table.
If we want to look at the VRF table, do a show ip route vrf
and then we'll put in the name, so cust1,
and there's our directly connected network of 172.16.3.
We hit the up arrow key and do a show ip route for vrf cust2, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We hit the up arrow key and do a show ip route for vrf cust2,
it should show us the 172.16.4 network.
So just be aware that once we have the VRFs, the ping
and trace and show commands regarding
routes are VRF specific.
Otherwise, if we don't specify VRF,
it's assuming the global routing table.
All right, so what we've done in this video
is we've taken a look at VRFs.
And if we want to take a look at the details of a VRF,
we do a show vrf, and let's go ahead and look at cust1,
see if there's any good options here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
see if there's any good options here.
That sounds great.
So there is the VRF for Customer 1.
And if we did a show ip vrf and a question mark,
and said detail and pressed Enter,
then we get the details regarding the VRFs.
So here is VRF Customer 1.
Here's the export route targets we configured.
Here's the import route targets we configured and the route
distinguisher that we specified is right here--
11:33.
Let's do a show cdp neighbors detail. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's do a show cdp neighbors detail.
And this says that Customer 2 Site 2, their IP address
is 172.16.4.44.
So if we did a ping to that address--
let's copy and paste it there--
it doesn't work.
And that's because the ping, by default,
is being attempted from the global routing table.
And that IP address is associated with Customer 2,
so if we wanted to ping that device, we could do ping
and then we'll type in vrf cust2 space
and then we'll put in the IP address, which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then we'll put in the IP address, which
is this guy right here.
Let's copy and paste that.
And we lost one for the ARP, which is normal,
and then the rest should work perfectly fine
because we're pinging it from the logical VRF where
our source IP address existed.
Otherwise, we don't have a route in the global routing table
for the 172.16 anything network.
We can verify that again with show ip route,
and yeah, there's no one 172.16 anything
in the global routing table.
And that's why the original ping failed because it
didn't know how to get there.
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 the VRF creation,
including a little bit about the route targets for import
and export and the route distinguisher
and what their purposes are.
And in the next video, what we get to do
is take a look at the routing between the provider
edge and the VRF on that associated interface
and the actual customer on the customer edge.
It can be done in a variety of flavors,
and I'd like to give you an overview of what those are,
and we'll do that in the next video.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.