So what should be the next one?
Well, this says to get to there, let's say 128, go to 127.5.
It was 127.5.
127.5 it says is connected to my gigabit 0/2 interface,
and my 0/2 interface is connected to Core2.
So if we went to Core2.
Well, what was the network that we were trying to originate from here?
So we were trying to originate from the 15.1 because that's my LAN
link on the other side of the distribution device,
but is the 15 route in Core2's routing table?
I mean, it's big enough here, but do you see any 15?
Wouldn't it be right here?
I would be right here.
Why do you think it's doing that?
We'll take a look at this command.
This is a new command I haven't used here yet,
but maybe this'll be the one that sort of shows this the most obviously.
Events.
What events do I see here that may cause a problem for the 15 network?
Let's see here.
(Muttering) Nothing's really weird yet.
Weird, weird, weird, weird.
Oh, hold on.
Here are the two networks.
Look at this.
A 15 network, 15.0 /30,
which is the one we were talking about from the
distribution 1 router to Access1, and the 15.4,
if we would have tried,
but this is the network that goes between the distribution 1 router and Access2.
Well, what's it say?
I got the route, and I ignored it because it's a duplicate routerid.
Now what's happening here is that distribution 1 has 4 connected interfaces.
It has 2 WAN links, which are in the 127 network that connect it to the core,
and 2 WAN links that connect it to it's access devices.
Well, the WAN link that connects it to Core2,
in this case, since the link to Core1 is down,
is connected on Core2, as well as distribution 1.
They're not advertising those two to each other.
Well they are, but they're going to --- both of them are going to drop them,
and since distribution 1 is going to originate
routes to that 15 network from that, sorry,
2.2 .2 .2 routerid.
Well, the core is saying, well, I'm 2.2 .2 .2.
I didn't originate it, so I'm going to ignore it.
Now the same type of thing is going to happen on the other side.
If we look at the distribution router, well,
the link that connects the core router to distribution 2 is in the 254 network.
So if we look at events on him --- there's no real great debug that shows these,
but let's see.
More ignored routes.
Ignored, ignored, ignored.
It ignored a whole bunch of these out here.
Wait, finally.
Here we go.
Down a little bit.
Ignored route for the 254 network.
Now this is the other, no, this is the network we were originally looking for.
It's not only ignoring these, but this is the one that we're showing right now.
The distribution 1 router is ignoring the WAN link between Core2 and
distribution 2 because that originated on Core2,
who also has a routerid of 2.2 .2 .2.
So he's ignoring that route,
but he's still getting information for the other devices on
the other side of Core2 because those routes are originated
from other router IDs on that side.
So as soon as we pull this duplicate off and put him
back to his original router-id, which is 3,
and wait for the network to reconverge for a second.
(Typing) Well, in this case, we're looking for that 254.0 network,
which is now back, and a 10 network,
which is the link that goes between Core1 and Core2 is back because this would
have been another route that was advertised from Core2 to distribution 1
within an originating router ID of that duplicate,
so he wouldn't see that.
He wouldn't see this external because this originated also from Core2.
So, in this case, I can now go back to normal operations.
I can ping there, and if I go to Access1 I can ping that again.
As you would imagine, you know,
just looking at some of these earlier routing tables,
let's see here, it's not --- okay, it looks rather close to complete,
and then you'd have to do individual route matching to figure out,
okay, what routes are missing,
and trying to find that out when you're troubleshooting is a bit entertaining.
So one of the things you want to look for just sort of up front,
especially whenever you just look at something like this simple command.
Even if you don't use all the information from this you just
look at this command and see if you see this type of duplicate
thing anywhere in this to match.
You see how there's a duplicate routerid that you know that he
received some update PLV from somebody that says,
I have a duplicate update coming in from somebody that's not us,
and I'm going to ignore it, but that's going to cause you all sorts of headaches,
so keep a lookout for that.
And the second thing we're going to look at,
first we're going to --- I guess back to real-life here,
and put our network back together where I'm actually connected to Core1 as well,
and when we do this we're going to look at the external route for a second.
The external route, in this case, is the 100 network.
I redistributed it before we started here from OSPF into Core1 and Core2.
Both of them have equal cost to that external network,
and so from here to there it's the same look here.
Now the same problem occurs here for external routes.
So, as you saw before, Okay,
we happen to have a link go down between this device in Core1,
and when are you going to have a core device link go
down that that's not fixed first?
So that's in question.
Well, okay, right now the network's back in normal operating condition,
and I have two paths here.
Well, how would a duplicate router ID affect an external route,
as opposed to an internal route?
See, this is how it's supposed to look.
We're supposed to have two equal paths going to that network.
Now if we go back in here and, again, overlap with the Core2 router,
and then wait for EIGRP to reconverge and bump.
(Typing) For the sake of right this second,
we're only going to pay attention to this external.
You notice that that external route going through
Core2 is now not there anymore.
Now, okay, that's problematic right this second because,
okay, we don't have two paths there,
and the same effect as we sort of inadvertently saw whenever we
were looking at or focusing on internal routes.
If we had a problem with that, like between Core1 and distribution 1,
all of a sudden that link to some external network,
that external network could be the internet,
it could be to headquarters, it could be to a secondary main hub,
it could be to a datacenter.
If that goes down, then you're going to have considerable problems,
but as it sits right now, and I try to do a route out to the 100 network,
well I have a clear path,
so I may not notice a problem right now because I can go out here and say,
okay, I can reach, you know, I can get out to that network,
so I'm just upfront checking connectivity.
I'm good.
We have one link fail and all of the sudden everything collapses.
So if we have, okay this link between distribution 1 and Core1 goes down again,
(Typing) just ignoring the internal route problems for a second,
well that external route completely disappears.
So, in this case, we could have that one interface,
and you're going, well hold on,
it's only a link between the distribution and the core.
That's not actually, you know,
it should be able to get connectivity through the other core.
So again,
this is another thing that can cause problems if you have duplicate router IDs.
It doesn't only affect internal routes; it also affects external routes,
and that's one of those sort of weird problems whenever you're trying to
troubleshoot that you may not even think about it unless you've listened to a
course like this or you've read a book that said,
hey, make sure to look for these things because it can show up in weird ways.
Always make sure whenever you're designing a network or if you happen
to be on a network that those router IDs are unique.
Now usually if you don't manually configure them,
and some networks you don't manually configure the EIGRP router ID,
they may use the default mechanism, which is similar to OSPF,
where it'll use the loopback address or the first loopback address,
or it may use the highest IP address of an up interface,
those are the defaults that it uses,
but if you're using a wide-scale EIGRP network and you're
designing it or you're in charge of it it's probably a good
idea to configure some static router IDs,
just so it's, you know,
or purposefully configure loopback interfaces with similar networks
that you would know to use as sort of a universal IP address for a
device and not interface specific.
So, with that said, that will conclude this module,
and we're going to move on in the next module and cover EIGRP
load balancing and how it differs from the use of load balancing options in other router protocols.