- [Instructor] In our previous video,
we saw that EIGRP is going to select the best route
to get to a destination network
based on metric if it has more than one route
that will get us there.
And that preferred route is called the successor route.
And hopefully, we'll have a backup path,
so if our successor route goes down,
we can go over this feasible successor route,
and we can fail over to that route almost immediately
within like a couple of seconds or so,
which is one of the big advantages of EIGRP,
that fast convergence.
However, in order for a backup path to be qualified
as a feasible successor path or a feasible successor route,
it has to meet one condition, and that condition
is called the EIGRP feasibility condition.
Here it is, and I'm going to go through this definition,
the formal definition with you.
And then we're going to take a look at an example.
And here's the way it reads.
"An EIGRP route is a feasible successor route,"
now let's pause right there.
A feasible successor route, that's a backup route
that we can fail over to almost immediately.
So again, "An EIGRP route
is a feasible successor route if," and only if,
"the Reported Distance from that neighbor,"
in other words, that neighbor's distance
to the network we're interested in,
this route is only going to be a feasible successor route
if that reported distance from the neighbor
is less than our preferred route's total distance.
In other words, the Feasible Distance
of our successor route.
And I'm going to show you a topology
where we will work through this condition
three different times.
But first, let me explain why we have this condition
in the first place.
EIGRP does not have the luxury that OSPF has.
OSPF has the luxury of having a map,
a topology of the entire network.
And it knows how routers are interconnected.
EIGRP does not know that.
EIGRP is an advanced distance vector routing protocol.
It knows about its neighbors,
but it doesn't know about any specific routers
beyond those neighbors.
So here's something that could happen.
Let's say that R1 one wants to get
to the 10.1.1.0/24 network.
And we'll say that the successor route,
the preferred path is via R2.
But if R2 goes down, great news,
we've got a feasible successor path via R3.
So we'll take R3 next.
What if R3 also goes down?
Well, R4 has reported
that it knows how to get to this network of 10.1.1.0/24,
but look at the logic here.
If R2 and R3 are down, can R4 get us there?
No, because R4 was dependent upon R3 being there.
And if R3's down, R4 can no longer get us
to this destination network.
So we don't want to say, "Yeah, I've got this backup path
that I can switch over to almost immediately,"
if we have reason to suspect that that backup path
might be relying on one of our other paths.
And this feasibility condition
can help detect when this kind of thing is happening.
However, it's not perfect.
Let me give you an example of when it's not perfect.
In other words, the feasibility condition
can actually reject a route
as being a feasible successor route,
even though it's a perfectly valid backup path.
Let me show you an example.
Again, let's say that R1 wants to get
to the 10.1.1.0/24 network,
and it's got three ways of getting there.
It could get there via R2, R3, or R4.
Those routers all go into R5,
and that goes out to the destination network.
And we can look at this
because we're kind of like OSPF here.
We can see the map of the network.
We can look at this and say,
"No, R2 is not dependent on R3 or R4,
and R3's not dependent on R2 or R4.
And R4 is not dependent on R2 or R3.
So it looks like these should all be valid routes.
Sure, we'll go with the route
that has the lowest feasible distance,
but it sure looks like these othe routes
would make great feasible successors."
But let's see how the math works out.
You see the metric or the distance
of each link I put on screen for you.
Let's take a look at this table R1 is building,
R1 is getting a report from its neighbor R2
that R2 is 6,000 away from this network.
We've got a distance of 5,000 to get from R2 to R5.
And then R5 has a distance of 1,000
to go out of that interface
and get to that destination network.
So 5,000 plus 1,000, 6,000,
and R2 reports that to R1.
That's it's reported distance.
What's the cost for R1 to get to R2?
10,000, it looks like we're going
over a fairly slow serial link.
So let's add those up.
What is 10,000?
My distance to R2 plus R2's reported distance
of 6,000, 10,000 plus 6,000 is 16,000.
Okay, what about R3?
R3 is reporting a distance of 11,000, 10,000 plus 1000.
What is the distance for us to get to R3? 7,000.
What is 7,000 plus 11,000? 18,000.
And finally, R4.
R4 is reporting to us it can get to this destination network
with a distance of 18,000,
which is 17,000 to get to R5 and then another thousand
to go out of R5.
What is our cost to get to R4 though?
It's 4,000.
What is 4,000 plus 18,000?
It's a whopping 22,000.
Now let's see which route is our preferred route.
Who's our successor route?
Well, it's going to be the route
that has the lowest feasible distance,
which in this case is the route via R2.
So that's our successor route.
And in some cases where we have multiple ways
of getting to a destination network,
we could have multiple feasible successors.
But before a route can be deemed a feasible successor,
it's got to pass that feasibility condition,
which said in order you to be a feasible successor,
one of those backup routes
that I can almost immediately fail over to,
in order for you to qualify as a feasible successor,
you've got to meet this feasibility condition.
So let's consider R3.
The condition says in order for R3
to be a feasible successor,
then it's reported distance, which is 11,000,
that has to be less than the feasible distance
of my preferred path, which is via R2.
My feasible distance of my successor route is 16,000.
So let's ask the question.
Is R3's reported distance of 11,000
less than R1's successor route's feasible distance
of 16,000?
Yes, 11,000 is less than 16,000.
So the path via R3 qualifies
as a feasible successor route,
a route that we can almost immediately fail over to
if R2 goes down.
What about R4?
R4 reported to us a distance of 18,000.
Is 18,000 less than the feasible distance
of our successor route?
In other words, is 18,000 less than 16,000?
No, it's not.
So even though we could look at this topology and say,
sure, R4 would make a great backup
if everybody else goes down, EIGRP's not convinced.
And it's going to disallow R4 from being a feasible successor.
It has failed the feasibility condition.
And at this point, you might be asking,
"You mean, R4 is never going to be used,
even if we lose R2 and R3?
It's a perfectly valid path to get to this network."
Well, it will be used,
but it did not qualify as a feasible successor.
It's not one of those backup paths
that we can fail over to in a couple of seconds.
Instead, we're going to have to go through a process
of vetting if you will, router R4,
of seeing if it is a way
for us to get to this destination network.
And that vetting is going to be done
through EIGRP's query process.
And we're going to check out that query process
in our next video.