- In this video, we're going to troubleshoot an EIGRP topology
that we see here on screen.
The symptom is every router has been configured for EIGRP.
In fact we've even got authentication configured
between R1 and R2,
but things don't seem to be working correctly.
Specifically, we don't have any EIGRP neighborships
that have been formed
and we have (indistinct) any routes from any other routers.
Now, your challenge is to import the Yammel file
that goes along with this EIGRP troubleshooting lab.
You're going to import that specifically into your copy
of Cisco Modeling Labs
or the Cisco Modeling Labs available for free
out of the Cisco DevNet site.
And you're going to attempt
to resolve that troubleshooting issue.
So for now go ahead and download the zip file,
extract the Yammel file from that,
import that into CML
and see if you can get these routers speaking EIGRP
to have full awareness
about all the networks in this topology.
Go ahead and pause the video.
And when you're done resume the video
and we'll walk through the solution together.
(upbeat music)
All right,
let's walk through the troubleshooting solution together.
First of all
let's confirm that the reported symptom is really happening.
Let's see if we can reproduce it.
Let's do a show IP route.
Have I learned any routes from any source?
No, I haven't.
Have I formed any neighborships
with the EIGRP?
Let's say show IP EIGRP neighbors.
Nope, but we see that I do have an autonomous system
of one configured for EIGRP.
So let's take a look at this configuration.
Let's do a show run
and I'll pipe that to the section of router EIGRP.
And we'll take a look at that.
And one thing that might seem a bit concerning
is that network statement.
If you were going through this lab
and notice that network statement
and thought that that did not match up
with any of our interfaces,
that network statement is actually fine as is.
Here's the reason.
Remember the network statement
is not saying, "Advertise this network."
The network statement is saying,
"Here is an IP address space."
And if we have an interface that is up
and its IP address is in this address space
then we want that interface to participate in EIGRP.
And by that we mean,
we want to advertise that interface's network
including that interface's subnet mask.
So just because this network statement does not directly map
to one of the networks connected to R1,
if you take a look at it,
you'll notice that it encompasses both networks.
We've got an eight bit subnet mass.
We're saying that any network
that begins with 192
is going to fall under this IP address base,
and that includes both of our interfaces on R1.
So that is actually valid.
Now let's take a look at the interface
going over to R2 to see what might be going on.
And then we'll go to R2 and compare things on that side.
Let's do a show IP interface, gigabit zero slash two.
That's pointing over to R2.
I'll just let you peruse this output a bit
noticing that our MTU is the default of 1500 bytes.
We see the subnet mask is a slash 30
and we see the IP address assigned to this interface.
All that seems to match up with our topology.
So that's good.
Let's go to R2 and check things out.
On router R2, let's do a show run
pipe to section router EIGRP.
And here the network statements do directly match up
with our interfaces.
And that's a common way of doing it
but as we saw back on R1, it doesn't have to be that way.
So these networks statements look fine.
And let's take a look at that interface
pointing back over to R1.
Let's do a show, IP interface, gigabit zero slash one.
Let's see if anything jumps out from this configuration.
I'm checking to make sure that the subnet mask matches
and it does.
I'm checking to make sure that the MTU matches and it does.
However, does the MTU have to match with the EIGRP?
It does not.
That's a requirement with OSPF,
but that would not have to match with EIGRP.
Let's take a deeper look at our configuration.
Let's do a show IP EIGRP interfaces detail command.
I'm noticing that we have default timers.
The hello interval is five seconds.
The whole time is 15 seconds.
And that's true for both of our interfaces.
Let's go check out R1.
Let's make sure those timers match up.
We'll do a show IP EIGRP interfaces
detail command here,
and the timers do match up.
However, do they need to?
That's something very interesting about EIGRP.
The interface timers do not have to match.
Let's jump over to R3 really quick.
You might have noticed on R3
by new a show, IP EIGRP interface's detailed command,
you might've noticed
we have a non-default hello-interval the whole time.
However, that's okay.
With OSPF those timers need to match.
They do not have to match with the EIGRP.
Because with EIGRP, this whole time
is not how long I'm waiting to hear a hello packet
from my neighbor,
it's how long we tell the neighbor
to wait to receive a hello packet from us.
So as long as this is three times our hello-interval
things should work just fine.
So even though we might have a mismatched MTU,
even though we might have a mismatched set of timers
with EIGRP, that is totally okay.
However, I did notice something in passing
I didn't point it out.
I wanted to see if you caught it.
I noticed when we were over on R2,
and I gave the command show run
popped a section router EIGRP.
Did you notice the autonomous system is 100?
Now with OSPF,
this is not an autonomous system number.
With OSPF,
that's a locally significant process ID.
But with EIGRP
that's an autonomous system number that must match
on our neighbors.
So that's wrong.
We need to fix that.
Let's go ahead and fix that right now.
I'll say no router EIGRP 100.
And then I'll say router EIGRP autonomous system one.
And I'll just copy and paste those networks statements
because they looked fine.
We'll put those networks statements back in there.
And let's see if we have an adjacency now.
Let's do a show IP EIGRP neighbors command.
Oh, great news.
I do know about one neighbor.
I know about R3.
Remember R3 had the higher timers.
Notice that instead of counting from 15 down to 10
and then resetting,
we're counting from 30.
So if I were to give this command repeatedly
we would see it bounce back
to about 29 or 30 seconds
because of our whole time.
But we still don't have a neighborship with R1.
Something is still going on.
So let's take a look
at the running config of that interface.
Let's do a show run
and let's look at interface gigabit zero slash one.
Let's take a look, here it is.
Do you notice anything odd about this interface?
Oh, we're configured for authentication.
And I think I mentioned that earlier.
We're configured for authentication between R1 and R2.
So let's make sure things match up there.
I'll just show you the config
and see if you spot any differences.
We are referencing a key chain named key one.
By the way, the key chain name is locally significant
that it does not have to match,
only the key string
and the authentication mode have to match.
So I've got an authentication mode
for EIGRP autonomous system one.
We're using MD5 and the key chain is named key one.
All right, let's take a look at that key chain.
Here is the key chain in key one.
We only have one key
and I started it at the beginning of 2020,
and it goes forever
to make sure that this key should be active
and you see the key string.
So take a look at that.
And then let's compare that configuration with R1.
On R1, let's do a show run command,
and we'll check out interface gigabit zero slash two
this time.
And we see that this is configured
for MD5 for EIGRP autonomous system one.
And I did use the same key chain name.
Let's take a look at that key chain.
Here it is.
Again, I set the accept and sin lifetimes
to begin at the beginning of 2020, going forever.
Do you notice anything that's inconsistent
with the configuration we saw on R2?
This is a bit of a tricky one.
Let me bounce back and forth.
Here's the key chain for R1.
Here's the key chain for R2.
Did you notice that the odd way we spelled Cisco
on R2, we had a capital O.
However, on R1, we had a zero, not an O.
So let's make the key strings match.
Let's go back to R2
and let's say key chain, key one.
And then we've got a key numbered one.
And I'm going to set the key string
to Cisco spelled capital C
and then the number one lower case SC and not a capital O
but a zero that should make things match up.
Let's see if we form a neighborship now, after we did that.
And by the way
we can verify the key chain by doing a show key chain
and giving the name of the key chain, which is key one.
And we can see that this key is valid now
for both accepting and sending.
And it's C-1-s-c-0.
Let's go check out R1.
Let's do a show key chain key one C-1-s-c-0.
And that looks good.
Let's see if we formed a neighborship with R2.
Let's do a show IP EIGRP neighbors command.
Great news, we have formed a neighborship with R2.
Let's go over to R2
and make sure that we're neighbors with both R1 and R3.
I think we may be fixed now.
We'll go to R2,
and I'll do a show IP EIGRP neighbors command.
Awesome.
I have a neighborship formed with both R1 and R2.
And I'm going to go over to R1
to make sure I've learned all the networks.
Let's do a show IP route
and a code of D tells me that I've learned a route
via EIGRP, and I have learned two networks.
I have learned the 203.0.113.0/30 network.
That's between R2 and R3.
And I've learned the 172.16.1.0 network
with a 24 bit subnet mask.
So I think we have met the criteria for this lab.
We went in and we took a look at our configurations
and we noticed what wasn't matching up.
Specifically, we had a mismatched autonomous system number
present on router R2.
We fixed that.
We also had a mismatched key string.
We had to look really closely,
it was tricky.
In one case we had the capital letter O
and the other case we had a zero, which looked very similar.
And once we made those match up,
then everything started working.
And we noticed some things that might look suspicious
but were actually fine.
And we didn't have any MTU mismatches
but remember if we did, that would still be okay.
We do have to have matching network addresses
and subnet masks,
but we saw that our timers did not have to match
that link between R2 and R3.
The interfaces on that link,
they had different timers and that was totally fine.
We also saw that the network statement
didn't have to explicitly match an interface's network
because that network statement
was just specifying an IP address base.
And if we had an interface
whose IP address falls within that address space
and that interface is up
then that interface is going to participate in EIGRP,
meaning that we're going to be advertising
that interface's network
along with that interface's subnet mask.
And that was a look at an EIGRP troubleshooting scenario.