1 00:00:00,000 --> 00:00:03,325 [AUDIO LOGO] 2 00:00:03,325 --> 00:00:08,080 3 00:00:08,080 --> 00:00:10,090 So now that we've taken a closer look 4 00:00:10,090 --> 00:00:14,650 at using AS Path prepending to influence our incoming 5 00:00:14,650 --> 00:00:17,740 or return traffic, now let's take a look at one 6 00:00:17,740 --> 00:00:20,230 of our other options to do that, which 7 00:00:20,230 --> 00:00:24,760 is MED or, as Cisco calls it, the metric. 8 00:00:24,760 --> 00:00:29,990 Now this is not very high on the BGP path selection criteria, 9 00:00:29,990 --> 00:00:34,060 so keep in mind that anything like weight local preference 10 00:00:34,060 --> 00:00:37,120 or AS Path prepending can certainly 11 00:00:37,120 --> 00:00:41,860 be used by the neighboring AS to override whatever 12 00:00:41,860 --> 00:00:43,960 we try to set with MED. 13 00:00:43,960 --> 00:00:47,350 Also keep in mind that, well, MED does 14 00:00:47,350 --> 00:00:49,750 have a few interesting caveats. 15 00:00:49,750 --> 00:00:53,470 Now we're going to explore those caveats in this video 16 00:00:53,470 --> 00:00:56,080 as we jump into the command line and start 17 00:00:56,080 --> 00:00:57,830 looking at how MED works. 18 00:00:57,830 --> 00:01:00,370 So we do have quite a few things to look at. 19 00:01:00,370 --> 00:01:03,040 Let's, of course, start by looking at that topology, 20 00:01:03,040 --> 00:01:05,290 talking about what we want to do and putting together 21 00:01:05,290 --> 00:01:06,310 a game plan. 22 00:01:06,310 --> 00:01:08,560 And then we'll jump onto the command line 23 00:01:08,560 --> 00:01:13,470 and see MED and its caveats at work. 24 00:01:13,470 --> 00:01:18,550 Once again, here, we'll be using BGP topology 1 in this video. 25 00:01:18,550 --> 00:01:21,030 And one of the things we're going to be doing 26 00:01:21,030 --> 00:01:26,280 is bringing in a new loopback interface on router 4. 27 00:01:26,280 --> 00:01:34,500 We'll go ahead and make that 100.4.4.0/24. 28 00:01:34,500 --> 00:01:38,010 We'll, of course, advertise that into BGP. 29 00:01:38,010 --> 00:01:43,650 And our main focus is going to be over here on router 7. 30 00:01:43,650 --> 00:01:46,980 Router 7 should ultimately have three different paths 31 00:01:46,980 --> 00:01:50,160 available to it to get to that prefix. 32 00:01:50,160 --> 00:01:53,100 One would be through AS 1000. 33 00:01:53,100 --> 00:01:56,100 Another one would be directly to router 1. 34 00:01:56,100 --> 00:02:00,190 And, finally, we should have a path to router 3 as well. 35 00:02:00,190 --> 00:02:02,260 Now a few things about this. 36 00:02:02,260 --> 00:02:08,460 First off, router 7 may not have all three paths to begin with. 37 00:02:08,460 --> 00:02:10,979 We may actually have to do a little bit of work 38 00:02:10,979 --> 00:02:13,140 for that to happen. 39 00:02:13,140 --> 00:02:17,160 Router 7 might be a transit AS. 40 00:02:17,160 --> 00:02:21,030 Meaning it might be learning the routes from AS 100, 41 00:02:21,030 --> 00:02:24,390 passing those on to AS 1000. 42 00:02:24,390 --> 00:02:28,960 And if AS 1000 is using those, it won't send them back. 43 00:02:28,960 --> 00:02:30,900 So we'll have to look and see what's happening 44 00:02:30,900 --> 00:02:33,217 right now in the topology. 45 00:02:33,217 --> 00:02:34,800 And the other thing that's going to be 46 00:02:34,800 --> 00:02:37,980 a little bit different about this demonstration 47 00:02:37,980 --> 00:02:42,090 is we're not going to start off with a goal of what we're 48 00:02:42,090 --> 00:02:45,540 trying to accomplish because we're going to look at MED 49 00:02:45,540 --> 00:02:47,880 and its different caveats. 50 00:02:47,880 --> 00:02:51,000 And depending on which caveat we're doing, 51 00:02:51,000 --> 00:02:53,650 it's going to change the path selection. 52 00:02:53,650 --> 00:02:57,660 So in this particular video, what we're more going to do 53 00:02:57,660 --> 00:03:01,440 is play around with MED and figure out 54 00:03:01,440 --> 00:03:05,100 how it chooses each of these different paths 55 00:03:05,100 --> 00:03:07,140 based on how we set the MED. 56 00:03:07,140 --> 00:03:09,720 So it's going to choose one of these three paths. 57 00:03:09,720 --> 00:03:11,610 But, again, we're going to be looking 58 00:03:11,610 --> 00:03:14,100 at the attributes of MED to figure out 59 00:03:14,100 --> 00:03:15,660 which one it's going to choose. 60 00:03:15,660 --> 00:03:18,420 So all of that said, let's go ahead 61 00:03:18,420 --> 00:03:20,170 and jump into the command line. 62 00:03:20,170 --> 00:03:22,410 Of course, we'll start on router 7 63 00:03:22,410 --> 00:03:26,025 and see if it even has all three of those paths to begin with. 64 00:03:26,025 --> 00:03:28,690 65 00:03:28,690 --> 00:03:32,310 So let's start off with just a sh ip bgp. 66 00:03:32,310 --> 00:03:38,490 And we can see right away that we do have that 100.4.4.0/24. 67 00:03:38,490 --> 00:03:41,980 And we do, actually, have all three paths. 68 00:03:41,980 --> 00:03:45,570 So let's get some more detailed information on that. 69 00:03:45,570 --> 00:03:47,810 So if we ask for the prefix, we can 70 00:03:47,810 --> 00:03:51,920 see that we do have the path from router 3, 71 00:03:51,920 --> 00:03:54,560 router 6, and router 1. 72 00:03:54,560 --> 00:03:57,830 And currently the path through router 1 73 00:03:57,830 --> 00:04:00,200 is considered the best. 74 00:04:00,200 --> 00:04:04,040 Now just so you know, we did already originate that loopback 75 00:04:04,040 --> 00:04:05,480 on router 4. 76 00:04:05,480 --> 00:04:08,340 Just in case you want to know what that looks like. 77 00:04:08,340 --> 00:04:11,690 This is simply the code that was put in on router 4. 78 00:04:11,690 --> 00:04:15,470 Simply to create a loopback 100, put the IP address on it 79 00:04:15,470 --> 00:04:20,040 and then advertise it into BGP with the network statement. 80 00:04:20,040 --> 00:04:23,510 So router 4 has been configured with the loopback 81 00:04:23,510 --> 00:04:28,260 and router 7 has the prefix with all three paths. 82 00:04:28,260 --> 00:04:32,660 So that puts us in a good position to start using MED. 83 00:04:32,660 --> 00:04:35,680 So let's jump over to router 1. 84 00:04:35,680 --> 00:04:40,240 So to begin with, let's go ahead and set the MED on this prefix 85 00:04:40,240 --> 00:04:41,890 to 100. 86 00:04:41,890 --> 00:04:44,820 So this time we'll use a prefix_set. 87 00:04:44,820 --> 00:04:48,180 Let's just call it R4_LOOP. 88 00:04:48,180 --> 00:04:53,550 And we'll match on the 100.4.4.0/24. 89 00:04:53,550 --> 00:04:55,960 Then we'll write our policy. 90 00:04:55,960 --> 00:04:58,620 We'll call this TO_R7. 91 00:04:58,620 --> 00:05:02,790 And we're going to say if destination 92 00:05:02,790 --> 00:05:08,340 is in our prefix set, then we're going to set the MED. 93 00:05:08,340 --> 00:05:14,160 Notice here on IOS XR, it actually calls it the MED. 94 00:05:14,160 --> 00:05:17,940 Now we can increase it or decrease it by a certain amount 95 00:05:17,940 --> 00:05:20,430 if it already had a value, or we can-- 96 00:05:20,430 --> 00:05:24,540 in this case what we want to do is just set it to be 100. 97 00:05:24,540 --> 00:05:26,730 Then we're going to pass the route. 98 00:05:26,730 --> 00:05:29,610 And, of course, since we're not trying to filter, 99 00:05:29,610 --> 00:05:34,140 we're just going to say else, pass the routes unchanged. 100 00:05:34,140 --> 00:05:38,080 We'll end our if statement, and end our policy. 101 00:05:38,080 --> 00:05:45,150 Then into router BGP 100 and towards the nei 50.0.167.7, 102 00:05:45,150 --> 00:05:47,400 which is router 7. 103 00:05:47,400 --> 00:05:51,150 Of course, for the address family IPv4 unicast, 104 00:05:51,150 --> 00:05:53,640 we're going to apply our route policy. 105 00:05:53,640 --> 00:05:55,990 That will, of course, be outbound. 106 00:05:55,990 --> 00:06:02,340 So let's commit the change, clear BGP IPv4 all * soft out, 107 00:06:02,340 --> 00:06:05,070 which will send out a reconfiguration. 108 00:06:05,070 --> 00:06:09,150 Now that that's done, let's go look at router 7. 109 00:06:09,150 --> 00:06:12,120 We'll simply repeat our previous command. 110 00:06:12,120 --> 00:06:17,070 And what we see happening here is the path to router 1 111 00:06:17,070 --> 00:06:19,770 is no longer considered the best. 112 00:06:19,770 --> 00:06:24,030 Notice that it's now moved the best path selection over 113 00:06:24,030 --> 00:06:25,590 to router 3. 114 00:06:25,590 --> 00:06:28,650 This is because remember that Cisco 115 00:06:28,650 --> 00:06:32,820 treats a missing metric or MED as the best 116 00:06:32,820 --> 00:06:35,610 possible value or a zero. 117 00:06:35,610 --> 00:06:37,710 Remember, lowest wins. 118 00:06:37,710 --> 00:06:41,250 Now that router 1 is setting the metric to 100 119 00:06:41,250 --> 00:06:45,030 as we can see here, now that's not the preferred best 120 00:06:45,030 --> 00:06:46,420 path anymore. 121 00:06:46,420 --> 00:06:50,820 So generally speaking, this is how MED is designed to work. 122 00:06:50,820 --> 00:06:54,930 But let's take a look at some of its caveats. 123 00:06:54,930 --> 00:06:56,700 So, first, let's explore what would 124 00:06:56,700 --> 00:07:02,820 happen if we told router 7 to reverse that philosophy. 125 00:07:02,820 --> 00:07:05,430 Don't treat the missing MED as the best, 126 00:07:05,430 --> 00:07:07,590 but rather treat it as the worst. 127 00:07:07,590 --> 00:07:12,570 So let's go into configuration mode, into our BGP process. 128 00:07:12,570 --> 00:07:19,680 And we say bgp bestpath med missing-as-worst. 129 00:07:19,680 --> 00:07:22,350 We'll go ahead and configure that, exit out 130 00:07:22,350 --> 00:07:24,450 of configuration mode. 131 00:07:24,450 --> 00:07:28,260 And now let's take a look at our paths again. 132 00:07:28,260 --> 00:07:32,280 Now we see that this behavior has completely flipped. 133 00:07:32,280 --> 00:07:36,510 The paths that do not have a Med or metric set 134 00:07:36,510 --> 00:07:41,400 are now roughly 4.3 billion maximum value 135 00:07:41,400 --> 00:07:43,770 in a 32-bit field, of course. 136 00:07:43,770 --> 00:07:47,880 While the path from router 1 is, well, it's still 100 137 00:07:47,880 --> 00:07:49,650 because we're setting that one. 138 00:07:49,650 --> 00:07:54,720 But the 100 is now best so the path through router 1 139 00:07:54,720 --> 00:07:57,880 is back to being considered the best path again. 140 00:07:57,880 --> 00:08:00,510 So we're not going to leave this feature in here, 141 00:08:00,510 --> 00:08:03,490 but I just wanted you to see how it works 142 00:08:03,490 --> 00:08:05,790 if you do MED missing as worst. 143 00:08:05,790 --> 00:08:10,370 So let's go ahead and take this back out. 144 00:08:10,370 --> 00:08:14,840 So we'll simply turn that back off under the bgp process. 145 00:08:14,840 --> 00:08:18,400 And if we look at this again, it hasn't hyperconverged back just 146 00:08:18,400 --> 00:08:21,010 yet but the metrics are gone. 147 00:08:21,010 --> 00:08:23,500 Let's give it a second to do it again. 148 00:08:23,500 --> 00:08:26,290 And then we can see it is now switched back 149 00:08:26,290 --> 00:08:29,170 to using router 3 as the preferred path 150 00:08:29,170 --> 00:08:32,470 because it does not have a MED set on it. 151 00:08:32,470 --> 00:08:36,000 So now let's talk about some of the caveats of MED. 152 00:08:36,000 --> 00:08:39,419 We'll start with deterministic MED. 153 00:08:39,419 --> 00:08:42,870 If we take a look at the prefixes and their paths 154 00:08:42,870 --> 00:08:47,280 as we have them right now, they are in chronological order 155 00:08:47,280 --> 00:08:50,580 from the newest to the oldest as they 156 00:08:50,580 --> 00:08:52,420 were learned by the router. 157 00:08:52,420 --> 00:08:56,460 Now the problem with this is when BGP chooses its best path, 158 00:08:56,460 --> 00:09:00,870 it's going to put the paths together into pairs, 159 00:09:00,870 --> 00:09:03,280 starting from the top down. 160 00:09:03,280 --> 00:09:07,020 So it's going to start with these two paths. 161 00:09:07,020 --> 00:09:09,810 And it's going to see that one is from AS 100 162 00:09:09,810 --> 00:09:13,050 and one is from AS 1000, and it's not 163 00:09:13,050 --> 00:09:17,250 going to compare the MED because they're from different ASes. 164 00:09:17,250 --> 00:09:20,460 Now depending on the winner out of that pair, 165 00:09:20,460 --> 00:09:24,360 if it's the path from AS 1000 that were to win, 166 00:09:24,360 --> 00:09:27,960 when that gets compared to the route below, 167 00:09:27,960 --> 00:09:30,880 MED would not be considered again. 168 00:09:30,880 --> 00:09:33,660 Which means that MED would have no say in this decision 169 00:09:33,660 --> 00:09:34,870 whatsoever. 170 00:09:34,870 --> 00:09:40,050 Now if the winner happens to be the path from AS 100, 171 00:09:40,050 --> 00:09:43,890 and then the AS 100 gets compared to AS 100, 172 00:09:43,890 --> 00:09:47,230 well, then the MED does count. 173 00:09:47,230 --> 00:09:52,620 So as in this example, the first pair, the route from AS 100 174 00:09:52,620 --> 00:09:55,290 one because of the shortest AS path. 175 00:09:55,290 --> 00:10:00,840 Then when the 100 is compared to the 100 router 3 to router 1, 176 00:10:00,840 --> 00:10:03,550 then it takes the metric into account. 177 00:10:03,550 --> 00:10:06,690 So in this case, the metric was counted. 178 00:10:06,690 --> 00:10:09,360 But here's the thing, we don't really 179 00:10:09,360 --> 00:10:14,310 want to rely on a situation where MED may or may not 180 00:10:14,310 --> 00:10:16,960 count as part of our path selection, 181 00:10:16,960 --> 00:10:19,140 especially when it has to do with something 182 00:10:19,140 --> 00:10:20,940 we can't control. 183 00:10:20,940 --> 00:10:23,760 This is based on when the routes were learned, 184 00:10:23,760 --> 00:10:26,010 which in most environments it's something 185 00:10:26,010 --> 00:10:27,700 that's out of our control. 186 00:10:27,700 --> 00:10:29,610 We have no control over that. 187 00:10:29,610 --> 00:10:32,820 Hence the term deterministic MED. 188 00:10:32,820 --> 00:10:36,780 It means that MED will always be considered in the path 189 00:10:36,780 --> 00:10:41,160 selection as long as the routes are coming from the same AS. 190 00:10:41,160 --> 00:10:46,620 We do that by grouping the updates together by AS 191 00:10:46,620 --> 00:10:51,160 rather than based on the time in which they were learned. 192 00:10:51,160 --> 00:10:53,880 So if we turn on deterministic MED, what we're going to see 193 00:10:53,880 --> 00:10:57,330 is the order of these prefixes is going to change 194 00:10:57,330 --> 00:11:00,210 and, therefore, the order in which they're compared 195 00:11:00,210 --> 00:11:02,010 is going to change. 196 00:11:02,010 --> 00:11:04,860 Will that ultimately change the final decision as far 197 00:11:04,860 --> 00:11:06,450 as the best path? 198 00:11:06,450 --> 00:11:07,860 Maybe, maybe not. 199 00:11:07,860 --> 00:11:10,450 That depends on a lot of other factors. 200 00:11:10,450 --> 00:11:13,200 But at least MED will get a say when 201 00:11:13,200 --> 00:11:16,950 we compare the ASes as groups rather 202 00:11:16,950 --> 00:11:20,040 than having them split apart by the order in which they 203 00:11:20,040 --> 00:11:20,710 were learned. 204 00:11:20,710 --> 00:11:22,680 Let's go ahead and turn this feature on, 205 00:11:22,680 --> 00:11:26,070 and we'll see what happens to the order of our path selection 206 00:11:26,070 --> 00:11:28,680 here. 207 00:11:28,680 --> 00:11:32,400 All we have to do is turn on BGP deterministic MED. 208 00:11:32,400 --> 00:11:34,950 We'll exit out of configuration mode. 209 00:11:34,950 --> 00:11:37,900 And let's take a look at our prefixes again. 210 00:11:37,900 --> 00:11:43,240 And we see that now the pairs are ordered by the AS number. 211 00:11:43,240 --> 00:11:47,970 So as we said, that ensures that in the first pair, 212 00:11:47,970 --> 00:11:50,500 MED is going to be considered. 213 00:11:50,500 --> 00:11:53,130 And then when the winner of that gets 214 00:11:53,130 --> 00:11:56,920 compared to the other AS, well, of course, 215 00:11:56,920 --> 00:11:58,530 it won't be considered there. 216 00:11:58,530 --> 00:12:01,950 But that's just because they're from two different ASes. 217 00:12:01,950 --> 00:12:04,620 Again, it doesn't mean that the final decision is 218 00:12:04,620 --> 00:12:09,540 going to change, but MED, at least, got a chance. 219 00:12:09,540 --> 00:12:13,380 Now speaking of things that we can't control, 220 00:12:13,380 --> 00:12:17,820 we don't really know if our neighboring ASes are 221 00:12:17,820 --> 00:12:21,720 going to be doing MED missing as worst or MED 222 00:12:21,720 --> 00:12:25,290 missing as best, which is the default on Cisco. 223 00:12:25,290 --> 00:12:27,570 If they're using another vendor, it very well could 224 00:12:27,570 --> 00:12:31,650 have a different default. So since we don't know 225 00:12:31,650 --> 00:12:34,500 and we don't want to have to rely on what the neighbor is 226 00:12:34,500 --> 00:12:38,850 doing in order for our routing choices to happen, 227 00:12:38,850 --> 00:12:42,690 we're probably going to want to set the MED on all the devices 228 00:12:42,690 --> 00:12:44,230 towards that neighbor. 229 00:12:44,230 --> 00:12:46,680 So the best practice would not be 230 00:12:46,680 --> 00:12:50,910 to let router 3 be sending this with no MED. 231 00:12:50,910 --> 00:12:53,520 So let's update this in such a way 232 00:12:53,520 --> 00:12:56,400 that our best path goes back to router 1. 233 00:12:56,400 --> 00:13:01,460 Let's change router 3 to have a MED of 200. 234 00:13:01,460 --> 00:13:04,410 So, again, we'll go into configuration mode. 235 00:13:04,410 --> 00:13:06,380 We'll do a prefix-set. 236 00:13:06,380 --> 00:13:08,330 We'll put in our prefix. 237 00:13:08,330 --> 00:13:10,610 And then we'll write our policy. 238 00:13:10,610 --> 00:13:12,930 We'll just call it the same thing. 239 00:13:12,930 --> 00:13:18,950 Once, again, if the destination is in PS_R4_LOOP, 240 00:13:18,950 --> 00:13:23,000 then we're going to set the MED to 200, 241 00:13:23,000 --> 00:13:28,790 pass the route through else, just pass the route and the if 242 00:13:28,790 --> 00:13:31,910 statement and then the policy. 243 00:13:31,910 --> 00:13:34,850 And then, of course, we'll apply this to our neighbor. 244 00:13:34,850 --> 00:13:38,240 In this case it's nei 10.7.7.7. 245 00:13:38,240 --> 00:13:40,310 And, again, it's outbound. 246 00:13:40,310 --> 00:13:41,930 Commit the change. 247 00:13:41,930 --> 00:13:44,060 Notice we're getting an error here. 248 00:13:44,060 --> 00:13:45,800 And it might be a little bit tricky 249 00:13:45,800 --> 00:13:49,730 to see we have a typo on the route policy here. 250 00:13:49,730 --> 00:13:55,430 I called it PR instead of RP, therefore, it's the wrong name. 251 00:13:55,430 --> 00:13:57,740 And, of course, IOS XR is saying, 252 00:13:57,740 --> 00:13:59,580 I don't know what you're talking about. 253 00:13:59,580 --> 00:14:00,450 So there we go. 254 00:14:00,450 --> 00:14:03,350 Now it's committed now that we fixed our typo. 255 00:14:03,350 --> 00:14:05,240 Let's do our clear. 256 00:14:05,240 --> 00:14:07,460 Let's go back over to router 7 and make sure 257 00:14:07,460 --> 00:14:09,210 that's taken effect. 258 00:14:09,210 --> 00:14:11,030 So we see now that it's back to choosing 259 00:14:11,030 --> 00:14:14,900 router 1 as the best with the metric of 100, 260 00:14:14,900 --> 00:14:20,100 where the metric of 200 is not being chosen any longer. 261 00:14:20,100 --> 00:14:24,830 So this is MED working properly with a neighboring AS. 262 00:14:24,830 --> 00:14:27,470 But here's an interesting proposition. 263 00:14:27,470 --> 00:14:32,900 What if we go over to router 6 now and make it's MED 50? 264 00:14:32,900 --> 00:14:38,240 Can we make it choose router 6 as the best path using MED? 265 00:14:38,240 --> 00:14:40,987 Now the answer is a little tricky. 266 00:14:40,987 --> 00:14:43,070 We're going to have to do some other things first. 267 00:14:43,070 --> 00:14:46,130 We can do it, but we're going to have a couple of bumps 268 00:14:46,130 --> 00:14:46,830 along the way. 269 00:14:46,830 --> 00:14:48,592 Let's go ahead and take a look. 270 00:14:48,592 --> 00:14:50,300 So first, of course, we have to configure 271 00:14:50,300 --> 00:14:53,310 the policy on router 6 itself. 272 00:14:53,310 --> 00:14:56,010 So configuration mode, of course, 273 00:14:56,010 --> 00:14:59,240 we're going to use the route map here on IOS XE. 274 00:14:59,240 --> 00:15:02,210 We'll still call it RM_TO_R7. 275 00:15:02,210 --> 00:15:04,953 Here it's called metric, so it will set the metric. 276 00:15:04,953 --> 00:15:05,870 And we'll make it low. 277 00:15:05,870 --> 00:15:07,490 We'll make it 50. 278 00:15:07,490 --> 00:15:10,268 Then we're going to router BGP 1000. 279 00:15:10,268 --> 00:15:15,290 And for the nei 50.0.167.7. 280 00:15:15,290 --> 00:15:20,870 We'll apply our route map RM_TO_R7 outbound. 281 00:15:20,870 --> 00:15:24,230 We'll clear our BGP session and, once again, 282 00:15:24,230 --> 00:15:26,420 go back to router 7. 283 00:15:26,420 --> 00:15:28,720 We'll look at our prefix again. 284 00:15:28,720 --> 00:15:31,100 And a few things to note here. 285 00:15:31,100 --> 00:15:34,480 First, reporter 1 is still selected as the best. 286 00:15:34,480 --> 00:15:37,510 However, the prefix from router 6 287 00:15:37,510 --> 00:15:39,970 now does have the metric of 50. 288 00:15:39,970 --> 00:15:44,750 That's not doing anything, but it's that set and it's there. 289 00:15:44,750 --> 00:15:47,950 The other thing to note is the prefix from router 6 290 00:15:47,950 --> 00:15:50,920 is at the top now because it just learned it 291 00:15:50,920 --> 00:15:53,200 through a new refresh. 292 00:15:53,200 --> 00:15:57,130 Again, this is still sudo chronological. 293 00:15:57,130 --> 00:16:01,400 Meaning it's still chronological within the AS numbers. 294 00:16:01,400 --> 00:16:06,700 So even with deterministic MED on, within the AS sets, 295 00:16:06,700 --> 00:16:08,800 it's still chronological. 296 00:16:08,800 --> 00:16:13,570 And between the sets themselves, it's chronological. 297 00:16:13,570 --> 00:16:17,290 Now what if we want that 50 to actually mean something? 298 00:16:17,290 --> 00:16:20,930 Well, there's actually two things that have to happen. 299 00:16:20,930 --> 00:16:22,840 The first thing that has to happen 300 00:16:22,840 --> 00:16:26,200 is we're going to have to tell router 7 not 301 00:16:26,200 --> 00:16:29,330 to look at the AS path length. 302 00:16:29,330 --> 00:16:32,380 We're going to have to skip that rule because if we 303 00:16:32,380 --> 00:16:36,010 look at this prefix, it's, of course, one AS coming 304 00:16:36,010 --> 00:16:37,210 from AS 100. 305 00:16:37,210 --> 00:16:39,850 And it's, of course, two ASes going 306 00:16:39,850 --> 00:16:42,580 through as 1000 and AS 100. 307 00:16:42,580 --> 00:16:45,130 So no matter what we do with MED, 308 00:16:45,130 --> 00:16:47,590 it's not going to make any difference here as 309 00:16:47,590 --> 00:16:50,710 long as one of them has the shorter AS path. 310 00:16:50,710 --> 00:16:54,640 So step one is we're going to have to tell router 7 not 311 00:16:54,640 --> 00:16:56,080 to look at the AS path. 312 00:16:56,080 --> 00:16:58,390 I wouldn't generally recommend doing this 313 00:16:58,390 --> 00:17:01,370 unless you have a very specific reason for doing it. 314 00:17:01,370 --> 00:17:03,310 However, this is a lab environment 315 00:17:03,310 --> 00:17:05,960 and we're trying to look at MED specifically 316 00:17:05,960 --> 00:17:09,710 so I call that a pretty good reason for doing it. 317 00:17:09,710 --> 00:17:12,710 So, again, we go into our BGP process. 318 00:17:12,710 --> 00:17:14,260 And here is going to be a fun one. 319 00:17:14,260 --> 00:17:19,750 If we say BGP best path, and we ask for context sensitive help 320 00:17:19,750 --> 00:17:23,079 here, notice there is no option that 321 00:17:23,079 --> 00:17:26,380 says anything about AS path. 322 00:17:26,380 --> 00:17:30,140 This is because Cisco doesn't want you to turn it off either. 323 00:17:30,140 --> 00:17:32,620 However, it's still there. 324 00:17:32,620 --> 00:17:35,950 If we just type as-path, it's not 325 00:17:35,950 --> 00:17:37,370 going to give us any further help. 326 00:17:37,370 --> 00:17:40,370 In fact, it's going to tell us it's an unrecognized command. 327 00:17:40,370 --> 00:17:42,800 It has no idea what I'm talking about. 328 00:17:42,800 --> 00:17:47,870 But if I actually say ignore, it takes the command. 329 00:17:47,870 --> 00:17:49,290 If you're not familiar with this, 330 00:17:49,290 --> 00:17:51,530 this is simply what we call a hidden command. 331 00:17:51,530 --> 00:17:53,270 There aren't many of them. 332 00:17:53,270 --> 00:17:56,310 Cisco hides them for a variety of reasons. 333 00:17:56,310 --> 00:17:58,490 We're not going to get into all of that here. 334 00:17:58,490 --> 00:18:00,710 It's probably a philosophical discussion. 335 00:18:00,710 --> 00:18:03,950 However, in this case, I think-- and I 336 00:18:03,950 --> 00:18:06,260 don't have any inside Cisco information-- 337 00:18:06,260 --> 00:18:09,560 but I think they hide it because you really 338 00:18:09,560 --> 00:18:13,220 shouldn't use it unless you know what you're doing and why. 339 00:18:13,220 --> 00:18:15,170 And if you know what you're doing and why, 340 00:18:15,170 --> 00:18:17,160 then you probably know the command. 341 00:18:17,160 --> 00:18:19,830 So that's just my opinion as to why they hide it. 342 00:18:19,830 --> 00:18:23,600 But, nonetheless, that's the command. 343 00:18:23,600 --> 00:18:26,390 Let's go ahead and look at our BGP path again. 344 00:18:26,390 --> 00:18:30,470 Now nothing's changed yet because even though we're not 345 00:18:30,470 --> 00:18:33,500 looking at the AS path length anymore, 346 00:18:33,500 --> 00:18:37,590 these MEDs are still coming from different ASes. 347 00:18:37,590 --> 00:18:41,070 So if we really want this whole thing to work, 348 00:18:41,070 --> 00:18:44,330 we're going to have to say bgp always-compare-med. 349 00:18:44,330 --> 00:18:47,450 Which tells it to compare the MED regardless of what 350 00:18:47,450 --> 00:18:50,120 neighboring AS it comes from. 351 00:18:50,120 --> 00:18:52,850 Once again, a command we really probably 352 00:18:52,850 --> 00:18:55,520 shouldn't use most of the time, unless we 353 00:18:55,520 --> 00:18:59,930 know that those neighboring ASes are using compatible metrics. 354 00:18:59,930 --> 00:19:02,420 So, for example, here in our lab we 355 00:19:02,420 --> 00:19:05,630 have control over these two different ASes, AS 100 356 00:19:05,630 --> 00:19:07,010 and AS 1000. 357 00:19:07,010 --> 00:19:09,440 So we know in this case that we want 358 00:19:09,440 --> 00:19:11,010 to compare MED between them. 359 00:19:11,010 --> 00:19:13,970 But make sure you understand the consequences of this 360 00:19:13,970 --> 00:19:16,880 if your neighboring service providers use 361 00:19:16,880 --> 00:19:18,770 radically different MEDs. 362 00:19:18,770 --> 00:19:22,440 This could not work out well if that's the case. 363 00:19:22,440 --> 00:19:25,190 So make sure that this is what you want before you 364 00:19:25,190 --> 00:19:27,120 turn this feature on. 365 00:19:27,120 --> 00:19:31,680 So once we turn it on, if we look at our prefixes again, 366 00:19:31,680 --> 00:19:34,680 we had to give it just a second there to run the BGP scanner. 367 00:19:34,680 --> 00:19:38,310 But we can see that now that path through router 6 368 00:19:38,310 --> 00:19:43,720 is now the best with the lowest metric of 50. 369 00:19:43,720 --> 00:19:46,950 So this is how MED works with all of its features 370 00:19:46,950 --> 00:19:49,290 and all of its caveats. 371 00:19:49,290 --> 00:19:51,240 Again, we did some things here in this lab 372 00:19:51,240 --> 00:19:54,270 I would not recommend doing in a production environment, 373 00:19:54,270 --> 00:19:56,020 just so we're very clear on that. 374 00:19:56,020 --> 00:19:58,890 We did some things here for educational purposes. 375 00:19:58,890 --> 00:20:01,620 Make sure you know what you're doing in the real world 376 00:20:01,620 --> 00:20:04,880 and why you're doing it. 377 00:20:04,880 --> 00:20:08,650 So in this video, we took a rather detailed look 378 00:20:08,650 --> 00:20:13,730 at the MED or metric attribute in BGP, 379 00:20:13,730 --> 00:20:17,290 how it works with many of its different caveats, 380 00:20:17,290 --> 00:20:19,420 such as deterministic MED. 381 00:20:19,420 --> 00:20:24,070 Always compare MED and how missing MED can either 382 00:20:24,070 --> 00:20:29,560 be the minimum or maximum value, depending on the vendor. 383 00:20:29,560 --> 00:20:31,780 I hope this has been informative for you. 384 00:20:31,780 --> 00:20:34,860 And I'd like to thank you for viewing. 385 00:20:34,860 --> 00:20:42,000