WEBVTT 1 00:00.000 --> 00:04.640 All right, let's take a look at a network topology here that involves tunnels 2 00:04.640 --> 00:05.160 and make sure we 3 00:05.160 --> 00:08.850 understand how tunneling architecture comes together, especially around the 4 00:08.850 --> 00:09.680 concept of 5 00:09.680 --> 00:11.200 recursive routing. 6 00:11.200 --> 00:16.480 So our topology here is that we have OSPF running across the overlay, and then 7 00:16.480 --> 00:17.360 down here in the 8 00:17.360 --> 00:20.120 underlay we're running EIGRP. 9 00:20.120 --> 00:23.370 So router one and router three, they're running both of these routing protocols 10 00:23.370 --> 00:24.200 , whereas router 11 00:24.200 --> 00:27.200 two is only running EIGRP. 12 00:27.200 --> 00:32.420 So we also have to understand that we're advertising all connected routes into WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 12 00:27.200 --> 00:32.420 So we also have to understand that we're advertising all connected routes into 13 00:32.420 --> 00:33.680 both routing protocols. 14 00:33.680 --> 00:38.810 That is not ideal because that means that I'm taking this 10.1.1.0 subnet and 15 00:38.810 --> 00:39.640 advertising 16 00:39.640 --> 00:41.840 it into EIGRP. 17 00:41.840 --> 00:44.280 Well router two doesn't need to know about this. 18 00:44.280 --> 00:48.710 If both of these are doing this, then that means that I'm actually learning 19 00:48.710 --> 00:49.440 about both 20 00:49.440 --> 00:53.840 of the overlay subnets on router two, whereas normally that wouldn't be needed. 21 00:53.840 --> 00:58.760 And so this is not a particularly ideal situation, a setup. 22 00:58.760 --> 01:01.320 So answer the following questions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 22 00:58.760 --> 01:01.320 So answer the following questions. 23 01:01.320 --> 01:04.270 Question number one here, given the current topology is routing recursion 24 01:04.270 --> 01:04.720 expected, why 25 01:04.720 --> 01:06.120 or why not? 26 01:06.120 --> 01:12.440 Well any time routing recursion occurs, we know that we are taking the tunnel 27 01:12.440 --> 01:13.720 destination, 28 01:13.720 --> 01:19.080 probably this physical address, and we're advertising it across the tunnel. 29 01:19.080 --> 01:20.840 And here's the key point. 30 01:20.840 --> 01:26.400 Number one, I advertise it, but number two, I decide to take it. 31 01:26.400 --> 01:31.010 If I add the tunnel destination into my routing table to say that the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 31 01:26.400 --> 01:31.010 If I add the tunnel destination into my routing table to say that the 32 01:31.010 --> 01:32.480 destination needs to 33 01:32.480 --> 01:36.040 go out the tunnel interface, that's a problem. 34 01:36.040 --> 01:39.440 That's what causes recursive routing and we don't want that. 35 01:39.440 --> 01:41.680 In this situation, do we expect this? 36 01:41.680 --> 01:44.440 Well we've just said that we're advertising all of the connected routes. 37 01:44.440 --> 01:45.680 So number one is true. 38 01:45.680 --> 01:49.930 I'm taking this physical interface that's in the underlay and I'm advertising 39 01:49.930 --> 01:50.800 it into 40 01:50.800 --> 01:53.360 the overlay, which is not good. 41 01:53.360 --> 01:57.120 So here's the question, do we see number two take place? 42 01:57.120 --> 02:02.480 And in this situation, believe it or not, the answer should be no. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 01:57.120 --> 02:02.480 And in this situation, believe it or not, the answer should be no. 43 02:02.480 --> 02:06.140 Now this does rely on a couple of assumptions, the biggest of which is that we 44 02:06.140 --> 02:07.080 have not changed 45 02:07.080 --> 02:12.570 administrative distance, but router one's routing table is going to be 46 02:12.570 --> 02:14.000 determined based 47 02:14.000 --> 02:17.760 on, as we've said before, a couple of these other tables. 48 02:17.760 --> 02:23.080 So we have an EIGRP table known as the topology table, we have an OSPF database 49 02:23.080 --> 02:23.940 , and both 50 02:23.940 --> 02:31.760 of them are going to claim to have a particular route, this 192.168.23 subnet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 50 02:23.940 --> 02:31.760 of them are going to claim to have a particular route, this 192.168.23 subnet. 51 02:31.760 --> 02:35.520 So router one is trying to decide how do I get to this subnet? 52 02:35.520 --> 02:39.740 I have routes from both routing protocols and based on administrative distance, 53 02:39.740 --> 02:40.120 EIGRP 54 02:40.120 --> 02:45.220 being 90, OSPF being 110, I would favor the EIGRP route, which actually goes 55 02:45.220 --> 02:45.840 into the 56 02:45.840 --> 02:47.160 underlay. 57 02:47.160 --> 02:50.970 So even though we're setting up a recursive routing challenge, the answer here 58 02:50.970 --> 02:51.640 is actually 59 02:51.640 --> 02:52.640 no. 60 02:52.640 --> 02:56.740 We're not going to expect recursive routing simply because we happen to see 61 02:56.740 --> 02:57.280 that the 62 02:57.280 --> 03:00.520 administrative distance is aligning in our favor. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 62 02:57.280 --> 03:00.520 administrative distance is aligning in our favor. 63 03:00.520 --> 03:03.980 If these routing protocols were flipped, well then we would see recursive 64 03:03.980 --> 03:05.120 routing because 65 03:05.120 --> 03:09.890 we would prefer EIGRP in either scenario and if EIGRP says to go through the 66 03:09.890 --> 03:10.640 tunnel, then 67 03:10.640 --> 03:12.560 we would take that path. 68 03:12.560 --> 03:15.550 Now question number two, without changing routing protocols, what is a 69 03:15.550 --> 03:16.640 recommended change to 70 03:16.640 --> 03:17.640 this setup? 71 03:17.640 --> 03:21.680 So we keep OSPF and EIGRP where they are, what should we change? 72 03:21.680 --> 03:26.290 Well the good news is recursive routing is not occurring, but we are still 73 03:26.290 --> 03:27.360 setting ourselves 74 03:27.360 --> 03:31.360 up for failure here if something were to change in the future. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 74 03:27.360 --> 03:31.360 up for failure here if something were to change in the future. 75 03:31.360 --> 03:32.360 So what should we change? 76 03:32.360 --> 03:38.400 Well we should stop advertising this underlay route into the overlay. 77 03:38.400 --> 03:44.680 Overlay routes should only go to overlay devices and underlay to underlay. 78 03:44.680 --> 03:47.080 So this is what we would want to change. 79 03:47.080 --> 03:51.230 If we're going to change anything, it would be stop advertising all connected 80 03:51.230 --> 03:51.840 routes into 81 03:51.840 --> 03:57.300 both routing protocols, only advertise underlay routes to EIGRP and only 82 03:57.300 --> 03:58.680 advertise overlay 83 03:58.680 --> 04:03.000 routes to OSPF, even though both of these routers, router one and router three WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 83 03:58.680 --> 04:03.000 routes to OSPF, even though both of these routers, router one and router three 84 04:03.000 --> 04:03.440 are running 85 04:03.440 --> 04:07.360 both routing protocols, we can make sure that we are keeping it clean. 86 04:07.360 --> 04:10.470 Now if we want to really make it clean, here's where number three comes in, 87 04:10.470 --> 04:11.080 which is asking 88 04:11.080 --> 04:15.040 hey how could we use VRFs in order to really clean this up? 89 04:15.040 --> 04:19.060 Well VRFs create two completely different routing domains and this is one 90 04:19.060 --> 04:19.840 application, 91 04:19.840 --> 04:24.680 especially in modern architectures where we might actually want to deploy VRFs 92 04:24.680 --> 04:24.960 within 93 04:24.960 --> 04:29.760 an enterprise and that is to separate out overlay and underlay. 94 04:29.760 --> 04:37.070 So I could create a VRF here in the underlay and that would be a completely WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 94 04:29.760 --> 04:37.070 So I could create a VRF here in the underlay and that would be a completely 95 04:37.070 --> 04:39.080 different routing 96 04:39.080 --> 04:40.080 domain. 97 04:40.080 --> 04:42.560 EIGRP would operate within that VRF. 98 04:42.560 --> 04:46.880 I wouldn't need to worry about accidentally advertising overlay routes into EIG 99 04:46.880 --> 04:47.560 RP because 100 04:47.560 --> 04:50.120 they just don't exist in that routing domain. 101 04:50.120 --> 04:54.500 And then of course I could also create a VRF that spans the entire overlay, 102 04:54.500 --> 04:55.200 making sure 103 04:55.200 --> 05:00.040 that the tunnel and those connected subnets are all part of that VRF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 103 04:55.200 --> 05:00.040 that the tunnel and those connected subnets are all part of that VRF. 104 05:00.040 --> 05:03.000 So we've got ways to keep this environment clean. 105 05:03.000 --> 05:06.840 This is going to again especially come into play when we talk about LISP and 106 05:06.840 --> 05:07.360 the XLAN 107 05:07.360 --> 05:10.690 and other tunneling mechanisms, but do keep in mind that we want to make sure 108 05:10.690 --> 05:11.040 we're 109 05:11.040 --> 05:15.320 keeping our overlay completely segmented from our underlay when we're using 110 05:15.320 --> 05:17.000 tunnel architectures. 111 05:17.000 --> 05:20.160 It'll keep things clean, but it will also help to prevent that recursive 112 05:20.160 --> 05:20.880 routing issue 113 05:20.880 --> 05:21.880 from occurring. 114 05:21.880 --> 05:25.510 And just in case the administrative distance situation doesn't work out in our 115 05:25.510 --> 05:26.040 favor. 116 05:26.040 --> 05:28.680 I hope this has been informative for you and I'd like to thank you for viewing.