WEBVTT 1 00:00.000 --> 00:05.720 So let's go ahead and draw out a topology here. We have a triangle of three 2 00:05.720 --> 00:06.240 switches 3 00:06.240 --> 00:14.200 and we'll make that top switch our root in the network. And now up until this 4 00:14.200 --> 00:17.960 video we've really just said, "All right, well, you know, one of these links is 5 00:17.960 --> 00:21.360 probably gonna get blocked and so we'll just go ahead and block that." But the 6 00:21.360 --> 00:26.640 question is, which one of these ports is going to go into a blocked state? And 7 00:26.640 --> 00:27.120 for 8 00:27.120 --> 00:32.200 that matter, could it actually be this link or this link? And the answer is yes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 8 00:27.120 --> 00:32.200 that matter, could it actually be this link or this link? And the answer is yes 9 00:32.200 --> 00:32.200 . 10 00:32.200 --> 00:36.040 Even though it's most likely going to end up down here, especially if all of 11 00:36.040 --> 00:36.120 the 12 00:36.120 --> 00:40.360 links are the same bandwidth, but at the same time we need to start to 13 00:40.360 --> 00:44.520 understand what it is that we're looking for. One of the best ways to 14 00:44.520 --> 00:48.960 understand this is to take a look at the fact that back when spanning tree 15 00:48.960 --> 00:49.240 first 16 00:49.240 --> 00:54.960 came out, there could have been a hub here. And this hub could have connected 17 00:54.960 --> 00:55.480 to 18 00:55.480 --> 01:01.480 hosts. And so in today's modern network, if we don't have this setup, we would WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 18 00:55.480 --> 01:01.480 hosts. And so in today's modern network, if we don't have this setup, we would 19 01:01.480 --> 01:05.440 say it doesn't matter whether it's this link or this link, just pick one. As 20 01:05.440 --> 01:05.640 long 21 01:05.640 --> 01:09.800 as there's no loop, we just need to block one of the ends of the links, of this 22 01:09.800 --> 01:10.120 link. 23 01:10.120 --> 01:16.480 But in the original era, these hosts would probably prefer to have the best 24 01:16.480 --> 01:24.480 path. For example, if these two switches were maybe connected on some different 25 01:24.480 --> 01:28.720 connection point, like maybe this is a hundred meg link, and this is a ten meg 26 01:28.720 --> 01:32.880 link, well, we wouldn't want to just arbitrarily choose to block this side, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 26 01:28.720 --> 01:32.880 link, well, we wouldn't want to just arbitrarily choose to block this side, 27 01:32.880 --> 01:37.160 because now these hosts have to go through a much slower connection to get 28 01:37.160 --> 01:41.280 out. Maybe in, if we think about it in modern terms, it would be like saying 29 01:41.280 --> 01:41.480 this 30 01:41.480 --> 01:45.320 is a gig link compared, well, I guess I got it. Yeah, no, that's right. A gig 31 01:45.320 --> 01:45.760 on 32 01:45.760 --> 01:50.440 this side and ten gig on that side. So we'd naturally not want to take the one 33 01:50.440 --> 01:53.960 gig link compared to the ten gig link. And this was true back when we had ten 34 01:53.960 --> 01:58.880 meg and one hundred meg links as well. And so this question of which one is 35 01:58.880 --> 02:05.200 going to matter for a user experience perspective, and the answer of which one WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 35 01:58.880 --> 02:05.200 going to matter for a user experience perspective, and the answer of which one 36 02:05.200 --> 02:11.240 is going to be to say that we want to take the fastest path. So the only 37 02:11.240 --> 02:11.720 question 38 02:11.720 --> 02:17.680 is how do we go about calculating the fastest path? Well, fortunately, we have 39 02:17.680 --> 02:17.720 a 40 02:17.720 --> 02:22.760 way of advertising our costs. When we send out a BP to you, it's going to carry 41 02:22.760 --> 02:22.800 a 42 02:22.800 --> 02:31.080 lot of information, including the cost to the root. Now this cost is going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 02:22.800 --> 02:31.080 lot of information, including the cost to the root. Now this cost is going to 43 02:31.080 --> 02:31.200 be 44 02:31.200 --> 02:34.840 tied to bandwidth. Again, we're looking for the fastest path, and that's 45 02:34.840 --> 02:35.200 usually in 46 02:35.200 --> 02:39.960 terms of megabits or gigabits per second. And so in our case, it's going to be 47 02:39.960 --> 02:45.480 inversely proportional to the bandwidth, meaning that the higher the bandwidth, 48 02:45.480 --> 02:49.800 the higher the speed, the lower the cost. And vice versa, if we have low 49 02:49.800 --> 02:50.240 bandwidth 50 02:50.240 --> 02:54.000 links, then that cost is going to be much higher. And so we want to find the 51 02:54.000 --> 02:54.480 lowest 52 02:54.480 --> 03:01.410 possible cost to the root. So since I'm advertising the cost to both sides, we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 52 02:54.480 --> 03:01.410 possible cost to the root. So since I'm advertising the cost to both sides, we 53 03:01.410 --> 03:01.480 're 54 03:01.480 --> 03:06.760 going to have a sense of who has the fastest path. Now the root is, well, it's 55 03:06.760 --> 03:11.290 already the root. It has the best path of all. It's going to advertise a cost 56 03:11.290 --> 03:11.400 of 57 03:11.400 --> 03:17.040 zero down to these two switches. But when these switches receive the BP to you, 58 03:17.040 --> 03:21.240 they're going to look at the speed of this link, and they're going to calculate 59 03:21.240 --> 03:26.000 their own path to the root or the path cost. And so when we're looking at a 60 03:26.000 --> 03:29.720 cost here, and we'll go into the details on this in a moment, a 10 meg 61 03:29.720 --> 03:30.760 connection WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 61 03:29.720 --> 03:30.760 connection 62 03:30.760 --> 03:39.040 is going to have a cost of 100, and the 100 meg cost defaults to 19. So this 63 03:39.040 --> 03:43.240 switch is going to see that, hey, I've got a cost of 19, I'm going to add these 64 03:43.240 --> 03:47.800 two together, adding zero to anything, it's just itself. And so I've got a cost 65 03:47.800 --> 03:47.880 of 66 03:47.880 --> 03:53.200 19 on the left, and this switch has a cost of 100 to the root. So they're going 67 03:53.200 --> 03:58.720 to advertise this to one another. And we're going to find that, okay, well, we 68 03:58.720 --> 03:58.960 both 69 03:58.960 --> 04:03.480 think that we've got a good path to the root, but I realized that I have the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 69 03:58.960 --> 04:03.480 think that we've got a good path to the root, but I realized that I have the 70 04:03.480 --> 04:03.760 worst 71 04:03.760 --> 04:08.660 path. Since I have the worst path, I'm going to block, which means that you don 72 04:08.660 --> 04:08.760 't 73 04:08.760 --> 04:13.560 have to. And this means that our hosts now are going to hit up the switch that 74 04:13.560 --> 04:19.200 does indeed have the best path to the root. Furthermore, let's say that we were 75 04:19.200 --> 04:25.360 to add another switch all the way down here. And now we might find that we've 76 04:25.360 --> 04:30.840 got, let's just say one gig links, we're starting to modernize our network and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 76 04:25.360 --> 04:30.840 got, let's just say one gig links, we're starting to modernize our network and 77 04:30.840 --> 04:37.240 we've upgraded the links to one gig. Well, one gig actually has a link cost of 78 04:37.240 --> 04:41.800 four when it comes to spanning tree costs. And so what's going to happen here? 79 04:41.800 --> 04:41.960 Well, 80 04:41.960 --> 04:47.120 I'm going to receive my BPDUs down, and I'm going to look at the advertised 81 04:47.120 --> 04:47.480 cost. 82 04:47.480 --> 04:54.320 The advertised cost is 19. And so I'm going to view this as 23 cost. This 83 04:54.320 --> 05:01.480 advertised cost is 100. So I'm going to view this as 104. And now I have two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 83 04:54.320 --> 05:01.480 advertised cost is 100. So I'm going to view this as 104. And now I have two 84 05:01.480 --> 05:06.240 choices. And as we might imagine, I'm going to favor the path going to the left 85 05:06.240 --> 05:06.360 . 86 05:06.360 --> 05:10.850 Because this forms a loop, I'm going to have to block one of these links. And I 87 05:10.850 --> 05:11.040 'm 88 05:11.040 --> 05:15.040 going to look at this and say, well, I far prefer the link on the left. Want to 89 05:15.040 --> 05:15.160 go 90 05:15.160 --> 05:19.280 through a 100 meg connection, even though it's not as fast as a gig, at least 91 05:19.280 --> 05:19.440 it's 92 05:19.440 --> 05:24.400 faster than 10 meg. And that's exactly how we figure this out. So cost of 23 93 05:24.400 --> 05:30.440 beats a cost of 104. And so I block the link on the right. So here's the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 93 05:24.400 --> 05:30.440 beats a cost of 104. And so I block the link on the right. So here's the 94 05:30.440 --> 05:34.880 important takeaway. Every switch is responsible for advertising its own cost 95 05:34.880 --> 05:40.280 to the root. When a device receives that BPDU in order to figure out its cost, 96 05:40.280 --> 05:40.280 it 97 05:40.280 --> 05:44.480 has to add the link. So it's not the responsibility of the upstream device. 98 05:44.480 --> 05:48.120 The root just says, hey, I've got a cost of zero. And I'm going to advertise 99 05:48.120 --> 05:48.400 that 100 05:48.400 --> 05:53.120 whether it's a on a 10 meg link or a 100 meg link or a 10 gigabit per second 101 05:53.120 --> 05:58.600 link. I have a cost of zero because the root is me. And so when we advertise 102 05:58.600 --> 05:58.960 down, 103 05:58.960 --> 06:03.160 now that switch has to say, okay, that's great that you're telling me you have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 103 05:58.960 --> 06:03.160 now that switch has to say, okay, that's great that you're telling me you have 104 06:03.160 --> 06:03.200 a 105 06:03.200 --> 06:09.520 cost of zero, but I received this on a 100 meg link, which means my cost is 19. 106 06:09.520 --> 06:13.800 And if I have multiple BPDUs, I have to start comparing which one of those is 107 06:13.800 --> 06:20.960 actually the best cost. So now the question is, how exactly are the cost and 108 06:20.960 --> 06:25.280 the bandwidth tied together? I made a really weird claim, which is 100 meg is 109 06:25.280 --> 06:30.560 equivalent to a spanning tree cost of 19. That seems rather random. Maybe the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 109 06:25.280 --> 06:30.560 equivalent to a spanning tree cost of 19. That seems rather random. Maybe the 110 06:30.560 --> 06:34.800 same thing down here that one gig is a spanning tree cost of four. I could 111 06:34.800 --> 06:38.800 almost get on board with at least 10 meg being 100, they seem to be multiples 112 06:38.800 --> 06:38.880 of 113 06:38.880 --> 06:45.040 one another. But where do these numbers come from? Well, spanning tree has a 114 06:45.040 --> 06:45.280 way 115 06:45.280 --> 06:49.040 of calculating costs. In fact, it has two ways of calculating costs and we have 116 06:49.040 --> 06:54.810 to understand both of them. We have short path costs and we have long path 117 06:54.810 --> 06:55.280 costs. 118 06:57.120 --> 07:00.400 Why are they called short and long? Well, we'll talk about that in a moment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 118 06:57.120 --> 07:00.400 Why are they called short and long? Well, we'll talk about that in a moment. 119 07:00.400 --> 07:00.720 But for 120 07:00.720 --> 07:07.280 right now, just understand that short path costs are not going to work very 121 07:07.280 --> 07:07.600 well in 122 07:07.600 --> 07:13.120 modern networks, because this really only handles speeds of up to 10 gigabit 123 07:13.120 --> 07:13.360 per 124 07:13.360 --> 07:18.720 second. Everything greater than 10 gig. 10 gig plus is all going to have the 125 07:18.720 --> 07:23.280 exact same cost of one. So it doesn't matter if it's a 25 gig link, a 50 gig 126 07:23.280 --> 07:28.560 link, 100 gig link, a terabit when that comes out. It's all going to have a 127 07:28.560 --> 07:28.800 cost 128 07:28.800 --> 07:33.040 of one, which is the problem with short path costs. But we do need to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 128 07:28.800 --> 07:33.040 of one, which is the problem with short path costs. But we do need to 129 07:33.040 --> 07:33.520 understand 130 07:33.520 --> 07:37.630 it as much as anything, because it's the default. And anything that's the 131 07:37.630 --> 07:38.240 default 132 07:38.240 --> 07:43.520 is oftentimes enabled in real world production networks. So let's go and talk 133 07:43.520 --> 07:50.160 through this real quick. So a short path cost is going to not really have a 134 07:50.160 --> 07:50.560 direct 135 07:50.560 --> 07:54.640 correlation, like a mathematical operation we can run. Instead, we're just 136 07:54.640 --> 07:54.880 going to 137 07:54.880 --> 07:59.200 have values that match up to one another. So for example, we said a 10 meg 138 07:59.200 --> 08:05.840 connection. This is a cost of 100. Now right away, we see a big problem here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 138 07:59.200 --> 08:05.840 connection. This is a cost of 100. Now right away, we see a big problem here, 139 08:05.840 --> 08:12.720 because the short path costs are going to use 16 bits to represent the total 140 08:12.720 --> 08:13.040 cost 141 08:13.040 --> 08:17.840 here. This is a 16 bit value. Well, if I do my binary math, 16 bits allows for 142 08:17.840 --> 08:26.080 65,500 and, well, say zero to five 65, 535. So I have a lot of numbers here, a 143 08:26.080 --> 08:26.560 lot of 144 08:26.560 --> 08:31.650 numbers. And yet I look at this very slow link, and I've already gotten down to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 144 08:26.560 --> 08:31.650 numbers. And yet I look at this very slow link, and I've already gotten down to 145 08:31.650 --> 08:32.640 100. 146 08:32.640 --> 08:40.320 So I've just scrapped 65,435 values that I could have used leading up to 10 meg 147 08:40.320 --> 08:41.680 abits per second, 148 08:41.680 --> 08:46.160 meaning that I'm possibly going to run out of values really quickly. I say, 149 08:46.160 --> 08:46.880 well, no worries, 150 08:46.880 --> 08:53.550 I've still got 100 values. So maybe a 100 meg could be 99, right? And then we 151 08:53.550 --> 08:54.720 'll count down from there. 152 08:54.720 --> 09:00.070 Well, unfortunately not, because we can still bundle 10 meg links together in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 08:54.720 --> 09:00.070 Well, unfortunately not, because we can still bundle 10 meg links together in 153 09:00.070 --> 09:00.640 ether channels, 154 09:00.640 --> 09:04.640 we have to have values that would represent a 20 meg connection and a 40 meg 155 09:04.640 --> 09:05.600 connection. 156 09:05.600 --> 09:10.880 And so a 100 meg connection actually gets the cost that we said earlier of 19. 157 09:10.880 --> 09:14.880 Feels a little arbitrary, but what we're trying to do is find the balance here 158 09:14.880 --> 09:15.920 of leaving values 159 09:15.920 --> 09:19.950 in the middle while also giving us values underneath, we don't want to run out 160 09:19.950 --> 09:21.120 of values. 161 09:21.120 --> 09:24.960 And so we started to stretch this out a little bit. And so as we just kind of j 162 09:24.960 --> 09:25.520 ot these out, 163 09:25.520 --> 09:30.090 we've got one gig has a cost of four. At this point, we're basically out of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 163 09:25.520 --> 09:30.090 we've got one gig has a cost of four. At this point, we're basically out of 164 09:30.090 --> 09:30.720 numbers, 165 09:30.720 --> 09:35.540 10 gig has a cost of two, and anything, as we already said, 10 gig plus has a 166 09:35.540 --> 09:36.720 cost of one. 167 09:36.720 --> 09:41.300 And this is the big problem. If these links, let's just draw a quick topology 168 09:41.300 --> 09:41.840 here. 169 09:43.360 --> 09:49.680 So if all of these links, let's say we had 100 gig, whoops, that's 100 gig. 170 09:49.680 --> 09:54.800 Let's write that one more time. 100 gig connections, 100 gig connection, 100 171 09:54.800 --> 09:56.560 gig connection, 40 gig 172 09:56.560 --> 10:02.710 connection. Yeah, this is a little bit of a weird network. But based on these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 172 09:56.560 --> 10:02.710 connection. Yeah, this is a little bit of a weird network. But based on these 173 10:02.710 --> 10:03.360 costs, 174 10:03.360 --> 10:07.980 this is a problem. We might well block the link on the left, because as I 175 10:07.980 --> 10:08.960 receive this, 176 10:08.960 --> 10:12.650 we're going to say, Oh, I've got a cost of one to the root because 100 gig is 177 10:12.650 --> 10:13.200 the same thing. 178 10:14.160 --> 10:18.560 As say, like 40 gig or what have you, it's just a cost of one. And then they 179 10:18.560 --> 10:19.760 advertise their 180 10:19.760 --> 10:24.410 cost of one down. And this switch says, okay, well, this is a cost of one. And 181 10:24.410 --> 10:25.520 this is a cost of one, 182 10:25.520 --> 10:29.920 because 140, we can't tell the difference between the two. And so this is why 183 10:29.920 --> 10:30.480 we might WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 183 10:29.920 --> 10:30.480 we might 184 10:30.480 --> 10:34.660 arbitrarily end up blocking this link and using the 40 gig connection over the 185 10:34.660 --> 10:36.160 100. Now, is this 186 10:36.160 --> 10:40.840 a realistic topology? Not really, especially in a network with 100 gig links. 187 10:40.840 --> 10:42.080 But at the same time, 188 10:42.080 --> 10:46.300 we need to recognize that this is a flaw. And when we have data centers that 189 10:46.300 --> 10:46.800 are built, 190 10:46.800 --> 10:51.770 not just on 100 gig links, but 200 and 400 and even 800, as of the time of this 191 10:51.770 --> 10:52.320 video, 192 10:52.320 --> 10:57.350 we need spanning tree to be able to tell the difference among those links. So 193 10:57.350 --> 10:58.000 that leads us 194 10:58.000 --> 11:05.360 to the second way of performing path cost calculation. And it is known as long WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 194 10:58.000 --> 11:05.360 to the second way of performing path cost calculation. And it is known as long 195 11:05.360 --> 11:06.160 path costs. 196 11:07.200 --> 11:13.280 It's called long path costs, because we're now going to use 32 bits. Now 32 197 11:13.280 --> 11:14.240 bits has like 198 11:14.240 --> 11:18.960 4.2 billion different values, which is great, except we kind of made sort of 199 11:18.960 --> 11:20.000 the similar type 200 11:20.000 --> 11:25.090 of deal here, where we very quickly start to use up all of those values. So for 201 11:25.090 --> 11:25.920 example, 202 11:25.920 --> 11:30.480 a 10 meg connection with long path costs already gets down to 2 million. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 202 11:25.920 --> 11:30.480 a 10 meg connection with long path costs already gets down to 2 million. 203 11:32.320 --> 11:37.040 And say, okay, well, that's not too bad, but we just got rid of most of the 4.2 204 11:37.040 --> 11:37.840 billion numbers 205 11:37.840 --> 11:42.120 before we even got to 10 megabits per second. So a little surprising. But I 206 11:42.120 --> 11:43.360 think the balance 207 11:43.360 --> 11:46.710 here is trying to get down to human readable numbers as well, because something 208 11:46.710 --> 11:47.840 like, you know, 209 11:47.840 --> 11:53.540 3.2 billion as the value might not sit well with a lot of us. So either way, we 210 11:53.540 --> 11:54.320 've got 10 meg 211 11:54.320 --> 11:59.040 at 2 million. And here it does become a little bit nicer math. So 100 meg being 212 11:59.040 --> 12:00.320 10 times better WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 212 11:59.040 --> 12:00.320 10 times better 213 12:00.320 --> 12:05.150 is going to be 10 times better from a numbers perspective. It's going to be 200 214 12:05.150 --> 12:05.680 ,000. 215 12:05.680 --> 12:12.980 One gig is therefore going to be 20,000. And from here, we can keep going. 10 216 12:12.980 --> 12:15.040 gig is going to be 20 217 12:15.040 --> 12:23.540 or 2000 rather. And then 100 gig is going to be 200, one terabyte terabit per 218 12:23.540 --> 12:25.200 second, I suppose, 219 12:25.200 --> 12:30.640 is going to be 20. And yeah, maybe in the future, we'll realize that, you know, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 219 12:25.200 --> 12:30.640 is going to be 20. And yeah, maybe in the future, we'll realize that, you know, 220 12:30.640 --> 12:31.360 maybe we should have 221 12:31.360 --> 12:35.420 given ourselves more, more wiggle room. But by the time we get to 10 terabit 222 12:35.420 --> 12:36.000 per second, 223 12:36.000 --> 12:39.990 we have a cost of two, maybe we'll be done with spanning tree altogether by the 224 12:39.990 --> 12:40.960 who knows. 225 12:40.960 --> 12:45.920 But either way, we see that we're using more bits in a really just a different 226 12:45.920 --> 12:47.200 way of counting. 227 12:47.200 --> 12:52.550 Now, I might say, okay, well, what does this mean 16 bit versus 32 bit? The 228 12:52.550 --> 12:53.280 interesting thing about 229 12:53.280 --> 12:58.560 the BP DU is it actually carries 32 bits for the cost, no matter whether we're 230 12:58.560 --> 12:59.520 using the short or 231 12:59.520 --> 13:03.560 long path cost. It's not about the number of bits being carried by the BP DU, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 231 12:59.520 --> 13:03.560 long path cost. It's not about the number of bits being carried by the BP DU, 232 13:03.560 --> 13:04.720 it's just how many of 233 13:04.720 --> 13:09.290 those bits are we actually using? So with the short path cost, we're only using 234 13:09.290 --> 13:11.120 16 bits of those 32, 235 13:11.120 --> 13:14.960 whereas with the long path cost, we're using all of them. And again, it's 236 13:14.960 --> 13:16.560 really less of a, like, 237 13:16.560 --> 13:21.400 where it's more of a representation of which of these values sets are we going 238 13:21.400 --> 13:23.520 to use. Now, this is, 239 13:23.520 --> 13:27.210 we might imagine, should be consistent throughout the whole network. And by 240 13:27.210 --> 13:28.400 default, as we said, 241 13:28.400 --> 13:32.290 Cisco devices, they use short path costs. So if I'm going to change to long WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 241 13:28.400 --> 13:32.290 Cisco devices, they use short path costs. So if I'm going to change to long 242 13:32.290 --> 13:33.280 path costs, which I 243 13:33.280 --> 13:38.800 absolutely should do the moment I see a link that's long faster than 10 gig, I 244 13:38.800 --> 13:39.600 should absolutely 245 13:39.600 --> 13:43.950 make sure my spanning tree long path cost is set to long. But as soon as I do 246 13:43.950 --> 13:45.040 that on one switch, 247 13:45.040 --> 13:48.560 I have to do that on all of the switches. Otherwise, we're going to be in a 248 13:48.560 --> 13:49.760 disagreement about what 249 13:49.760 --> 13:53.890 link costs are. They're compatible with one another, because the BP DU's can 250 13:53.890 --> 13:54.880 still be read. 251 13:54.880 --> 13:59.450 But they're going to interpret path costs very differently as they as these BP 252 13:59.450 --> 14:00.160 DU's propagate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 252 13:59.450 --> 14:00.160 DU's propagate 253 14:00.160 --> 14:03.520 through the network. So always make sure we have the same setting throughout 254 14:03.520 --> 14:04.560 the entire domain. 255 14:04.560 --> 14:09.520 Now we do have one final option to be aware of with path costs. And that would 256 14:09.520 --> 14:10.400 be the idea that 257 14:10.400 --> 14:16.240 we can set them manually. We can set manual costs if we so desire. For example, 258 14:16.240 --> 14:17.840 I could come over here 259 14:17.840 --> 14:22.320 to the let's just say this link here. And I could just tell this switch, hey, 260 14:22.320 --> 14:23.920 guess what? That's not 261 14:23.920 --> 14:30.880 a cost of four. That's a cost of 40. For whatever reason, I really don't want WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 261 14:23.920 --> 14:30.880 a cost of four. That's a cost of 40. For whatever reason, I really don't want 262 14:30.880 --> 14:31.920 that link to be used. 263 14:31.920 --> 14:36.100 Maybe I know upstream is a 10 meg connection. I don't know. But I can override 264 14:36.100 --> 14:36.720 that value, 265 14:36.720 --> 14:42.400 say it's 40. Now it's going to see it as 140 as it comes in. So I do have that 266 14:42.400 --> 14:43.520 capability. I can 267 14:43.520 --> 14:48.190 set manual costs. It's generally not required and generally not a good idea. 268 14:48.190 --> 14:49.360 But in the worst case 269 14:49.360 --> 14:54.280 scenario, maybe one day I install a hundred terabit per second connection. I 270 14:54.280 --> 14:55.120 have no idea. 271 14:55.120 --> 15:00.940 But either way, maybe especially using short path costs, maybe until we migrate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 271 14:55.120 --> 15:00.940 But either way, maybe especially using short path costs, maybe until we migrate 272 15:00.940 --> 15:01.840 to long path 273 15:01.840 --> 15:05.620 costs, I could use manual costing to get around problems where we're blocking 274 15:05.620 --> 15:06.480 the wrong links. 275 15:06.960 --> 15:10.230 But this path costs coming back to the original conversation over here, it's 276 15:10.230 --> 15:11.200 great that now we 277 15:11.200 --> 15:15.670 understand how the path costs come together. What really matters most is 278 15:15.670 --> 15:17.280 understanding how these 279 15:17.280 --> 15:22.270 path costs get advertised, how we receive them and add our own link costs to 280 15:22.270 --> 15:23.680 the path cost before 281 15:23.680 --> 15:29.140 we advertise it. And importantly, that we're going to use that as the primary 282 15:29.140 --> 15:30.160 criteria for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 282 15:29.140 --> 15:30.160 criteria for 283 15:30.160 --> 15:34.450 deciding which link we're going to block. We always want to block the slower 284 15:34.450 --> 15:35.760 paths to the route.