[AUDIO LOGO]
So now that we've gotten a good introduction to virtual links,
now let's jump onto the command line
and actually implement just a couple to see how they work
and to see some of the nuances of how
they work with authentication on our different platforms.
So let's start by looking at our topology,
plan out where we're going to need our virtual links,
and then jump into the command line and build them.
So once again, we are on OSPF Topology 3
so you can follow along.
And let's take a look at the places
where we're going to have to deal with some issues.
So first and foremost, we, of course,
have an area 0 up here on router 10
as well as I guess what we'll call our main area 0 down here
on the bottom left.
So clearly, we're going to need a virtual link between router
10 and router 6 in order to join these two areas together.
So we'll definitely be building a virtual link
between R6 and R10.
Then we have another area 0 over here on the right.
This is going to require a virtual link between router
3 and router 4, going through area 100,
so we'll have to build a virtual link here as well.
And, finally, we have an area of 1000
up here, which doesn't join area 0 at all.
Router 2 is only connected to area 1000 and area 100.
Therefore, again, we're going to need a virtual link between R2
and R1.
So this is what we're going to have to build.
Let's go ahead and start up here in area 200 building
that virtual link between R6 and R10.
So let's begin here on router 6 there is a loopback
interface, loopback 100 on router 10,
that we should really be seeing here on router 6.
However, if we do a show ip route ospf,
we actually don't have that route in our routing table.
It's supposed to be a 100.1.1.0/24.
However, if we look in our database
specifically for that 100.1.1.0, what we see
is that we actually have the entry.
In fact, by all arguments, it actually
looks like a normal entry.
However, if we look at the internal information
on this, what we see is that it's missing the routing bit.
Now in older code, Cisco actually
called this the routing bit.
In newer code, it's going to refer to this
as the route reference count.
Now we can see this if we look at another network that
is actually valid.
So, for example, let's look at 10.2.2.2.
This would be a valid entry.
And notice this line right here where
it says that it's in the topology base
with the multitopology identifier of 0,
meaning the main OSPF table with a route reference count of 1.
This is the equivalent of the routing bit,
meaning this route is being entered into the routing table.
Our entry doesn't look like that because we need a virtual link.
So let's go ahead and build it.
So we simply go into configuration mode.
We're going to router ospf 1.
We'll say area 200 virtual-link, and this would be going
to 10.10.10.10, which is router 10's router ID.
Notice that, right away, it's telling us
that it does not have a valid authentication
key for the virtual link.
This is because it knows that OSPF authentication is enabled
for area 0, but we don't have a key
to use on this virtual link which
is, of course, part of area 0.
But before we fix this, let's go configure router 10 first just
to see what happens.
Now up here, on router 10, we have a slightly different
situation going on.
Here, it's yelling that it's receiving an invalid packet.
And the whole reason for this, of course,
is we've only configured one side of the virtual link.
It's sending area 0 hellos to us,
and we're very confused because that interface is not
in area 0.
So once we finish the virtual link, this will be fine.
So let's go into configuration mode, router ospf
1, area 200 virtual-link to 10.6.6.6.
Notice that, once again, it yells at us
that there's no valid authentication
key for that interface virtual link.
Well, interestingly enough, notice down here,
it says that virtual link, in fact, just came up.
It just went from loading to full.
So that's an interesting contradiction.
Let's find out if it's actually working or not.
Let's go back over to router 6 and do our check again.
By our check, I simply mean looking at the routing table.
Notice that here is the 100.1.1.0/24 in the routing
table.
So it actually is up and working.
If we do a show ip ospf virtual-link,
notice this incredibly dangerous message here at the bottom--
cryptographic authentication is enabled.
No key configured, using default key id 0.
I don't know about you, but this doesn't seem like the best idea
to me.
We have forced both sides to use area 0 authentication.
The virtual link doesn't have a key set on it
so it just exchanges the default key 0.
Now rumor has it that default key 0 is actually
a key string of Cisco.
I've never cared enough to do any sort of packet capturing
to try to figure that out or anything.
It doesn't really matter what the key is for key 0--
what the key string is.
Fact of the matter is it's not the password
that we want to be using, so this should never
be left this way.
It's just interesting that it will go ahead and use
this default key 0 and actually bring the virtual link up,
and it's fully functional.
Now, of course, we're not going to leave it like this.
We're going to go put the key on it like it's supposed to be.
So let's do that.
All we have to do is go back into configuration.
We'll go back up to our virtual-link command,
add authentication message-digest,
and then message-digest-key 1 md5 Cisco_PASS.
We simply put it on one big long line,
and we go do the same thing on router 10.
Once this is configured on both sides,
if we look at the virtual link again,
now not only is the cryptographic authentication
enabled, but now it's actually using the youngest
key, which is key ID 1.
This is how it should be configured.
Let's go see what happens if we do pretty much the same thing
between routers 3 and 4.
Let's start on router 3.
So let's go into configuration mode for router OSPF 1.
This is going to be for area 100.
And we'll set up a virtual link again.
This is going to go to 10.4.4.4, which is router 4's router ID.
Commit the changes.
And we'll do the same thing on router 4.
Once again, router 4 is complaining
about getting those OSPF hellos with an area 0 in them,
but it'll be fine once we go ahead and configure this.
Here, we see the virtual link did, in fact, just come up.
So let's do a show ip ospf virtual-link,
but notice that on IOS XR, it brought the link up.
It's working.
In fact, again, if we want to prove this,
we could go over to, say, a router away from this
environment-- let's just say router 7--
do a show ip route ospf, and let's look specifically
for router 5's loopback.
We see right here that we have router 5's loopback, which
would have been in a discontiguous area 0.
So the fact that this is here indicates
that our virtual link is working,
but there's no authentication.
Let's go back over to router 4 again.
Notice there is no authentication
on this virtual link at all.
So on IOS XR, it actually brought it up
without authentication.
That's, of course, not what we want,
so let's configure the authentication here.
So, basically, we go back into the area,
back into the virtual link.
Here's where we configure the authentication.
First thing we do is turn on message-digest,
and then we set up the key.
Commit the changes, and we have to do the same thing on router
3, of course.
If we look at our virtual link again, notice now,
message digest authentication is enabled,
and it's using the youngest key ID of it.
It also says it's in the process of a rollover
because one neighbor is using the old key
but there is no other key.
We just configured one, so it's not actually
going to do a rollover.
So just to wrap up, we need one more virtual link
between R1 and R2.
However, this is going to be exactly the same
as the other virtual links we built.
So we'll just go ahead and copy and paste that configuration.
So on router 1, we'll paste in the configuration for the link
to router 2.
Of course, we're including the authentication here.
On router 2, we will do the same.
We see that the virtual link went from loading to full.
We can verify with a show ip ospf virtual.
We see that it is, in fact, up.
We also see some of those other things
that we talked about during our virtual link overview.
We see that it's being run as a demand circuit,
that DoNotAge is allowed, and we see down here,
under the Adjacency State, that the hellos are suppressed.
And as one final check, let's jump over to router 7.
Let's do a show ip route here.
And what we should see is all of the loopbacks
from all of the routers.
So here we see router 1, 2, 3, 4, 5, 6--
of course, we're on router 7--
8, 9, and 10.
We also see that 100.1.1.0/24 coming from the area 0 up
on router 10.
So this indicates that all of our virtual links
are up and running, working, and now we
know they're also properly authenticated.
So in this video, we jumped in and we
saw how to configure virtual links in a, well, very bad OSPF
design.
We just have 10 routers here, and we
needed three virtual links.
So this is definitely not an example
of how we should be building our OSPF environments.
Please understand this was just done
so we could have a good place to demonstrate our virtual links.
I hope this has been informative for you,
and I'd like to thank you for viewing.