1 00:00:00,000 --> 00:00:03,960 [AUDIO LOGO] 2 00:00:03,960 --> 00:00:07,930 3 00:00:07,930 --> 00:00:12,460 So let's jump in by getting an introduction to redistribution. 4 00:00:12,460 --> 00:00:14,500 And what that basically means, we 5 00:00:14,500 --> 00:00:17,500 want to talk about why we need to do redistribution, 6 00:00:17,500 --> 00:00:21,650 under what situations we may have to, and, of course, 7 00:00:21,650 --> 00:00:25,360 the different caveats that each routing protocol has 8 00:00:25,360 --> 00:00:28,540 that we want to watch out for when we do redistribution. 9 00:00:28,540 --> 00:00:31,090 So let's go ahead and jump in and look 10 00:00:31,090 --> 00:00:34,020 at some of those details. 11 00:00:34,020 --> 00:00:37,470 One of the first things we want to say about redistribution 12 00:00:37,470 --> 00:00:40,930 is, whenever it's at all possible, 13 00:00:40,930 --> 00:00:43,890 use a single routing protocol. 14 00:00:43,890 --> 00:00:47,820 In other words, we do want to avoid redistribution. 15 00:00:47,820 --> 00:00:50,580 The reason for that we've already said during 16 00:00:50,580 --> 00:00:53,250 the introduction-- and we're going to see more of it as we 17 00:00:53,250 --> 00:00:55,180 move through this video-- 18 00:00:55,180 --> 00:00:58,000 but we introduced the possibility of loops 19 00:00:58,000 --> 00:01:01,020 and we lose routing information, and, overall, 20 00:01:01,020 --> 00:01:02,880 it's really something that we should 21 00:01:02,880 --> 00:01:05,459 avoid if at all possible. 22 00:01:05,459 --> 00:01:08,220 Of course, we wouldn't be having this discussion 23 00:01:08,220 --> 00:01:10,540 if it was always possible. 24 00:01:10,540 --> 00:01:14,400 So, in many cases, it's not possible to avoid this. 25 00:01:14,400 --> 00:01:17,080 And some of the reasons for that-- and there could be, 26 00:01:17,080 --> 00:01:18,300 of course, many-- 27 00:01:18,300 --> 00:01:20,850 but just one example would be mergers. 28 00:01:20,850 --> 00:01:23,170 One company buys another company. 29 00:01:23,170 --> 00:01:25,980 And one of them was running EIGRP. 30 00:01:25,980 --> 00:01:27,960 The other one's running OSPF. 31 00:01:27,960 --> 00:01:31,200 At some point in time, you may merge on 32 00:01:31,200 --> 00:01:33,180 to a single routing protocol. 33 00:01:33,180 --> 00:01:35,280 But in the meantime, you are probably 34 00:01:35,280 --> 00:01:37,560 going to want your network to function, 35 00:01:37,560 --> 00:01:40,200 and you're using two different protocols. 36 00:01:40,200 --> 00:01:42,930 Same sort of thing with business partners. 37 00:01:42,930 --> 00:01:45,660 We may have business partners that we need to exchange routes 38 00:01:45,660 --> 00:01:49,680 with, and they may be running a completely different protocol. 39 00:01:49,680 --> 00:01:52,460 Different vendors can be an issue. 40 00:01:52,460 --> 00:01:55,790 Sometimes companies do this one to themselves. 41 00:01:55,790 --> 00:01:58,520 I used to work for a company, which I will not mention, 42 00:01:58,520 --> 00:02:01,940 but they had a policy that all network 43 00:02:01,940 --> 00:02:04,010 equipment had to be Cisco. 44 00:02:04,010 --> 00:02:05,930 That was just their policy. 45 00:02:05,930 --> 00:02:07,910 And because of that policy-- 46 00:02:07,910 --> 00:02:10,080 and this happened before I started-- 47 00:02:10,080 --> 00:02:13,430 but they had chosen to run EIGRP. 48 00:02:13,430 --> 00:02:16,070 Fair enough, the EIGRP worked perfectly fine 49 00:02:16,070 --> 00:02:17,850 in their environment. 50 00:02:17,850 --> 00:02:19,340 And then down the road-- 51 00:02:19,340 --> 00:02:21,380 of course, while I was working there-- 52 00:02:21,380 --> 00:02:24,080 they decided to build a whole new building, 53 00:02:24,080 --> 00:02:29,120 and they outfitted that entire building with Nortel equipment. 54 00:02:29,120 --> 00:02:30,800 Yes, it was a little while ago. 55 00:02:30,800 --> 00:02:33,600 Nortel's not really around anymore. 56 00:02:33,600 --> 00:02:37,580 But the Nortel equipment would only run OSPF. 57 00:02:37,580 --> 00:02:40,880 So now we have two different protocols 58 00:02:40,880 --> 00:02:45,110 within our own network just because of a policy change, 59 00:02:45,110 --> 00:02:46,610 where all of a sudden they started 60 00:02:46,610 --> 00:02:48,450 buying from another vendor. 61 00:02:48,450 --> 00:02:50,690 So again, should this be avoided? 62 00:02:50,690 --> 00:02:51,590 Yes. 63 00:02:51,590 --> 00:02:54,620 In this case, it was honestly political. 64 00:02:54,620 --> 00:02:57,800 It obviously was not a decision of the networking department 65 00:02:57,800 --> 00:02:58,920 to do that. 66 00:02:58,920 --> 00:03:01,820 We would have outfitted that building with Cisco equipment, 67 00:03:01,820 --> 00:03:03,300 just like everything else. 68 00:03:03,300 --> 00:03:05,840 But, of course, the decision came from higher up. 69 00:03:05,840 --> 00:03:07,710 We don't exactly know why. 70 00:03:07,710 --> 00:03:11,780 But the point is we got forced into that situation where 71 00:03:11,780 --> 00:03:13,940 we had to do redistribution. 72 00:03:13,940 --> 00:03:16,040 And, to a certain extent, that can bleed over 73 00:03:16,040 --> 00:03:18,440 into this last point that I have on here as well-- 74 00:03:18,440 --> 00:03:20,630 different areas of the network. 75 00:03:20,630 --> 00:03:25,310 That same company had a very, very old mainframe, 76 00:03:25,310 --> 00:03:30,350 and that old mainframe would only run RIP version 2. 77 00:03:30,350 --> 00:03:32,120 It's, of course, been replaced. 78 00:03:32,120 --> 00:03:35,870 But the point is we had to redistribute to the mainframe 79 00:03:35,870 --> 00:03:36,840 as well. 80 00:03:36,840 --> 00:03:38,810 You could argue that that's because of vendors, 81 00:03:38,810 --> 00:03:41,540 or you could argue that that's different areas of the network. 82 00:03:41,540 --> 00:03:43,760 Again, these are all similar concepts. 83 00:03:43,760 --> 00:03:48,650 But the idea is, when possible, avoid redistribution. 84 00:03:48,650 --> 00:03:51,410 And one other thing that should probably be on this list 85 00:03:51,410 --> 00:03:54,470 but I didn't put it on here, sometimes the technology 86 00:03:54,470 --> 00:03:56,300 itself requires it. 87 00:03:56,300 --> 00:04:01,190 Later in this course, we'll be covering MPLS Layer 3 VPN. 88 00:04:01,190 --> 00:04:04,250 And just because of what layer VPN is-- 89 00:04:04,250 --> 00:04:08,010 passing customer routes through a service provider environment 90 00:04:08,010 --> 00:04:08,900 and so on-- 91 00:04:08,900 --> 00:04:12,200 it almost requires redistribution. 92 00:04:12,200 --> 00:04:16,010 Now, that redistribution may happen in the service provider, 93 00:04:16,010 --> 00:04:18,709 and it may happen at the customer's site. 94 00:04:18,709 --> 00:04:20,750 That's a discussion we can have when 95 00:04:20,750 --> 00:04:23,090 we get to MPLS Layer 3 VPNs. 96 00:04:23,090 --> 00:04:25,400 But, regardless of where it happens, 97 00:04:25,400 --> 00:04:27,350 that's another situation where we almost 98 00:04:27,350 --> 00:04:29,180 have to do redistribution. 99 00:04:29,180 --> 00:04:32,690 So again, can we always avoid redistribution? 100 00:04:32,690 --> 00:04:34,430 Absolutely not. 101 00:04:34,430 --> 00:04:37,040 Should we avoid it whenever possible 102 00:04:37,040 --> 00:04:40,340 just because of the problems that it can introduce? 103 00:04:40,340 --> 00:04:41,720 Absolutely. 104 00:04:41,720 --> 00:04:43,670 Now, since we can't always avoid it, 105 00:04:43,670 --> 00:04:45,950 it's, of course, very important to understand 106 00:04:45,950 --> 00:04:50,690 how to avoid its caveats and problems, such as what 107 00:04:50,690 --> 00:04:52,100 do we do with metrics and what do 108 00:04:52,100 --> 00:04:54,050 we do to prevent routing loops. 109 00:04:54,050 --> 00:04:55,740 And that's exactly where we're headed. 110 00:04:55,740 --> 00:04:57,500 So let's get back into this. 111 00:04:57,500 --> 00:04:59,270 Now, this may be a little bit redundant. 112 00:04:59,270 --> 00:05:02,450 But again, the reason we have to do redistribution 113 00:05:02,450 --> 00:05:04,850 in these cases that we mentioned is 114 00:05:04,850 --> 00:05:07,700 to get that end-to-end reachability. 115 00:05:07,700 --> 00:05:10,670 Otherwise, the two different routing protocols 116 00:05:10,670 --> 00:05:13,190 would not be exchanging routes, and we 117 00:05:13,190 --> 00:05:18,030 wouldn't be able to get traffic from one domain to the other. 118 00:05:18,030 --> 00:05:20,780 Now, a couple attributes of redistribution 119 00:05:20,780 --> 00:05:24,560 to keep in mind as we move through the rest of this skill. 120 00:05:24,560 --> 00:05:31,250 First, redistribution always happens from the routing table. 121 00:05:31,250 --> 00:05:35,190 It never happens from the database. 122 00:05:35,190 --> 00:05:40,520 Now, a side effect of this is that redistribution cannot be 123 00:05:40,520 --> 00:05:45,090 redistributed again on the same device. 124 00:05:45,090 --> 00:05:48,050 So let's talk about what this means from two 125 00:05:48,050 --> 00:05:49,440 different perspectives. 126 00:05:49,440 --> 00:05:51,530 First, let's just talk about what 127 00:05:51,530 --> 00:05:53,420 these points mean directly. 128 00:05:53,420 --> 00:05:57,530 And that is, if I learn a route, say, through RIP, 129 00:05:57,530 --> 00:06:03,050 and then I redistribute RIP into OSPF, on the same router, 130 00:06:03,050 --> 00:06:08,810 I then redistribute OSPF into, say, EIGRP. 131 00:06:08,810 --> 00:06:12,860 That route will not end up in EIGRP. 132 00:06:12,860 --> 00:06:18,470 And the reason is it's still in the routing table from RIP. 133 00:06:18,470 --> 00:06:21,600 That's the original routing protocol I learned it from. 134 00:06:21,600 --> 00:06:24,980 So I can't redistribute from RIP into OSPF and then OSPF 135 00:06:24,980 --> 00:06:30,830 into EIGRP and expect the RIP route to end up in EIGRP. 136 00:06:30,830 --> 00:06:32,390 It won't happen. 137 00:06:32,390 --> 00:06:36,360 You never use your own redistributed routes. 138 00:06:36,360 --> 00:06:39,140 So the route stays in the routing table 139 00:06:39,140 --> 00:06:43,640 from the original protocol, which, in my example, is RIP. 140 00:06:43,640 --> 00:06:45,830 Now, the other thing to keep in mind 141 00:06:45,830 --> 00:06:50,030 about redistributing from the database is simply this. 142 00:06:50,030 --> 00:06:52,390 Let's do a slightly different example. 143 00:06:52,390 --> 00:06:59,730 Let's say I learn the exact same route from OSPF and EIGRP. 144 00:06:59,730 --> 00:07:03,250 Now, admin distance would kick in that case. 145 00:07:03,250 --> 00:07:06,750 And assuming it's an EIGRP internal route, 146 00:07:06,750 --> 00:07:10,470 I would put the EIGRP route into my routing table 147 00:07:10,470 --> 00:07:14,820 because it's got an admin distance of 90, by default. 148 00:07:14,820 --> 00:07:19,100 Now, I redistribute OSPF into RIP. 149 00:07:19,100 --> 00:07:22,880 Is that route in the OSPF database? 150 00:07:22,880 --> 00:07:24,050 Yes. 151 00:07:24,050 --> 00:07:28,340 Is it in the routing table from OSPF? 152 00:07:28,340 --> 00:07:29,450 No. 153 00:07:29,450 --> 00:07:33,410 Therefore, when I do the redistribution into RIP, 154 00:07:33,410 --> 00:07:36,470 I will not get that route even though it's 155 00:07:36,470 --> 00:07:38,130 in the OSPF database. 156 00:07:38,130 --> 00:07:40,280 That's what we mean when we say we never 157 00:07:40,280 --> 00:07:42,260 redistribute from the database. 158 00:07:42,260 --> 00:07:47,330 It has to be in the routing table from the source protocol 159 00:07:47,330 --> 00:07:51,230 when you do the redistribution. 160 00:07:51,230 --> 00:07:53,720 Again, another important thing to keep in mind 161 00:07:53,720 --> 00:07:58,220 is that routing protocols do have their own built-in loop 162 00:07:58,220 --> 00:07:59,940 prevention mechanism. 163 00:07:59,940 --> 00:08:03,230 Now, that varies, of course, from protocol to protocol. 164 00:08:03,230 --> 00:08:07,100 However, when we do redistribution between those 165 00:08:07,100 --> 00:08:11,750 routing protocols, we are going to lose that built-in loop 166 00:08:11,750 --> 00:08:13,340 prevention mechanism. 167 00:08:13,340 --> 00:08:14,910 That's fine. 168 00:08:14,910 --> 00:08:17,310 It's a side effect of doing this. 169 00:08:17,310 --> 00:08:22,970 However, that makes it the administrator's responsibility 170 00:08:22,970 --> 00:08:25,100 to prevent the loops. 171 00:08:25,100 --> 00:08:26,750 That means you. 172 00:08:26,750 --> 00:08:31,310 So we have to ensure that loops are prevented. 173 00:08:31,310 --> 00:08:33,200 And something else to keep in mind, 174 00:08:33,200 --> 00:08:36,770 that, with a few exceptions, we do 175 00:08:36,770 --> 00:08:41,000 lose the attributes of the redistributed route. 176 00:08:41,000 --> 00:08:44,120 Again, we can't take an OSPF metric 177 00:08:44,120 --> 00:08:48,120 and try to put it into a RIP hop count. 178 00:08:48,120 --> 00:08:51,740 Now, as it says here, there are a few exceptions. 179 00:08:51,740 --> 00:08:54,570 We'll talk about some of these as we go. 180 00:08:54,570 --> 00:08:57,570 But one notable exception is, for example, 181 00:08:57,570 --> 00:09:01,610 when we redistribute into BGP, whatever metric 182 00:09:01,610 --> 00:09:05,960 is on the route that's coming from the routing table will be 183 00:09:05,960 --> 00:09:10,700 copied into the BGP MED field, or the metric field that Cisco 184 00:09:10,700 --> 00:09:11,520 calls it. 185 00:09:11,520 --> 00:09:13,130 So there are a few exceptions. 186 00:09:13,130 --> 00:09:16,970 But, generally speaking, we lose the attributes. 187 00:09:16,970 --> 00:09:20,420 Of course, when we take a BGP route, for example, 188 00:09:20,420 --> 00:09:23,660 and redistribute it into an IGP, we're 189 00:09:23,660 --> 00:09:25,820 going to lose all sorts of things. 190 00:09:25,820 --> 00:09:28,580 You would lose communities and local preference 191 00:09:28,580 --> 00:09:30,980 and all of those attributes that BGP 192 00:09:30,980 --> 00:09:34,160 carries that none of the other routing protocols support. 193 00:09:34,160 --> 00:09:35,730 Those would all be gone. 194 00:09:35,730 --> 00:09:40,340 So again, most of the time, we lose all the attributes. 195 00:09:40,340 --> 00:09:44,570 There are again a handful of exceptions. 196 00:09:44,570 --> 00:09:47,260 So since we are losing those attributes, 197 00:09:47,260 --> 00:09:50,080 depending on the protocol in question, 198 00:09:50,080 --> 00:09:54,770 we as administrators may need to provide a seed metric. 199 00:09:54,770 --> 00:09:57,440 So let's take a look at the examples here. 200 00:09:57,440 --> 00:09:59,950 First example is RIP. 201 00:09:59,950 --> 00:10:03,370 If you are redistributing connected or static, 202 00:10:03,370 --> 00:10:06,370 those will have a metric of 1. 203 00:10:06,370 --> 00:10:09,670 Everything else, you're going to need a seed 204 00:10:09,670 --> 00:10:13,030 metric because there isn't 1, which 205 00:10:13,030 --> 00:10:15,280 means you need to supply it. 206 00:10:15,280 --> 00:10:20,320 What it actually does is it sets all of the metrics to infinite. 207 00:10:20,320 --> 00:10:23,330 So that makes all of the routes unusable. 208 00:10:23,330 --> 00:10:25,990 So you as the administrator will have to set this. 209 00:10:25,990 --> 00:10:29,110 EIGRP is very similar. 210 00:10:29,110 --> 00:10:32,680 Once again, no seed metrics, which means you're 211 00:10:32,680 --> 00:10:35,020 going to have to provide one or it simply 212 00:10:35,020 --> 00:10:36,850 won't do the redistribution. 213 00:10:36,850 --> 00:10:39,700 One exception to that is if you're redistributing 214 00:10:39,700 --> 00:10:44,530 from one EIGRP AS to another EIGRP AS, 215 00:10:44,530 --> 00:10:47,740 it will actually copy the metric over because it's 216 00:10:47,740 --> 00:10:53,260 going EIGRP to EIGRP, just into different AS numbers. 217 00:10:53,260 --> 00:11:00,850 OSPF actually defaults to a seed metric of 20 for most routes. 218 00:11:00,850 --> 00:11:03,580 Again, there's going to be a few exceptions here. 219 00:11:03,580 --> 00:11:08,230 Just like EIGRP, if you're redistributing OSPF to OSPF, 220 00:11:08,230 --> 00:11:10,360 it's again going to copy that metric. 221 00:11:10,360 --> 00:11:11,960 So that's an exception. 222 00:11:11,960 --> 00:11:16,000 And if you're coming from BGP, it's 223 00:11:16,000 --> 00:11:19,750 going to default to a metric of 1 rather than the 20 224 00:11:19,750 --> 00:11:22,810 that it does for all of the other protocols. 225 00:11:22,810 --> 00:11:25,580 IS-IS is very straightforward. 226 00:11:25,580 --> 00:11:30,220 It simply uses a seed metric of 0 for everything. 227 00:11:30,220 --> 00:11:34,570 And BGP, again, it'll copy it from the other routing 228 00:11:34,570 --> 00:11:38,980 protocols, as we mentioned earlier, except connected 229 00:11:38,980 --> 00:11:45,060 and static will have a MED or metric of 0. 230 00:11:45,060 --> 00:11:47,520 Some final notes on redistribution. 231 00:11:47,520 --> 00:11:52,260 First, it, of course, can be done either in one direction 232 00:11:52,260 --> 00:11:54,450 or in both directions, which we generally 233 00:11:54,450 --> 00:11:57,870 call mutual redistribution, and it 234 00:11:57,870 --> 00:12:02,260 can be done on either one device or multiple devices. 235 00:12:02,260 --> 00:12:05,520 So, of course, we usually want to use multiple devices 236 00:12:05,520 --> 00:12:07,350 for redundancy. 237 00:12:07,350 --> 00:12:09,240 However, be aware that when you're 238 00:12:09,240 --> 00:12:13,270 doing mutual redistribution on multiple devices, 239 00:12:13,270 --> 00:12:15,910 this is where we get a risk of loops, 240 00:12:15,910 --> 00:12:18,420 and we have to be very, very careful. 241 00:12:18,420 --> 00:12:23,040 Again, you can safely do mutual redistribution 242 00:12:23,040 --> 00:12:26,970 on a single router without creating loops. 243 00:12:26,970 --> 00:12:31,150 But again, you have that problem is there's no redundancy. 244 00:12:31,150 --> 00:12:33,580 So if you lose that one device, of course, 245 00:12:33,580 --> 00:12:36,000 your entire network would be down. 246 00:12:36,000 --> 00:12:39,990 Now, it can still cause sub-optimal routing even 247 00:12:39,990 --> 00:12:41,760 on a single router. 248 00:12:41,760 --> 00:12:46,770 Very, very simple example, if I have two routers here-- 249 00:12:46,770 --> 00:12:51,660 let's say, over here, I'm running RIP; over here, I'm 250 00:12:51,660 --> 00:12:53,520 running OSPF-- 251 00:12:53,520 --> 00:12:55,980 and I only configure redistribution 252 00:12:55,980 --> 00:12:58,950 on one of these routers. 253 00:12:58,950 --> 00:13:02,200 Well, let's say we have a RIP route over here, 254 00:13:02,200 --> 00:13:07,200 Network X. Network X gets sent to this router. 255 00:13:07,200 --> 00:13:09,870 This router redistributes it into OSPF 256 00:13:09,870 --> 00:13:12,160 and sends it down to this router. 257 00:13:12,160 --> 00:13:14,190 Well, now, here's the problem. 258 00:13:14,190 --> 00:13:17,310 OSPF has an admin distance of 110, 259 00:13:17,310 --> 00:13:21,390 and RIP has an admin distance of 120. 260 00:13:21,390 --> 00:13:23,220 I didn't draw it, but remember that this 261 00:13:23,220 --> 00:13:24,910 will learn it from RIP as well. 262 00:13:24,910 --> 00:13:27,420 So the router at the bottom-- 263 00:13:27,420 --> 00:13:29,550 we'll call it Router B-- 264 00:13:29,550 --> 00:13:32,370 learns the route from OSPF and RIP. 265 00:13:32,370 --> 00:13:35,130 Well, given the two admin distances, which 266 00:13:35,130 --> 00:13:36,960 one is it going to follow? 267 00:13:36,960 --> 00:13:39,420 The answer is it's going to follow OSPF. 268 00:13:39,420 --> 00:13:41,880 And, therefore, any traffic that arrives 269 00:13:41,880 --> 00:13:46,470 at Router B going to Network X, instead of going directly, 270 00:13:46,470 --> 00:13:50,400 like we would normally want it to, instead it's 271 00:13:50,400 --> 00:13:53,970 going to go up to this router following OSPF 272 00:13:53,970 --> 00:13:57,420 and then over here to network X. 273 00:13:57,420 --> 00:13:58,890 Will it still work? 274 00:13:58,890 --> 00:14:00,430 Yes, of course. 275 00:14:00,430 --> 00:14:02,430 It's just sub-optimal routing. 276 00:14:02,430 --> 00:14:04,560 It's not a loop. 277 00:14:04,560 --> 00:14:08,040 But just keep in mind that sub-optimal routing 278 00:14:08,040 --> 00:14:12,900 is only one step away from being a routing loop. 279 00:14:12,900 --> 00:14:15,100 We'll talk about that more a little bit later. 280 00:14:15,100 --> 00:14:18,750 But look at that white line that I just drew on there. 281 00:14:18,750 --> 00:14:20,760 It's almost a loop. 282 00:14:20,760 --> 00:14:24,430 All I'd have to do is this to make it a loop. 283 00:14:24,430 --> 00:14:26,460 So it's very close to being a loop. 284 00:14:26,460 --> 00:14:28,320 We have to be very, very careful. 285 00:14:28,320 --> 00:14:30,600 Again, without doing the mutual redistribution, 286 00:14:30,600 --> 00:14:33,310 though, that last error won't happen. 287 00:14:33,310 --> 00:14:36,000 And that's why we said this is safe. 288 00:14:36,000 --> 00:14:38,520 It just may be sub-optimal. 289 00:14:38,520 --> 00:14:42,310 And again, this last point, we've pretty much already said 290 00:14:42,310 --> 00:14:46,200 if you do redistribution on multiple routers, 291 00:14:46,200 --> 00:14:49,380 it will, of course, add redundancy, 292 00:14:49,380 --> 00:14:52,350 but it can lead to those routing loops. 293 00:14:52,350 --> 00:14:55,780 This is what we have to watch out for. 294 00:14:55,780 --> 00:15:00,480 So, in this video, we got an introduction to redistribution 295 00:15:00,480 --> 00:15:03,120 between routing protocols, specifically 296 00:15:03,120 --> 00:15:07,560 our IGPs with a minor mention of BGP here and there. 297 00:15:07,560 --> 00:15:11,400 We saw the caveats of each of the different IGPs, how they 298 00:15:11,400 --> 00:15:13,860 handle the metrics, and we talked about some 299 00:15:13,860 --> 00:15:17,580 of the dangers we have to watch out for with this creating 300 00:15:17,580 --> 00:15:20,610 loops if we're doing mutual redistribution 301 00:15:20,610 --> 00:15:22,720 on multiple routers. 302 00:15:22,720 --> 00:15:25,860 So it's time to jump in and start actually 303 00:15:25,860 --> 00:15:28,200 doing this redistribution, and we'll 304 00:15:28,200 --> 00:15:33,330 start that in the next video with IS-IS redistribution. 305 00:15:33,330 --> 00:15:36,720 Until then, I hope this has been informative for you, 306 00:15:36,720 --> 00:15:39,830 and I'd like to thank you for viewing. 307 00:15:39,830 --> 00:15:43,000