In our previous video, we saw that
in order for a backup route in EIGRP to be
one of those routes that we fail over to
really, really quickly,
it had to qualify as a feasible successor route,
and sometimes, a perfectly valid alternate path
does not qualify as a feasible successor route
as we saw.
But what happens then?
That's what we're going to talk about in this video.
In this example, let's say that R1 loses connectivity
with the 192.168.1.0/24 network.
Maybe something happens to that switch
for whatever reason, R1 can no longer get to that network
to which it was directly attached.
So it sends out this query
that goes throughout the network saying,
"Can anybody get me to 192.168.1.0/24?"
R1 is going to send a query down to R2,
R2 says, "I don't know how to get there,
but let me ask my other neighbors."
And R2 will send out queries to R3 and R4.
They don't know how to get there,
so they send out queries to their neighbors,
R5, R6, R7, and R8.
Nobody knows how to get there.
So what happens?
Well, the last router that has no more
neighbors downstream,
those last routers, routers R5,
R6, R7, R8,
they're going to send up replies
saying, "Sorry, I don't know how to
get to that network."
And those replies go to routers R3 and R4,
and they forward the replies up to R2,
and the sad news is relayed up to router R1,
and it realizes it has no way to get to this
destination network.
However, if there were an alternate path,
the reply would've come back and said, "Yes,
I know how to get there!"
In fact, in our previous video, remember R4?
It was a perfectly valid path, it just didn't
meet the feasibility condition.
In that case, R4 would've been able to reply
and say "Yes, I know how to get there."
But here, there is not an alternate path
to get to 192.168.1.0/24.
Now, this query process can give us some issues.
Now this used to be a much bigger problem
years ago than it is today.
One reason is because iOS handled it
a bit differently years ago,
and we had slower routers, slower router processors,
and sometimes the routers simply would not have
time to process one of these replies.
And this could lead to a condition that I want you
to know about; it's called SIA or Stuck In Active.
Let's go through the scenario again.
That same network goes down. R1 sends out a call saying,
"Does anybody know how to get to this network?"
The query goes down to R2, R2 sends the queries to
R3 and R4, and they send the queries
down to their neighbors. Again, they say,
"We don't know how to get there,"
and they reply.
But this time, when R3 replies to R2,
that works, but when R4 is trying to reply
to R2, the packet gets dropped.
I mean, after all, on a congested network,
it's possible for that to happen.
So what would R2 do?
It would set a three-minute timer
and say, "I'll give you three minutes
to send me your reply. I haven't heard anything."
And remember, R1 is also waiting for a reply from R2,
so R1, it also has a three-minute timer set.
And the sad news is, R4 has no idea that
that packet got dropped.
So it's not going to send another reply packet.
Tick tock, three minutes go away,
and R2 says, "I don't think R4 is available any longer,
so I'm going to prune it off. And all those networks
available off of R4, I'm going to delete them
from my routing table."
So R2 just lost a big portion of the network
in its routing table.
And since R4 didn't get all of its replies,
it didn't reply to R1, and R1 says,
"I didn't get a reply from R2,
I think it must no longer be available."
And it's going to prune off all the networks
that it connected to the R2.
So R1 just lost connectivity with the rest of the network.
Again, that was an issue primarily years ago,
and that was called an SIA, a Stuck In Active condition
because R2 and R1, they went active for this route
that they were looking for,
and they never got a reply so they were stuck
in that active state.
And after the time-out of three minutes happened,
we would start losing big chunks of the network
from our routing table.
But in more recent versions of Cisco iOS,
that has been addressed.
Let me show you how things work now. Let's go through
the same scenario. We lose the same network,
we send out the same series of queries
to all the neighbors,
they don't know how to get there,
so they're going to start replying with their replies,
again, we're going to drop the packet from R4 going to R2,
what happens now?
Well, we set that three-minute timer
on both R2 and R1,
but here in newer version of Cisco iOS,
we don't wait for those three minutes to elapse
and just assume our neighbor is unavailable.
Instead, we wait for half that time.
We wait for ninety seconds.
After ninety seconds has elapsed on both R1 and R2,
we wonder if our neighbor did not respond to us
because they're not there any longer,
or maybe they haven't heard a response themselves
or maybe the packet got dropped.
So we're going to send out a query to our neighbor.
Now, in this instance, both R1 and R2, they're both
stuck in this active state,
so R1 and R2 will simultaneously send out
this Stuck In Active query to their neighbors.
R1 says to R2, "Are you there any longer?
I haven't heard back from you and
I wasn't sure if you're still there,
or maybe you sent the reply and I just didn't get it,
or maybe you didn't send a reply because
you're waiting on a reply yourself."
And R2 says to R4, "I sent you a query
and I've not heard a reply, what's up?
Are you there? Did you send the reply and I didn't get it?
Or did I not get it because you're
waiting on a reply yourself?"
Well, in response to these Stuck In Active queries,
R2 is going to tell R1, "Yeah, I'm just waiting
for a reply myself. That's the reason you haven't
heard from me, but I'm still here,
don't prune me off."
And R4 says to R2, "I could've sworn I sent you a reply!
Oh, here it is again. It's not because I'm down."
So that's going to cause R4 to resend the reply
and let R2 know that it's still there,
R2's going to let R1 know that it's still there,
and we didn't prune any networks off.
That's the way that this query process works today,
but for historical and for certification purposes,
I did want you to know about that condition called
Stuck In Active.
And that's a look at how EIGRP can query for a network
that it doesn't know how to reach
if it doesn't have a feasible successor route
that it can fail over to almost immediately.