In the previous video, we took a look at the concept of VRFs,
like little mini-me versions of routing
tables that can be logically created on a Cisco router.
So it's now time to implement.
Now, there's a couple of ways of implementing VRFs.
I'm going to share with you in this video and hands-on lab,
so by the way, if you're logged on to the CBT Nuggets,
click on the Launch Virtual Lab link
and do this right alongside me.
So one way is using IPv4-specific VRF commands
to implement. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to implement.
So we'll do that specifically in this video.
I'll walk through the commands, and then in the next video,
we'll take a look at doing the same thing,
but with a slightly different set of commands
with address families.
All right, let's take a look at the topology,
and then let's go right to the lab.
All right, so here's our plan.
I want to make sure we know where addresses are.
So this interface, gig 1/0 on R4, has the IP address of--
the IP address here ends in dot 4 in both of these links,
and it's 172.16.3.4 and for gig 2/0, it's 172.16.4.4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it's 172.16.3.4 and for gig 2/0, it's 172.16.4.4.
So those are the interface IP addresses on gig 1/0 and 2/0.
And then on the customer edge router
it's got dot 33 on that segment and dot 44 off that segment.
So one of the things that happens--
what we're going to do is, we're going to create the VRFs,
and I recommend we use green.
So this syntax is IP VRF and then the name of the VRF.
I'm going to use green in lowercase.
And then we'll create IP VRF purple. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we'll create IP VRF purple.
That way we'll know exactly who they're for.
The purple VRF will be associated with gig 2/0,
and the green VRF will associate with gig 1/0.
And so once we create the VRFs, we then
go to interface configuration mode
and assign those interfaces to those specific VRFs.
And then the rest of it is done, as far as just pinging
and being able to work with the VRFs.
And we'll walk through that together,
including the Show Commands.
Let's go in the lab environment and let's go to R4,
and let's start configuring VRFs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and let's start configuring VRFs.
All right, so let's get on the right router-- that's R4,
and let's do a show ip int brief, just to verify.
Right, so it's got gig 1/0, which goes to our customer
green, and this interface here of gig 2/0
goes to customer purple.
And let's start off by seeing if we have any VRFs created,
so show vrf--
no VRFs, whatsoever.
Also, if you do a show ip route, by default all the routes, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Also, if you do a show ip route, by default all the routes,
the directly connected networks--
oh, I've got some OSPF cooking, too-- so all the routes
are in the global routing table, so sometimes
referred to as the default instance,
or the global instance, of the VRF--
the ones that you just get by default.
So let's go ahead and create the two VRFs.
So the syntax would be, if you're creating a VRF for IPv4
only, it'd be ip space vrf space, and then the name.
So we'll create one called green,
and we'll type in Exit to get out of VRF configuration mode, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we'll type in Exit to get out of VRF configuration mode,
and we'll do ip vrf and purple.
Now there are a few details that we could put in,
as far as the VRF details, that we're going to be using,
including when we do MPLS layer 3 VPNs, but for VRF Lite,
all we're doing right now is creating the VRFs.
So we'll type in exit, and we'll do a do show vrf.
Da-duh-duh-da!
We've got the protocols IPv4, the two VRFs
are called green and purple, and see
the interfaces that are associated with those two VRFs? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There aren't any, so basically we have these empty VRFs,
so do a show ip route for VRF green,
which is how you see the routing table for VRF green.
It says I don't even have a routing table.
We have no interfaces.
There's nothing going on.
So what we're going to do-- let's take a look
at our topology here--
let's associate gig 1/0 with VRF green, and 2/0 with VRF purple.
And then, once we do that, this is a heads up--
when you assign an interface to a VRF, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
when you assign an interface to a VRF,
it whacks the associated IP address, so,
because we're doing IPv4 VRFs only at the moment,
it's going to remove the existing IPv4 address,
and it's going to force us to go ahead and put it back in,
which, when we do, it'll be become part of that VRF.
So you'll see that in the lab.
You'll see that here in the demo.
Let's go ahead and do it.
So one thing I'm going to do is, I'm
going to do a show ip int brief, just so
that those addresses will be close by if we
need to replace them. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
need to replace them.
And we'll go to configuration mode, interface gig 1/0
and ip vrf forwarding.
This is how you tell this interface
that it should belong to the VRF that we'll
put in here, which is green.
We press Enter.
It says, OK, Warning.
I just deleted your IPv4 addresses.
Great, so we'll put that IP address back on-- ip address,
and this is on gig 1/0 I'm just going to copy it from right
here--
and it's a 24-bit mask, so boom, it's back on. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it's a 24-bit mask, so boom, it's back on.
Now check this out-- if you do a do show vrf,
it now shows that we have a green VRF,
and you can call it whatever-- it's just a name.
And then it's supporting IPv4, and it's
supporting interface gig 1/0.
Let's also go into interface gig 2/0,
and hit the Up Arrow key a few times,
and do ip vrf forwarding--
for, this time, purple, wiping out the IP address there.
And then we'll put the IP address back in,
and on that interface it's going to be 4.4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and on that interface it's going to be 4.4.
Based this looking up, up here in the output.
It's 4.4.
Great.
So now, check this out.
If you do a show ip route that show
IP route is for the global instance,
the default routing table.
And so we have OSPF for outlier routes,
so I'm learning from R3 and other devices internally,
but you'll notice in the routing table
here it's not showing the 172.16.3 or the 172.16.4.
Those are no longer a part of this routing table. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Those are no longer a part of this routing table.
So if we want to see those, we do show ip route vrf green.
And there's the routing table for VRF green,
and here is the routing table for VRF purple.
Now another interesting thing-- it takes a little bit getting
used to, but it's manageable-- is this--
get my pen out here.
So this interface right here and this IP address are in the VRF
called green.
If we wanted to ping from that VRF using that routing table, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we wanted to ping from that VRF using that routing table,
we'd have to include that VRF in the actual command.
So we should be able to ping dot 33--
172.16.3.33 if we source it and associate that
ping that it should come from the green VRF.
And if we don't, it won't fly because it won't have a route.
But let's demonstrate that.
That's good to see at least once.
Let's do a show ip route for 172.16. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's do a show ip route for 172.16.
There's no routes.
So if we tried to do a ping of 172.16.3.33, there's no route.
And so this route, by default, is
being sourced from the global routing table,
and it's just-- it's got nowhere to go.
It's failing.
So if we want to do that ping, what we could do is do a ping,
and let's just verify the route real quick-- show ip
route for vrf green, so we have a directly connected network
of 172.16.3 So if we did a ping and we specified, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of 172.16.3 So if we did a ping and we specified,
hey, I want to use VRF green, spelled correctly,
and then 172.16.3.33, the first one
got consumed by ARP, as normal on a Cisco device.
And then the rest should be fine.
So that's important to note, that you
need to do some VRF-specific commands.
So if we do a show ip vrf, it's showing us
the green and purple, or gig 1/0, 2/0.
We do a show vrf and a question mark, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We do a show vrf and a question mark,
and there is information about the VRF
that we can see, like show vrf detail and press Enter,
so it gives, again, more detail about the VRFs
that exist on our devices.
So in this case, we're just using VRF Lite.
We're not really too concerned about route distinguishers
and route targets, which are all coming up with MPLS layer 3
VPNs, but we do have the ability now
on this device to have two separate routing tables, one WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on this device to have two separate routing tables, one
for Customer Green one for Customer Purple,
and as we proceed even further and we
have dynamic routing protocols, which I'll share with you
how to do in a lab, anything we learn on gig 1/0
dynamically with that neighbor, it'll
be associated with the VRF green.
Anything we learn on gig 2/0 through a routing protocol
for VRF purple will be associate with that VRF as well.
So in this lab and video, we've taken a look
at how to implement VRFs for IPv4 only,
and then the next video we'll kick it up a notch, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then the next video we'll kick it up a notch,
and we'll use the option for VRF creation
which supports address families for both IPv4 and IPv6,
if you'd like to do it that way, too.
So I'll see you that next video in a moment.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.