Oh my gosh.
I used to know this route.
I lost it.
Can you help me?
That's not always the best scenario with EIGRP.
And here is why.
Let's imagine that this represents our headquarters
location for an organization.
Let's call it Acme, Inc. There we go.
And we have some remote sites.
I puts some serial links in here to help
represent slower connectivity.
And let's imagine that R8 is a branch, a remote branch office. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's imagine that R8 is a branch, a remote branch office.
We'll call it branch, how about, branch one.
And at corporate HQ, we probably have, like,
maybe even hundreds or thousands of routes.
And let's imagine, let's just pick one.
Let's pick the 1.1.1.1 network with a 32-bit mask
just so it's easy to find.
There happens to be a loopback on R1.
And here's what happens.
If we're running EIGRP and all of a sudden
this route goes away, the 1.1.1.1 disappears,
R1's going to start asking people about it--
not just anybody. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
not just anybody.
He's going to ask his neighbor.
So R1's going to ask his neighbor R3 and neighbor R2.
And they're going to say, oh my goodness.
Oh my goodness.
And they're going to ask their neighbors.
They'll be queries going this way.
I'm not going to draw all of them,
just give you an idea of all the queries involved.
And then the query is good on here and here and here and here
and here.
Everybody is asking, hey, hey, hey, hey,
do you know where this network 1.1.1.1 is?
Well, you know if there's another path
to 1.1.1.1, that will help the convergence process.
But I'll tell you this, this network down here--
let me put it in a different color.
Let me put it in red. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let me put it in red.
This router down here, no matter what happens,
he's not the best route to get to 1.1.1.1,
even if he thinks he knows about it.
I mean, if 1.1.1.1 is really up here in the corporate network,
we don't need to go asking R8 at the WAN site
about it, especially with the slow connectivity.
So we've got a serial link here, a serial link here,
a serial link there, which represents some very, very
slow connectivity, compared to our modern standards.
And so, unfortunately, that query does happen.
It goes through the entire network.
And that's referred to as going active for a route. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's referred to as going active for a route.
So if we do a show IP EIGRP topology,
it's going to show that the routes in that topology table,
if they're all settled, are passive, meaning,
we know where this is.
Everything is good.
In fact, let me show you.
So here on R1, we have a loopback address.
We do a show IP interface brief.
Is it in EIGRP?
We'll do a show IP EIGRP interface.
And sure enough, loopback 0 is being
advertised as part of EIGRP.
And do we have neighbors? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And do we have neighbors?
Show IP EIGRP neighbors.
And check this out, we're using named EIGRP configuration mode.
And so we can do a show EIGRP address family IPv4 neighbors.
And that would give us the same exact output.
So either way you want to slice it is great.
Do we have neighbors?
And if we did a show IPA EIGRP topology, and that's for IPv4.
And let's actually just focus on the one network of 1.1.1.1.
And right here it's showing state is passive. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And right here it's showing state is passive.
Most of these IP's up here are presented as well.
It is passive, meaning it's not actively querying
looking for that network.
And it's not only directly connected,
but it's also in the topology table.
So if we were to do something like this,
let's do a config T interface loopback 0.
And then I shut it down.
But what happens is, if I shut it down,
router one's going to go active.
This is version, like, 15.2 of IOS.
So if I do a shut it down, router one's going
to go active, asking his neighbors, hey,
do you know where 1.1.1.1 is? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
do you know where 1.1.1.1 is?
And they're going to respond.
And once they get the response and the neighbors say,
nope, we don't know how to get to it
either, then that route will be removed from the topology table
because it got its answer back.
So to see that, one way we could do that is we could do a
do show--
I'm just going to copy this right here--
EIGRP topology for that one route.
And do show IP.
OK.
So if I do EIGRP I'll have to specify address family IPv4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if I do EIGRP I'll have to specify address family IPv4.
Fair enough.
All right.
So there's our output.
And then if we do a shutdown and I hit that command again,
we can see that instead of it being passive,
it will be going active for it.
And also we could do a debug over here on R2.
Let's do a debug EIGRP packet query.
And if we have queries, they'll show up in this debug also.
Let's go back to R1 and I'll do a shut and a couple Up arrows
and that show command again.
Check that out.
You have to be fast.
EIGRP is pretty fast.
So it went active for just a moment
while it did its queries.
And then it got the answers back. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then it got the answers back.
And then said, OK, great.
And it's no longer in the topology table.
So it's gone now.
So if we take a look at R2 and we do an undebug all here.
And we look at the query message, which is right here.
I'll scroll up for it.
So here on R2 we have queries are being received.
We have queries are being sent.
We're all asking about this route.
And we looked at the details for the queries,
in fact, if we went down to R6, so let's take
a look at our topology.
If we went down to R6 and we captured the packets
on this network right here, between R6 and R8, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on this network right here, between R6 and R8,
it would be doing a query, too.
R6 would be saying, hey, where is this?
So everybody's asking about this route because it's now missing.
It was in the EIGRP topology table.
And now it's missing.
And it just so happens I have a packet capture of that.
So this is the query.
The source address here is 10.2.68.6, that's R6.
And it's an EIGRP query being sent to the multicast address
or EIGRP, which is 224.0.0.10.
And if we go down, the actual route that's being looked for
is 1.1.1.1.
So everybody's asking. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So everybody's asking.
And if we go to R6 and we look at the neighbors for R6,
we'll do a show IP EIGRP neighbors detail.
And you can use the EIGRP command with the address
families if you want.
You get the same output.
And this shows us the details that R6 has two neighbors.
One is R8, based on the IP address there.
And one is R4, based on the IP address.
That's great.
And here's the problem.
We really don't need our headquarter location sending
out queries to remote branch offices that are, like,
at the end of the world.
If we have a hub and spoke environment, with our spokes, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we have a hub and spoke environment, with our spokes,
we probably shouldn't be sending queries for HQ routes
way out to the WAN.
Because if we send out a query, and then for whatever reason
we have a WAN failure or a device failure,
and we don't get a response back,
that route will then be stuck in active
until the timeout expires.
So stuck in active is not good.
It's like router one and everyone else is, like, oh,
I need to find this.
But I'm not getting the answers I need.
So it's better to have a "no", that
nope we can't get there from here, rather than just
crickets-- because then we can be stuck in active.
So the solution to this problem is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the solution to this problem is
we can train the network that here at HQ,
if we ever lose routes that drop out of the routing table,
don't bother asking these devices.
And let's just pick on R8 as an example.
Let's imagine he's a spoke.
We might have other spokes.
Perhaps we have a DMVPN network with lots of spokes.
We have a hub or two.
We could go ahead and train the spoke routers
at the remote branches that they are stubs from an EIGRP
perspective.
And so in the next video, I will walk you
through the logic of that, how we would configure it, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
through the logic of that, how we would configure it,
and also how we can verify it.
So I'll see you in that next video in just a moment.
Meanwhile, I hope this has been informative for you.
And I'd like to thank you for viewing.