What do you call that thing that if it's told to somebody else
it could ruin it for him?
Oh yeah, spoiler alert.
That's what this video is for IPv4
troubleshooting with EIGRP.
So in the previous video, I presented you
with a lab, a problem for both IPv4 and IPv6.
And just a moment ago, when I was recording,
I was bringing up this walk-through
for IPv4 EIGRP troubleshooting.
And I wanted to verify that R4, you know, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I wanted to verify that R4, you know,
couldn't ping the gig 0/0 interface on R7
using the optimal path.
And it worked.
And I thought, what?
It's already working?
I had launched the wrong lab.
I'd launched the lab from the video
on get to know the network as opposed
to the link for the troubleshooting lab, which
I've now launched.
So let me go ahead and remind us where we're
at with the troubleshooting.
Our goal here is IPv4.
And what we want to do is ping from R4 to this gig 0/0
interface of 10.1.7.7.
And we want it to take the optimal path, which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we want it to take the optimal path, which
is going to be this way.
We want to avoid the serial links
because they are definitely not the optimal path for that.
And I don't know why we'd be taking this link.
I guess if we had some other major problem.
But that's the goal.
So I would say the first thing we'd
want to do is verify from our R4's perspective,
can we reach that?
And is it using the right path?
That'd be a great starting point.
Let's do that right now.
All right.
So here we are on DC-NUG, the management computer.
And we've got tabs for all the devices.
Let's first of all verify, let's go to R7. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's first of all verify, let's go to R7.
And we'll do a show IP interface brief.
And there's his IP address on gig 0/0.
So I'm going to just copy that, put it in my buffer.
And then we'll go back to R4.
Let's just do a ping.
OK.
Now, that works.
Let's go ahead and verify the path with a trace.
And this says, based on the last octets
here in the IPv4 address, it's going from itself, from R4, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here in the IPv4 address, it's going from itself, from R4,
with R6 6 as the next hop, then R8, then R7.
If we look at our topology, that is not the optimal path.
So we've got a problem somewhere in the optimal path
that we need to resolve.
So let's verify from R4 that he's
got neighbors with R2 and R3.
And let's just work that direction,
verify who our neighbors are.
Go back to the--
and the funny thing is I built these labs a while ago, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and the funny thing is I built these labs a while ago,
I mean, not like weeks ago, but several hours ago I
built several of these labs with problems in them.
And I don't remember all the time
which problems I put in which labs.
So it's kind of a reminder for me to, you know,
do my valid troubleshooting skills.
Let's do a show IP EIGRP neighbors.
Let's see who we've got.
We've got R3, R6, R2.
And that looks good.
I wasn't expecting those neighborships.
But they are there.
So that's great.
And let's go over, let me do a show IP route for 10.1.7.0. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's go over, let me do a show IP route for 10.1.7.0.
Huh, OK.
So we have neighbors in place, but we're not
going the right direction.
Let's jump over in the topology to--
we have neighborships between us and R2 and R3.
Let's go over to R3.
And let's just verify the route from that perspective
because R4 is going the wrong direction.
He's not learning the network of 10.1.7 from R3. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
He's not learning the network of 10.1.7 from R3.
And he should be.
Though it doesn't appear to be the best network.
Let's go to R3.
And here on R3, if I go to the right tab.
All right.
Here on R3 we'll do a show IP EIGRP neighbors.
All right.
And I'm going to bring up my topology real quick.
So R3 says I'm a neighbor with R4, based on that last octet.
So R3 is a neighbor with R4.
But it's not a neighbor with R1, nor is it a neighbor with R5. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But it's not a neighbor with R1, nor is it a neighbor with R5.
We're missing two neighborships there.
So let's tackle the one between R3 and R5 first,
see what's going on there.
All right.
So let's see.
We'll do a show IP EIGRP interface.
And I want to make sure it's enabled.
What's the interface?
It is, it should be FA 4/1.
And I don't see OSPF-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I don't see OSPF--
I don't see EIGRP enabled on FA 4/1.
So that would be why we're not peering.
Let's do a show IP protocols.
This says it's EIGRP autonomous system 4.
Here are our K values.
They have to match if we want to be good neighbors.
Those look like the defaults to me.
We could verify that, compare it against the neighbor.
And what is our network statement? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And what is our network statement?
Oh, there it-- OK.
There's our problem right there.
So that network statement basically
says 10.0 anything is going to be included or enabled
for EIGRP.
And the interface that's going down to R5,
do a show IP interface brief, right here, is 10.1.35.
And that's why it's not being picked up.
This network statement does not include the 10.1.35.3 address
on FA 4/1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on FA 4/1.
So let's correct that.
And to do that--
oh, oh, wait.
Before I start going crazy with traditional classic EIGRP,
let's do a show IP protocols again.
And we are using named configuration mode for EIGRP.
So I will need to do it there.
So let's do a show run section router.
All right.
So I'm going to go into configuration mode. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'm going to go into configuration mode.
And I'm just going to double click on router
EIGRP our EIGRP.
That will paste it below if I right click it.
And then we want to go to address family
for IPv4 unicast AS4.
Good.
Done.
And then, OK, we have authentication.
So the authenticate-- well, it's not--
we need to enable EIGRP first before we worry about
if authentication is matching.
And then we need to--
oh, so just a network statement right here.
So we'll do a, I'm just going to copy that, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll do a, I'm just going to copy that,
and I'll say network 10 dot-- actually I'm just
going to put everything in.
It's cheating a little bit, but it's all right.
Boom, baby.
Every IPv4 interface, you're in.
And let's verify that tech with a show IP EIGRP interface.
And now we have lots.
We've got a loopback in there.
We've got FA 4/1.
And I don't see a neighborship coming up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I don't see a neighborship coming up.
You see there's a message for that.
Show IP EIGRP neighbors.
Oh, there's the neighborship, right there.
Did I miss a log message?
Huh.
OK.
I didn't see a log message.
But I do see a neighborship.
So we have a neighborship with R8.
And let me make sure I understand where that is.
OK, oh, right here.
So we have a neighborship between us and R8.
Great.
Let me get my pen out.
So between us and R8 and we had one, I think, with five. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So between us and R8 and we had one, I think, with five.
And was it 4?
Based on the last octet, let's just take a look.
We should have a neighborship with 1, 4, 5, and 8.
Those are all the people that we should
have EIGRP neighborships with.
Let's go take a look.
4, 5, OK, we're missing 1.
We're missing R1.
So to troubleshoot that, let's think about that for a moment.
We show IP EIGRP interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We show IP EIGRP interface.
So we've got the interface going to R1 is gig 1/0 right there.
Great, great, OK.
And that is enabled for EIGRP.
We have no peers.
Let's go make sure that on router 1
that EIGRP is enabled or its interface going down to R3,
which is going to be gig 2/0.
All right. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right.
So R1, show IP EIGRP interface.
Oh, OK.
Look at this guy.
He's got no, none, he's got no peers at all on any interfaces,
which is kind of suspicious.
So why would he have no peers anywhere?
He should have a peering with R2 and with R3.
He's got no peers whatsoever.
Show IP EIGRP neighbor.
It's not going to help. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's not going to help.
Nobody's there.
OK.
Let's turn on some debugging.
Let's do a debug EIGRP.
How about packets.
OK.
And we can analyze that.
Let's do an undebug all.
All right.
So I have hellos that are being seen.
Oh, right there.
Look at that, K value mismatch.
So the K values have to match in order to become neighbors.
So I would say that off this interface, received hello WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I would say that off this interface, received hello
on gig 1/0, that's coming in from R2.
And there is a K value mismatch.
So because we have no neighbors whatsoever with anybody,
I would say that probably R1 is a bit off.
Let's do a show IP protocols.
And then I'll scroll up just a little bit.
So it's metric weights are K1 is 1, K2 is 0, K3 is 1, K4 is 0,
K5 is 1.
Somebody's been mucking around with the K values.
So if we just compare those with R3, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we just compare those with R3,
we'll do a show IP protocols.
And this one is K1 is 1, 0, 1, 0.
So it's 1 and 3 are on.
And all the other bits are off.
And if we look at back at R1, he's got bits on where
the others don't.
And that would be why we're not forming neighborships.
So to solve that, again, we're using address families.
So I'm going to do a show run section OSPF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'm going to do a show run section OSPF.
Yeah, I don't think OSPF is on here.
Section router, and it will show us our routing protocols.
If we had OSPF, they'd show up as well.
But we're running EIGRP named address families.
And right here.
Look at that.
Somebody mucked up with the weights right there.
So I'm going to do a config T. And I'm
going to go into router EIGRP, or that named EIGRP.
I've got OSPF on the brain.
And I'll go into this address family. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I'll go into this address family.
And we want to have that right there, right in the address
family, the metric weights.
So I'm going to go head and do a no metric weights.
And that should just default them
back to their normal defaults for the metric weights.
I'm not seeing messages.
Oh, and look what somebody did in the address family,
no EIGRP log neighbor changes.
That's a gift. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's a gift.
I wanted to make it a little more challenging because the K
values if they don't match by default log neighbor changes
as on, and I was, like, ahh, the K values don't match.
The K values don't match.
So if we'd turned that on, it would actually show us.
So that's exactly why we're not getting any messages.
But if we do a show IP EIGRP neighbors, OK.
Now we've got a neighborship with R2 and R3.
Let's go back to R4.
And let's try that same trace again. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's try that same trace again.
And the goal is to go through 2 to 1 to 3 to 5 to 7.
That is a home run.
So here's what I recall, we had an interface
based on a network statement that wasn't in EIGRP.
And a result, you can't form a neighborship.
And then on R1, we had the K values, which were mucked up.
And that way R1 would not become a neighbor with R2 or R3
because the K values have to match up.
Also, if the autonomous system number hadn't matched,
or we have a whole laundry list, or if the authentication WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or we have a whole laundry list, or if the authentication
was off, we just keep whittling it down
until we find out what is different between the two
peers, causing then not to be able to go ahead and become
fully adjacent.
So R4 now has this path.
And that would be just fantastic.
Yeah!
Except we also have the same challenge about IPv6.
It's a different set of problems,
but it's the same result. And that
is IPv6, from R4's perspective, is
having no love taking the optimal path to get to gig 0/0 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
having no love taking the optimal path to get to gig 0/0
on R7.
So that's the same troubleshooting lab
that we had previously, in the previous video.
So what we're going to do in the next video is I'm going to walk
you through-- another spoiler alert--
I'm going to walk you through the troubleshooting exercise
for IPv6 on this same topology.
So I'll see you in that video when you're ready for it.
Meanwhile, I hope this has been informative for you.
And I'd like to thank you for viewing.