The last section that we are going to have for this module is
one covering the use of the EIGRP Router-ID.
Just like other routing protocols, like OSPF,
EIGRP makes use of a Router-ID in originating and redistributing routes.
This is an important thing to keep in mind if weird
routing behavior is witnessed or reported.
Keep in mind that an EIGRP device will only accept route information that
originates from devices with router IDs different from its own.
So if a remote device is using the same router ID,
then the device will automatically drop it.
This is true for both internal and external EIGRP routes,
and the results can be a bit interesting to pinpoint.
Because of this,
we are going to move into the lab and show these results first hand.
So for this lab we're going to begin by taking a look at the lab topology again,
and in this case we're going to note that we made a
couple changes to this since the last lab.
We have added an external network that we're going to
talk about here in a few minutes,
and it's connected off of the core for the 100.100 .100 .0 /24 network.
We've removed the dual-homed link between Access2 and the distribution 2 device,
and we've removed all of the summaries from the network.
I've done this in an effort to sort of show exactly what's happening whenever
we show this weird behavior as it relates to router IDs.
So first what we're going to do is we're going to sort of
set up a situation where having a duplicate router ID can
cause some interesting results.
So we're going to go on to the distribution 1 device,
let's move to the lab, hit the distribution 1.
The first thing I'm going to do is I'm going to shut down his link to Core1.
So we're going to give him only one path that connects from him to any
of the networks that connect off of distribution 2.
So when we do that his routing table is going to show
everything going back through Core2, which,
in this case, is the 127.5 address.
And if we check at this point, without doing anything else,
from Access1 we can still get to Access129,
and it'll still go, it'll take a similar path that it did in previous labs,
the distribution 1 to Core2 to distribution 2,
and to the Access129 router, in this case.
So let's move back,
and the next thing that we're going to do is if we look at this routing table,
just keep that in mind, this sort of --- it takes the whole screen up here,
and we're going to make it so distribution 1 has a router
ID that overlaps with that of Core2.
So, in this case, the router IDs that I used were just 1.1 .1 .1 and similar,
2.2 .2 .2 from the core.
Core1 and Core2 have 1.1 .1 .1 and 2.2 .2 .2.
The distribution routers have 3.3 .3 .3 and 4.4 .4 .4,
and the access routers are 5.5 .5 .5 and through to 8.8 .8 .8.
So the Core2 router has a router-id right now of 2.2 .2 .2.
If I make the distribution 1 router have the same router-id,
and let the network do it's thing here.
There it is.
(Network doing its thing) Now you notice now the
routing table is a bit shorter isn't it,
but what routes are missing?
So if we take a look there's still a route in there for the .128 .0,
so that's the LAN network that goes off Access128.
There's still the 129 network is here.
Okay, those are there.
He has his connected links that go, this is the WANs that go from him down.
He still has a link that connects from him to this goes down.
These are the LANs on his two access routers,
--- 143,
these are the networks that are configured off of
distribution 2 and his LANs down.
What is missing?
Let's see, what's this guy?
254.
254.4.
So this is the network that goes between Core1 and the distribution 2 device.
So if we move to Core1 here's that network.
This is the one that connects the 3 to distribution 2.
There's supposed to be one other network showing here.
Well, two more actually.
One is for the Core2 router and it's connection to distribution 2,
which would be the 254.0 network, which is not here.
So what happens at this point?
Can we get to any of these networks?
Let's see if we can get from distribution 1 to there.
Let's see.
That works.
Hmm.
Can't get there.
(Loading) I can't get there.
Now the 10 network is one that connects the core routers divide to the other.
That's the only thing that the other network's used for.
I can't get to the other core device and route.
Interesting, but I can get to the other side.
Let's see.
What does the Access route do?
What routes does he see?
He still sees the --- I can still get to 128.
Let's see what it does.
Oh, whoops.
You can't get there.
You would think if I have a route here that says that I can get to
the 128 network by going to the 15.1 address,
and 15.1 is the distribution 1 router, and the 1 router,
this guy as we showed here a second ago,
can get to these guys, what's the problem?
Well, you normally check reachability and troubleshooting this way.
Well, I can get here, and you can get there, so why can't I get there?
What's the one thing that we didn't check yet?
Does the reverse path exist?
So usually on a Cisco device you pull up a good old extended ping and say,
okay, I want to go to this guy,
and once the network that connects distribution 1 to,
say, the Access1 device, that's in the 15 number.
So it would be 15.2 would be Access1, but even if we used our interface,
which would be 15.1.
So if we go, okay, I want you to repeat, but I want you, yep, to use my 15.1.
So this is on the other side of the distribution router.
Instead of having a source of this ping or trace that is on the
distribution WAN link going towards the core,
let's try it with its IP address for the distribution
WAN links that go towards the access.
Hmm. Now this seems to indicate that there's a reverse route problem.