1 00:00:00,000 --> 00:00:02,856 [AUDIO LOGO] 2 00:00:02,856 --> 00:00:07,150 3 00:00:07,150 --> 00:00:11,110 Next, let's talk about the Multiexit Discriminator, 4 00:00:11,110 --> 00:00:12,880 or the MED. 5 00:00:12,880 --> 00:00:16,870 Now, in most of their outputs and even in their commands 6 00:00:16,870 --> 00:00:20,680 to set this, Cisco refers to this as metric 7 00:00:20,680 --> 00:00:26,320 quite frequently both on IOS XE and IOS XR. 8 00:00:26,320 --> 00:00:30,250 Now, in the scheme of BGP attributes, 9 00:00:30,250 --> 00:00:33,490 this one is definitely not the strongest. 10 00:00:33,490 --> 00:00:35,590 We're getting pretty far down the path 11 00:00:35,590 --> 00:00:39,490 selection criteria by the time we get to MED. 12 00:00:39,490 --> 00:00:41,980 So most of the other attributes that we've 13 00:00:41,980 --> 00:00:46,750 discussed in other videos and skills come before MED. 14 00:00:46,750 --> 00:00:50,000 So again, not the strongest metric here, 15 00:00:50,000 --> 00:00:52,960 but it is still something we can use. 16 00:00:52,960 --> 00:00:58,960 It also comes with, well, honestly, quite a few caveats. 17 00:00:58,960 --> 00:01:01,090 So there's some things we can adjust. 18 00:01:01,090 --> 00:01:03,130 There's actually situations that can 19 00:01:03,130 --> 00:01:06,580 occur that MED can be set but yet 20 00:01:06,580 --> 00:01:10,450 not actually be considered in part of the path selection 21 00:01:10,450 --> 00:01:11,600 process. 22 00:01:11,600 --> 00:01:15,440 So we'll be taking a look at those details in this video. 23 00:01:15,440 --> 00:01:17,830 So let's jump in and take a look at the details 24 00:01:17,830 --> 00:01:22,260 and the caveats of using MED in our path selection process. 25 00:01:22,260 --> 00:01:24,920 26 00:01:24,920 --> 00:01:26,980 So let's begin talking about some 27 00:01:26,980 --> 00:01:31,100 of the basic attributes of MED before we get to the caveats. 28 00:01:31,100 --> 00:01:36,430 First, this is going to be handled by BGP rule number six, 29 00:01:36,430 --> 00:01:41,410 and we are going to prefer the path with the lowest Multiexit 30 00:01:41,410 --> 00:01:43,240 Discriminator, or MED. 31 00:01:43,240 --> 00:01:47,530 So this is an example where lowest value wins. 32 00:01:47,530 --> 00:01:50,800 Again, this is going to be used to affect the return 33 00:01:50,800 --> 00:01:57,850 traffic or the inbound traffic between two neighboring ASes. 34 00:01:57,850 --> 00:02:02,680 This is an important concept to realize with MED is the default 35 00:02:02,680 --> 00:02:06,970 behavior is this only works between two neighboring AS 36 00:02:06,970 --> 00:02:08,300 numbers. 37 00:02:08,300 --> 00:02:11,200 The reason for this is our first point here. 38 00:02:11,200 --> 00:02:16,180 We only compare the MED if those paths 39 00:02:16,180 --> 00:02:20,270 are from the same neighboring AS number. 40 00:02:20,270 --> 00:02:23,170 So this is only going to be between two directly connected 41 00:02:23,170 --> 00:02:26,960 ASes with multiple paths between them. 42 00:02:26,960 --> 00:02:32,230 So MED is actually only passed to that neighboring AS 43 00:02:32,230 --> 00:02:38,080 and within the neighboring AS, but it doesn't go any further. 44 00:02:38,080 --> 00:02:40,210 We'll see in just a moment that this 45 00:02:40,210 --> 00:02:44,380 is something we refer to as a nontransitive attribute. 46 00:02:44,380 --> 00:02:51,940 The way this is enforced is if the MED is learned via iBGP, 47 00:02:51,940 --> 00:02:56,320 it will not be propagated to eBGP neighbors. 48 00:02:56,320 --> 00:03:01,360 That's going to prevent it from leaving the current AS. 49 00:03:01,360 --> 00:03:03,320 What happens instead? 50 00:03:03,320 --> 00:03:07,270 Well, we set it back to zero when we send it 51 00:03:07,270 --> 00:03:09,430 to these eBGP neighbors. 52 00:03:09,430 --> 00:03:12,400 Therefore, it's not being propagated. 53 00:03:12,400 --> 00:03:16,480 Now, we can change whether it sets it to zero 54 00:03:16,480 --> 00:03:19,930 or not, so that part can be modified. 55 00:03:19,930 --> 00:03:24,100 We can simply have it set it to a different value using 56 00:03:24,100 --> 00:03:25,900 default-metric. 57 00:03:25,900 --> 00:03:30,940 Now, we did mention part of this, that it is nontransitive, 58 00:03:30,940 --> 00:03:34,030 meaning it does not get sent to other ASes 59 00:03:34,030 --> 00:03:36,100 beyond your neighboring AS. 60 00:03:36,100 --> 00:03:39,820 But it's also optional, which technically 61 00:03:39,820 --> 00:03:42,700 means it does not have to be supported 62 00:03:42,700 --> 00:03:45,040 by a router in order for that router 63 00:03:45,040 --> 00:03:47,560 to say that it's BGP compliant. 64 00:03:47,560 --> 00:03:52,660 Now, that said, I'm personally not aware of any vendors 65 00:03:52,660 --> 00:03:56,740 out there that do not support the MED attribute. 66 00:03:56,740 --> 00:03:58,960 As far as I've seen, every router 67 00:03:58,960 --> 00:04:03,100 that I've ever run BGP on fully supports this attribute. 68 00:04:03,100 --> 00:04:07,780 Now, the behaviors that Cisco chooses to implement with MED 69 00:04:07,780 --> 00:04:10,180 may not be the same on other vendors. 70 00:04:10,180 --> 00:04:13,300 But they do generally at least understand 71 00:04:13,300 --> 00:04:15,350 the attribute itself. 72 00:04:15,350 --> 00:04:17,290 But remember, the fact that it's optional 73 00:04:17,290 --> 00:04:19,850 means they technically don't have to. 74 00:04:19,850 --> 00:04:22,330 So when you're using MED, you may 75 00:04:22,330 --> 00:04:25,900 have to verify whether your neighboring devices actually 76 00:04:25,900 --> 00:04:27,790 understand this attribute or not. 77 00:04:27,790 --> 00:04:30,610 It's not necessarily a given. 78 00:04:30,610 --> 00:04:33,490 Next is one of the points we sort of already discussed, 79 00:04:33,490 --> 00:04:37,150 and that is that Cisco refers to the MED 80 00:04:37,150 --> 00:04:41,950 as the metric in most commands. 81 00:04:41,950 --> 00:04:45,400 Now, this is going to be the show and the debug commands 82 00:04:45,400 --> 00:04:48,640 as well as configuration commands. 83 00:04:48,640 --> 00:04:53,110 But just be aware we are very carefully using that word most. 84 00:04:53,110 --> 00:04:57,130 There are a few places where they actually call it the MED. 85 00:04:57,130 --> 00:04:59,920 However, there are more places where they refer 86 00:04:59,920 --> 00:05:02,800 to it as the metric than they do the MED. 87 00:05:02,800 --> 00:05:05,680 In fact, I would say probably 90% of the time, 88 00:05:05,680 --> 00:05:08,410 they're referring to it as the metric. 89 00:05:08,410 --> 00:05:12,130 Also, be aware that this is a 32-bit number. 90 00:05:12,130 --> 00:05:15,130 It's important that this is a 32-bit number, 91 00:05:15,130 --> 00:05:19,450 not necessarily because we need that number of values in a MED 92 00:05:19,450 --> 00:05:20,410 field. 93 00:05:20,410 --> 00:05:23,050 It's important because one of the default 94 00:05:23,050 --> 00:05:25,960 behaviors that we'll see when we implement 95 00:05:25,960 --> 00:05:31,630 this is when we redistribute routes into BGP, if they have 96 00:05:31,630 --> 00:05:36,220 an IGP metric on them already, that metric will be brought 97 00:05:36,220 --> 00:05:39,070 into the MED or the Metric field. 98 00:05:39,070 --> 00:05:44,740 And some of our IGPs actually have a 32-bit metric 99 00:05:44,740 --> 00:05:46,250 on those routes. 100 00:05:46,250 --> 00:05:49,300 So the nice thing here is it's large enough 101 00:05:49,300 --> 00:05:53,530 to cover the metrics in all of our IGPs. 102 00:05:53,530 --> 00:05:55,660 Now, of course, not all of them do. 103 00:05:55,660 --> 00:05:58,000 If you were to take something like RIP, 104 00:05:58,000 --> 00:06:02,720 it only has 16 possible values, 0 through 15. 105 00:06:02,720 --> 00:06:04,870 So that would certainly not apply. 106 00:06:04,870 --> 00:06:09,490 But things like EIGRP do have 32-bit metrics 107 00:06:09,490 --> 00:06:13,820 that we can fit here into BGP. 108 00:06:13,820 --> 00:06:15,970 So we actually have that on this point 109 00:06:15,970 --> 00:06:19,930 here, that the MED is copied from the IGP. 110 00:06:19,930 --> 00:06:24,458 So again, this is why it needs to be 32 bits. 111 00:06:24,458 --> 00:06:26,500 This again is going to happen whether we bring it 112 00:06:26,500 --> 00:06:30,610 in with the network command or through redistribution. 113 00:06:30,610 --> 00:06:33,460 No matter which method you use, that MED 114 00:06:33,460 --> 00:06:37,750 is still going to be copied from the IGP metric. 115 00:06:37,750 --> 00:06:41,140 Now, once again, if that's not your desired behavior, 116 00:06:41,140 --> 00:06:44,410 first, you can of course overwrite it here 117 00:06:44,410 --> 00:06:47,080 with the default-metric command again. 118 00:06:47,080 --> 00:06:51,880 But also keep in mind that when you redistribute those routes, 119 00:06:51,880 --> 00:06:55,510 you can always run that redistribution through a route 120 00:06:55,510 --> 00:06:58,570 map or routing policy language. 121 00:06:58,570 --> 00:07:04,220 And you can modify the metric or the MED in that policy as well. 122 00:07:04,220 --> 00:07:06,580 So you could set it on individual prefixes 123 00:07:06,580 --> 00:07:09,130 when you're doing that redistribution using 124 00:07:09,130 --> 00:07:11,740 a route map or an RPL. 125 00:07:11,740 --> 00:07:15,680 So now we need to start talking about some of the caveats. 126 00:07:15,680 --> 00:07:18,700 So the first thing we have is an option 127 00:07:18,700 --> 00:07:22,910 called bgp always-compare-med. 128 00:07:22,910 --> 00:07:25,390 And just a quick note on the commands 129 00:07:25,390 --> 00:07:28,220 that we're showing here in this video-- 130 00:07:28,220 --> 00:07:31,300 these are the commands for IOS XE. 131 00:07:31,300 --> 00:07:34,610 They are very similar on IOS XR. 132 00:07:34,610 --> 00:07:37,510 However, some of them may vary just a little bit. 133 00:07:37,510 --> 00:07:40,930 We'll get into that a little bit more in our skills 134 00:07:40,930 --> 00:07:45,370 on implementation of these different attributes. 135 00:07:45,370 --> 00:07:48,490 But what this command actually causes 136 00:07:48,490 --> 00:07:54,730 is it causes the MED to be compared for all paths. 137 00:07:54,730 --> 00:07:57,310 Remember that the default behavior 138 00:07:57,310 --> 00:08:01,930 is we only compare MEDs if the two paths are 139 00:08:01,930 --> 00:08:04,930 from the same neighboring AS. 140 00:08:04,930 --> 00:08:08,950 This would actually allow us to compare the MEDs 141 00:08:08,950 --> 00:08:12,830 even if they're coming from different ASes. 142 00:08:12,830 --> 00:08:16,070 And just another quick note here on this feature-- 143 00:08:16,070 --> 00:08:18,560 this can be of course very useful 144 00:08:18,560 --> 00:08:21,080 if this is what you want to do. 145 00:08:21,080 --> 00:08:23,900 This would be commonly done if maybe you're 146 00:08:23,900 --> 00:08:27,530 in administrative control of multiple different ASes, 147 00:08:27,530 --> 00:08:31,460 maybe in a large corporation or a service provider core, 148 00:08:31,460 --> 00:08:35,090 and you want to use MED for your own purposes 149 00:08:35,090 --> 00:08:37,370 between those different ASes. 150 00:08:37,370 --> 00:08:39,679 Where this gets a little bit tricky 151 00:08:39,679 --> 00:08:43,010 is if it's two completely different service providers 152 00:08:43,010 --> 00:08:45,090 that you're partnering with. 153 00:08:45,090 --> 00:08:49,350 They may be using MED completely differently. 154 00:08:49,350 --> 00:08:53,220 One of them might have MEDs in the ranges of the hundreds 155 00:08:53,220 --> 00:08:54,690 or maybe thousands. 156 00:08:54,690 --> 00:08:57,210 And maybe the other service provider 157 00:08:57,210 --> 00:09:00,390 has MEDs that are in the ranges of the millions. 158 00:09:00,390 --> 00:09:03,690 Since there's not necessarily an industry standard 159 00:09:03,690 --> 00:09:06,870 on how to use and implement the MED, 160 00:09:06,870 --> 00:09:10,440 you can't really count on your neighboring ASes 161 00:09:10,440 --> 00:09:13,410 using MED in a similar fashion. 162 00:09:13,410 --> 00:09:16,110 Again, they could be using completely different ranges 163 00:09:16,110 --> 00:09:20,640 of values that aren't compatible with each other or comparable 164 00:09:20,640 --> 00:09:22,150 to each other. 165 00:09:22,150 --> 00:09:26,550 So you really need to make sure that those neighboring ASes are 166 00:09:26,550 --> 00:09:28,920 using some sort of comparable metrics 167 00:09:28,920 --> 00:09:31,440 before you decide to use this feature. 168 00:09:31,440 --> 00:09:34,710 Again, it's a great feature to have when we need it. 169 00:09:34,710 --> 00:09:36,870 But I'm sure we can sort of understand, 170 00:09:36,870 --> 00:09:38,550 at least hopefully at this point, 171 00:09:38,550 --> 00:09:41,700 why that's not enabled by default. 172 00:09:41,700 --> 00:09:45,180 And one other thing to remember about this option is 173 00:09:45,180 --> 00:09:47,370 whether you're going to-- we say disable here-- 174 00:09:47,370 --> 00:09:50,820 but enable it, disable it, the point 175 00:09:50,820 --> 00:09:53,940 is you must have a consistent policy 176 00:09:53,940 --> 00:09:58,230 on this over the entire AS. 177 00:09:58,230 --> 00:09:59,880 Otherwise, you could theoretically 178 00:09:59,880 --> 00:10:01,110 get routing loops. 179 00:10:01,110 --> 00:10:04,690 And of course, we sure as heck don't want routing loops. 180 00:10:04,690 --> 00:10:07,740 So be consistent with this policy, 181 00:10:07,740 --> 00:10:10,780 whether we're going to enable it or disable it. 182 00:10:10,780 --> 00:10:13,320 Next up, we have another feature-- 183 00:10:13,320 --> 00:10:17,880 bgp bestpath med confed. 184 00:10:17,880 --> 00:10:21,180 This option is only going to apply 185 00:10:21,180 --> 00:10:24,090 when we have confederations, because this is 186 00:10:24,090 --> 00:10:27,160 based on the confed sequence. 187 00:10:27,160 --> 00:10:29,970 So what this feature does is it allows 188 00:10:29,970 --> 00:10:34,740 us to compare the MEDs between the different ASes 189 00:10:34,740 --> 00:10:36,660 in the confederation. 190 00:10:36,660 --> 00:10:39,150 Remember, the idea behind the confederation 191 00:10:39,150 --> 00:10:43,232 is we're going to have multiple internal AS numbers. 192 00:10:43,232 --> 00:10:44,940 These are AS numbers that are going to be 193 00:10:44,940 --> 00:10:47,460 local to the confederation. 194 00:10:47,460 --> 00:10:52,530 So we may want to use MED between those AS numbers 195 00:10:52,530 --> 00:10:56,040 since they are considered internal or local 196 00:10:56,040 --> 00:11:01,830 to the confederation but maybe not from external ASes. 197 00:11:01,830 --> 00:11:04,590 That's the difference between these two commands. 198 00:11:04,590 --> 00:11:09,810 The bgp always-compare-med will compare all ASes 199 00:11:09,810 --> 00:11:10,890 with each other. 200 00:11:10,890 --> 00:11:15,030 Bgp bestpath med confed will only 201 00:11:15,030 --> 00:11:19,200 do it for routes within the local confederation. 202 00:11:19,200 --> 00:11:22,260 203 00:11:22,260 --> 00:11:26,200 So the next thing we want to discuss are received paths. 204 00:11:26,200 --> 00:11:29,970 Now, if we receive a path with no MED on it, 205 00:11:29,970 --> 00:11:33,870 we're going to assign that a MED of zero. 206 00:11:33,870 --> 00:11:37,470 That's the default behavior on Cisco. 207 00:11:37,470 --> 00:11:40,290 And that's very important to understand 208 00:11:40,290 --> 00:11:42,630 because where this starts to change 209 00:11:42,630 --> 00:11:51,040 is we have another feature here called bgp bestpath med 210 00:11:51,040 --> 00:11:53,570 missing-as-worst. 211 00:11:53,570 --> 00:11:56,320 And if we enable that feature, what happens 212 00:11:56,320 --> 00:12:00,280 is instead of the paths being assigned a zero, 213 00:12:00,280 --> 00:12:04,930 they are instead assigned the maximum value. 214 00:12:04,930 --> 00:12:10,010 Keep in mind that's the maximum value in a 32-bit field. 215 00:12:10,010 --> 00:12:12,890 So what is this feature all about? 216 00:12:12,890 --> 00:12:15,280 Well, remember we said previously 217 00:12:15,280 --> 00:12:17,560 that there's really no industry standard 218 00:12:17,560 --> 00:12:22,810 or consistency in the industry as far as what to do with MED? 219 00:12:22,810 --> 00:12:26,380 Well, this is one of those situations where 220 00:12:26,380 --> 00:12:29,230 Cisco, when they decided how to implement 221 00:12:29,230 --> 00:12:33,500 BGP on their platforms, they said, well, 222 00:12:33,500 --> 00:12:37,170 if there's no MED there, then, well, it 223 00:12:37,170 --> 00:12:40,240 should be the same number of things that I have in my hand 224 00:12:40,240 --> 00:12:41,230 right now-- 225 00:12:41,230 --> 00:12:42,160 zero. 226 00:12:42,160 --> 00:12:46,540 It should be nothing because if it's not there, then it's zero. 227 00:12:46,540 --> 00:12:49,480 The problem with that, though, from a logic standpoint-- 228 00:12:49,480 --> 00:12:52,270 or at least a lot of other vendors believe this-- 229 00:12:52,270 --> 00:12:55,300 that if it's missing, it shouldn't 230 00:12:55,300 --> 00:12:59,650 be the preferred value, because remember, lowest wins. 231 00:12:59,650 --> 00:13:05,860 Well, if the lowest MED is going to win, then zero is the best. 232 00:13:05,860 --> 00:13:08,090 Other vendors looked at this and said, 233 00:13:08,090 --> 00:13:10,900 well, that doesn't really make any sense. 234 00:13:10,900 --> 00:13:15,040 If the MED is not purposefully set by the administrator 235 00:13:15,040 --> 00:13:19,090 or by the device, it shouldn't be the best value. 236 00:13:19,090 --> 00:13:22,280 It should be the worst value. 237 00:13:22,280 --> 00:13:26,530 Now, either way you want to go here is fine. 238 00:13:26,530 --> 00:13:30,580 You just have to understand what they're doing. 239 00:13:30,580 --> 00:13:33,130 A lot of times we'll change this to be 240 00:13:33,130 --> 00:13:36,610 consistent with other vendors' equipment. 241 00:13:36,610 --> 00:13:39,280 Just to let you know, in my experience, 242 00:13:39,280 --> 00:13:44,230 what I usually do is just make sure if you're using MED, 243 00:13:44,230 --> 00:13:46,970 set it on all the paths. 244 00:13:46,970 --> 00:13:50,530 So maybe on the path that you want to use, 245 00:13:50,530 --> 00:13:52,540 set the MED to 100. 246 00:13:52,540 --> 00:13:57,250 And the one that you don't want to use, set the med to 200. 247 00:13:57,250 --> 00:13:59,770 What you don't want to do, most likely, 248 00:13:59,770 --> 00:14:03,070 is set the MED on one path to 100 249 00:14:03,070 --> 00:14:06,730 and leave the other one blank, because again, there's 250 00:14:06,730 --> 00:14:08,380 that inconsistency. 251 00:14:08,380 --> 00:14:11,170 What's the other side going to do? 252 00:14:11,170 --> 00:14:15,640 If I don't set the MED, they may treat that as the best value. 253 00:14:15,640 --> 00:14:18,850 They may treat that as the worst value. 254 00:14:18,850 --> 00:14:20,710 And that's going to completely flip 255 00:14:20,710 --> 00:14:23,530 the logic of what I'm trying to do by setting 256 00:14:23,530 --> 00:14:25,690 the other path to 100. 257 00:14:25,690 --> 00:14:28,870 That 100 then might be the best path 258 00:14:28,870 --> 00:14:31,220 or it might be the worst path. 259 00:14:31,220 --> 00:14:32,890 I mean, I guess I'll find out when 260 00:14:32,890 --> 00:14:35,860 I see how the traffic comes back into my network, right? 261 00:14:35,860 --> 00:14:38,990 But we don't generally want to use guesswork here. 262 00:14:38,990 --> 00:14:43,870 So the best practice is to set the MED on all the paths. 263 00:14:43,870 --> 00:14:46,840 And set it so that the one that you want to use 264 00:14:46,840 --> 00:14:50,380 has the lower or the better MED. 265 00:14:50,380 --> 00:14:52,900 The last feature here we need to discuss 266 00:14:52,900 --> 00:14:57,100 is one called bgp deterministic-med. 267 00:14:57,100 --> 00:15:00,760 This one is a little bit interesting 268 00:15:00,760 --> 00:15:03,100 to understand what it does. 269 00:15:03,100 --> 00:15:09,220 It actually groups our routes by the autonomous system number 270 00:15:09,220 --> 00:15:13,440 rather than the order in which they were learned. 271 00:15:13,440 --> 00:15:15,630 The best way to understand this is 272 00:15:15,630 --> 00:15:18,360 going to be to look at an actual example. 273 00:15:18,360 --> 00:15:22,790 And we'll do exactly that in the next video. 274 00:15:22,790 --> 00:15:26,620 So in this video, we jumped into MED. 275 00:15:26,620 --> 00:15:31,270 And as you just saw, there's actually a lot to MED. 276 00:15:31,270 --> 00:15:34,480 The basic overall rules, not so bad. 277 00:15:34,480 --> 00:15:36,940 But all the little caveats, as far as 278 00:15:36,940 --> 00:15:39,790 always-compare-med and deterministic-med, 279 00:15:39,790 --> 00:15:42,620 these things get a little bit more complicated. 280 00:15:42,620 --> 00:15:44,740 So the biggest thing to remember here 281 00:15:44,740 --> 00:15:47,860 is that by default, MED is only considered 282 00:15:47,860 --> 00:15:51,100 if the paths are coming from the same neighboring AS. 283 00:15:51,100 --> 00:15:56,200 And deterministic-med-- make sure that MED is always 284 00:15:56,200 --> 00:15:58,480 at least considered. 285 00:15:58,480 --> 00:16:00,640 I hope this has been informative for you, 286 00:16:00,640 --> 00:16:03,780 and I'd like to thank you for viewing. 287 00:16:03,780 --> 00:16:07,000