- [Narrator] In this lab, you're going to be troubleshooting
an OSPF topology.
We've got three routers, we've got a couple of areas,
you see that router, R two, that's our ABR.
And currently none of our routers
are learning any OSPF routes.
So your challenge is to visit each of these routers,
take a look at the existing OSPF configuration,
and make any corrections necessary so
that each router has full visibility
to all the different networks.
And at this point, you might want to pause the video.
And if you've not already done so,
you want to upload the YAML file for OSPF troubleshooting,
into your copy of Cisco Modeling labs
or into Cisco Modeling labs available
on the Cisco DevNet Sandbox.
Once you get that up and going,
then you can go to each of these three routers
and troubleshoot the configuration.
Then you can resume the video
and we'll walk through the solution together.
(upbeat music)
Let's take a look at the configuration,
for each of our routers.
Let's verify first of all that we don't have any knowledge
of routes learned via OSPF.
I'll do a show IP route.
And it looks like we've not learned anything
from any routing protocol.
Let's do a show IP protocols command.
Let's verify that OSPF is indeed configured.
Yes indeed, we've got OSPF process ID one.
Let's take a look at our running configuration.
In fact, let's just zoom down to the OSPF area.
Here we see that Gigabit zero slash one
is a Passive Interface.
Is that okay?
Yes.
If you take a look at the topology,
Gigabit zero slash one, it points out the switch SW one.
There's no need to send OSPF messages out of
that interface or receive OSPF messages on that interface.
Because there are no OSPF neighbors off of that interface.
We've only got one network statement, is that a problem?
Not necessarily this one network statement
is causing Gigabit zero slash one to participate
in this OSPF routing process but,
if we take a look at the other interface,
we've gone directly into that interface and said,
hey we want you to participate in OSPF process ID one
as a member of Area Zero.
So it looks like both interfaces are participating.
And if we jump over to router R two
and do a show IP protocols command,
something you might have noticed is that,
instead of saying OSPF one here it says OSPF two.
Is that a problem?
No, unlike EIGRP, this is not an Autonomous System Number.
This is a locally significant process ID,
they do not have to match between routers.
So that is okay.
And something you might have noticed on R three,
if we do a show run pipe to Section Router, OSPF,
you might have noticed that we had this network statement
that didn't really seem to specify
a specific network connected to R three.
But remember what the network statement is doing.
The network statement is saying,
here is an IP address space.
And any interface whose IP address lives
in that address space,
we want that interface to participate in OSPF.
And what that means is we want to advertise
that interface's network,
along with that interface's subnet mask.
So here, we've got a network statement
that encompasses all possible IP version four addresses.
So yes, both of our interfaces have IP addresses
that fall within this address space,
of all possible addresses.
And that's going to cause both interfaces to participate.
Those are some things you might have noticed.
Now let's see what is not correct about this configuration.
In fact, right here, I think we see a problem area.
If we look at the topology,
we see that we do indeed have an opportunity
to have a Passive Interface,
but it would be off of Gigabit zero slash two on R three.
It looks like this has been mistyped.
We have a Passive Interface off of Gigabit zero slash one.
That's going to prevent a neighborship from forming
between R two and R three.
Let's fix that.
Let's go into Router Configuration Mode,
for OSPF process ID one, and I'm going to negate,
this Passive Interface command.
And let's put in a different Passive Interface command.
I'll say, Passive hyphen Interface, Gigabit zero slash two.
And we might have an adjacency come up with router R two,
unless something else is going on,
which is totally possible.
In fact, let's take a closer look
at the entire configuration to make sure
nothing looks suspicious.
We've got Interface Gigabit zero slash one,
all that looks good.
Gigabit zero slash two, all that looks good.
Our Passive Interfaces Gigabit zero slash two,
that's looking good as well.
Let's go over to router R two.
In fact, let's see if we're in the process
of forming a neighborship.
Let's do a show IP OSPF neighbor command.
Nope, no neighbor yet.
Can I see my neighbor? Let's try that, show CDP neighbor.
I see both neighbors.
So I've got Physical Visibility or Physical Connectivity
to those neighbors. So that's good.
What else might be going on?
Let's take a look at our interfaces.
Let's do a show IP OSPF Interface Gigabit zero slash one.
And we see its network type, we see its timers.
Anything suspicious here?
I think there is, I think the default timer
for a broadcast network type is 10 seconds.
So I think we're set to a non default value here.
And also notice that we're a member of Area Zero here,
and if we look at Gigabit zero slash two,
we're a member of Area One.
So if we look at our topology, we see that,
R three's interfaces should be a member of Area One.
I think they were set to Area Zero.
I think that's another issue.
So let's fix both of those issues.
We've got a timer issue,
and we've got a mismatched area issue.
First, let's go back to R three.
And sure enough, look at this,
I'm saying that, that network statement
is putting interfaces in Area Zero
while the zero dot zero dot zero dot zero.
Well, that's fine.
The area's wrong. So let's get rid of that.
I'll say router OSPF one and on the gate,
that network statement.
Let's do a copy paste.
And let's put it in specifying Area One,
network zero dot zero dot zero dot zero
with a wildcard mask of all 255s.
This time, we'll say Area One,
and hopefully we'll have an Adjacency come up.
And while we're waiting on that to happen,
let's go over to router R two and fix
that timer issue on that interface pointing over to R one.
Back to R two.
Let's just confirm that we do have a,
non default timer configured.
And we do, it says, IP OSPF hello-interval 20.
Let's set that back to the default, which is 10 seconds.
And if I'm unsure of the default, I can say
default IP
OSPF,
hello-interval
and that should put it back to 10 seconds.
Let's see if it did.
Let's do a show IP OSPF Interface Gigabit, zero slash one.
And when we put it back to the default,
it did indeed go back to 10 seconds.
Let's see if we're trying to form any neighborships now.
Let's do a show IP OSPF neighbor command.
It looks like we're working on it.
Looks like we have formed a neighborship with R three.
And it looks like we're working on one with R one.
Let's do a show IP route.
Have I learned anything?
Yes, I have learned about the 172 dot 16
dot one dot zero network.
That's the network hanging off of R three,
going over to switch SW two.
So we've resolved that issue.
But it seems like we still don't have a connection,
with R one.
And notice the state that we seem to be stuck in,
is this EXSTART state.
Oftentimes when you see that EXSTART state,
let's see if we still have that,
we do, we're not transitioning through it,
we're kind of stuck there.
Eventually, it'll probably timeout and just say we're down.
But if we're stuck in that EXSTART state,
that often indicates an MTU mismatch.
So let's check out our MTU configuration.
For Gigabit zero slash one I can say,
show IP Interface, Gigabit zero slash one,
that'll tell me the MTU.
It says the MTU is the default of 1500 bytes.
What about R one?
What about the other end of this link?
Let's go to R one,
and we'll do a show IP Interface Gigabit zero slash two.
And it has, oh look at this.
It has a non default MTU.
And we got a hint that this is what might be going on,
by having our neighborships
stuck for a period of time in that EXSTART state.
So let's take a look at our config and what calls this.
Let's do a show run.
Let's take a look at Gigabit zero slash two.
Yeah, it looks like we've set a non default MTU.
So let's fix that.
Let's go into Interface Gigabit zero slash two.
And I can either say, IP MTU 1500,
Or I can say,
Default IP MTU.
Either one would work.
So let's set this back to the appropriate MTU value
and see if we have an Adjacency come up here in a moment.
Let's do a show IP OSPF neighbor.
And it looks like we have a neighborship.
That is great news.
In fact, let's go back over to R two
and make sure it knows about two neighbors.
Let's do a show IP OSPF neighbor command.
Great news.
We do have two neighbors.
This is R one, this is R three
and we have fully established an Adjacency.
So let's go back to where we started.
Let's go back to R one and make sure
that I have full visibility throughout the network.
I should have learned about two routes via OSPF.
I should have learned about the two zero three
dot zero dot 113 dot zero slash 30 network,
between R two and R three.
And I should have learned about the 172 dot 16
dot one dot zero slash 24 network off of R three,
going over to SW two.
Let's confirm that.
Let's do a show IP route.
Great news, we have indeed learned about those two networks.
And we see the IA code that indicates
that they live in a different area.
That's because we're currently in Area Zero,
while those two networks they live in Area One.
Now let's sum up some of the issues that we ran into.
One thing is we specified an incorrect area.
So if you have a Multi Area Network,
we need to be really careful
that we're specifying the appropriate area
as part of the network command.
Or as part of the IP OSPF command,
in Interface Configuration Mode.
We also had a non default timer
and we have to have matching timers with OSPF.
We had a Passive Interface applied
to an incorrect interface.
We hadn't applied to an interface off of which
we did want to establish a neighborship.
And finally we had a mismatched MTU.
And we were stuck in that EXSTART state
in our neighbor formation for a period of time.
And oftentimes that does indicate an MTU mismatch.
And that's a look at a troubleshooting scenario for OSPF.