It's fantastic to have a routing protocol.
Now we can learn routes from our neighbors.
Now, in EIGRP, I want to share with you
what we're learning from our neighbors
and how we can use that to determine our best cost paths
to get to any given network.
[MUSIC PLAYING]
So in this video, we're going to take a big step
in the right direction regarding understanding how reported
or advertised bandwidth and delay information coming
from neighbors can help us in making our own route
calculations for a given route.
So in the previous video, we took a look that each router-- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So in the previous video, we took a look that each router--
router 1, 2, 3, and 4--
had a route, a successor route for the 10.2.68 network,
and they had a metric associated with each of those routes,
respectively.
And in EIGRP, we affectionately refer
to that metric for the successor route as the feasible distance.
From that router's perspective, the metric
it has for that winning route.
And so for fun, because we looked
at these in the previous video, let's
go and write out, for each one of these routers, what
the actual metric is for the successor route regarding WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the actual metric is for the successor route regarding
10.2.68.
So on R1, it's this guy right here, 2,172,928.
Great.
And on R2, it's 2,172,672.
Fantastic.
R3, 2,173,184.
And then R4--
I'll put it over here--
was 2,172,416.
So that's their metric, AKA feasible distance, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that's their metric, AKA feasible distance,
for the successor routes regarding 10.2.68 on each
of those routers, respectively.
Now, how in the world did they determine that?
How did they calculate that?
The information that's shared--
and now the actual by default how
EIGRP metrics are calculated-- are really based on two things.
What?
Just two things?
Yeah, two things.
It is the worst bandwidth in the path.
And then before we go on to step number two,
let's talk about how that's possible.
Keith, you said in, like, a video or so ago, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Keith, you said in, like, a video or so ago,
that EIGRP is a distance vector, like routing protocol,
in that it doesn't have direct knowledge
of the entire topology.
It knows about its neighbors and what its neighbors tell it.
But it doesn't know about, like, a router three or four
hops away, and what the bandwidth is
on those interfaces, and so forth.
How is it done?
What's the magic?
So here's how the router can figure out
what the worst possible bandwidth is in the path.
Let's take an example of another network.
I'll use a different color.
Let's use 10.1.7.0/24, which is off of gig 0/0 here on R7. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's use 10.1.7.0/24, which is off of gig 0/0 here on R7.
If we're running EIGRP, and we are--
and this is a hands-on lab, by the way,
so if you want to log on from a computer to the CBT Nuggets
website and click on the link for this hands-on lab and just
follow right along with me.
So as we're advertising this route up,
basically, R7 is going to advertise,
regarding bandwidth, hey, it's a gig.
Because it has gig interfaces, it's all gig.
And then when R5 gets it, it's going
to say, hey, I got a gig between me and that network.
So it's going to advertise, hey, the worst bandwidth in the path WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it's going to advertise, hey, the worst bandwidth in the path
is a gig.
And R3 gets it.
R3 is going to say, oh, bummer.
Well, between me and that network,
I've got fast Ethernet.
So it's going to change the equation
and then say, yeah, the worst path in the link is
now fast Ethernet.
And if we go on an extreme level,
once that route is propagated all the way down here,
this link right here-- oh, my gosh.
It's so sad.
It's 1.54 megabits per second.
It's like a serial T1 link--
very, very slow compared to today's standards.
So what's going to happen is as R6 advertises that 10.1.7 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what's going to happen is as R6 advertises that 10.1.7
network, it's going to say, yeah, and by the way, my update
here--
the lowest link in the path is 1.54.
And so when R8 gets that, if it has fast Ethernet, which
it does, it doesn't matter.
It's going to be told the slowest link in the path
is 1.54 megabits.
And it'll go ahead and use that as part of its equation.
So there's two parts in the equation
that we use to calculate the metric.
One is the worst bandwidth in the path.
And now there's no mystery about how R8 learned it.
Its neighbor said, worst link is 1.54 megabits.
Deal with it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Deal with it.
And the second part is a sum of delays.
So based on the speed of the interface,
there's a delay that's associated with the interface.
It assumes that a gigabit interface
is going to have less of a delay than, for example,
fast Ethernet or a serial link.
And so there's microseconds of delays that are added.
So as that route gets propagated,
each router takes the advertised delay,
and then it adds its own, based on its interface.
And then it advertises that.
So initially, there's not going to be very much delay WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So initially, there's not going to be very much delay
as R7 reports that.
But by the time it gets over to R8, what R8's going to hear is,
oh, by the way, the delay is, like, 20,000 or something.
And R8 will say, well, I'm fast Ethernet.
I'm going add 20 microseconds, or whatever it is, to that
for my final calculation.
So the calculation in EIGRP regarding
the metric, or the feasible distance,
if it's the successor route, that calculation
involves the worst bandwidth in the path
and a sum of all the delays between that router WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and a sum of all the delays between that router
and the target network.
So that's how the calculation works.
We'll take a closer look at the math involved
with that in a separate video.
But I want to share with you what's being advertised.
So regarding this network, 10.2.68,
if we're focusing here on R# for a moment,
R4 is advertising information about the bandwidth and some
of the delays.
R1's advertising information.
And then R3 is going to take all that data.
It's going to increase the delay because it
has interfaces it has to go over to get to those next hop WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
has interfaces it has to go over to get to those next hop
routers.
And then it does its own calculation
to calculate the metric for the routes
that it's receiving from both R1 and R4.
So both routes that it's learning about--
the 10.2.68 from R1 and R4--
because they're both EIGRP, they're
both internal EIGRP-learned routes.
And they would both have an administrative distance of 90.
So they're both believable equally that way.
But then the metrics are going to be different
because of the calculations it does.
And then it's going to choose--
R3 is going to choose the best path based WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
R3 is going to choose the best path based
on its calculations of that metric
and put that winner in the routing table.
Or if it has two equal cost routes, by default,
it will put them both in the routing table.
And the intent of this video is twofold.
One, I wanted to share with you what's being communicated--
the lowest cost bandwidth in the path and a sum of the delays--
but I also wanted to share with you what we call it in EIGRP,
and that is this row right here.
And it can be referred to as two different names,
depending on your perspective.
So let's imagine we're R3.
And we are receiving these updates regarding the 10.2.68 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we are receiving these updates regarding the 10.2.68
network.
We're receiving it from R4.
We're receiving it from R1.
And what we're going to call those are received distance.
Now, it's really unfortunate they use the word distance
there, because this received distance is just
talking about what we're receiving, in the case of R3,
what we're receiving from our neighbors regarding
information, like the lowest bandwidth in the path
and information about the sum of the delays up to that point.
And that's the received distance we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's the received distance we're
receiving from our neighbors.
Now, that's if we're doing it from our R3's perspective.
But if we go to R4, who's advertising that information,
in that context, it could be called the advertised distance.
So that's what I have right here.
I put-- Received, I put RD in parentheses, so if you saw it,
you wouldn't think distance, administrative distance.
So with EIGRP, when we're talking about information
that's being shared between two neighbors,
if we're receiving that, we can refer to that as received
distance or the received information about the route
cost. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
cost.
And if we're sharing it with somebody else,
we can refer to that as advertised distance.
So RD or AD, depending on who you read.
But it is really unfortunate that they use the word
distance, because administrative distance,
the reliability of a route-- you know,
like who's going to get the routing table--
that, you know, administrative distances, that whole subject,
and this distance, the received and advertised distance,
only has to do with the metric calculation.
Nothing to do with administrative distance.
So I wanted to point that out as a couple more terms WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I wanted to point that out as a couple more terms
that we can use to build our vocabulary
within the world of EIGRP.
And as an example of confirming this,
let's imagine that we're going to go to R3, which in the lab,
we will, here in just a moment.
And on R3 for this one route, the 10.2.68 network,
we have a feasible distance, a metric, of 2,173,184.
And we'll also see that from R1, when it communicated
to us the received distance we received from R1, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to us the received distance we received from R1,
it's advertising its information about what it
knows about that route to us.
So what we would see inside of the interface
is we would see that the advertised distance,
or the received distance that we're getting from R1,
would be R1's feasible distance.
And that's right here.
So going back to R3--
and I'll change the color here--
R3, we have a feasible distance for the successor
route of 2,172,184.
But right below it, I have the received distance
that we learn from R1.
And that is the feasible distance WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that is the feasible distance
that R1 currently has that he advertised to us.
So we took what he said and then we
added our own calculations to create our feasible distance.
And also, in the background, just as a heads up,
it doesn't actually send the number.
It just sends the calculations based on bandwidth and delay.
And the router is doing all those calculations
for the output on our display.
So let's take a look at R3.
And I'll show you how we can see both the feasible distance
for R3, regarding this route, and also
the reported, or advertised, distance for that same route. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the reported, or advertised, distance for that same route.
So here in the lab, let's do a show IP route.
I just want to verify that we have the route
and that the metric is correct.
So here's the metric for that 10.2.68 network.
It is 2,172,184.
I'm just going to double check that against our notes.
So 2,172,184, correct.
So that's great.
And then let me show you how we can see the reported
distance that we're using as part of our calculations
to get to that number.
And one way of seeing that is with the command
show ip eigrp topology. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
show ip eigrp topology.
And we'll press Enter.
And then we're just going to go pick out that 10.2.68
network, which is right there.
So the command here is show ip eigrp topology.
And then here is the route.
And so what this is saying is that for the 10.2.68 network,
we have one successor, which in English means
we have one winning route.
The feasible distance, which is the metric for that successor
route, is 2,172,184.
We saw that in the routing table.
And then it's showing us the details about that successor WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then it's showing us the details about that successor
route.
So there is the metric.
So these two numbers are the same.
And then-- I'll put this in a different color.
I'm going to use green.
And then right here, it's showing us
the advertised distance.
So this is the advertised distance
that R1 shared with us.
So basically what happened is R3 got this advertised distance,
which is exactly the feasible distance from R1.
And it took that data and said, OK, I
need to add a little bit of delay
because I have to go through an interface to get to R1, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because I have to go through an interface to get to R1,
ran its own calculations.
And that's when it came up with this final metric
for the successor route.
So the first number here in the command show ip eigrp
topology is the full metric for that route.
And then the second number is the advertised distance,
or the reported distance, that we learned from our neighbor
on the network.
In this case, we learned it from R1.
So to confirm that in the lab, if we went to R1
and did a show IP route, this literally
would be the metric for that specific route.
The feasible distance on R1 is this number right here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The feasible distance on R1 is this number right here.
So R3 took that advertised distance,
added a little bit of delay because of its own interface,
ran the calculations, and then came out
with this metric for the successor route.
Also, I'd like to point out, while we're here,
that there's two candidates here that could have been the winner
route.
But this one right here has a metric of 2,173,184.
And the one below it, which is coming through R4, is 2,174.
And because it's a higher metric, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And because it's a higher metric,
it lost and didn't get put in the routing table.
However, there is good news.
If the primary route ever goes away for some reason,
we have high hopes that that backup route could be installed
immediately in the routing table and this router could still
have reachability to that remote network.
And that's the topic of our next video
is how to identify if we have a backup route that
can be used by our Cisco router that's running EIGRP.
So I'll see you in that video and lab in just a few moments.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and I'd like to thank you for viewing.