WEBVTT 1 00:00.000 --> 00:05.200 What we want to do here is talk through the concept of recursive routing. 2 00:05.200 --> 00:08.840 So if we're building a tunnel environment, in fact, the scenario here says an 3 00:08.840 --> 00:09.280 engineer 4 00:09.280 --> 00:13.120 configured the environment and is now seeing recursive routing. 5 00:13.120 --> 00:16.420 So we need to understand what causes it and make sure that we can talk through 6 00:16.420 --> 00:16.760 potential 7 00:16.760 --> 00:17.840 solutions. 8 00:17.840 --> 00:22.760 So scenario or question number one here, the engineer proposes a change to the 9 00:22.760 --> 00:23.640 OSPF cost. 10 00:23.640 --> 00:28.340 So we want to change the cost of OSPF probably on these links here or 11 00:28.340 --> 00:29.800 potentially even the 12 00:29.800 --> 00:31.800 tunnel interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 12 00:29.800 --> 00:31.800 tunnel interface. 13 00:31.800 --> 00:34.480 But either way, the question is, will this work? 14 00:34.480 --> 00:38.010 The reason why the details don't matter a whole lot is because we can already 15 00:38.010 --> 00:38.400 answer 16 00:38.400 --> 00:41.240 the question, this is not going to work. 17 00:41.240 --> 00:45.570 Changing OSPF cost doesn't matter because the issue here is that we're going to 18 00:45.570 --> 00:47.520 be receiving 19 00:47.520 --> 00:52.360 these underlay routes across the overlay and EIGRP. 20 00:52.360 --> 00:54.920 So changing OSPF cost isn't going to fix the issue. 21 00:54.920 --> 00:59.360 It's not going to impact the fact that EIGRP has administrative distance of 90. 22 00:59.360 --> 01:02.160 OSPF has administrative distance of 110. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 22 00:59.360 --> 01:02.160 OSPF has administrative distance of 110. 23 01:02.160 --> 01:08.040 And so if I see these routes, let's say we've got routes A, B, C, and D here. 24 01:08.040 --> 01:12.700 So if I think that routes C and D are better known through EIGRP, it doesn't 25 01:12.700 --> 01:13.560 matter what 26 01:13.560 --> 01:17.840 the OSPF cost is, I'm always going to favor EIGRP. 27 01:17.840 --> 01:20.560 Now question number two says, okay, it's almost like a follow up, right? 28 01:20.560 --> 01:23.720 Like, okay, so the cost isn't going to fix it. 29 01:23.720 --> 01:29.680 But what if we change the OSPF administrative distance on routers one and two? 30 01:29.680 --> 01:34.040 So now rather than saying it's 110, we say that it's 80. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 30 01:29.680 --> 01:34.040 So now rather than saying it's 110, we say that it's 80. 31 01:34.040 --> 01:35.040 Will this work? 32 01:35.040 --> 01:40.150 Believe it or not, the answer is yes, this would actually work because now if I 33 01:40.150 --> 01:41.160 'm getting, 34 01:41.160 --> 01:46.300 if I understand that routes C and D can be reached via both directions, the 35 01:46.300 --> 01:46.720 reason why 36 01:46.720 --> 01:51.340 I'm favoring EIGRP to start with is because the administrative distance is more 37 01:51.340 --> 01:52.200 favorable. 38 01:52.200 --> 01:54.200 So this is a lower number. 39 01:54.200 --> 01:57.280 But now OSPF has the lower number. 40 01:57.280 --> 02:00.600 So I will actually favor going out towards OSPF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 40 01:57.280 --> 02:00.600 So I will actually favor going out towards OSPF. 41 02:00.600 --> 02:02.120 So this actually is a solution. 42 02:02.120 --> 02:05.680 It's not an ideal solution, but it totally would work. 43 02:05.680 --> 02:10.060 And it's again, making sure we understand what's going on that would lead us to 44 02:10.060 --> 02:10.320 being 45 02:10.320 --> 02:12.520 able to draw that conclusion. 46 02:12.520 --> 02:15.720 Now number three here, how could VRS be used to fix the issue? 47 02:15.720 --> 02:20.590 We walked through this exact scenario in a lab and we said, hey, you know what 48 02:20.590 --> 02:21.080 we're 49 02:21.080 --> 02:27.640 going to do is we're just going to turn this whole domain into its own VRF. 50 02:27.640 --> 02:31.760 So now OSPF runs as part of a different VRF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 50 02:27.640 --> 02:31.760 So now OSPF runs as part of a different VRF. 51 02:31.760 --> 02:35.680 We'll call this VRF you for the underlay. 52 02:35.680 --> 02:41.900 And because this VRF now is managing all of OSPF, it's managing its own routing 53 02:41.900 --> 02:44.080 tables. 54 02:44.080 --> 02:51.400 Now this possibility of CND existing in the overlay, it's impossible. 55 02:51.400 --> 02:56.440 It can't exist in the overlay, not unless we somehow glue these VRFs together. 56 02:56.440 --> 03:01.520 And so as long as these VRFs truly remain separated, CND will never be known WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 56 02:56.440 --> 03:01.520 And so as long as these VRFs truly remain separated, CND will never be known 57 03:01.520 --> 03:01.920 outside 58 03:01.920 --> 03:03.600 of that VRF. 59 03:03.600 --> 03:07.010 Now remember, we have to use that special tunnel VRF command to make sure that 60 03:07.010 --> 03:07.640 the tunnel 61 03:07.640 --> 03:12.770 is actually built from the underlay perspective, even though the tunnel must 62 03:12.770 --> 03:13.800 remain as part 63 03:13.800 --> 03:17.520 of the overlay VRF or potentially the default VRF. 64 03:17.520 --> 03:22.770 But this is again a pretty good fail-safe, a protection mechanism is to make 65 03:22.770 --> 03:23.480 sure that 66 03:23.480 --> 03:26.160 the underlay is part of its own VRF. 67 03:26.160 --> 03:28.480 I'd say that's a pretty good solution. 68 03:28.480 --> 03:31.680 But number four is what drives at the root cause of the issue. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 68 03:28.480 --> 03:31.680 But number four is what drives at the root cause of the issue. 69 03:31.680 --> 03:33.000 It's what we just talked about. 70 03:33.000 --> 03:37.730 The root cause of the issue is that for whatever reason, we are taking CND and 71 03:37.730 --> 03:38.680 we're actually 72 03:38.680 --> 03:41.920 advertising it into the overlay. 73 03:41.920 --> 03:43.640 The VRF prevents this. 74 03:43.640 --> 03:46.240 The VRF says that's not possible and that's good. 75 03:46.240 --> 03:48.400 But we don't need a VRF to do that. 76 03:48.400 --> 03:51.160 We could just simply stop advertising it. 77 03:51.160 --> 03:52.960 Then we don't have to worry about it. 78 03:52.960 --> 03:54.160 And same thing over here. 79 03:54.160 --> 04:01.640 I'm assuming I must be advertising A and B into the overlay this way. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 79 03:54.160 --> 04:01.640 I'm assuming I must be advertising A and B into the overlay this way. 80 04:01.640 --> 04:03.720 And once again, stop that. 81 04:03.720 --> 04:08.200 Just stop advertising the underlay routes into the overlay and we won't have 82 04:08.200 --> 04:08.840 recursive 83 04:08.840 --> 04:09.960 routing. 84 04:09.960 --> 04:14.330 So again, just walking through this real quick, changing cost and changing 85 04:14.330 --> 04:17.160 bandwidth and changing 86 04:17.160 --> 04:22.200 any of those kinds of things from a metrics perspective that's only going to 87 04:22.200 --> 04:22.920 work if these 88 04:22.920 --> 04:24.800 are the same routing protocols. 89 04:24.800 --> 04:28.960 OSPF and OSPF or EIGRP and EIGRP. 90 04:28.960 --> 04:33.000 Changing the cost and metrics regardless of what the goal is, if there's two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 04:28.960 --> 04:33.000 Changing the cost and metrics regardless of what the goal is, if there's two 91 04:33.000 --> 04:33.600 different 92 04:33.600 --> 04:36.480 routing protocols at play, that's just not going to work. 93 04:36.480 --> 04:38.320 Changing a Ministry of Distance is an option. 94 04:38.320 --> 04:41.560 It's not an ideal one, but it is an option. 95 04:41.560 --> 04:47.010 Certainly the biggest solution is making sure we don't advertise our routes 96 04:47.010 --> 04:48.040 into overlay 97 04:48.040 --> 04:49.900 and underlay and vice versa. 98 04:49.900 --> 04:54.400 And yes, a VRF is a great protection mechanism to help us manage that.