To appreciate our EIGRP routing protocol,
let's first take a look at our topology as it currently sits.
And this is also the topology you'll be having an opportunity
to practice with in the lab coming up.
So we've got eight routers on the left hand side.
I've got router 1, 3, 5, and 7,
and on the right hand side I've got R2, 4, 6, and 8.
There's also running on this topology both IPv4 and IPv6.
For this set of videos on EIGRP, we'll be focusing on IPv6.
And then in the lab, I've got a client-nud machine
at 10.0.150. It's on the 10.0.1 network sitting here on our topology. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at 10.0.150. It's on the 10.0.1 network sitting here on our topology.
I've also got server 1 nug down here on our topology
at 192.1 state 1, 100 on the 192.1 state 1 network.
And then I have all the other subnets that's shown here for IPv4.
So for example, between R1 and R3,
I have subnet 10.0.13 between R1 and R2,
subnet 0.12, just using the two router numbers.
Then down here, 10.135 between R3 and R5,
10.157 between R5 and R7.
And then on the right hand side, between R4 and R6, 10.246, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then on the right hand side, between R4 and R6, 10.246,
and between R6 and R8, 10.268.
And over here is the 10.17 network.
And hanging off of R8, I've got the 192.1 state 1 network.
And that's the lay of the land regarding IPv4 addressing.
Also for the connections, I've drawn the fast ethernet connections,
100 megabits per second in yellow.
They're also labeled as such with the F there for fast ethernet.
I've got these green links.
Those are all gigabit ethernet, labeled appropriately with the G
in front of the interfaces that are connecting the routers to those segments.
And then also for the benefit of really appreciating
or routing protocols and how they work with the various bandwidths and so forth WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or routing protocols and how they work with the various bandwidths and so forth
.
I've also got three serial links.
A serial link between R3 and R8, that's 10.380,
one between R7 and R8, 10.780,
and one between R4 and R6, and that's 10.2.46.
And instead of taking the default bandwidth on these serial links,
which are these like 1.54 megabits per second,
I have set on each of these serial interfaces,
a bandwidth of 64 kilovits per second.
So that's here for this link, and also true for that link,
and for that link.
And I set that on the interfaces that are connecting those routers WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I set that on the interfaces that are connecting those routers
to those serial networks.
So once again, gigabit is gigabit,
fast ethernet is fast ethernet,
and the serial links are 64 kilovits per second.
All right, so let me clean that up a little bit.
And let's talk about some characteristics regarding
the enhanced interior gateway routing protocol.
Now, EIGRP is considered to be an advanced
distance vector routing protocol.
And the question may come up, well, why is it exactly
an advanced distance vector routing protocol?
To start off, these routers, as they form adjacencies WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with other EIGRP routers, they only know what those directly
connected neighbors are telling them.
So for example, R1 here only knows what it hears coming in from R2
and from R3.
Now, R2 and R3 may have information about routes
that are downstream, for example, the 10.780 network,
or the 8888 address that loop back address here on R8.
But at the end of the day, it's really trusting what information
it got from its directly connected neighbors.
Now, if we compare that to OSPF, if this was one giant OSPF area,
every router would have seen the LSAs from every other router. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
every router would have seen the LSAs from every other router.
And as a result, they would have direct knowledge
on all the directly connected networks.
And that information would have come from the source.
For example, in OSPF, R7's information about
its links that's connected to and so forth would be learned by R1.
Because those LSAs, the links they had advertised
would be propagated and advertised all the way up to R1.
Again, assuming this is one giant OSPF area.
But getting back to ERGRP, ERGRP doesn't play that way.
So information can be propagated from R7 to R5 and R5 to R3 and R3 to R1.
So R1 will learn information that R3 is sending WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So R1 will learn information that R3 is sending
and that R2 is sending.
But it won't have direct knowledge about remote routers
and their directly connected links.
Now, what makes it advanced is also that it's using
hello messages and it's building neighborships
between the routers.
So R1 knows it has a formal adjacency, if you will,
with R2, with ERGRP and with R3 and vice versa.
And that's if they agree on some basic concepts.
And for those holos, we're using multicast
and that multicast address ends in .10 with IPv4,
or A, which is the equivalent of 10 in hexadecimal with IPv6. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or A, which is the equivalent of 10 in hexadecimal with IPv6.
It also uses its own layer for protocol
and that is protocol number 88.
So it's not using TCP or UDP.
It's using its own layer for protocol, protocol 88.
Another cool feature of ERGRP is that if it's configured to do so,
it can do proportional load balancing.
And let me give you an example of that.
So let's imagine we have a router 4 here.
And it wants to go ahead and be able to route
or forward packets down to, let's use the loopback on R8,
which is 8.8.8.8.8. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is 8.8.8.8.8.
Sorry, Google, I know that's also your DNS,
but in the lab environment, each of the routers
has a loop packet rest, loop x0, using its router number 4 times.
So it'd be 8.8.8.8 here and 7777 here
and 1111 here and so forth.
So we're going to R4.
Let's imagine it's learning how to reach the 8.8.8 network from R2
and also from its advertisements coming in from R3
and also its advertisements coming in from R6.
Now it's super likely that one of those routes
this learning is going to be the best.
It's going to have the lowest metric WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's going to have the lowest metric
and as a result, it's going to be the winner
and placed in the routing table.
And just for Grins, because it's going to be super important later as well,
let me just jot down here that the winning route,
the one that gets put into the routing table
because it has the lowest metric,
that winning route has a very fun name in the world of EIGRP
and that name is the successor or the successor route.
So I'm going to put in parentheses the word route
just to help us remember that's the winning route in the routing table.
Call these successor routes.
Now in the case of R4, if we had some other routes
that could also potentially be used WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that could also potentially be used
and we'll call those feasible successors,
by default EIGRP is only going to take the best route
and put in the routing table.
But if we modify how it operates with this load balancing,
we can say, you know what?
If the second and third feasible successors,
we can think of those like backup routes.
So one thing we could do is we could tell R4 that, hey, you know what?
If you have these feasible successors potential backup routes,
in case the primary route goes away,
if they have metrics that are, for example,
no worse than two times the successor metric,
meaning they're not twice as bad, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
meaning they're not twice as bad,
something less than twice as bad,
go ahead and use those as well
and do proportional load balancing with them.
So assuming that the other two routes met that condition,
not being twice as bad as the primary route,
they could then be added into the routing table
and then load balance across all three paths.
And again, if we said we were using 2x for our variance
between the best route, any possible backup routes
and these two routes fill in that category
where they qualified for that,
then we'd have a total of three routes
that could be used and placed in the routing table for R4 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that could be used and placed in the routing table for R4
regarding the destination network, 8888.
So make clean that up a little bit
and let's talk about a few other functions
and basic characteristics regarding EIGRP.
Now, one of the interesting aspects of using EIGRP
is that there's more than just one way to configure it.
We can use the traditional method,
which we use for decades and decades,
or we could go ahead and use named EIGRP.
And as we proceed through these videos,
I'll give you demonstrations of each
and at the tail end of this skill,
I'll also give the opportunity to practice configuring it
in either way you want.
And I've got a little notepad file sitting here on server 1nug WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I've got a little notepad file sitting here on server 1nug
that can help you at the syntax as well if you'd like to use it.
Now, when looking at routes,
each routing protocol has its own way
of identifying the cost or the metric of a route.
And so in the world of EIGRP,
the cost is referred to as a metric.
And although EIGRP is sharing a lot of information
with its neighbors,
it shares information, for example, about M2U
and reliability and load and bandwidth and delay,
the actual default metric calculation boils down to this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the actual default metric calculation boils down to this
is the sum of the delays.
So let's imagine we're focused right here
on the 8.8.8.8 network here on our 8.
And let's also go back to our 4.
So our 4 is learning about the network here from R2
and also from R3 and also from R4.
And in this case, R6 and R3 and R2 are all reporting
the information regarding the delays involved up to that point.
And so our 4 is going to be receiving the current sum of delays
from the perspective of R2.
They call that the reported distance or RD for short. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They call that the reported distance or RD for short.
So R2 is going to have a reported distance
and R3 is going to have a reported distance
and R6 is going to have a reported distance
all being fed into R4.
And part of that reported distance is going to be
from each of those routers perspectives,
the sum of the delays.
So as far as the delays are concerned,
each link has an associated delay with it.
So a gigabit ethernet interface is going to have a fairly low
static delay associated with it,
a fast event is going to have a greater delay associated with it.
And then on these serial links,
by default it's like 1.54 megabits. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
by default it's like 1.54 megabits.
I artificially configured a 64 kilobit per second bandwidth
on the interfaces, which caused a considerably worse delay
factor regarding these serial links.
So when R4 receives all this information,
it's going to consider the sum of the delays
and it's also going to consider the slowest link.
And as part of the advertisements coming in to R4 from R2
and also from R3 and also from R6,
they are reporting the slowest links.
And to help reinforce that, let's go ahead and use R1
as an example, because R1 is not directly connected WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as an example, because R1 is not directly connected
to any slow serial links.
So here's our one up here and it's going to be having information
with the reported distance coming in from R3
and also report distance coming in from R2.
And that report distance is going to include the sum of the delays
from R3's perspective and R2's perspective
getting down to that network 8888.
And each of those are also going to report the slowest link in the path.
So here on R8, let's imagine that it's advertising the route up to R3
and R3 realizes this link that's directly connected to
has a bandwidth of 64K. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
has a bandwidth of 64K.
And so as it does the reported distance up to R1
about that 8888 network down here, it's going to report that,
oh, you know what, the worst link in this whole path is 64K.
And so R1 will get that information
in the routing updates coming into it from R3.
And R2 will also have that slowest link as well,
because let's say the advertisement went here
and then here and then here.
So that information is propagated from R6 over here to R4
and R4 is learning it here on a slow serial link.
R4 when it advertises up to R2 and its reported distance WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R4 when it advertises up to R2 and its reported distance
as part of the information conveyed, it's going to indicate that the worst
bandwidth in the path is 64K.
And as a result, R2 is going to say, you know what?
R4 told me that we're spanned within the path, 64K.
So that's when it reports you, again,
regarding this route 8.8.8.
Now it's also interesting to note that there's a lot of additional information
that's being reported and advertised
in these neighbor advertisements and route updates
that are going back and forth.
But the only two that are being used by default
is the sum of the delays for all the links involved in the path. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is the sum of the delays for all the links involved in the path.
And then we're also using the slowest link.
And then there's a multiplier as well.
And to make this clear, I'm also not going to play dividing line there.
So it's not dividing the slowest link in this.
So it's taking these sum of the delays,
whatever that sum is up to the point where the routers are making the
calculation.
It's also considering the slower link.
It's doing some math on that.
And that's what's calculating the actual metric.
So it's not by default considering the load
or the M2 or the number of hops, even though all of that information is also
communicated
for a routing update with EIDGRP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for a routing update with EIDGRP.
So as an example, to reinforce that,
here is a route update that I captured with Wireshark on one of the links
between two routers.
And I want to focus on the advertisement
regarding this route 8.8.8.8/32.
As far as the information is being advertised about that route,
as this route update is coming in,
it indicates the reliability, the load,
the M2, the hop count, and none of those values are used by default.
The ones that are used are the delay.
So that is the sum of the delays. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that is the sum of the delays.
And based on the flavor of EIDGRP
that we're using, that could be in microseconds or picoseconds.
But either way, we want to be aware that that's what that is.
It's the sum of the delays in this advertised route of 8.8.8.8.
That's coming in.
And for the bandwidth, that is the slowest link in the path
towards that target network 8.8.8.
So these are the only two values that we really need to worry about,
the sum of the delays and the lowest bandwidth in the path.
Also, while we're at it, this is an example of a hello message
between two EIDGRP neighbors.
So based on the source address, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So based on the source address,
this is being advertised from 10.013.3.
That'd be R3.
And the destination is the multicast address for EIDGRP,
the one ending in .10.
So this is a hello message.
And in that hello message, it's also indicating
which K values are being used.
So if there's a one here,
that means that value is being used
as part of the metric calculation.
And if there's a zero, that means it isn't.
So K1 represents the minimum bandwidth
up to that point in the path.
And K3 represents the sum of the delays up to that point.
So as long as all of our routers by default
are using just these two values, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are using just these two values,
the sum of the delays and the slowest link in the path
as part of their calculation,
that's one of the elements that has to be agreed on
if they're going to become neighbors.
And then if they're using that same calculation
from their own perspective,
each router can make its best decision
based on which route we're going to use
based on the lowest final metric calculates.
So let me clean this up a little bit.
And even though we are going to be talking
in a separate video in the set of videos
about the actual terms and some vocabulary,
let me also give you a preview
of some of those important vocabulary terms
regarding EIGRP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
regarding EIGRP.
We've already mentioned a few of them.
One is reported distance.
So if R4 is advertising information to R2,
it's going to be using something called
reported distance.
So I'll put here vocab reported distance.
And the only two really important things we care about
in reported distance is the information
regarding some of the delays that's being advertised
or reported and also the slowest link
in the path that's being reported by that neighbor.
This term also reported distance or RD for short.
Also has another way of describing it
as advertised distance. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as advertised distance.
And the reason I hesitate to even bring that up
is because if we abbreviate that,
we have AD, which is not represent
administrative distance.
Advertise distance or reported distance.
Just think of it as these two factors
that are being reported from a neighbor
to another neighbor about a given route.
The sum of the delays in the path
as well as the slowest link.
And that way our two can get that information
and to its own number crunching.
To figure out of all the routes it's learned about
from R1 and from R4 in this case,
R2 then do a calculation based on that information WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R2 then do a calculation based on that information
to determine which if any routes
are going to make it into the routing table.
So again, the reported distance,
advertised distance, those are the same animal right there.
Information being advertised from a neighbor to another neighbor.
Another term that we mentioned,
which I'll put up here again, is a successor route.
So a successor or a successor route,
think of that like the winner
that makes it into the routing table.
And if there's two or three different routes,
they have the same exact metric.
By default, it'll load balance across all those.
Or if they're not quite the same metric,
we can tune and tweak it to do load balancing
even on unequal paths. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
even on unequal paths.
But the successor route is the winning route.
And the backup routes are called feasible successors.
So think of feasible successor as a possible successor.
So if that successor or winning route went away,
one of the feasible successors could be brought up,
put in the routing table,
and the router could start to use it right away.
So how make a note, it's a backup route.
And I'm going to continue our vocabular
over here on the right, to have a little more room.
So let's say R4, after it's learned all of its information,
about the 8.8.8 network.
And it's learned that from R6 and R3 and from R2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it's learned that from R6 and R3 and from R2.
Once it does the calculation,
which is a sum of the delays and the slowest link in the path,
and some math involving multiplying it all by 256.
When it comes up with the final metric
for the winning route, a successor route,
that's referred to as the feasible distance,
or FD for short.
So if you see a route in the routing table,
and has a metric of like 11 billion,
or whatever it is for EIGRP for a specific route,
that number you're looking at is the feasible distance,
the final metric for that route.
And so let me just make sure I got all the core terms
I wanted to share. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I wanted to share.
The reported distance or advertised distance
is this information being shared with the neighbor.
Regarding a route, the successor route would be the winning route
that one that's put in the routing table.
The feasible successor routes that could be placed in the routing table
if the current successor route is gone or no longer available.
And the feasible distance is the final metric
that the route is using for a given route
to get to a given destination.
So here I'm also going to just jot down the metric,
because that effectively is what a feasible distance is,
it's the metric for that route.
Now the core idea in this set of videos WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now the core idea in this set of videos
is to understand how EIGRP works.
And so to that light,
I want to walk you through configuring EIGRP traditionally,
and also with named EIGRP.
But instead of making this a typing exercise in the lab
at the tail end of this video,
I'll give you options of using either one you want.
I'll demonstrate both of them first.
And I've also got a little notepad document
sitting on server one nug with all the appropriate commands
that you can use if you want to.
So you can refer to that notepad document
or if you want to do it manually, either way is great. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Get that hands-on practice.
So in the next video,
I'd like to take just a moment to walk you through
implementing EIGRP using the traditional methods.
So I'll see you in the next video for exactly that.