WEBVTT 1 00:00.000 --> 00:04.640 So we know that we can use GRE to carry our IP traffic. 2 00:04.640 --> 00:09.840 And the question is, can we also use it to carry our routing protocol traffic? 3 00:09.840 --> 00:12.560 And the answer is yes, we absolutely can. 4 00:12.560 --> 00:16.080 This is going to be very helpful for us if we're trying to connect two 5 00:16.080 --> 00:16.860 different networks 6 00:16.860 --> 00:17.860 to one another. 7 00:17.860 --> 00:21.960 So let's say we've got these two disparate networks with a bunch of devices and 8 00:21.960 --> 00:22.640 subnets. 9 00:22.640 --> 00:25.560 We'll say subnets A, B and C on the left. 10 00:25.560 --> 00:28.240 Subnets D, E and F on the right. 11 00:28.240 --> 00:32.470 And then we've got these routers here that have connections into those WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 11 00:28.240 --> 00:32.470 And then we've got these routers here that have connections into those 12 00:32.470 --> 00:34.040 individual networks. 13 00:34.040 --> 00:39.680 And then we're going to form a tunnel relationship here from one router to the 14 00:39.680 --> 00:40.440 other. 15 00:40.440 --> 00:45.330 At this point, everything I've drawn in yellow here, this is going to be part 16 00:45.330 --> 00:46.560 of the overlay. 17 00:46.560 --> 00:51.470 It's the network that we're trying to form, essentially, regardless of the 18 00:51.470 --> 00:52.600 physical network 19 00:52.600 --> 00:54.480 that we already have constructed. 20 00:54.480 --> 00:59.880 The physical network we have constructed would be a bunch of routers down here. 21 00:59.880 --> 01:03.240 And they're all connected to one another in various fashions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:59.880 --> 01:03.240 And they're all connected to one another in various fashions. 22 01:03.240 --> 01:05.760 And so maybe it's something like this. 23 01:05.760 --> 01:11.320 And this, once again, is known as the underlay. 24 01:11.320 --> 01:16.720 So what we'd like to do is be able to advertise routes from one network to the 25 01:16.720 --> 01:17.280 other. 26 01:17.280 --> 01:22.770 So going back to our overlay network, let's say I want to run EIGRP as my 27 01:22.770 --> 01:24.000 routing protocol 28 01:24.000 --> 01:25.000 in this domain. 29 01:25.000 --> 01:31.130 Well, I can run EIGRP and I can send my advertisements through the tunnel WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 29 01:25.000 --> 01:31.130 Well, I can run EIGRP and I can send my advertisements through the tunnel 30 01:31.130 --> 01:32.880 interface be received on 31 01:32.880 --> 01:34.200 the other side. 32 01:34.200 --> 01:40.440 So now I also know where D, E and F are on the left. 33 01:40.440 --> 01:45.680 And if I advertise back the other direction, well, now I'm going to see that I 34 01:45.680 --> 01:46.360 now know 35 01:46.360 --> 01:51.720 where A, B and C are on my devices on the right. 36 01:51.720 --> 01:56.600 So I have successfully shared routes between the two networks. 37 01:56.600 --> 01:59.460 Now notice something very, very important, which ties to what we just talked 38 01:59.460 --> 01:59.880 about in 39 01:59.880 --> 02:01.040 the last video. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 39 01:59.880 --> 02:01.040 the last video. 40 02:01.040 --> 02:06.630 And that's that the underlay network has no clue where any of these networks 41 02:06.630 --> 02:07.560 are, nor 42 02:07.560 --> 02:09.160 does it need to know? 43 02:09.160 --> 02:13.170 It just needs to know how to get from this router on the left to this router on 44 02:13.170 --> 02:14.400 the right, 45 02:14.400 --> 02:18.270 using one of the physical interfaces or potentially one of the loopback 46 02:18.270 --> 02:19.160 interfaces. 47 02:19.160 --> 02:22.200 But either way, we understand that we're going to have a layer three network 48 02:22.200 --> 02:22.840 that needs to 49 02:22.840 --> 02:24.120 converge. 50 02:24.120 --> 02:27.520 As a result, we might well be running another routing protocol in here. 51 02:27.520 --> 02:29.120 Maybe we're running OSPF. 52 02:29.120 --> 02:32.160 It doesn't have to be the same one as the overlay. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 52 02:29.120 --> 02:32.160 It doesn't have to be the same one as the overlay. 53 02:32.160 --> 02:36.320 And so we're running OSPF and that forms convergence in this space and make 54 02:36.320 --> 02:37.000 sure that 55 02:37.000 --> 02:41.570 everybody knows where all of the layer three interfaces are, namely when a 56 02:41.570 --> 02:42.440 packet comes 57 02:42.440 --> 02:47.840 in for or into this router and it encapsulates, it needs to send it to the 58 02:47.840 --> 02:49.280 tunnel interface 59 02:49.280 --> 02:52.360 on the right, basically this logical interface. 60 02:52.360 --> 02:55.720 Well that logical interface is it has to be accessible via a physical interface 61 02:55.720 --> 02:55.960 . 62 02:55.960 --> 02:58.360 Maybe it's this truly physical interface. 63 02:58.360 --> 03:02.770 Maybe it's a loopback that is part of the physical device and it's part of the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 63 02:58.360 --> 03:02.770 Maybe it's a loopback that is part of the physical device and it's part of the 64 03:02.770 --> 03:03.600 underlay. 65 03:03.600 --> 03:07.680 Either way, I just need to be able to get to that interface so that the router 66 03:07.680 --> 03:08.760 can be encapsulate 67 03:08.760 --> 03:10.160 that traffic. 68 03:10.160 --> 03:13.480 So that is the responsibility of the underlay. 69 03:13.480 --> 03:17.480 But this is going to lead us to a rather interesting scenario. 70 03:17.480 --> 03:22.640 And the scenario is known as recursive routing. 71 03:22.640 --> 03:27.270 This is a commonly cited scenario, especially when it comes to our encore 72 03:27.270 --> 03:28.040 studies. 73 03:28.040 --> 03:31.320 It's just something that Cisco expects us to be able to understand. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 73 03:28.040 --> 03:31.320 It's just something that Cisco expects us to be able to understand. 74 03:31.320 --> 03:34.540 Now in the real world, we're probably most likely to see this in a lab 75 03:34.540 --> 03:35.840 environment truthfully 76 03:35.840 --> 03:40.010 when we're playing around with tunnels and we probably are going to inject a 77 03:40.010 --> 03:40.440 bad route 78 03:40.440 --> 03:42.480 somewhere and cause this issue. 79 03:42.480 --> 03:45.280 But it is certainly very easy to cause the issue. 80 03:45.280 --> 03:49.080 We do not want to cause this in a production network, which is why we need to 81 03:49.080 --> 03:49.720 know about 82 03:49.720 --> 03:50.720 it. 83 03:50.720 --> 03:53.120 So what exactly is this big issue? 84 03:53.120 --> 03:58.070 Well it has to do with a very important rule that we need to make sure we 85 03:58.070 --> 03:59.200 establish. 86 03:59.200 --> 04:12.360 And that is that we cannot use our tunnel interface in order to access the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 86 03:59.200 --> 04:12.360 And that is that we cannot use our tunnel interface in order to access the 87 04:12.360 --> 04:16.800 tunnel destination. 88 04:16.800 --> 04:20.360 What in the world are we talking about here? 89 04:20.360 --> 04:21.760 Well let's diagram this out. 90 04:21.760 --> 04:26.000 Let's say we have a simpler network than what we drew over on the left. 91 04:26.000 --> 04:28.600 We just have a few routers connected here. 92 04:28.600 --> 04:36.040 We want to form a tunnel relationship between routers one and three. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 92 04:28.600 --> 04:36.040 We want to form a tunnel relationship between routers one and three. 93 04:36.040 --> 04:38.480 And we have router two down here. 94 04:38.480 --> 04:40.720 And let's just assign some IP addresses here. 95 04:40.720 --> 04:44.320 We'll say that one, that two, that three, that four. 96 04:44.320 --> 04:47.400 Now even though I use those sequentially, these would be two different subnets. 97 04:47.400 --> 04:51.800 So this would be subnet A here and subnet B over on the right. 98 04:51.800 --> 04:56.120 And then we've got some overlay networks on the other side of the tunnel. 99 04:56.120 --> 05:00.680 So maybe subnets C and D, something like that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 99 04:56.120 --> 05:00.680 So maybe subnets C and D, something like that. 100 05:00.680 --> 05:05.590 So I've got a packet that arrives on router one, source address from subnet C, 101 05:05.590 --> 05:06.560 destination 102 05:06.560 --> 05:09.840 address is going to be subnet D. 103 05:09.840 --> 05:13.320 So that's great and all except we're going to encapsulate this. 104 05:13.320 --> 05:15.440 And we need to send it across the tunnel. 105 05:15.440 --> 05:18.320 Well in order for me to send it across the tunnel, I need to put, this is the 106 05:18.320 --> 05:18.960 inner header 107 05:18.960 --> 05:22.240 up here, I need the outer header to have a destination. 108 05:22.240 --> 05:25.160 And this destination is going to be .4. 109 05:25.160 --> 05:27.360 Which is this interface right here. 110 05:27.360 --> 05:28.600 It's a physical interface. 111 05:28.600 --> 05:29.600 It's part of the underlay. 112 05:29.600 --> 05:33.600 I just need to make sure that I have a route to .4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 112 05:29.600 --> 05:33.600 I just need to make sure that I have a route to .4. 113 05:33.600 --> 05:36.560 So router one's going to check its routing table. 114 05:36.560 --> 05:40.880 And it's going to see that this .4, whatever the subnet is, maybe it's a slash 115 05:40.880 --> 05:42.040 32, probably 116 05:42.040 --> 05:45.280 more like a slash 30 or something like that. 117 05:45.280 --> 05:50.490 But either way, this is going to be sent out its physical gig zero, zero 118 05:50.490 --> 05:51.640 interface. 119 05:51.640 --> 05:54.800 That would be this interface right here. 120 05:54.800 --> 05:58.720 And it's got a next hop of router two. 121 05:58.720 --> 05:59.720 Perfect. 122 05:59.720 --> 06:04.840 All right, so I send that packet out to router two, and then I pass that up to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 122 05:59.720 --> 06:04.840 All right, so I send that packet out to router two, and then I pass that up to 123 06:04.840 --> 06:05.880 router three 124 06:05.880 --> 06:06.880 and life is good. 125 06:06.880 --> 06:10.200 So this would be a steady state type of situation. 126 06:10.200 --> 06:11.280 Here's the question. 127 06:11.280 --> 06:14.080 How exactly did I learn about this route? 128 06:14.080 --> 06:20.160 Maybe I am doing something like running OSPF here in the underlay. 129 06:20.160 --> 06:23.080 So this would be an OSPF route. 130 06:23.080 --> 06:26.920 We have formed OSPF adjacencies here and here. 131 06:26.920 --> 06:30.770 And so we know where all of these IP addresses and importantly, where all of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 131 06:26.920 --> 06:30.770 And so we know where all of these IP addresses and importantly, where all of 132 06:30.770 --> 06:31.600 these subnets 133 06:31.600 --> 06:32.840 exist. 134 06:32.840 --> 06:34.360 So again, that's perfectly fine. 135 06:34.360 --> 06:35.680 This is steady state operation. 136 06:35.680 --> 06:38.360 My routing table is good to go here. 137 06:38.360 --> 06:43.660 But now let's say that this domain over on the right and this domain over on 138 06:43.660 --> 06:44.480 the left, 139 06:44.480 --> 06:48.320 that these are running EIGRP. 140 06:48.320 --> 06:53.640 Because after all, we do need router one to know where subnet D is. 141 06:53.640 --> 06:56.720 We need router three to know where subnet C is. 142 06:56.720 --> 07:00.280 And there might be a lot of other subnets involved in all of this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 142 06:56.720 --> 07:00.280 And there might be a lot of other subnets involved in all of this. 143 07:00.280 --> 07:02.040 So how are they going to find out about this? 144 07:02.040 --> 07:06.920 Well, we're going to form an EIGRP. 145 07:06.920 --> 07:10.360 Neighborship across the tunnel interface, which is perfectly fine. 146 07:10.360 --> 07:17.160 We just said we can enable routing across a GRE or across a tunnel interface. 147 07:17.160 --> 07:21.200 And so we're going to advertise EIGRP routes across this. 148 07:21.200 --> 07:26.840 So I'm going to advertise subnet D. And from router three, router one is going 149 07:26.840 --> 07:27.480 to advertise 150 07:27.480 --> 07:30.080 subnet C. And that's perfectly fine. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 150 07:27.480 --> 07:30.080 subnet C. And that's perfectly fine. 151 07:30.080 --> 07:32.840 Everything is good so far still. 152 07:32.840 --> 07:34.280 But here's the question. 153 07:34.280 --> 07:37.280 How exactly did we configure EIGRP? 154 07:37.280 --> 07:42.960 Because sometimes EIGRP and other routing protocols will victim to this concept 155 07:42.960 --> 07:43.520 of let's 156 07:43.520 --> 07:49.920 advertise all routes. 157 07:49.920 --> 07:51.520 That includes my connected routes. 158 07:51.520 --> 07:55.040 That includes routes that are already being advertised by other protocols. 159 07:55.040 --> 08:00.520 And so I might have told this EIGRP process to advertise everything. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 159 07:55.040 --> 08:00.520 And so I might have told this EIGRP process to advertise everything. 160 08:00.520 --> 08:06.660 Well, router three is attached to subnet B. And so what if it actually advert 161 08:06.660 --> 08:07.440 ises subnet 162 08:07.440 --> 08:09.960 B across the tunnel? 163 08:09.960 --> 08:15.810 Well, router one is going to receive that update, realize, oh, I can get to sub 164 08:15.810 --> 08:16.280 net B. 165 08:16.280 --> 08:18.240 And now remember, subnet B is right here. 166 08:18.240 --> 08:21.690 Now, we probably should have just called it subnet B instead of a dot four 167 08:21.690 --> 08:22.360 address. 168 08:22.360 --> 08:26.490 But either way, we already have an entry for subnet B. It's via the physical 169 08:26.490 --> 08:27.240 underlay, 170 08:27.240 --> 08:29.920 heading to router two, learned it via OSPF. 171 08:29.920 --> 08:32.960 Again, that is how it's supposed to be. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 171 08:29.920 --> 08:32.960 Again, that is how it's supposed to be. 172 08:32.960 --> 08:38.640 But now I just learned about subnet B via EIGRP. 173 08:38.640 --> 08:43.040 Well, what's the EIGRP going to, or what is that router going to do with an EIG 174 08:43.040 --> 08:43.720 RP route 175 08:43.720 --> 08:45.520 compared to OSPF? 176 08:45.520 --> 08:49.410 Well, if I get the same subnet, I'm going to compare my administrative distance 177 08:49.410 --> 08:49.880 values 178 08:49.880 --> 08:55.860 with EIGRP has 90, OSPF has 110, and 90 is going to win because the lower 179 08:55.860 --> 08:57.120 administrative 180 08:57.120 --> 08:59.240 distance is better. 181 08:59.240 --> 09:02.360 Now, I am saying I'm running OSPF in this case. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 181 08:59.240 --> 09:02.360 Now, I am saying I'm running OSPF in this case. 182 09:02.360 --> 09:06.440 Maybe I have a floating static route, meaning that I've got a static route that 183 09:06.440 --> 09:07.080 I manually 184 09:07.080 --> 09:11.520 configure with an administrative distance of 200 or something like 250. 185 09:11.520 --> 09:14.720 But either way, EIGRP will win over all of this. 186 09:14.720 --> 09:18.560 So we're going to cross out our route here and change it. 187 09:18.560 --> 09:20.240 And we're going to say, hey, guess what? 188 09:20.240 --> 09:25.320 subnet B actually lives out the tunnel interface via router three. 189 09:25.320 --> 09:28.880 And I learned that via EIGRP. 190 09:28.880 --> 09:34.760 So that is a big problem because next time a packet tries to come in to router WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 190 09:28.880 --> 09:34.760 So that is a big problem because next time a packet tries to come in to router 191 09:34.760 --> 09:35.400 one and 192 09:35.400 --> 09:40.560 it's destined for the other side of the tunnel, well, it's going to want to 193 09:40.560 --> 09:42.800 encapsulate this 194 09:42.800 --> 09:44.480 and then figure out where to send it. 195 09:44.480 --> 09:46.760 Well, it's supposed to send it out the tunnel interface. 196 09:46.760 --> 09:48.240 Well, that doesn't make any sense. 197 09:48.240 --> 09:51.870 It's almost like a chicken and egg problem here, which is, do I encapsulate it 198 09:51.870 --> 09:52.400 first? 199 09:52.400 --> 09:54.160 Do I send it first via the tunnel? 200 09:54.160 --> 09:58.080 If I send it via the tunnel, then I've got to send it out the tunnel to get to 201 09:58.080 --> 09:58.680 the other 202 09:58.680 --> 10:01.200 side of the underlay, which doesn't make any sense. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 202 09:58.680 --> 10:01.200 side of the underlay, which doesn't make any sense. 203 10:01.200 --> 10:06.480 And what we're really doing here is we're crisscrossing our overlay and under 204 10:06.480 --> 10:07.640 lay networks. 205 10:07.640 --> 10:10.880 And this is a big, big problem. 206 10:10.880 --> 10:12.240 This is going to break. 207 10:12.240 --> 10:17.520 In fact, Cisco is running, just messaging back and forth. 208 10:17.520 --> 10:21.240 It's going to recognize that this is a problem on the router. 209 10:21.240 --> 10:25.320 This is going to actually generate an error message. 210 10:25.320 --> 10:32.250 When that error message is going to cite the fact that there is recursive WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 210 10:25.320 --> 10:32.250 When that error message is going to cite the fact that there is recursive 211 10:32.250 --> 10:33.480 routing. 212 10:33.480 --> 10:39.790 And so because there's recursive routing happening, we are going to shut down 213 10:39.790 --> 10:42.680 that tunnel interface. 214 10:42.680 --> 10:47.780 Now this is not a hard shutdown situation where the tunnel interface is 215 10:47.780 --> 10:48.520 actually down 216 10:48.520 --> 10:53.300 down, but it is going to temporarily disable it until this issue rectifies 217 10:53.300 --> 10:54.080 itself. 218 10:54.080 --> 10:56.200 But here's the question. 219 10:56.200 --> 10:59.520 Is it going to rectify itself? 220 10:59.520 --> 11:02.440 Kind of yes, but also then kind of no. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 220 10:59.520 --> 11:02.440 Kind of yes, but also then kind of no. 221 11:02.440 --> 11:05.240 In other words, this is going to go through a process here. 222 11:05.240 --> 11:08.760 So first of all, we are going to exchange. 223 11:08.760 --> 11:14.520 We've got an EIGRP route now, and we've got an OSPF route, and we're going to 224 11:14.520 --> 11:15.200 choose 225 11:15.200 --> 11:17.520 the EIGRP route. 226 11:17.520 --> 11:21.930 Second of all, we're going to flag this error, and we're going to shut down our 227 11:21.930 --> 11:23.120 tunnel interface, 228 11:23.120 --> 11:28.280 which interestingly means that I'm going to lose my ERGRP route. 229 11:28.280 --> 11:32.630 Because I just lost my ERGRP route, I am now back to an OSPF route, which means WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 229 11:28.280 --> 11:32.630 Because I just lost my ERGRP route, I am now back to an OSPF route, which means 230 11:32.630 --> 11:33.160 that I 231 11:33.160 --> 11:35.720 can form my tunnel again. 232 11:35.720 --> 11:39.430 So the tunnel connection will come back online, at which point we come all the 233 11:39.430 --> 11:40.160 way back to 234 11:40.160 --> 11:45.000 the start, at which point we exchange EIGRP messages. 235 11:45.000 --> 11:49.880 I learn about this route via the tunnel, and I install it into my routing table 236 11:49.880 --> 11:50.480 , and then 237 11:50.480 --> 11:54.200 we progressively go through this looping process. 238 11:54.200 --> 11:57.450 So this error is going to continuously appear, and appear, and appear, and 239 11:57.450 --> 11:58.400 appear, and appear 240 11:58.400 --> 12:02.680 over and over again, because we never break out of this loop. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 240 11:58.400 --> 12:02.680 over and over again, because we never break out of this loop. 241 12:02.680 --> 12:08.830 So that's why I say it kind of resolves itself, and that the tunnel is shut 242 12:08.830 --> 12:09.840 down here, but 243 12:09.840 --> 12:14.320 it also kind of doesn't because it'll never hit stability. 244 12:14.320 --> 12:17.760 So this is certainly a problem that we need to address. 245 12:17.760 --> 12:22.240 The question, with any of these kinds of situations, is how do we address it? 246 12:22.240 --> 12:27.760 How do we prevent this recursive lookup issue? 247 12:27.760 --> 12:30.320 So what's our prevention methods? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 247 12:27.760 --> 12:30.320 So what's our prevention methods? 248 12:30.320 --> 12:34.520 Well, the first one is pretty simple. 249 12:34.520 --> 12:37.880 We just look and see, well, what caused all of this problem? 250 12:37.880 --> 12:38.880 Well, it's right here. 251 12:38.880 --> 12:44.120 It's the fact that we decided to advertise an underlay route into the overlay. 252 12:44.120 --> 12:52.250 And so the number one prevention is simply don't advertise the route into the 253 12:52.250 --> 12:53.560 overlay. 254 12:53.560 --> 13:01.380 Don't advertise underlay routes, we'll say, and especially the tunnel WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 254 12:53.560 --> 13:01.380 Don't advertise underlay routes, we'll say, and especially the tunnel 255 13:01.380 --> 13:03.000 destination. 256 13:03.000 --> 13:10.360 Don't advertise those into the tunnel, and we'll say to tunnel neighbors. 257 13:10.360 --> 13:12.360 This is the primary source of the problem. 258 13:12.360 --> 13:15.960 If we just cut this off, then we should be good to go. 259 13:15.960 --> 13:20.490 But what if, for whatever reason, we find ourselves in a sticky situation, we 260 13:20.490 --> 13:20.960 can't 261 13:20.960 --> 13:25.210 change the way our routing is being advertised, and we're facing this problem 262 13:25.210 --> 13:26.120 in a production 263 13:26.120 --> 13:27.120 network. 264 13:27.120 --> 13:30.320 Well, then we're going to have to get a little bit clever. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 264 13:27.120 --> 13:30.320 Well, then we're going to have to get a little bit clever. 265 13:30.320 --> 13:36.510 Now one thing we can do is compare OSPF and EIGRP, because if we're comparing 266 13:36.510 --> 13:37.280 these two 267 13:37.280 --> 13:41.240 routing protocols, then we know that we have an administrative distance issue 268 13:41.240 --> 13:42.280 where OSPF 269 13:42.280 --> 13:46.340 has a lower priority, I guess we could say a higher, higher, higher 270 13:46.340 --> 13:48.120 administrative distance 271 13:48.120 --> 13:51.840 of 110 versus EIGRP having 90. 272 13:51.840 --> 13:57.280 And so this might be an administrative distance issue, or it could also be a 273 13:57.280 --> 13:58.440 cost or metric 274 13:58.440 --> 14:02.320 issue, because what if we're running EIGRP for both? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 274 13:58.440 --> 14:02.320 issue, because what if we're running EIGRP for both? 275 14:02.320 --> 14:06.600 Well, then I just need to make sure the tunnel has a very bad metric. 276 14:06.600 --> 14:11.160 And if I'm running OSPF, then I need to make sure it has a very bad cost. 277 14:11.160 --> 14:15.710 That way this path would still be preferred simply because the cost appears to 278 14:15.710 --> 14:16.600 be shorter. 279 14:16.600 --> 14:19.200 Now, Cisco tries to help us out with this. 280 14:19.200 --> 14:23.000 This actually is the default setting for tunnel interfaces. 281 14:23.000 --> 14:26.540 It's going to have a very poor metric and a very poor cost to try to help us 282 14:26.540 --> 14:27.080 prevent 283 14:27.080 --> 14:31.940 this issue for just happen to be running OSPF or EIGRP everywhere for the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 283 14:27.080 --> 14:31.940 this issue for just happen to be running OSPF or EIGRP everywhere for the 284 14:31.940 --> 14:33.040 overlay or the 285 14:33.040 --> 14:34.720 or and the overlay at the same time. 286 14:34.720 --> 14:38.230 But we might still have to manipulate this, especially if we have multiple 287 14:38.230 --> 14:38.800 tunnels or 288 14:38.800 --> 14:40.800 something along those lines. 289 14:40.800 --> 14:45.600 Now, lastly, we can start to put together all of the knowledge that we've been 290 14:45.600 --> 14:46.600 obtaining, 291 14:46.600 --> 14:53.710 and we could actually deploy a separate VRF to the overlay and a separate VRF 292 14:53.710 --> 14:55.960 to the underlay. 293 14:55.960 --> 15:00.610 This is pretty common in large network fabrics where we're heavily taking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 293 14:55.960 --> 15:00.610 This is pretty common in large network fabrics where we're heavily taking 294 15:00.610 --> 15:01.800 advantage of overlay 295 15:01.800 --> 15:05.320 and underlay networks, especially with software defined networks. 296 15:05.320 --> 15:08.920 So at that point, we have a completely separate routing domain. 297 15:08.920 --> 15:13.140 And then at that point, we can't advertise from one to the other because the 298 15:13.140 --> 15:13.840 interfaces 299 15:13.840 --> 15:16.800 are locked to their specific VRFs. 300 15:16.800 --> 15:19.160 So that would certainly be another solution as well. 301 15:19.160 --> 15:23.400 But again, I do come back to the fact that if we can just not advertise that 302 15:23.400 --> 15:24.440 tunnel destination 303 15:24.440 --> 15:28.150 or again, the underlay network into the overlay, then at that point, we're not 304 15:28.150 --> 15:28.760 going to have 305 15:28.760 --> 15:29.760 this issue at all. 306 15:29.760 --> 15:33.280 But we do need to be aware of it in case we see it in production networks. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 306 15:29.760 --> 15:33.280 But we do need to be aware of it in case we see it in production networks. 307 15:33.280 --> 15:35.850 And of course, in case Cisco wants to make sure that we understand what's 308 15:35.850 --> 15:36.800 happening here 309 15:36.800 --> 15:37.560 and how to fix it.