Okay, so now I want to move into the lab a little bit, but first I want to touch
on what the new lab topology is going to be going forward.
As you can see in the slide,
we have eight different devices that are laid out in a hierarchical fashion.
For the moment, all of these devices will be part of the same area.
Okay,
so now I want to move into the lab for a minute, but first
I want to take a look at the lab topology that we are going
to be using moving forward.
As you can see in the slide,
we have eight devices that are connected together in a hierarchical fashion.
Currently,
all of these devices are configured into a single Area 0, or backbone area.
For the purposes of this lab,
we are only going to be paying attention to a few of the links between
Core1 and Core2 to show how adjusting the different parameters so that they
mismatch affects the neighborship between them.
So let's move to Core1, and if we first look at just the
established neighborships, the preconfiguration I have done on this
lab is I have configured OSPF on every device,
and I have allowed all the neighborships to come up
without any special configuration.
So, in this case,
we have 2 neighbors from Core1, 1 to Core2 and 1 to Core3. But first let's take
a quick look at just the interface between Core1 and Core2.
And what we can see from this show is that this interface is connected into
Area 0, its current default network type is broadcast,
and that's because this is an Ethernet interface, and because of that,
if you remember from the table from a few slides ago,
the hello and dead intervals are set to 10 seconds and 40 seconds respectively.
Now, you can also look a little bit closer and say he's adjacent with
2.2.2.2. This 2.2.2.2 is the router ID of Core2.
And if you can also see up here,
designated 2.2.2.2 is Core2 and 1.1.1.1 Is this device. So, if we wanted to
find out what this device's OSPF router ID was, we can show it right here.
We are configured with OSPF in Process ID 10 with the router ID of 1.1.1.1.
So first what we're going to do is we're going to mismatch the hello timers
between Core1 and Core2.
Now,
while we wait for that to stop working because it's going to have to go
through the dead interval in order for it to fail, we can take a look at the
interface again and show the behavior here. By default, on Cisco devices, the
hello interval, whenever you adjust it, will automatically adjust the dead
interval to be four times it.
So whenever we adjusted the hello interval to 11 seconds,
the dead interval was automatically adjusted to 44. It also at
the moment shows that everything is currently still working, and
then as we can see from that message,
the dead timer expired on the neighborship between me and
Core2. The relationship went from a FULL to DOWN. Neighborship
states we're going to cover in more detail later on in this
course. And that neighborship, if we look at a full display here,
will have gone down.
And the only reason for that is because OSPF does require that the hello
and dead interval timers be the same between devices.
And if we had just brought this up and the neighborship
wasn't up previous to me adjusting this,
then this neighborship wouldn't have come up in the first place.
So let's go and fix that so it's not away from default, and we'll see.
This will take a second.
And there we go.
We see that this guy brought his neighborship back up
with Core2, and if we look at it, we'll have those 2 neighborships back up again.
Another thing we talked about was having a router ID conflict between
devices. Now, having a unique router ID is a requirement for a
neighborship to form, but technically, if you had another non‑unique
router ID in the whole OSPF domain, that would not make a
neighborship not be able to form, but it would cause problems with routing.
So if we had, from looking at this,
we can see that our router ID on this device is 1.1.1.1, and as
long as Core2 and Core3 were not configured with 1.1.1.1, it would
still form neighborships with them.
But this, if it was some other device on the network was configured with this on,
like on the other side of the network that wasn't directly
attached, that would make routing not work correctly.
So you want to make sure that the router ID is unique
across the whole OSPF domain. So real quick,
let's just show how this makes it fail.
So if I change the the router ID on this device to mismatch
with Core2, I adjust it, and by default,
it's going to require me to reset the OSPF process in order to make that change.
So, on a Cisco device, that's clear ip ospf process, and
it'll adjust and it'll drop everything.
Both of the neighborships went down and automatically it said, well, hold
on, I have a duplicate router ID with the other device that has this guy,
and this is his IP interface address on his side.
Now, if we look at the OSPF neighborships themselves,
I don't have a conflict with Core3; I only have a conflict with Core2.
So if we wait while these guys exchange traffic,
the neighborship between Core1 and Core3 will come up here in a minute.
The one thing you will notice, well, there it is, between
OSPF and the IGRP is the neighborships in OSPF usually take
a little bit longer to form.
So now, let's see here, we saw that neighborship come up, so we show that one,
but it's never going to move forward on this neighborship between Core1 and
Core2 because these 2 have the same router ID. You see,
it keeps trying, and it'll keep coming up with these messages
repeatedly if you sit here and wait for it, but this can't be a
duplicate between direct neighbors. (Typing) If we reset it out
again, alter it, that went down,
neighbor, let's see, this is the Core1 to Core2. These already come up.
Give it a second between Core1 and Core3 will come up, and they're happy.
So, what's next?
We want to look at subnets.
That's the next one I had on my list.
As I noted with IPv4, it is required that each one of the
devices be in the same IPv4 subnet or they won't be able to
communicate with each other.
This is just sort of basic IPv4 networking stuff, but it's a little bit unique.
You have to know that because with IPv6, it's not the same.
Since IPv6 versions of OSPF use the link local addresses,
which is a concept that exists in IPv4, but is not commonly
used, for this purpose, IPv6 uses the link local addresses and
they're always unique to that device.
So, having a conflict in the global IPv6 subnet is not going to cause
the same problems as if you had the same type of duplicate, or, sorry,
an incorrect subnet on an IPv4 network. So,
we saw that that neighborship came up.
So, we take a quick look here and we'll show that my subnets, similar to
the last lab, I just used a whole bunch of 252s or /30s.
So if I wanted to just put this in a completely different subnet, let's just
put the interface and let's just change it up a little bit.
Let's say between Core1 and Core3,
which is this guy, let's make him have an IP interface
address that's not on the same network.
And as soon as we did that,
we see that the neighborship went down because just basic IPv4
networking is if you're not on the same subnet,
you're not going to be able to talk to anyone else.
So let's just real quick adjust that. And one other thing
that you may want to note here that sometimes gets people is
OSPF uses the primary address,
and sometimes you can configure with Cisco stuff, and I am sure you
could do it on other vendor's equipment, is you can configure a
secondary address on an interface so that 1 interface has multiple IPv4
addresses. And that can make your life a little confusing because since
there's a secondary address there, I can ping from Core1 to Core3.
So, obviously, there is a traffic path between Core1 and Core3 because the
secondary address here configured is in the same subnet.
However,
with IPv4, we use, or, the OSPF process will use only the primarily
configured IPv4 address for communications for OSPF.
So even though I have an address here that would work,
the OSPF process is only going to grab this primary IPv4 address and
try to constantly send all my traffic only from this IPv4 address, so
this type of configuration will not work.
So, if we adjust this again,
take that secondary off, and make it the primary,
see that neighborship forms again.
And the last thing that I wanted to cover is referencing authentication.
It may seem sort of obvious,
but if you have one site configured with authentication with one key and
you have authentication configured on the other side with a different
key, obviously if you have the wrong key,
it's not going to be able to open the lock, and the
same concept is true with OSPF.
So if I configure Core1 to have authentication configured, so I have the OSPF
authentication (mumbling), you don't really need to learn that configuration
because this isn't a configuration‑centric course, but these 2 commands are
used to enable authentication between Core1 and Core2, in this case. See,
we're using simple password authentication that does support other modes, but
in this case, it's just a clear text authentication password between the two.
And you will see here in a second whenever the dead interval expires again,
these two devices are still trying to communicate.
But since there is an authentication mismatch,
I'm not going to be able to see,
or it's not going to pay attention to any traffic
that's not authenticated on that side.
So if I turn on a couple debugs here,
you'll see that the process itself will say,
I'm trying to, I received a packet from 10.10.10.2, which is Core2,
but the authentication type was wrong, it's mismatched. And this is
just other traffic, so this would be I was trying to send out traffic
and I received traffic in, it was mismatched. So, basically, it's only,
it's going to see it coming in, but it's just going to say,
well, okay, your authentication doesn't match,
so it's just going to ignore it.
The rest of this authentication equals 0.
This is the traffic from Core1 to Core3,
where there was no authentication configured,
so it works just fine.
Turn off all these debugs so it's not cluttering the screen, and
you'll see that the neighborship came back up.
It was here in the mix here somewhere, And we'll take a closer look
at what this information means here a bit later.
So for the purposes of this lab, that's all I wanted to cover.
We're going to return to the lab here in a little bit.
For now,
let's move on from this section and have a conversation about OSPF network types.