So let's get started in this course by taking a look at what
EIGRP is and how it is used on a network.
While I will assume that the majority of those people watching this course
already understand at least the high-level purpose of EIGRP,
I want to run through some of the basics for those who don't know.
Enhanced interior gateway routing protocol,
or EIGRP, is an interior gateway protocol,
meaning that it is used to control how IP and IPv6 traffic is
routed within a single organization's network.
Other common interior gateway protocols include open shortest path first,
or OSPF, and intermediate system to intermediate system,
or IS-IS.
Each one of these has their own advantages and disadvantages,
but all provide a high-speed routing solution.
These interior gateway protocols are contrasted with exterior
gateway protocols that are used to control how traffic is
routed between organizational networks.
The only protocol that is commonly used for this
purpose is the border gateway protocol, or BGP.
within the realm of interior gateway protocols,
there are two different types, distance vector and link state.
Distance vector protocols exchange a distance or metric and
a vector or direction between devices.
Each device will then make a decision based on this collected information.
This collected information is based only on the current
reachability known to the neighboring device.
Because of this,
each device has a limited view of the network and assumes
its neighbor's information is correct.
The alternative is a link state protocol.
Link state protocols exchange a state of each of the connected links.
In this case,
every link state device collects a complete copy of how all destinations can be
reached and then makes a decision based on this information.
Because of this, link state devices have a better view of the network overall,
but they are also more complex.
Let's take a quick look at how this works using the topology
that we will be using throughout this course.
In this topology,
we have six different routers that are labeled from R1
through R6 using a simple design.
In this topology,
I put on some sample metrics that indicate the cost to use a specific path.
So for example, from R5 to get to R6, it will cost a total of 1.
From R4 to R6, it would cost 3.
From R3 to R6, it would cost 4.
Notice that in this case,
there are three different potential ways that R3 can
reach R6 with a total cost of 4.
For R2 to R6, it would cost 2.
And finally, from R1 to R6, it would cost 3.
Let's move into the lab environment.
In this case,
I have connected up six different routers to emulate the same
topology that we showed on the previous slide.
And in order to mock up a simple distance vector protocol,
I have configured the routing information protocol,
or RIP.
And on R6,
we have set up an interface that would be off of R6
for the 100.100 .100 .0 /24 network, in this case using a loopback interface.
So if we move back, let's see.
Let's jump back to the slides real quick.
And as you can see, the metric between R5 and R6, on that direct link, is 1.
So if we move back to the lab, on R5,
if we look up the route to the 100.100 .100 /24 network,
the cost to reach that network is 1,
and that matches what we showed on the topology.
Now if we also look back at the slides from R4 to R6.
Let's jump over.
You see from R4 to R6, there are several different paths to take from R4 to R6,
but the lowest-cost path is a cost of 3.
So if we look at R4, and as we would expect if we look at the routing table,
the cost from R4 to R6's 100 network is 3,
as we would assume.
But if we look at the database of RIP, it only shows one known route to that one,
which matches up with the minimum cost path,
the lowest-cost path to get from R4 to R6.
If we move back to R3, R3,
if we add up all the different metrics and we look at that,
there are three different routes from R3 to get from
R3 to that 100 network off of R6.
From R3 using R5, R3 to R5 to R6, which is a cost of 4,
from R3 to R4 to R6, which is also a cost of 4,
and from R3 to R1 to R2 to R5 to R6, which is also a cost of 4.
Now if we look at the RIP database in this case on R3,
we will see these three each with a cost of 4 using three different paths.
Now if we move back to R2, let's see, R2 only has one route via R5,
which in this case is this R4 interface,
and we can verify that, this R4 is via R5.
And then back on our 1 finally, on R1, what do we go back here and expect?
Let's see expected to see that R1 only has one route via R2,
which is what, let's move back to the slide,
you can see there's a path from R1 to R2 to R5 to R6.
Now just as an example, we could do a trace from R1 to R6's interface,
and you'll see it jumps to R2 to R5 and to R6.
So this is what it looks like in a very simplified,
using a very simplified distance vector protocol.
But keep in mind that the information that was shown here,
so if I look at the RIP database,
and this is one fact that we need to highlight here,
is that the database only has the best path shown here.
It does not show that there are other alternate paths possible.
It only shows the best path.
Now if you look at the topology, let's then move back.
And you can see o the topology, R1 can go other ways to get there,
but it just doesn't cost 3 or less.
But my point is that the devices have a very limited view of the network.
They are not aware of every link state throughout the existing routing domain.
And because of this,
that's one of the reasons that a lot of these distance
vector protocols or distance vector,
the ways that distance vector protocols work are
referred to as routing by rumor.
You're assuming that the neighbors that you connect
to have the correct information,
and they are advertising the information that they know,
the caveat here being that each one of their neighbors does not send all
of their known knowledge to get to that destination.
It only will advertise the information for the entries that
exist in that device's routing table,
even if that device is given an advertisement like--- For example,
if you look, R1 goes to R2.
Well R2, at least from an advertisement's perspective,
would be getting advertisements from R4 and R3 and R5.
But the only route that is going to get put into the routing
table for R2 is going to be the route via R5.
And because of that, even if it knows that there's a route through R4 or R3,
it will not put that information in its routing table or its RIP database,
and because of that, it will not advertise any of that information to R1.
So as far as R1 is concerned,
it's only path available to get to that destination is via R2.
So if there is a failure on the link between R1 an dR2,
there must be a considerable amount of time that goes by,
especially with RIP, before R1 is familiar that okay,
this link is down, and there is an alternative path.
Now EIGRP generally significantly reduces this,
the time to converge,
but that's because of some of its more link state-type behavior,
and we'll get into that in a minute.
Now that we've gone through the RIP version of this lab,
let's take a look at how and see how this differs on an EIGRP implementation.
For EIGRP, I have configured the exact same topology using the same names,
but I have configured EIGRP instead of RIP.
So if we look at R6, we still have the 100.100 .100 .0 /24 network.
And if we look at other devices within the EIGRP,
for example R3, if you remember from the RIP lab,
we had three different paths that were available to it to
reach that 100.100 .100 .0 /24 network.
In an EIGRP, this reflects exactly the same.
Now keep in mind,
I have altered the metrics the same as with RIP as I did with EIGRP,
which means the metrics that I showed on the topology,
instead of altering the hop count, which I did on the other one,
and in this way, I altered the EIGRP delay parameter.
And we'll get into metrics a little bit further later in this course.
But I just wanted to show you, let's see,
where does it differ from RIP if I look at the EIGRP topology table?
And we look.
If you remember,
the RIP database only had an entry for it for the best
paths to that specific destination, in this case the 100.100 .100 .0 /24 network.
And it didn't include any other additional information.
Even if it had gotten additional advertising information for it,
it just looked and saw that the path wasn't the lowest one,
so it didn't put it in its database.
If we look here, we'll notice, let's see, this entry right here.
We'll notice that EIGRP doesn't necessarily do the same thing.
And we'll get into the specifics of this later,
but you'll see that the three routes that are shown in the routing
table that have the same metric are these top three.
It says a metric of 131, 584,
and these first three entries have the exact same metric.
And these are the three entries that get placed into the routing table.
It also shows a fourth route here.
And this fourth route, if you see it,
it actually has a slightly higher metric at 132,
352.
Now this isn't going to be put into the routing table
because it doesn't have the lowest metric.
But it will be placed into the topology table here,
and it is used by EIGRP as a backup.
So if those three routes fail for whatever reason,
then it knows that it can quickly put this one route in place
of those should all three of those fail.
Now obviously, that's unlikely.
You can see this happens also on this other route that's here.
Let's see, this route, the 10.10 .10 .36 /30 network is another example.
These first two routes have the same metric,
and they would be placed into the routing table.
This third route has a slightly higher metric,
and this route would not be placed into the routing table,
but it is placed in the topology table.
And again, if these first two routes were to fail,
the EIGRP can quickly add this entry into the routing table.
And, as you can imagine,
that considerably shortens the amount of time it
takes to converge on the network,
whereas a protocol like RIP would need to sit there and wait to listen to its
neighbors and wait to see if it finds another path to that.
It wouldn't have that information immediately available to it.
Let's take a minute before we go any further and talk about what
differentiates EIGRP from other distance vector protocols.
The traditional problems with distance vector protocols revolve
around their speed of convergence and reliability.
EIGRP remedies these problems by using some common
characteristics of link state protocols.
For example, EIGRP uses neighborships.
These are established to ensure that collected routing information
is reliable and from a known operating source.
It doesn't send periodic updates like common distance vector protocols.
It only needs to send updates if something on the network changes.
It also uses a more complex metric.
This is especially helpful when using different
networking technologies where common metrics like hop
count that RIP uses are too simplistic.
And for these reasons and others,
EIGRP is often referred to as an advanced distance vector protocol
or a hybrid protocol in some other literature.
Its fundamental mechanism is distance vector,
but it takes on several of the traits from link state.
So now with this covered, let's move on and discuss EIGRP successors, feasible successors, and its use of the feasibility condition.