WEBVTT

1
00:00.000 --> 00:04.220
In the previous video, we walked through the implementation of EIGRP using the

2
00:04.220 --> 00:05.500
traditional method.

3
00:05.500 --> 00:09.220
So in this video, we're going to remove that config and then walk through the

4
00:09.220 --> 00:10.600
implementation of EIGRP.

5
00:10.600 --> 00:13.300
But this time, use named EIGRP.

6
00:13.300 --> 00:16.600
So if you brought the lab up in the previous video or if you're bringing it now

7
00:16.600 --> 00:17.800
and you want to do this along with me

8
00:17.800 --> 00:21.180
or if you want to wait to the end, it's all good either way you want to do it,

9
00:21.180 --> 00:22.600
but please get the hands on practice.

10
00:22.600 --> 00:27.880
So to remove the current EIGRP and put the new named EIGRP, what I'm going to

11
00:27.880 --> 00:29.800
do is go back to this text document.

12
00:29.800 --> 00:34.620
So this is on server one nug and this is the document called EIGRP configs
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

12
00:29.800 --> 00:34.620
So this is on server one nug and this is the document called EIGRP configs

13
00:34.620 --> 00:37.100
sitting on the desktop just to confirm that where it's at.

14
00:37.100 --> 00:38.900
We'll minimize that, minimize that.

15
00:38.900 --> 00:42.400
It's this little document right there EIGRP configs.

16
00:42.400 --> 00:47.000
So with that open, let's go down a little bit and this part right here, the

17
00:47.000 --> 00:50.900
second part is going to remove all the routing protocols, including EIGRP.

18
00:50.900 --> 00:54.600
And then walk through the implementation of using EIGRP with address families.

19
00:54.600 --> 00:58.340
So this part right here is all about getting rid of anything that might have

20
00:58.340 --> 01:00.700
been there previously starting off fresh.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

20
00:58.340 --> 01:00.700
been there previously starting off fresh.

21
01:00.700 --> 01:03.900
And then here is how we're going to configure named EIGRP.

22
01:03.900 --> 01:08.580
We start off with the name router EIGRP space and then you give it a name that

23
01:08.580 --> 01:09.300
you want to use.

24
01:09.300 --> 01:15.960
And then once you're there inside named EIGRP, it can support both IPv4 as well

25
01:15.960 --> 01:17.300
as IPv6.

26
01:17.300 --> 01:21.460
So because we're focusing on IPv4, the first thing we'd want to do is specify

27
01:21.460 --> 01:24.300
okay for address family IPv4.

28
01:24.300 --> 01:28.550
I want to use the autonomous system number of 100 and then you would use

29
01:28.550 --> 01:32.300
network statements once you're in this address family for IPv4 just like you
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:28.550 --> 01:32.300
network statements once you're in this address family for IPv4 just like you

30
01:32.300 --> 01:33.600
would with the traditional flavor.

31
01:33.600 --> 01:37.670
So whether you want to use every interface with network 0, 0, 0, 0 or network

32
01:37.670 --> 01:40.800
10 and these wild card bits either way is great.

33
01:40.800 --> 01:44.800
And then once you're done, boom, we now have EIGRP running.

34
01:44.800 --> 01:47.300
But this time we're using our named EIGRP.

35
01:47.300 --> 01:51.300
And within the address family for IPv4, we're using AS100.

36
01:51.300 --> 01:54.330
So I'm going to go ahead and scroll up a little bit. I'm going to go ahead and

37
01:54.330 --> 01:55.500
copy that entire section.

38
01:55.500 --> 01:59.900
So this is what I currently have. I'll right click. I'll copy that and then I

39
01:59.900 --> 02:02.800
'll go back to multi tab buddy.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

39
01:59.900 --> 02:02.800
'll go back to multi tab buddy.

40
02:02.800 --> 02:06.080
So I'll click on the icon in the taskbar to get there. And then I'm going to

41
02:06.080 --> 02:07.300
use this option once again.

42
02:07.300 --> 02:11.300
So I'll click here for send script and then I'll go ahead and right click.

43
02:11.300 --> 02:15.620
I'll paste in all those commands. I'll click on select all and then I'll go

44
02:15.620 --> 02:17.100
ahead and scroll down and say, you know what?

45
02:17.100 --> 02:21.300
We don't want to send that to PC 7 or 8 or PC 1 because they're not routers.

46
02:21.300 --> 02:22.600
They won't know what to do with it.

47
02:22.600 --> 02:26.770
And so with router 1 through 8 selected and the script input here will go ahead

48
02:26.770 --> 02:28.100
and click on send script.

49
02:28.100 --> 02:31.100
And that's going to remove any routing that may have been there.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

49
02:28.100 --> 02:31.100
And that's going to remove any routing that may have been there.

50
02:31.100 --> 02:35.040
And it's going to implement named EIGRP. And then it looks like I didn't have a

51
02:35.040 --> 02:36.100
carriage return up from my end.

52
02:36.100 --> 02:40.890
So I'm going to go back here and press enter here in the script section. Select

53
02:40.890 --> 02:44.100
all send it and little PCs won't care if they get it enter.

54
02:44.100 --> 02:47.390
So once again now that we have it configured we can do those same types of

55
02:47.390 --> 02:51.100
commands. So if we go to our four, it's good our four.

56
02:51.100 --> 02:54.830
So here in our four we do a show IP protocols in press center. It'll show us

57
02:54.830 --> 02:57.100
our protocols that are running for IPv4.

58
02:57.100 --> 03:02.610
So here's showing us EIGRP 100 is showing us the K values that is using again
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

58
02:57.100 --> 03:02.610
So here's showing us EIGRP 100 is showing us the K values that is using again

59
03:02.610 --> 03:08.530
the K1 represents the minimum bandwidth in the path and K3 reports to some of

60
03:08.530 --> 03:09.100
the delays.

61
03:09.100 --> 03:11.840
And another way of seeing some of those values that are being used is spring

62
03:11.840 --> 03:13.100
back to topology for a moment.

63
03:13.100 --> 03:18.680
So we're looking at the loop back down R8. If we did a show IP route for 8.8.8.

64
03:18.680 --> 03:20.100
8.8 and press enter.

65
03:20.100 --> 03:24.100
Here's the routing information for that route. It was learned via EIGRP 100.

66
03:24.100 --> 03:27.600
Here's the current metric for that route. And another name for that metric

67
03:27.600 --> 03:29.100
would be the feasible distance.

68
03:29.100 --> 03:33.390
That's the calculation involving the sum of the delays and the lowest link in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

68
03:29.100 --> 03:33.390
That's the calculation involving the sum of the delays and the lowest link in

69
03:33.390 --> 03:34.100
the path.

70
03:34.100 --> 03:37.870
And if you're wondering, well, what is the total delay and what is the minimum

71
03:37.870 --> 03:41.720
bandwidth in the path right here showing us in the show output for the show IP

72
03:41.720 --> 03:47.100
route showing us the total delay is looks like 20,000 and 32 microseconds.

73
03:47.100 --> 03:51.250
And the minimum bandwidth in the path is 64. And if we looked at that route for

74
03:51.250 --> 03:55.590
8.8.8.8 and we looked at it from R1's perspective, even though R1 isn't

75
03:55.590 --> 04:00.100
directly connected to any 64K links, that information would have been reported
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:55.590 --> 04:00.100
directly connected to any 64K links, that information would have been reported

76
04:00.100 --> 04:02.100
regarding the worst link in the path.

77
04:02.100 --> 04:05.790
It would have been reported by R2 or R3 because that's also what they believe

78
04:05.790 --> 04:09.690
the worst link in the path is because that's what they were told or in the case

79
04:09.690 --> 04:13.100
of R3, it's directly connected and learning the route on that 64 bit network.

80
04:13.100 --> 04:16.880
And to verify that, let's just go ahead over to R2 and R3. So we'll go to the

81
04:16.880 --> 04:19.100
tab for R2 and R2. Let's do a show.

82
04:19.100 --> 04:22.690
Back here, check this out. We need this to. Let's go ahead for all the routers

83
04:22.690 --> 04:28.100
and I click up here again. And let's do a show IP route for 8.8.8.8.

84
04:28.100 --> 04:32.100
And press enter a couple times and let's send that to everybody except for the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

84
04:28.100 --> 04:32.100
And press enter a couple times and let's send that to everybody except for the

85
04:32.100 --> 04:35.100
PCs because they're not routers. They want to do it with it.

86
04:35.100 --> 04:38.200
But we'll send that command to all of them at once. Do send script and then we

87
04:38.200 --> 04:39.100
'll look at R2.

88
04:39.100 --> 04:43.810
So here on R2 with the R2 tab selected, we can see the minimum bandwidth is 64K

89
04:43.810 --> 04:49.850
. The other router was R3. So if we go to R3 and we look at the minimum link in

90
04:49.850 --> 04:53.800
the path is 64 bits, again, it's because that has been advertised as the worst

91
04:53.800 --> 04:57.100
path from their neighbors if they weren't directly connected to those networks.

92
04:57.100 --> 05:03.100
Also, over here, R3 is reporting a total delay of 20,000 and two microseconds.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

92
04:57.100 --> 05:03.100
Also, over here, R3 is reporting a total delay of 20,000 and two microseconds.

93
05:03.100 --> 05:08.100
And if we go to R2, R2 is reporting a delay of 20,000 and 22 microseconds.

94
05:08.100 --> 05:13.810
So the delay that goes into the calculation is less from R3. So if we go to R1

95
05:13.810 --> 05:18.690
and look at the route, that's why it's using .3 as the next hop because after

96
05:18.690 --> 05:21.100
the calculation was all done, that had the lowest metric.

97
05:21.100 --> 05:26.860
We can verify that with a show, IP, EIGRP, topology, press enter, and I'm going

98
05:26.860 --> 05:31.420
to hit space bar. So here is our route. Now this P on the far left, that means
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

98
05:26.860 --> 05:31.420
to hit space bar. So here is our route. Now this P on the far left, that means

99
05:31.420 --> 05:32.100
it's passive.

100
05:32.100 --> 05:36.390
I mean, it's not actively trying to learn where that route is. It's pretty

101
05:36.390 --> 05:39.320
stable in the routing table. And that's why there's a P there for passive. It's

102
05:39.320 --> 05:43.100
saying there's one winning route. And the final metric is this one right here.

103
05:43.100 --> 05:48.470
So if we count all the characters there, 11 billion, 551. So there's the

104
05:48.470 --> 05:54.190
feasible distance right there again. And the reported distance that came in

105
05:54.190 --> 05:57.830
from R3, the reported distance based on the sum of the delays and the worst

106
05:57.830 --> 05:58.100
link.

107
05:58.100 --> 06:01.640
When R1 calculated that based on the reported information, it came up with that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

107
05:58.100 --> 06:01.640
When R1 calculated that based on the reported information, it came up with that

108
06:01.640 --> 06:05.930
metric. So that's the advertised distance or reported distance that R1 is

109
06:05.930 --> 06:10.100
receiving from R3 regarding that route to 8888.

110
06:10.100 --> 06:14.730
And the cool thing is most of the show commands are going the same regarding IP

111
06:14.730 --> 06:19.740
v4, EIGRP, whether or not we implemented it as traditional EIGRP or whether we

112
06:19.740 --> 06:21.100
used named EIGRP.

113
06:21.100 --> 06:24.760
So as a reminder, if you do a show run, pipe section router, press enter and

114
06:24.760 --> 06:28.530
give that a moment to process that'll show us the running config regarding our

115
06:28.530 --> 06:30.100
router configuration.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

115
06:28.530 --> 06:30.100
router configuration.

116
06:30.100 --> 06:35.560
So all we typed in was our named EIGRP. We went to address family for IPv4 Unic

117
06:35.560 --> 06:40.410
ast for a time system 100. And then we did nothing with the topology base. We

118
06:40.410 --> 06:45.320
left it as default. And then all we did was specify network 0, 0, 0, 0. And

119
06:45.320 --> 06:47.100
everything else you see here is based on the defaults.

120
06:47.100 --> 06:51.530
So again, the commands can be show IP EIGRP interface and also in the notepad

121
06:51.530 --> 06:55.770
document. If you're doing this lab with me, if you scroll the bottom, I have a

122
06:55.770 --> 06:59.100
whole bunch of relevant show commands you might want to play with.

123
06:59.100 --> 07:03.620
So we could just show IP EIGRP interface. We're going to show IP EIGRP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

123
06:59.100 --> 07:03.620
So we could just show IP EIGRP interface. We're going to show IP EIGRP

124
07:03.620 --> 07:06.100
neighbors to see who our neighbors are.

125
07:06.100 --> 07:11.740
Another cool option is show IP EIGRP topology all links now by default there is

126
07:11.740 --> 07:16.130
something called a feasibility condition. In fact, let's find a router and let

127
07:16.130 --> 07:20.100
me tell you about that right now. Let's go to R4.

128
07:20.100 --> 07:23.460
And here on R4, let me bring up the topology. Let's look at it real quick. So

129
07:23.460 --> 07:30.030
here on R4, it is learning about the 8888 network from R2 and from R3 and also
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
07:23.460 --> 07:30.030
here on R4, it is learning about the 8888 network from R2 and from R3 and also

130
07:30.030 --> 07:31.100
from R6.

131
07:31.100 --> 07:35.980
So if we did a show IP EIGRP topology and press down or and I'm going to go

132
07:35.980 --> 07:40.680
down a little bit and take a look at 8888 and I'll just go ahead and do Q for

133
07:40.680 --> 07:41.100
quit.

134
07:41.100 --> 07:44.750
So here knows about that route. There is the metric for it, which is like 11

135
07:44.750 --> 07:48.100
billion 552. And that is the winning route right there.

136
07:48.100 --> 07:52.120
So that feasible distance for the successor out is the metric that it has for

137
07:52.120 --> 07:56.100
this route that it learned based on that last octet coming from R2.

138
07:56.100 --> 08:00.350
So this is the feasible distance for the successor out. There's the effective
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

138
07:56.100 --> 08:00.350
So this is the feasible distance for the successor out. There's the effective

139
08:00.350 --> 08:04.100
result of the details from the reported distance coming in from R2.

140
08:04.100 --> 08:09.660
And we have two feasible successors. These two routes did not make it into the

141
08:09.660 --> 08:13.420
routing table because they didn't have a better or lower final metric or

142
08:13.420 --> 08:16.100
feasible distance than the prior route.

143
08:16.100 --> 08:19.950
So let me tell you about these two feasible successors that could if the

144
08:19.950 --> 08:23.460
primary successor out goes way that they could be installed in the routing

145
08:23.460 --> 08:24.100
table.

146
08:24.100 --> 08:27.100
The reason these two routes are here and being shown even though they're not

147
08:27.100 --> 08:30.900
the winning routes or feasible successors, they could be winning routes if the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

147
08:27.100 --> 08:30.900
the winning routes or feasible successors, they could be winning routes if the

148
08:30.900 --> 08:34.580
primary route goes way is because they meet something called the feasibility

149
08:34.580 --> 08:35.100
condition.

150
08:35.100 --> 08:39.260
And here's what the feasibility condition means. So we're focusing on R4. So

151
08:39.260 --> 08:43.380
far four has three potential paths that it can forward to get to 8888. One has

152
08:43.380 --> 08:45.100
a better metric and that's going to R2.

153
08:45.100 --> 08:49.200
So I'm going to put R2 here as the successor out. That's the winner route. So

154
08:49.200 --> 08:52.100
our four of these four of the packet is going to forward to R2.

155
08:52.100 --> 08:56.690
But where are the other two potential paths are dot six and that's our six

156
08:56.690 --> 09:01.100
based on that last octet and R3. So I'll draw the 8888 network down here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

156
08:56.690 --> 09:01.100
based on that last octet and R3. So I'll draw the 8888 network down here.

157
09:01.100 --> 09:04.540
So in these three routes are reporting that information. They're all reporting

158
09:04.540 --> 09:09.100
the sum of the delays. That's the K3 aspect regarding the metric calculation.

159
09:09.100 --> 09:14.100
And they're also reporting the minimum bandwidth in the path and that's the K1.

160
09:14.100 --> 09:19.590
So as R6 and R3 are reporting that information if and only if the result of the

161
09:19.590 --> 09:22.890
calculation that R4 is doing based on the reported distance coming from R6 and

162
09:22.890 --> 09:23.100
R3.

163
09:23.100 --> 09:26.400
Only if that information the reported distance and I'll go ahead and get arrows

164
09:26.400 --> 09:30.100
here as well. That reported distance is right here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

164
09:26.400 --> 09:30.100
here as well. That reported distance is right here.

165
09:30.100 --> 09:34.440
So there's a reported distance coming in from R6 and here is the reported

166
09:34.440 --> 09:38.100
distance coming in from R3 based on those last two octets.

167
09:38.100 --> 09:43.010
So the feasibility condition says I will consider them as usable routes if

168
09:43.010 --> 09:48.280
these advertised distances here also known as reported distances are lower than

169
09:48.280 --> 09:52.100
the current feasible distance or the current metric for the successor route.

170
09:52.100 --> 09:58.430
So we look at this number here 11 billion 552 here we have 11 billion 550. So

171
09:58.430 --> 10:03.100
that reported distance coming in from R3 is lower than the current final metric
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

171
09:58.430 --> 10:03.100
that reported distance coming in from R3 is lower than the current final metric

172
10:03.100 --> 10:04.100
for the winning route.

173
10:04.100 --> 10:08.290
And the route being advertised without six is significantly lower than the

174
10:08.290 --> 10:12.400
final metric. So as a result these two routes are considered feasible success

175
10:12.400 --> 10:16.670
ors because they meet the feasibility condition that is the reported information

176
10:16.670 --> 10:20.740
coming from R3 and R6 when R4 to the calculation based on that reported

177
10:20.740 --> 10:24.970
distance their reported distance is lower than the value of the metric for the

178
10:24.970 --> 10:26.100
winning route.

179
10:26.100 --> 10:29.740
So this is the feasible distance right here for the winning route and these two

180
10:29.740 --> 10:33.110
right here are the reported distances and the calculation based on that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

180
10:29.740 --> 10:33.110
right here are the reported distances and the calculation based on that

181
10:33.110 --> 10:36.100
reported distance information coming in from R6 and R3.

182
10:36.100 --> 10:40.550
And that's going to be true for all the feasible successor shown. So here we

183
10:40.550 --> 10:44.100
have one successor for the 1001 network. There's the feasible distance.

184
10:44.100 --> 10:46.990
Here is that winning route right there feasible distance again on the right we

185
10:46.990 --> 10:50.100
have the advertised or reported distance that's coming in from the neighbor.

186
10:50.100 --> 10:53.880
And this metric right here which is way higher than the successor metric and

187
10:53.880 --> 10:58.070
that's why it's not in the routing table. The reason is here is because this

188
10:58.070 --> 11:02.100
advertised distance the reported distance if you will coming in from R3 is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

188
10:58.070 --> 11:02.100
advertised distance the reported distance if you will coming in from R3 is

189
11:02.100 --> 11:04.100
still lower than the final metric for the winning route.

190
11:04.100 --> 11:07.900
So because it's lower they reported distance coming in from R3 it is considered

191
11:07.900 --> 11:12.360
a feasible successor. So if we had another route that came in and the reported

192
11:12.360 --> 11:17.100
distance was higher than our current metric for the winning route we wouldn't

193
11:17.100 --> 11:19.100
even show it here by default because it doesn't meet the feasibility condition.

194
11:19.100 --> 11:23.440
Now there is one other command let me go ahead and create a screen. There is

195
11:23.440 --> 11:26.590
one other command we could do if you want to see the additional routes that don

196
11:26.590 --> 11:28.100
't meet the feasibility condition.

197
11:28.100 --> 11:33.450
You could go into a show IP EADGRP topology and then a question mark and the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

197
11:28.100 --> 11:33.450
You could go into a show IP EADGRP topology and then a question mark and the

198
11:33.450 --> 11:39.440
option is right there all links. So I could type in all dash links press enter

199
11:39.440 --> 11:43.800
and that's going to show us every single route the successor routes and

200
11:43.800 --> 11:45.100
feasible successors.

201
11:45.100 --> 11:49.060
It's also going to show us routes that are not feasible successors. So just to

202
11:49.060 --> 11:52.790
compare and contrast that real quick we do a show IP EADGRP topology press

203
11:52.790 --> 11:56.100
enter and let's take just look at the first five or six routes there.

204
11:56.100 --> 12:00.100
And we do it again with the all links press enter and there is a difference.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

204
11:56.100 --> 12:00.100
And we do it again with the all links press enter and there is a difference.

205
12:00.100 --> 12:03.110
Let's just scroll up and see where that difference is without the all links.

206
12:03.110 --> 12:08.100
Let's take a look at the 1017 network. We have a successor route and that's

207
12:08.100 --> 12:08.100
this one right here.

208
12:08.100 --> 12:11.670
And then we have a feasible successor right here and that's because this value

209
12:11.670 --> 12:15.180
right here the report distance is lower than our current final metric and this

210
12:15.180 --> 12:20.370
is making it in. However, when we did the show IP EADGRP topology and we use

211
12:20.370 --> 12:24.100
the option of all links we take the same network look at this is now showing us

212
12:24.100 --> 12:25.100
three.

213
12:25.100 --> 12:29.490
So we solve one successor that's this route right here coming in for two and we

214
12:29.490 --> 12:33.710
saw the feasible successor right here but look at this one this route which is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

214
12:29.490 --> 12:33.710
saw the feasible successor right here but look at this one this route which is

215
12:33.710 --> 12:37.740
advertised by our six based on that last octet of dot six right there it's

216
12:37.740 --> 12:43.310
reported distance it looks like 11 billion 557 which is way the heck higher

217
12:43.310 --> 12:46.640
than the current metric for the winning route and as a result this route right

218
12:46.640 --> 12:49.790
here is not a feasible successor and that's why it wouldn't show it to us by

219
12:49.790 --> 12:51.100
default.

220
12:51.100 --> 12:55.470
We did the command again with show IP EADGRP topology and no all links option

221
12:55.470 --> 13:00.410
press dinner and then we look at that 10.17 route it's showing us the successor
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

221
12:55.470 --> 13:00.410
press dinner and then we look at that 10.17 route it's showing us the successor

222
13:00.410 --> 13:05.100
route which is through dot two and the feasible successor which is dot three

223
13:05.100 --> 13:09.100
but it's no longer showing us we scroll up it's not showing us the non feasible

224
13:09.100 --> 13:12.100
successor here going through dot six.

225
13:12.100 --> 13:15.960
We've got all these commands you want to practice and play with them in the lab

226
13:15.960 --> 13:19.510
assignment I put all them right here as well so we did a show IP EADGRP top

227
13:19.510 --> 13:23.780
ology from our four and let's take a look at our topology once again so from our

228
13:23.780 --> 13:27.840
four let's look at the details for network eight eight eight eight which is

229
13:27.840 --> 13:29.100
loop back down on our eight.

230
13:29.100 --> 13:32.520
We just show EADGRP topology until we get the eight eight eight network here
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

230
13:29.100 --> 13:32.520
We just show EADGRP topology until we get the eight eight eight network here

231
13:32.520 --> 13:36.030
showing us that we have one successor one winning route there's its feasible

232
13:36.030 --> 13:40.460
distance or metric and then we have two feasible successors that could be used

233
13:40.460 --> 13:44.100
in the event that primary route goes way so based on the metric we're looking

234
13:44.100 --> 13:48.770
at that's the successor route and then our six and our three both meet the feas

235
13:48.770 --> 13:52.750
ibility condition and that's why those routes are also showing up here with the

236
13:52.750 --> 13:58.100
command show IP EADGRP topology however if we did a trace to and let's go ahead

237
13:58.100 --> 13:58.100
and do it long hand here.

238
13:58.100 --> 14:02.820
We'll go to eight eight eight eight and we'll go ahead and say please repeat
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

238
13:58.100 --> 14:02.820
We'll go to eight eight eight eight and we'll go ahead and say please repeat

239
14:02.820 --> 14:07.450
the probe count let's do ten times and press enter and then we'll press enter

240
14:07.450 --> 14:10.870
all the way through notice that it's taking the same first hop every single

241
14:10.870 --> 14:14.970
time through dot two and then for the second hop our two is in 14 and over to R

242
14:14.970 --> 14:19.470
1 and R1 is in R3 and then R3 is sitting down to R8 based on the last octets as

243
14:19.470 --> 14:24.220
shown right here and that's because we did a show IP route for eight eight

244
14:24.220 --> 14:27.100
eight eight and we could put the final eight there there's our next hop.

245
14:27.100 --> 14:31.310
And for the calculation for the final metric there is the total delay and there
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

245
14:27.100 --> 14:31.310
And for the calculation for the final metric there is the total delay and there

246
14:31.310 --> 14:36.140
is the minimum bandwidth in the path that we're used as part of the calculation

247
14:36.140 --> 14:40.630
to get that final metric and that final metric is right here we can all see

248
14:40.630 --> 14:44.760
that metric in the routing table with the show IP route press enter and go up

249
14:44.760 --> 14:48.390
to the eight eight eight network right here and there's that metric once again

250
14:48.390 --> 14:49.100
for that route.

251
14:49.100 --> 14:52.730
So currently our four only has one path for the eight eight eight network that

252
14:52.730 --> 14:56.570
's using the feasible successor the winning route and that's setting it up to R2

253
14:56.570 --> 15:01.460
it's not considering other feasible successors for example our three going over
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

253
14:56.570 --> 15:01.460
it's not considering other feasible successors for example our three going over

254
15:01.460 --> 15:06.030
the left or our six going straight down it's only using the best route in the

255
15:06.030 --> 15:06.100
path.

256
15:06.100 --> 15:09.520
However with eagrp if we want to say you know what if you've got some

257
15:09.520 --> 15:13.610
additional feasible successors go ahead and start using them we can do that as

258
15:13.610 --> 15:18.100
well so the next video I'll walk you through both options for doing one for

259
15:18.100 --> 15:22.770
traditional eagrp and another for named eagrp and it's using the feature of

260
15:22.770 --> 15:26.720
variance inside the routing protocol so I'll see you in the next video for

261
15:26.720 --> 15:27.100
exactly that.