WEBVTT 1 00:00.000 --> 00:02.640 To appreciate our EIGRP routing protocol, 2 00:02.640 --> 00:05.200 let's first take a look at our topology as it currently sits. 3 00:05.200 --> 00:07.920 And this is also the topology you'll be having an opportunity 4 00:07.920 --> 00:10.080 to practice with in the lab coming up. 5 00:10.080 --> 00:12.480 So we've got eight routers on the left hand side. 6 00:12.480 --> 00:14.800 I've got router 1, 3, 5, and 7, 7 00:14.800 --> 00:17.760 and on the right hand side I've got R2, 4, 6, and 8. 8 00:17.760 --> 00:21.440 There's also running on this topology both IPv4 and IPv6. 9 00:21.440 --> 00:24.880 For this set of videos on EIGRP, we'll be focusing on IPv6. 10 00:24.880 --> 00:28.240 And then in the lab, I've got a client-nud machine 11 00:28.240 --> 00:32.080 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 11 00:28.240 --> 00:32.080 at 10.0.150. It's on the 10.0.1 network sitting here on our topology. 12 00:32.080 --> 00:34.720 I've also got server 1 nug down here on our topology 13 00:34.720 --> 00:39.280 at 192.1 state 1, 100 on the 192.1 state 1 network. 14 00:39.280 --> 00:42.320 And then I have all the other subnets that's shown here for IPv4. 15 00:42.320 --> 00:44.480 So for example, between R1 and R3, 16 00:44.480 --> 00:47.600 I have subnet 10.0.13 between R1 and R2, 17 00:47.600 --> 00:50.320 subnet 0.12, just using the two router numbers. 18 00:50.320 --> 00:54.080 Then down here, 10.135 between R3 and R5, 19 00:54.080 --> 00:56.800 10.157 between R5 and R7. 20 00:56.800 --> 01:00.880 And then on the right hand side, between R4 and R6, 10.246, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 20 00:56.800 --> 01:00.880 And then on the right hand side, between R4 and R6, 10.246, 21 01:00.880 --> 01:03.840 and between R6 and R8, 10.268. 22 01:03.840 --> 01:05.760 And over here is the 10.17 network. 23 01:05.760 --> 01:09.200 And hanging off of R8, I've got the 192.1 state 1 network. 24 01:09.200 --> 01:12.320 And that's the lay of the land regarding IPv4 addressing. 25 01:12.320 --> 01:15.680 Also for the connections, I've drawn the fast ethernet connections, 26 01:15.680 --> 01:17.520 100 megabits per second in yellow. 27 01:17.520 --> 01:21.040 They're also labeled as such with the F there for fast ethernet. 28 01:21.040 --> 01:22.160 I've got these green links. 29 01:22.160 --> 01:24.880 Those are all gigabit ethernet, labeled appropriately with the G 30 01:24.880 --> 01:27.680 in front of the interfaces that are connecting the routers to those segments. 31 01:27.680 --> 01:29.520 And then also for the benefit of really appreciating 32 01:29.520 --> 01:32.570 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 32 01:29.520 --> 01:32.570 or routing protocols and how they work with the various bandwidths and so forth 33 01:32.570 --> 01:32.720 . 34 01:32.720 --> 01:34.480 I've also got three serial links. 35 01:34.480 --> 01:38.240 A serial link between R3 and R8, that's 10.380, 36 01:38.240 --> 01:40.960 one between R7 and R8, 10.780, 37 01:40.960 --> 01:45.280 and one between R4 and R6, and that's 10.2.46. 38 01:45.280 --> 01:47.760 And instead of taking the default bandwidth on these serial links, 39 01:47.760 --> 01:50.240 which are these like 1.54 megabits per second, 40 01:50.240 --> 01:52.480 I have set on each of these serial interfaces, 41 01:52.480 --> 01:55.600 a bandwidth of 64 kilovits per second. 42 01:55.600 --> 01:58.560 So that's here for this link, and also true for that link, 43 01:58.560 --> 01:59.680 and for that link. 44 01:59.680 --> 02:03.200 And I set that on the interfaces that are connecting those routers WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 44 01:59.680 --> 02:03.200 And I set that on the interfaces that are connecting those routers 45 02:03.200 --> 02:04.560 to those serial networks. 46 02:04.560 --> 02:06.240 So once again, gigabit is gigabit, 47 02:06.240 --> 02:07.600 fast ethernet is fast ethernet, 48 02:07.600 --> 02:10.560 and the serial links are 64 kilovits per second. 49 02:10.560 --> 02:12.320 All right, so let me clean that up a little bit. 50 02:12.320 --> 02:14.400 And let's talk about some characteristics regarding 51 02:14.400 --> 02:17.360 the enhanced interior gateway routing protocol. 52 02:17.360 --> 02:20.240 Now, EIGRP is considered to be an advanced 53 02:20.240 --> 02:22.320 distance vector routing protocol. 54 02:22.320 --> 02:24.160 And the question may come up, well, why is it exactly 55 02:24.160 --> 02:26.240 an advanced distance vector routing protocol? 56 02:26.240 --> 02:30.000 To start off, these routers, as they form adjacencies WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 57 02:30.000 --> 02:33.760 with other EIGRP routers, they only know what those directly 58 02:33.760 --> 02:35.360 connected neighbors are telling them. 59 02:35.360 --> 02:39.840 So for example, R1 here only knows what it hears coming in from R2 60 02:39.840 --> 02:40.800 and from R3. 61 02:40.800 --> 02:43.440 Now, R2 and R3 may have information about routes 62 02:43.440 --> 02:45.760 that are downstream, for example, the 10.780 network, 63 02:45.760 --> 02:49.280 or the 8888 address that loop back address here on R8. 64 02:49.280 --> 02:52.160 But at the end of the day, it's really trusting what information 65 02:52.160 --> 02:54.560 it got from its directly connected neighbors. 66 02:54.560 --> 02:58.880 Now, if we compare that to OSPF, if this was one giant OSPF area, 67 02:58.880 --> 03:02.320 every router would have seen the LSAs from every other router. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 67 02:58.880 --> 03:02.320 every router would have seen the LSAs from every other router. 68 03:02.320 --> 03:04.480 And as a result, they would have direct knowledge 69 03:04.480 --> 03:06.240 on all the directly connected networks. 70 03:06.240 --> 03:08.080 And that information would have come from the source. 71 03:08.080 --> 03:11.360 For example, in OSPF, R7's information about 72 03:11.360 --> 03:14.720 its links that's connected to and so forth would be learned by R1. 73 03:14.720 --> 03:16.560 Because those LSAs, the links they had advertised 74 03:16.560 --> 03:19.040 would be propagated and advertised all the way up to R1. 75 03:19.040 --> 03:21.280 Again, assuming this is one giant OSPF area. 76 03:21.280 --> 03:24.960 But getting back to ERGRP, ERGRP doesn't play that way. 77 03:24.960 --> 03:29.600 So information can be propagated from R7 to R5 and R5 to R3 and R3 to R1. 78 03:29.600 --> 03:32.160 So R1 will learn information that R3 is sending WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 78 03:29.600 --> 03:32.160 So R1 will learn information that R3 is sending 79 03:32.160 --> 03:33.360 and that R2 is sending. 80 03:33.360 --> 03:37.200 But it won't have direct knowledge about remote routers 81 03:37.200 --> 03:38.880 and their directly connected links. 82 03:38.880 --> 03:41.280 Now, what makes it advanced is also that it's using 83 03:41.280 --> 03:44.000 hello messages and it's building neighborships 84 03:44.000 --> 03:45.360 between the routers. 85 03:45.360 --> 03:48.080 So R1 knows it has a formal adjacency, if you will, 86 03:48.080 --> 03:51.760 with R2, with ERGRP and with R3 and vice versa. 87 03:51.760 --> 03:54.320 And that's if they agree on some basic concepts. 88 03:54.320 --> 03:56.800 And for those holos, we're using multicast 89 03:56.800 --> 03:59.760 and that multicast address ends in .10 with IPv4, 90 03:59.760 --> 04:04.160 or A, which is the equivalent of 10 in hexadecimal with IPv6. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 03:59.760 --> 04:04.160 or A, which is the equivalent of 10 in hexadecimal with IPv6. 91 04:04.160 --> 04:06.400 It also uses its own layer for protocol 92 04:06.400 --> 04:08.480 and that is protocol number 88. 93 04:08.480 --> 04:10.480 So it's not using TCP or UDP. 94 04:10.480 --> 04:13.280 It's using its own layer for protocol, protocol 88. 95 04:13.280 --> 04:17.440 Another cool feature of ERGRP is that if it's configured to do so, 96 04:17.440 --> 04:20.000 it can do proportional load balancing. 97 04:20.000 --> 04:21.360 And let me give you an example of that. 98 04:21.360 --> 04:23.680 So let's imagine we have a router 4 here. 99 04:23.680 --> 04:25.680 And it wants to go ahead and be able to route 100 04:25.680 --> 04:28.720 or forward packets down to, let's use the loopback on R8, 101 04:28.720 --> 04:31.040 which is 8.8.8.8.8. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 101 04:28.720 --> 04:31.040 which is 8.8.8.8.8. 102 04:31.040 --> 04:32.560 Sorry, Google, I know that's also your DNS, 103 04:32.560 --> 04:34.640 but in the lab environment, each of the routers 104 04:34.640 --> 04:38.960 has a loop packet rest, loop x0, using its router number 4 times. 105 04:38.960 --> 04:42.720 So it'd be 8.8.8.8 here and 7777 here 106 04:42.720 --> 04:44.320 and 1111 here and so forth. 107 04:44.320 --> 04:45.680 So we're going to R4. 108 04:45.680 --> 04:49.760 Let's imagine it's learning how to reach the 8.8.8 network from R2 109 04:49.760 --> 04:52.400 and also from its advertisements coming in from R3 110 04:52.400 --> 04:55.040 and also its advertisements coming in from R6. 111 04:55.040 --> 04:57.760 Now it's super likely that one of those routes 112 04:57.760 --> 04:59.440 this learning is going to be the best. 113 04:59.440 --> 05:01.040 It's going to have the lowest metric WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 113 04:59.440 --> 05:01.040 It's going to have the lowest metric 114 05:01.040 --> 05:02.640 and as a result, it's going to be the winner 115 05:02.640 --> 05:04.000 and placed in the routing table. 116 05:04.000 --> 05:06.560 And just for Grins, because it's going to be super important later as well, 117 05:06.560 --> 05:09.120 let me just jot down here that the winning route, 118 05:09.120 --> 05:10.800 the one that gets put into the routing table 119 05:10.800 --> 05:12.160 because it has the lowest metric, 120 05:12.160 --> 05:16.160 that winning route has a very fun name in the world of EIGRP 121 05:16.160 --> 05:19.120 and that name is the successor or the successor route. 122 05:19.120 --> 05:21.200 So I'm going to put in parentheses the word route 123 05:21.200 --> 05:24.560 just to help us remember that's the winning route in the routing table. 124 05:24.560 --> 05:25.840 Call these successor routes. 125 05:25.840 --> 05:28.160 Now in the case of R4, if we had some other routes 126 05:28.160 --> 05:30.240 that could also potentially be used WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 126 05:28.160 --> 05:30.240 that could also potentially be used 127 05:30.240 --> 05:32.480 and we'll call those feasible successors, 128 05:32.480 --> 05:35.520 by default EIGRP is only going to take the best route 129 05:35.520 --> 05:36.320 and put in the routing table. 130 05:36.320 --> 05:40.000 But if we modify how it operates with this load balancing, 131 05:40.000 --> 05:40.960 we can say, you know what? 132 05:40.960 --> 05:43.760 If the second and third feasible successors, 133 05:43.760 --> 05:45.520 we can think of those like backup routes. 134 05:45.520 --> 05:48.480 So one thing we could do is we could tell R4 that, hey, you know what? 135 05:48.480 --> 05:51.440 If you have these feasible successors potential backup routes, 136 05:51.440 --> 05:53.280 in case the primary route goes away, 137 05:53.280 --> 05:56.000 if they have metrics that are, for example, 138 05:56.000 --> 05:59.120 no worse than two times the successor metric, 139 05:59.120 --> 06:00.800 meaning they're not twice as bad, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 139 05:59.120 --> 06:00.800 meaning they're not twice as bad, 140 06:00.800 --> 06:02.400 something less than twice as bad, 141 06:02.400 --> 06:03.920 go ahead and use those as well 142 06:03.920 --> 06:06.320 and do proportional load balancing with them. 143 06:06.320 --> 06:10.160 So assuming that the other two routes met that condition, 144 06:10.160 --> 06:12.880 not being twice as bad as the primary route, 145 06:12.880 --> 06:15.360 they could then be added into the routing table 146 06:15.360 --> 06:17.920 and then load balance across all three paths. 147 06:17.920 --> 06:20.560 And again, if we said we were using 2x for our variance 148 06:20.560 --> 06:23.120 between the best route, any possible backup routes 149 06:23.120 --> 06:24.720 and these two routes fill in that category 150 06:24.720 --> 06:26.000 where they qualified for that, 151 06:26.000 --> 06:27.520 then we'd have a total of three routes 152 06:27.520 --> 06:30.320 that could be used and placed in the routing table for R4 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 06:27.520 --> 06:30.320 that could be used and placed in the routing table for R4 153 06:30.320 --> 06:32.400 regarding the destination network, 8888. 154 06:32.400 --> 06:33.760 So make clean that up a little bit 155 06:33.760 --> 06:36.320 and let's talk about a few other functions 156 06:36.320 --> 06:38.800 and basic characteristics regarding EIGRP. 157 06:38.800 --> 06:41.360 Now, one of the interesting aspects of using EIGRP 158 06:41.360 --> 06:43.600 is that there's more than just one way to configure it. 159 06:43.600 --> 06:45.200 We can use the traditional method, 160 06:45.200 --> 06:47.120 which we use for decades and decades, 161 06:47.120 --> 06:50.240 or we could go ahead and use named EIGRP. 162 06:50.240 --> 06:51.680 And as we proceed through these videos, 163 06:51.680 --> 06:53.200 I'll give you demonstrations of each 164 06:53.200 --> 06:55.120 and at the tail end of this skill, 165 06:55.120 --> 06:58.000 I'll also give the opportunity to practice configuring it 166 06:58.000 --> 06:59.120 in either way you want. 167 06:59.120 --> 07:02.400 And I've got a little notepad file sitting here on server 1nug WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 167 06:59.120 --> 07:02.400 And I've got a little notepad file sitting here on server 1nug 168 07:02.400 --> 07:05.120 that can help you at the syntax as well if you'd like to use it. 169 07:05.120 --> 07:06.320 Now, when looking at routes, 170 07:06.320 --> 07:08.400 each routing protocol has its own way 171 07:08.400 --> 07:11.920 of identifying the cost or the metric of a route. 172 07:11.920 --> 07:13.760 And so in the world of EIGRP, 173 07:13.760 --> 07:16.960 the cost is referred to as a metric. 174 07:16.960 --> 07:20.320 And although EIGRP is sharing a lot of information 175 07:20.320 --> 07:21.440 with its neighbors, 176 07:21.440 --> 07:24.000 it shares information, for example, about M2U 177 07:24.000 --> 07:28.480 and reliability and load and bandwidth and delay, 178 07:28.480 --> 07:32.000 the actual default metric calculation boils down to this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 178 07:28.480 --> 07:32.000 the actual default metric calculation boils down to this 179 07:32.000 --> 07:34.480 is the sum of the delays. 180 07:34.480 --> 07:35.920 So let's imagine we're focused right here 181 07:35.920 --> 07:38.880 on the 8.8.8.8 network here on our 8. 182 07:38.880 --> 07:40.240 And let's also go back to our 4. 183 07:40.240 --> 07:42.880 So our 4 is learning about the network here from R2 184 07:42.880 --> 07:45.040 and also from R3 and also from R4. 185 07:45.040 --> 07:48.720 And in this case, R6 and R3 and R2 are all reporting 186 07:48.720 --> 07:52.880 the information regarding the delays involved up to that point. 187 07:52.880 --> 07:56.480 And so our 4 is going to be receiving the current sum of delays 188 07:56.480 --> 07:57.760 from the perspective of R2. 189 07:57.760 --> 08:01.280 They call that the reported distance or RD for short. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 189 07:57.760 --> 08:01.280 They call that the reported distance or RD for short. 190 08:01.280 --> 08:03.360 So R2 is going to have a reported distance 191 08:03.360 --> 08:05.200 and R3 is going to have a reported distance 192 08:05.200 --> 08:07.200 and R6 is going to have a reported distance 193 08:07.200 --> 08:08.720 all being fed into R4. 194 08:08.720 --> 08:10.800 And part of that reported distance is going to be 195 08:10.800 --> 08:12.800 from each of those routers perspectives, 196 08:12.800 --> 08:14.480 the sum of the delays. 197 08:14.480 --> 08:16.480 So as far as the delays are concerned, 198 08:16.480 --> 08:18.800 each link has an associated delay with it. 199 08:18.800 --> 08:22.080 So a gigabit ethernet interface is going to have a fairly low 200 08:22.080 --> 08:23.920 static delay associated with it, 201 08:23.920 --> 08:26.880 a fast event is going to have a greater delay associated with it. 202 08:26.880 --> 08:28.160 And then on these serial links, 203 08:28.160 --> 08:30.400 by default it's like 1.54 megabits. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 203 08:28.160 --> 08:30.400 by default it's like 1.54 megabits. 204 08:30.400 --> 08:34.240 I artificially configured a 64 kilobit per second bandwidth 205 08:34.240 --> 08:37.280 on the interfaces, which caused a considerably worse delay 206 08:37.280 --> 08:39.120 factor regarding these serial links. 207 08:39.120 --> 08:40.880 So when R4 receives all this information, 208 08:40.880 --> 08:42.720 it's going to consider the sum of the delays 209 08:42.720 --> 08:46.240 and it's also going to consider the slowest link. 210 08:46.240 --> 08:50.160 And as part of the advertisements coming in to R4 from R2 211 08:50.160 --> 08:52.640 and also from R3 and also from R6, 212 08:52.640 --> 08:54.320 they are reporting the slowest links. 213 08:54.320 --> 08:57.440 And to help reinforce that, let's go ahead and use R1 214 08:57.440 --> 09:00.240 as an example, because R1 is not directly connected WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 214 08:57.440 --> 09:00.240 as an example, because R1 is not directly connected 215 09:00.240 --> 09:02.000 to any slow serial links. 216 09:02.000 --> 09:04.880 So here's our one up here and it's going to be having information 217 09:04.880 --> 09:07.200 with the reported distance coming in from R3 218 09:07.200 --> 09:10.000 and also report distance coming in from R2. 219 09:10.000 --> 09:13.360 And that report distance is going to include the sum of the delays 220 09:13.360 --> 09:16.320 from R3's perspective and R2's perspective 221 09:16.320 --> 09:18.400 getting down to that network 8888. 222 09:18.400 --> 09:21.120 And each of those are also going to report the slowest link in the path. 223 09:21.120 --> 09:26.720 So here on R8, let's imagine that it's advertising the route up to R3 224 09:26.720 --> 09:29.440 and R3 realizes this link that's directly connected to 225 09:29.440 --> 09:31.600 has a bandwidth of 64K. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 225 09:29.440 --> 09:31.600 has a bandwidth of 64K. 226 09:31.600 --> 09:34.400 And so as it does the reported distance up to R1 227 09:34.400 --> 09:37.520 about that 8888 network down here, it's going to report that, 228 09:37.520 --> 09:40.880 oh, you know what, the worst link in this whole path is 64K. 229 09:40.880 --> 09:43.440 And so R1 will get that information 230 09:43.440 --> 09:46.000 in the routing updates coming into it from R3. 231 09:46.000 --> 09:48.080 And R2 will also have that slowest link as well, 232 09:48.080 --> 09:50.720 because let's say the advertisement went here 233 09:50.720 --> 09:52.560 and then here and then here. 234 09:52.560 --> 09:56.000 So that information is propagated from R6 over here to R4 235 09:56.000 --> 09:58.880 and R4 is learning it here on a slow serial link. 236 09:58.880 --> 10:02.320 R4 when it advertises up to R2 and its reported distance WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 236 09:58.880 --> 10:02.320 R4 when it advertises up to R2 and its reported distance 237 10:02.320 --> 10:05.840 as part of the information conveyed, it's going to indicate that the worst 238 10:05.840 --> 10:07.600 bandwidth in the path is 64K. 239 10:07.600 --> 10:09.760 And as a result, R2 is going to say, you know what? 240 10:09.760 --> 10:12.800 R4 told me that we're spanned within the path, 64K. 241 10:12.800 --> 10:14.960 So that's when it reports you, again, 242 10:14.960 --> 10:17.440 regarding this route 8.8.8. 243 10:17.440 --> 10:20.560 Now it's also interesting to note that there's a lot of additional information 244 10:20.560 --> 10:22.880 that's being reported and advertised 245 10:22.880 --> 10:25.360 in these neighbor advertisements and route updates 246 10:25.360 --> 10:26.480 that are going back and forth. 247 10:26.480 --> 10:29.280 But the only two that are being used by default 248 10:29.280 --> 10:32.720 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 248 10:29.280 --> 10:32.720 is the sum of the delays for all the links involved in the path. 249 10:32.720 --> 10:35.040 And then we're also using the slowest link. 250 10:35.040 --> 10:36.720 And then there's a multiplier as well. 251 10:36.720 --> 10:39.440 And to make this clear, I'm also not going to play dividing line there. 252 10:39.440 --> 10:41.200 So it's not dividing the slowest link in this. 253 10:41.200 --> 10:43.200 So it's taking these sum of the delays, 254 10:43.200 --> 10:45.580 whatever that sum is up to the point where the routers are making the 255 10:45.580 --> 10:46.400 calculation. 256 10:46.400 --> 10:47.920 It's also considering the slower link. 257 10:47.920 --> 10:49.200 It's doing some math on that. 258 10:49.200 --> 10:51.360 And that's what's calculating the actual metric. 259 10:51.360 --> 10:54.160 So it's not by default considering the load 260 10:54.160 --> 10:58.560 or the M2 or the number of hops, even though all of that information is also 261 10:58.560 --> 10:59.280 communicated 262 10:59.280 --> 11:01.600 for a routing update with EIDGRP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 262 10:59.280 --> 11:01.600 for a routing update with EIDGRP. 263 11:01.600 --> 11:03.600 So as an example, to reinforce that, 264 11:03.600 --> 11:07.700 here is a route update that I captured with Wireshark on one of the links 265 11:07.700 --> 11:08.640 between two routers. 266 11:08.640 --> 11:10.320 And I want to focus on the advertisement 267 11:10.320 --> 11:12.960 regarding this route 8.8.8.8/32. 268 11:12.960 --> 11:15.520 As far as the information is being advertised about that route, 269 11:15.520 --> 11:17.200 as this route update is coming in, 270 11:17.200 --> 11:20.640 it indicates the reliability, the load, 271 11:20.640 --> 11:26.080 the M2, the hop count, and none of those values are used by default. 272 11:26.080 --> 11:28.640 The ones that are used are the delay. 273 11:28.640 --> 11:30.640 So that is the sum of the delays. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 273 11:28.640 --> 11:30.640 So that is the sum of the delays. 274 11:30.640 --> 11:32.480 And based on the flavor of EIDGRP 275 11:32.480 --> 11:35.200 that we're using, that could be in microseconds or picoseconds. 276 11:35.200 --> 11:37.440 But either way, we want to be aware that that's what that is. 277 11:37.440 --> 11:41.360 It's the sum of the delays in this advertised route of 8.8.8.8. 278 11:41.360 --> 11:42.160 That's coming in. 279 11:42.160 --> 11:46.320 And for the bandwidth, that is the slowest link in the path 280 11:46.320 --> 11:48.240 towards that target network 8.8.8. 281 11:48.240 --> 11:50.320 So these are the only two values that we really need to worry about, 282 11:50.320 --> 11:53.760 the sum of the delays and the lowest bandwidth in the path. 283 11:53.760 --> 11:56.880 Also, while we're at it, this is an example of a hello message 284 11:56.880 --> 11:59.200 between two EIDGRP neighbors. 285 11:59.200 --> 12:00.320 So based on the source address, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 285 11:59.200 --> 12:00.320 So based on the source address, 286 12:00.320 --> 12:02.720 this is being advertised from 10.013.3. 287 12:02.720 --> 12:04.080 That'd be R3. 288 12:04.080 --> 12:07.040 And the destination is the multicast address for EIDGRP, 289 12:07.040 --> 12:08.720 the one ending in .10. 290 12:08.720 --> 12:10.080 So this is a hello message. 291 12:10.080 --> 12:12.400 And in that hello message, it's also indicating 292 12:12.400 --> 12:14.080 which K values are being used. 293 12:14.080 --> 12:15.200 So if there's a one here, 294 12:15.200 --> 12:16.720 that means that value is being used 295 12:16.720 --> 12:18.400 as part of the metric calculation. 296 12:18.400 --> 12:20.400 And if there's a zero, that means it isn't. 297 12:20.400 --> 12:22.640 So K1 represents the minimum bandwidth 298 12:22.640 --> 12:24.080 up to that point in the path. 299 12:24.080 --> 12:27.360 And K3 represents the sum of the delays up to that point. 300 12:27.360 --> 12:29.200 So as long as all of our routers by default 301 12:29.200 --> 12:30.880 are using just these two values, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 301 12:29.200 --> 12:30.880 are using just these two values, 302 12:30.880 --> 12:33.760 the sum of the delays and the slowest link in the path 303 12:33.760 --> 12:35.120 as part of their calculation, 304 12:35.120 --> 12:36.880 that's one of the elements that has to be agreed on 305 12:36.880 --> 12:38.080 if they're going to become neighbors. 306 12:38.080 --> 12:39.920 And then if they're using that same calculation 307 12:39.920 --> 12:40.960 from their own perspective, 308 12:40.960 --> 12:42.960 each router can make its best decision 309 12:42.960 --> 12:44.240 based on which route we're going to use 310 12:44.240 --> 12:46.560 based on the lowest final metric calculates. 311 12:46.880 --> 12:48.560 So let me clean this up a little bit. 312 12:48.560 --> 12:50.320 And even though we are going to be talking 313 12:50.320 --> 12:52.480 in a separate video in the set of videos 314 12:52.480 --> 12:54.880 about the actual terms and some vocabulary, 315 12:54.880 --> 12:56.960 let me also give you a preview 316 12:56.960 --> 12:59.120 of some of those important vocabulary terms 317 12:59.120 --> 13:00.400 regarding EIGRP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 317 12:59.120 --> 13:00.400 regarding EIGRP. 318 13:00.400 --> 13:01.600 We've already mentioned a few of them. 319 13:01.600 --> 13:03.120 One is reported distance. 320 13:03.120 --> 13:06.720 So if R4 is advertising information to R2, 321 13:06.720 --> 13:08.320 it's going to be using something called 322 13:08.320 --> 13:09.520 reported distance. 323 13:09.520 --> 13:12.240 So I'll put here vocab reported distance. 324 13:12.240 --> 13:14.720 And the only two really important things we care about 325 13:14.720 --> 13:17.520 in reported distance is the information 326 13:17.520 --> 13:19.680 regarding some of the delays that's being advertised 327 13:19.680 --> 13:21.680 or reported and also the slowest link 328 13:21.680 --> 13:24.160 in the path that's being reported by that neighbor. 329 13:24.160 --> 13:27.040 This term also reported distance or RD for short. 330 13:27.040 --> 13:28.640 Also has another way of describing it 331 13:28.640 --> 13:30.400 as advertised distance. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 331 13:28.640 --> 13:30.400 as advertised distance. 332 13:30.400 --> 13:32.560 And the reason I hesitate to even bring that up 333 13:32.560 --> 13:34.640 is because if we abbreviate that, 334 13:34.640 --> 13:37.200 we have AD, which is not represent 335 13:37.200 --> 13:38.320 administrative distance. 336 13:38.320 --> 13:40.160 Advertise distance or reported distance. 337 13:40.160 --> 13:42.080 Just think of it as these two factors 338 13:42.080 --> 13:43.840 that are being reported from a neighbor 339 13:43.840 --> 13:45.760 to another neighbor about a given route. 340 13:45.760 --> 13:47.600 The sum of the delays in the path 341 13:47.600 --> 13:48.960 as well as the slowest link. 342 13:48.960 --> 13:50.960 And that way our two can get that information 343 13:50.960 --> 13:52.400 and to its own number crunching. 344 13:52.400 --> 13:55.040 To figure out of all the routes it's learned about 345 13:55.040 --> 13:57.280 from R1 and from R4 in this case, 346 13:57.280 --> 14:00.240 R2 then do a calculation based on that information WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 346 13:57.280 --> 14:00.240 R2 then do a calculation based on that information 347 14:00.240 --> 14:01.680 to determine which if any routes 348 14:01.680 --> 14:03.200 are going to make it into the routing table. 349 14:03.200 --> 14:04.640 So again, the reported distance, 350 14:04.640 --> 14:07.360 advertised distance, those are the same animal right there. 351 14:07.360 --> 14:10.560 Information being advertised from a neighbor to another neighbor. 352 14:10.560 --> 14:11.520 Another term that we mentioned, 353 14:11.520 --> 14:14.000 which I'll put up here again, is a successor route. 354 14:14.000 --> 14:15.840 So a successor or a successor route, 355 14:15.840 --> 14:17.280 think of that like the winner 356 14:17.280 --> 14:18.960 that makes it into the routing table. 357 14:18.960 --> 14:20.800 And if there's two or three different routes, 358 14:20.800 --> 14:22.560 they have the same exact metric. 359 14:22.560 --> 14:24.640 By default, it'll load balance across all those. 360 14:24.640 --> 14:26.640 Or if they're not quite the same metric, 361 14:26.640 --> 14:29.120 we can tune and tweak it to do load balancing 362 14:29.120 --> 14:30.560 even on unequal paths. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 362 14:29.120 --> 14:30.560 even on unequal paths. 363 14:30.560 --> 14:32.640 But the successor route is the winning route. 364 14:32.640 --> 14:35.680 And the backup routes are called feasible successors. 365 14:35.680 --> 14:38.560 So think of feasible successor as a possible successor. 366 14:38.560 --> 14:40.960 So if that successor or winning route went away, 367 14:40.960 --> 14:43.840 one of the feasible successors could be brought up, 368 14:43.840 --> 14:45.040 put in the routing table, 369 14:45.040 --> 14:46.800 and the router could start to use it right away. 370 14:46.800 --> 14:48.560 So how make a note, it's a backup route. 371 14:48.560 --> 14:50.160 And I'm going to continue our vocabular 372 14:50.160 --> 14:51.600 over here on the right, to have a little more room. 373 14:51.600 --> 14:54.800 So let's say R4, after it's learned all of its information, 374 14:54.800 --> 14:56.960 about the 8.8.8 network. 375 14:56.960 --> 15:00.240 And it's learned that from R6 and R3 and from R2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 375 14:56.960 --> 15:00.240 And it's learned that from R6 and R3 and from R2. 376 15:00.240 --> 15:01.760 Once it does the calculation, 377 15:01.760 --> 15:04.880 which is a sum of the delays and the slowest link in the path, 378 15:04.880 --> 15:07.920 and some math involving multiplying it all by 256. 379 15:07.920 --> 15:10.240 When it comes up with the final metric 380 15:10.240 --> 15:12.240 for the winning route, a successor route, 381 15:12.240 --> 15:15.120 that's referred to as the feasible distance, 382 15:15.120 --> 15:16.720 or FD for short. 383 15:16.720 --> 15:18.480 So if you see a route in the routing table, 384 15:18.480 --> 15:20.320 and has a metric of like 11 billion, 385 15:20.320 --> 15:22.880 or whatever it is for EIGRP for a specific route, 386 15:22.880 --> 15:25.200 that number you're looking at is the feasible distance, 387 15:25.200 --> 15:27.520 the final metric for that route. 388 15:27.520 --> 15:29.200 And so let me just make sure I got all the core terms 389 15:29.200 --> 15:30.080 I wanted to share. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 389 15:29.200 --> 15:30.080 I wanted to share. 390 15:30.080 --> 15:32.080 The reported distance or advertised distance 391 15:32.080 --> 15:34.320 is this information being shared with the neighbor. 392 15:34.320 --> 15:37.760 Regarding a route, the successor route would be the winning route 393 15:37.760 --> 15:39.440 that one that's put in the routing table. 394 15:39.440 --> 15:42.480 The feasible successor routes that could be placed in the routing table 395 15:42.480 --> 15:45.600 if the current successor route is gone or no longer available. 396 15:45.600 --> 15:48.080 And the feasible distance is the final metric 397 15:48.080 --> 15:50.240 that the route is using for a given route 398 15:50.240 --> 15:51.680 to get to a given destination. 399 15:51.680 --> 15:53.760 So here I'm also going to just jot down the metric, 400 15:53.760 --> 15:55.920 because that effectively is what a feasible distance is, 401 15:55.920 --> 15:57.440 it's the metric for that route. 402 15:57.440 --> 16:00.240 Now the core idea in this set of videos WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 402 15:57.440 --> 16:00.240 Now the core idea in this set of videos 403 16:00.240 --> 16:03.280 is to understand how EIGRP works. 404 16:03.280 --> 16:04.560 And so to that light, 405 16:04.560 --> 16:08.000 I want to walk you through configuring EIGRP traditionally, 406 16:08.000 --> 16:09.600 and also with named EIGRP. 407 16:09.600 --> 16:12.560 But instead of making this a typing exercise in the lab 408 16:12.560 --> 16:14.080 at the tail end of this video, 409 16:14.080 --> 16:16.800 I'll give you options of using either one you want. 410 16:16.800 --> 16:18.400 I'll demonstrate both of them first. 411 16:18.400 --> 16:20.960 And I've also got a little notepad document 412 16:20.960 --> 16:24.160 sitting on server one nug with all the appropriate commands 413 16:24.160 --> 16:25.920 that you can use if you want to. 414 16:25.920 --> 16:27.680 So you can refer to that notepad document 415 16:27.680 --> 16:30.000 or if you want to do it manually, either way is great. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 416 16:30.000 --> 16:31.360 Get that hands-on practice. 417 16:31.360 --> 16:32.560 So in the next video, 418 16:32.560 --> 16:35.440 I'd like to take just a moment to walk you through 419 16:35.440 --> 16:38.800 implementing EIGRP using the traditional methods. 420 16:38.800 --> 16:42.000 So I'll see you in the next video for exactly that.