So now let's get started with this next section by talking
about the EIGRP metric more specifically.
The full EIGRP metric, as can be seen from this slide,
is a monster that may make some people just tune out almost immediately.
It involves the use of K-values that are used with EIGRP to alter the
different parameters that are used to calculate the metric.
By default, K1 and K3 values are set to 1.
In effect,
this enables only the bandwidth and delay parameters
to be used to calculate the metric.
When we take this into account,
it makes the metric formula much simpler to look at.
Two things that I will cover here before we move on
to how these metrics are used.
First,
the bandwidth that is used for this metric is the minimum path bandwidth
between the current device and the destination in Kbps.
And second,
the delay is the sum of the path delay from source to
destination in 10s of microseconds.
This second part can often trip up people because most
statistics show the delay in microseconds,
not 10s of microseconds.
Now let's move back into the lab environment.
How are these metrics used practically?
Just like any distance vector protocol, advertisements are learned,
and certain ones are placed into a local database.
For EIGRP as can be shown here,
it maintains this information in a topology database.
So if we also look, and as we noted in the previous section,
only specific entries are entered from the topology
table into the routing table.
So again, if we look at this route,
the routes that are available for the 100.100 .100 .0 /24 network,
there are four entries that exist in the topology table,
but there are three entries that are going to exist in the routing table.
So let's start at the topology table and discuss how EIGRP makes the
decision as to which routes that it learns about are placed into the
topology table and then from there which routes are placed from the
topology table into the routing table.
Now note that not all entries that are learned by EIGRP are
placed into the topology table in the first place.
Only those that are considered feasible are used.
So what exactly is feasible?
Before we cover that,
we first need to cover the differences between advertised or
reported distance and feasible distance.
Let's move back to the slides for a minute.
The cost to reach R3 from R2 in this example is 10.
This is then advertised to R1.
R1 then adds the cost of the link between itself and R2 to
come up with its total metric to R3, which is 15 in this case.
The distance that is advertised to R1 is referred to as the
advertised distance or the reported distance.
And the total metric, including the additional link cost,
is referred to as the feasible distance.
So let's move back into the lab for a minute, and I'll show an example of this.
R5, if we look at the R5 EIGRP topology table,
from R5 to R6,
there is currently only one path that passes the feasibility condition,
which we'll talk about in a second and is placed into the topology table.
In this case, it is this route right here via R6.
This first number that's shown in the topology table
is what's the feasible distance.
This is the total metric to get to that destination from R5.
This second advertisement here, the second number here after the slash,
is the advertised distance.
So if we went to R6 and looked up its cost to reach
the 100.100 .100 .0 /24 network, this is its feasible distance.
And this is R6's feasible distance, and it advertising this to R5,
and then R5 will use this as its advertised distance.
Now the other thing you can look at just to get a little bit
more familiar with the topology table show,
this is the feasible distance for this specific entry.
In this case, there is only 1,
so it'll show up here the feasible distance is this.
The entry above here, if we see there are two entries available to this one,
the one with the lowest feasible distance,
lowest metric cost, in this case this one,
will get reflected up here.
So for this entry to get to this one,
it will use only this one with the lowest metric,
and its metric is 4096.
But the key point here is the difference between advertised or
reported distance and feasible distance.
The advertised cost is the cost that's received from a neighbor,
from the perspective of the neighbor.
And the feasible distance is the cost, total cost,
to reach that destination from the current device.
So let's roll back to the question here, the statement that I said earlier.
The entries are only placed into the topology table if
they meet the feasibility condition.
So what's feasibility condition?
What makes a specific entry feasible?
Well if we,
now that we know what the difference is between
advertised and feasible distance,
a specific entry is not considered feasible if the advertised distance is
equal than or more than the current best feasible distance.
Said simpler,
remote paths should have a lower cost than what the current best cost is.
If they have a higher cost than the current best cost from the current device,
then they aren't considered feasible.
This mechanism is one of the ways that EIGRP prevents loops from forming,
and it uses this on top of the split horizon feature to make
loops almost impossible whenever you use EIGRP.
Now if we move back to the lab again,
the routes that are shown on this topology table
show that we looked at previously,
these are all considered feasible from the perspective of R5.
Now we can also add one additional parameter on this called all- links,
and this will show you all of the routes that are received by this device.
So if we look at this first entry, 10.10 .10 .32,
there are two entries that are existing that are considered feasible.
But if we look at all of the advertised links,
you'll see that there are three total advertisements coming
into this device to reach that network.
There are two.
These top two are considered feasible,
and the reason they are is because the advertised distance,
so the advertised distance, the best--- Well,
let's roll back here.
The current best feasible distance is using this first path,
and the feasible distance for this is 3584.
The second entry is considered feasible and is entered into the topology table,
but at this point is not going to be placed into the routing
table because it doesn't have the best metric.
But if you notice this second value is the advertised distance to this path.
This advertised distance is less than the current feasible distance,
and because of this, this entry is considered feasible.
So it's placed in the table here and it'll be used as a
backup EIGRP should this initial path fail.
This second entry, even though it has the same feasible distance,
so the cost from R5 in this case to reach the 10.10 .10 .32 /30
network is the same from this device's perspective.
But if you look at the advertised distance,
its advertised distance to get from the advertising
neighbor to that destination is 3584,
which is equal than the current best feasible distance.
And because it's equal than or more than the current feasible distance,
this entry will not be placed into the topology table.
So if we look back up here a little bit,
we will notice that there are only two entries.
That third entry via R2 right here is not considered feasible because this
number right here is the same or greater than this number,
and that's what the feasibility condition is.
So if you're looking at this on any other network,
and you're getting confused as to why a specific route is not
being placed into the main topology table,
which would be without this all-links parameter here,
this is what you're going to be looking for.
You're going to be looking for what does this value,
how does this value here compare to this value right here?
If it's equal than or more, it will not be placed into the normal topology table,
and it will not be considered a potential backup route.
Now keep in mind that things can change.
If this route fails, then this goes away because this route's no longer possible,
then both of these routes have the same feasible distance to that destination.
And at that point, then the feasible distance becomes this value,
and these advertised distances become irrelevant because this is less than this.
And because of that, if I was to close this interface right here,
both of these routes would be entered in to the routing table.
There would be a little bit of a delay for this second route because
since this isn't considered feasible right now,
EIGRP isn't going to immediately consider it.
Immediately,
it's going to place only the entries that it knows about
that are feasible into the routing table.
So if this fails, this will immediately be placed into the routing table,
this will be learned on shortly thereafter and be
entered into the topology table, then inserted into the routing table.
There will be a slight delay between that,
but this one would be entered first and then this would be second.
And from then forward,
it'll have two load- balanced paths to get to that destination.
Now before we wrap up this module,
we're talking about these primary versus backup.
Okay, if we go back, let's just clear this out a little bit,
and go back to the main topology table.
We're going to show you the difference between what's referred to as
a successor and a feasible successor in EIGRP.
A successor as noted in this shell, successors,
is the current route that's going to be used and be
placed into the routing table.
In this case,
if we use just this top one because it's a simple one to understand.
There are two entries that exist.
This one with the best metric is going to be the one that's
going to be placed into the routing table,
and this is the one successor.
Now this second one is also considered feasible as we noted a second ago.
And because it's also considered feasible,
but it's not the lowest metric, it is considered a feasible successor.
A feasible successor means should the primary successor or successors fail,
I can immediately use this route and place it in the routing table.
So EIGRP, as I noted a second ago,
EIGRP knows that there's a backup route that's known.
If that initial route fails,
it immediately uses any feasible successors with the lowest metrics
to be placed into the routing table immediately.
So the fall-over and the convergence time from the primary to
the secondary is subsecond most of the time.
As soon as it knows that there's a failure,
it knows to pull that route and put the feasible successor route in.
That's another mechanism that's used by EIGRP in order to
considerably speed up the convergence process,
especially compared with any existing distance vector protocols,
the main one that we're talking about referring to RIP.
But it is important to understand that distinction,
especially for those who like to say well any distance
vector protocol is automatically faster,
or sorry, automatically slower than any of the link state options.
That's not necessarily correct with EIGRP,
and it's one of the reasons the lot of Cisco-specific shops have
used EIGRP over other options for a long time.
The main "problem" with EIGRP has traditionally been that
EIGRP is a Cisco proprietary protocol.
And for years, since it was a proprietary protocol,
any of the other networking vendors couldn't implement EIGRP.
So any network designers wouldn't implement EIGRP if
they had a multivendor environment.
And for very large networks, that happened a lot of the time.
So they would use protocols that were standards-based, like OSPF or IS-IS.
Several years ago, and I'm not exactly sure what year it was,
Cisco decided to publically release EIGRP,
and they made an informational RFC about it.
So because of that,
now other routing vendors are able to implement EIGRP if they wish.
And it enables it to be used in multivendor scenarios
that weren't previously possible.
It is also important,
and the last thing I'm going to note in this specific module and section,
the way that most networking vendors implement the
selection of a specific route over another.
And here when I'm talking about that,
I'm talking about the selection process when there are
multiple sources of routing information.
So I'm not talking about how EIGRP specifically
makes the routing selection process,
but how a device would differentiate if they were
running multiple routing protocols,
so if there was one that ran OSPF and it also ran EIGRP.
If OSPF said the best route was at, you know,
interface 1, and EIGRP said the best route was at interface 2,
the way that this is usually implemented on routing devices,
and especially Cisco, but other vendors use a similar mechanism,
is called administrative distance.
Administrative distance on Cisco devices and on several other
devices prefer EIGRP routes over OSPF routes.
So that's an important distinction to remember if any one of your
devices is implementing multiple routing protocols.
Now that's not an overly common scenario.
Most of the time,
an organization will choose a specific interior
gateway routing protocol over another,
and they would tend to go in that direction.
But I know I have,
and I'm sure any person who's listening to this course who
has been on any very large networks,
I've been on several networks that they implement the best routing
protocol that works in a specific environment.
So if you have a large organization,
one routing protocol may work well in that environment,
and another routing protocol may work well on another environment,
and there has to be a device in the middle there somewhere
that translates from one to the other.
And sometimes that device, it is interesting to troubleshoot,
and that person troubleshooting it must be familiar with how
administrative distance works and how that device makes its route selection between the different routing protocols.