Well, it's time to see this configuration in action.
We need to log into our iOS XC devices, log into this lab space, and actually
do the configurations
for VRFs and GRE tunnels.
And so what we're going to do here in this lab is just start off by looking
just one at
a time.
We're going to do VRFs in this session.
In the next video, we'll take a look at the GRE tunnels.
And then in the challenge, we're going to find that we're going to combine the
two together.
We're going to have to build an environment from scratch, including an underlay WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're going to have to build an environment from scratch, including an underlay
VRF.
So that's actually pretty cool how that all comes together.
For now, let's go ahead and explore our configuration commands.
And I would encourage you also to go ahead and maybe pull up the lab
environment that
is included in the skill down below.
And during these first two videos, play around with the configuration, make
sure we're comfortable
with setting it all up and then reset that lab environment for the lab
challenge.
Because when we do the lab challenge, we're going to want a fresh, basically
how it loads,
we want that fresh configuration in place when we begin the lab challenge. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we want that fresh configuration in place when we begin the lab challenge.
But just configuring these commands as we go along together would be a very
good way
to make sure that we are grasping it and locking it in.
So our topology for this video specifically, again, we're using the same lab
environment
for all of it, but we're just going to use a few different devices each time.
For this one, we're going to have, let's see here, we've got router 3
connecting into
router 1, then connecting to router 2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
router 1, then connecting to router 2.
And what we're going to do is we're going to configure VRFs on both sides.
So we'll do VRF, since this is 1 and 3, we'll do 13 and VRF 12 on the right.
So we're going to effectively carve router 1 up into two different VRFs.
Now router 3 and router 2 don't need to be VRF aware, if they exist entirely
within
one VRF within one layer 3 environment, then we don't need to worry about
configuring
it on those devices.
It's the devices in the middle that have multiple VRFs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's the devices in the middle that have multiple VRFs.
That point we need to be very intentional with our VRF definitions as well as
our interface
assignments.
So keep in mind what we're accomplishing with VRFs.
VRFs are carving a layer 3 device like a router up into multiple layer 3
domains in the same
way that we do that with VLANs and layer 2 switches.
Now in this environment, from a subnet and routing perspective, we do have OSPF
running
throughout this entire space.
We're going to see that we need to modify OSPF here on this router in order to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're going to see that we need to modify OSPF here on this router in order to
make it
work with VRFs.
And from a subnet perspective, we have 10.0.13.0/24 with .3 for router 3, .1
for router 1,
and then over here 10.0.23.0/24 once again, .1 and this time .2 for router 2.
So hopefully that gives us all of the configuration information we need just to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So hopefully that gives us all of the configuration information we need just to
kind of poke around
with VRFs here.
So let's go ahead and get onto router 1 here.
Yeah, well, I don't have a router 1.
So router 1 and we're going to start by entering global configuration mode and
we have to begin
with defining the VRFs.
And we literally use the word definition for defining here.
So VRF definition and then I'll say VRF 12.
Now keep in mind, VLANs have to be a number whereas VRFs can be a name.
So I could just call this 12, I could use numbers in my VRF naming scheme, but WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I could just call this 12, I could use numbers in my VRF naming scheme, but
usually
it's better to avoid that and just feels a little cleaner to have something
like VRF
in front of it and that way we know for sure what's going on.
So we enter into this sub configuration prompt here, this VRF subconfig.
And we have to enable this VRF with an address family.
The address family is going to allow me to enable, for example, IPv4, IPv6. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The address family is going to allow me to enable, for example, IPv4, IPv6.
And then on some platforms, not this one, but on some platforms we'll see that
we can
individually enable unicast and multicast routing.
For now, we'll just hit enter and even on those platforms we can just hit enter
and
enable both of those.
So I just want to prepare you for in case you do a question mark in your own
lab environment
and you see more options there.
Now if you are running on older lab hardware, I know if you're like me, in my
lab environment,
I've got some pretty old routers running.
And Cisco at some point changed the syntax for this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And Cisco at some point changed the syntax for this.
And I will say relatively recently, I mean not like a year or two ago, but also
not 15
years ago.
And so they changed this concept over to VRF definition and VRF forwarding as
we're about
to see.
Whereas before it just simply used to be IPVRF.
All of the commands started with IP and then you saw VRF.
So if you're configuring this on an old 2900 router, for example, then you
might type
VRF definition and it doesn't work.
Just type IPVRF and understand that the syntax has changed. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Just type IPVRF and understand that the syntax has changed.
But in the modern era and modern equipment, it's all going to be VRF definition
and a
VRF forwarding rather than IPVRF forwarding.
So once we've configured the VRF, we can go ahead and apply it to our interface
.
And oh, you know, let's since we're here, we might as well go ahead and just
create the
other VRF as well.
So VRF definition, VRF 13, and once again, address family IP before. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So VRF definition, VRF 13, and once again, address family IP before.
All right.
So now we can apply our VRF to the interfaces.
Now, if I look at these interfaces and the interfaces here should be gig one
zero and
two zero, I believe one zero and two zero.
Okay.
Yes, it is.
So when we look at these interfaces, we already have IP addressing.
We have 10 dot zero dot 13 dot one, which is right here.
And then we also have 10 dot zero dot 12 dot one, which would be on the other WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we also have 10 dot zero dot 12 dot one, which would be on the other
side right
there.
So these interfaces are going to need to be placed into the VRF or into these
new VRFs.
The thing about this is we might already have an interface in VRF 13 that
happens to
have the 10 dot zero dot 13 dot one subnet or really address at that point.
So remember, VRFs allow us to have duplicate IP addresses across the different
VRFs.
So it's not a duplicates. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it's not a duplicates.
It's not technically a duplicate address if it doesn't exist in the same VRF
because
different VRFs are truly different routing spaces.
So I could have 10 dot zero dot 13 dot one in every single one of my VRFs.
I could apply it to VRF 13 VRF 12 and the default VRF.
Never forget about that.
So we've got three VRFs running on router one right now.
The thing is is that if I'm going to place an interface into a new VRF Cisco
wants to
prevent the situation where we have an IP address in this VRF and it works, but WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
prevent the situation where we have an IP address in this VRF and it works, but
that
that IP address already exists in the new VRF.
And so we put it in there, it causes the conflict, that would be bad.
So just to make sure we are starting with a fresh slate, so to speak, Cisco is
going
to wipe the IP address off that interface when we change it.
And so what we're going to find here is that we will have to reconfigure the IP
addresses.
So let's go ahead and do that.
And running a show run like this allows us to very quickly restore the IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And running a show run like this allows us to very quickly restore the IP
addresses.
We're not going to need the IPV6 addresses, so we won't worry about those.
Let me get on to interface gig one zero to start with.
And the command for this is VRF forwarding.
And again, on legacy platforms, we put an IP in the front of that IP VRF
forwarding.
But on modern platforms, it's VRF forwarding.
And then I can say VRF.
And let's see here.
It is 12.1, which is over on the right.
And so I said 23.0. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so I said 23.0.
How about that?
So that's a little bit wrong.
That should actually be 12.
There we go.
That's more correct.
All right, so now we'll say VRF 12.
And we see that the IP addresses have been removed and OSPF has lost its IP
address.
So it has gone down that neighbor relationship between R1 and R2.
So from here, I'm going to restore the IP address. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So from here, I'm going to restore the IP address.
And again, I can just kind of scroll up, grab the configuration, paste it in,
and we're
good.
So then I can do interface gig two zero.
Same thing, except this time it's going to be VRF forwarding VRF 13.
IP addresses are removed.
Scroll back up a little bit, grab that IP address command, and we've restored
the IP
addresses.
So at this point, if I run those same commands, show run interface gig one zero WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So at this point, if I run those same commands, show run interface gig one zero
, and then
two zero, we should now see that we're part of VRF 12 on the right.
12.1 address is still there.
So that's good.
Well, thereafter, I put it back on.
And then VRF 13 here on the left, 13.1 pointing out towards router three.
So I should be able to do my ping commands.
Now, again, if I were to say, even if I just ping my own address, let's see, 10
.0.13.1,
we're going to find that this ping command is no longer working. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we're going to find that this ping command is no longer working.
And the reason for that is because the ping command assumes the default VRF.
I have to now specify which VRF I want to ping.
So I have to say ping VRF, and then I could say VRF 12.
Let's do that one first.
And over on the 12 side, it should be 10.0.12.2.
So that should be router two.
And once our works, there we go.
And then also VRF 13, 10.0.13.3 should be router three. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then also VRF 13, 10.0.13.3 should be router three.
And there we go.
So that's great.
The IP addresses are working.
I can ping if I do a show IP OSPF neighbors, we are still a big blank here.
So why didn't OSPF come up?
Well, if I do a show run and look at the OSPF configuration, we are going to
find that
we actually need to replace this configuration because router OSPF 1 assumes
the default VRF WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the default VRF
as well.
So we're going to say no router OSPF 1, and then we're going to make OSPF aware
.
I'm going to use the same process ID.
It doesn't matter which one I pick here.
But when I run my question mark here, we'll see I can specify a VRF.
So if, again, we're creating a brand new routing domain.
If I'm creating a brand new routing domain, I'm going to need the routing
protocols to
exist only within that domain, within that layer three VRF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
exist only within that domain, within that layer three VRF.
So if router OSPF 1 goes to the default VRF, then I need to create a different
process
of routing process that works in the other VRF.
So in this case, I was able to remove OSPF 1.
In the case I couldn't remove it, I might do something like router OSPF 12 and
then
VRF for VRF 12.
But since I got rid of OSPF 1, I can just add this in.
Let's, we're going to have to create two different routing processes here for
the two different
VRFs.
So let's just go ahead and call this OSPF 12 now. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's just go ahead and call this OSPF 12 now.
I think about it and then we'll say VRF 12.
And then I can put this network statement back in.
So network 10, 0, 12.1, all 0 is white mask, really just targets that specific
IP address.
And there we go.
We've got our OSPF neighbor or adjacency really back with R2.
Now let's do the same thing.
On the other side, on the left side of that diagram, OSPF 13, VRF 13.
And then we will grab that network statement for that subnet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we will grab that network statement for that subnet.
And there we go.
So now we have OSPF, we should see some OSPF routes here.
If I do a show IP route, OSPF, look at that, no OSPF routes.
So what went wrong here?
Well, what went wrong is simply that show IP route OSPF is assuming the default
VRF again.
How about that?
Show IP route VRF and then specify the VRF and then I can specify a routing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Show IP route VRF and then specify the VRF and then I can specify a routing
protocol
like OSPF.
So there we go.
I've got an OSPF route in VRF 12.
I could do the same thing for VRF 13.
And it looks like I don't actually have any routes coming from there.
But if I do a show IP OSPF neighbor and now we do see, I'm be very careful
about this
command.
And I see that we have these two adjacencies established.
It does not specify the VRF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It does not specify the VRF.
So we just happen to not be getting any routes from router 13.
And that's fine in this situation.
We're not actually advertising anything.
It's what it comes down to.
So what's the takeaway here?
Well, what we need to keep in mind is that when we establish different layer
three domains
with using VRFs, it changes the way our configurations work.
We have to not only create the VRF, we have to place it onto interfaces at WIPE
's IP address.
I have to put the IP address back in there. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I have to put the IP address back in there.
I can now have that IP address on different interfaces on the same device so
long as those
interfaces are in different VRFs.
Every layer three interface, whether that's a sub interface, a physical
interface, a VLAN
interface belongs to a VRF.
And by default, it's part of the default VRF.
So when we run commands like ping and show IP route and trace route and all of
these,
we're going to assume the default VRF.
And so as soon as I start using VRFs, I have to start specifying which VRF I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so as soon as I start using VRFs, I have to start specifying which VRF I
want to run
those commands in.
So again, VRFs carve our layer three device up into multiple layer three
domains, and
it changes the way that I have to use the commands because now I have to think
about
which layer three domain I want to operate in.