WEBVTT 1 00:00.000 --> 00:06.360 When we think about the concept of encapsulation, our focus tends to be more on 2 00:06.360 --> 00:08.080 OSI models, 3 00:08.080 --> 00:11.200 or OSI layers as part of the OSI model. 4 00:11.200 --> 00:17.110 And so we're thinking about encapsulating, for example, a TCP datagram at layer 5 00:17.110 --> 00:17.520 four 6 00:17.520 --> 00:23.930 into an IP packet at layer three, which would turn into an Ethernet frame at 7 00:23.930 --> 00:25.160 layer two. 8 00:25.160 --> 00:29.340 This is sort of our standard way that we encapsulate our traffic and send it 9 00:29.340 --> 00:32.120 through a TCP/IP network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 9 00:29.340 --> 00:32.120 through a TCP/IP network. 10 00:32.120 --> 00:37.970 But what if we took this and rather than taking our TCP datagram and encaps 11 00:37.970 --> 00:38.640 ulating it into 12 00:38.640 --> 00:45.630 IP and then encapsulating it into Ethernet, what if we encapsulate it into 13 00:45.630 --> 00:47.840 another IP header 14 00:47.840 --> 00:51.680 before putting it into Ethernet? 15 00:51.680 --> 00:54.920 What this accomplishes is it gives us two different headers. 16 00:54.920 --> 00:59.640 It gives us an outer header and an inner header. 17 00:59.640 --> 01:06.720 And this allows us to sort of hide one packet inside of the other. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 17 00:59.640 --> 01:06.720 And this allows us to sort of hide one packet inside of the other. 18 01:06.720 --> 01:12.760 So this outer packet is going to be what's used for routing. 19 01:12.760 --> 01:16.720 Our routers and layer three devices are going to take a look at this outer 20 01:16.720 --> 01:17.560 header without 21 01:17.560 --> 01:23.370 looking to or looking any further in, which makes sense because if a router 22 01:23.370 --> 01:24.680 were to receive 23 01:24.680 --> 01:30.720 this packet here, it would de-encapsulate Ethernet, look at the IP information, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 23 01:24.680 --> 01:30.720 this packet here, it would de-encapsulate Ethernet, look at the IP information, 24 01:30.720 --> 01:32.120 then re-encapsulate 25 01:32.120 --> 01:36.160 Ethernet and send it on its way, assuming it's sending it out another Ethernet 26 01:36.160 --> 01:37.000 interface. 27 01:37.000 --> 01:40.640 But it never actually looks any deeper than the first IP header. 28 01:40.640 --> 01:41.840 Now, same thing here. 29 01:41.840 --> 01:44.360 It's going to de-encapsulate if it gets this packet. 30 01:44.360 --> 01:47.120 It'll de-encapsulate our Ethernet. 31 01:47.120 --> 01:51.540 It'll look at this IP header, then it will re-encapsulate Ethernet and send it 32 01:51.540 --> 01:52.520 on, assuming 33 01:52.520 --> 01:57.810 that it's not the destination and it's actually supposed to route this packet 34 01:57.810 --> 01:58.320 and send it 35 01:58.320 --> 02:00.280 out another interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 35 01:58.320 --> 02:00.280 out another interface. 36 02:00.280 --> 02:02.040 So it never looks inside. 37 02:02.040 --> 02:06.040 It never sees the TCP or the inner IP header. 38 02:06.040 --> 02:08.800 It is truly hidden inside of this. 39 02:08.800 --> 02:13.480 So this concept is what we call tunneling. 40 02:13.480 --> 02:19.360 Tunneling is when we hide one encapsulation or one header inside of something 41 02:19.360 --> 02:20.160 else that's 42 02:20.160 --> 02:24.760 intended to be carried through a different type of network. 43 02:24.760 --> 02:28.530 And so what this creates is sort of this scenario here where maybe I've got a 44 02:28.530 --> 02:28.840 series 45 02:28.840 --> 02:33.440 of routers and these routers are all connected to each other. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 45 02:28.840 --> 02:33.440 of routers and these routers are all connected to each other. 46 02:33.440 --> 02:40.440 And I'm going to form, again, just thinking about it logically, form a tunnel 47 02:40.440 --> 02:40.840 from one 48 02:40.840 --> 02:43.040 router to the other. 49 02:43.040 --> 02:47.480 The reason we draw it out this way is because when I send this packet down into 50 02:47.480 --> 02:48.720 these devices, 51 02:48.720 --> 02:53.660 which by the way, we're going to now refer to this as the underlay network, the 52 02:53.660 --> 02:54.120 underlay 53 02:54.120 --> 02:58.000 network only looks at the outer header. 54 02:58.000 --> 03:01.090 Because it's only looking at the outer header, it never sees the inner header WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 54 02:58.000 --> 03:01.090 Because it's only looking at the outer header, it never sees the inner header 55 03:01.090 --> 03:01.680 nor does it 56 03:01.680 --> 03:06.160 need to know where the inner header is trying to get to. 57 03:06.160 --> 03:11.160 So for example, let's say we're sending it from subnet A to subnet B. And 58 03:11.160 --> 03:11.560 meanwhile, 59 03:11.560 --> 03:16.320 we also have subnets C, D, and E throughout the process. 60 03:16.320 --> 03:20.320 So where is the inner header destined for? 61 03:20.320 --> 03:26.170 The inner header is trying to get to subnet B, but the outer header is trying 62 03:26.170 --> 03:27.560 to get where? 63 03:27.560 --> 03:30.720 Well, the outer header is just trying to get over to this router, which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 63 03:27.560 --> 03:30.720 Well, the outer header is just trying to get over to this router, which 64 03:30.720 --> 03:31.560 probably means 65 03:31.560 --> 03:34.900 we're either trying to connect to a loopback interface or a virtual interface 66 03:34.900 --> 03:35.400 like what 67 03:35.400 --> 03:39.280 I have drawn here, or we could have done the tunnel over to this physical 68 03:39.280 --> 03:40.640 interface here 69 03:40.640 --> 03:45.880 that would be part of subnet E. But let's just say we're going to a loopback 70 03:45.880 --> 03:46.160 interface. 71 03:46.160 --> 03:50.820 Either way, we're trying to get, let's just call these routers one and four now 72 03:50.820 --> 03:51.320 with router 73 03:51.320 --> 03:53.480 two and router three in the middle. 74 03:53.480 --> 03:59.760 So our outer is trying to actually get to this router for loopback address. 75 03:59.760 --> 04:04.450 So this underlay, these two routers router two and router three, what do their WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 75 03:59.760 --> 04:04.450 So this underlay, these two routers router two and router three, what do their 76 04:04.450 --> 04:04.960 routing 77 04:04.960 --> 04:06.880 tables need to contain? 78 04:06.880 --> 04:11.840 Well they need to have ownership of this underlay, meaning that they need to 79 04:11.840 --> 04:13.240 have, they need 80 04:13.240 --> 04:19.200 to have in their routing table installed entries for subnets C, D and E, but 81 04:19.200 --> 04:19.720 they also are 82 04:19.720 --> 04:21.800 going to need to have the loopbacks. 83 04:21.800 --> 04:26.080 So let's just say that we've got our one loopback zero to our for loopback zero 84 04:26.080 --> 04:26.440 . 85 04:26.440 --> 04:32.760 So we're going to need our one loopback zero and our for loopback zero. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 85 04:26.440 --> 04:32.760 So we're going to need our one loopback zero and our for loopback zero. 86 04:32.760 --> 04:37.880 So notice that these underlay routers, they only need access or they only need 87 04:37.880 --> 04:38.640 a routing 88 04:38.640 --> 04:44.680 table that has entries for what do we got here, five subnets. 89 04:44.680 --> 04:49.560 And also notice that out of this, we don't know where A is and we don't know 90 04:49.560 --> 04:50.080 where B 91 04:50.080 --> 04:51.520 is. 92 04:51.520 --> 04:53.680 So is that a problem? 93 04:53.680 --> 04:58.020 And the answer is no, it's not a problem because these are only looking at the 94 04:58.020 --> 04:58.400 outer 95 04:58.400 --> 04:59.400 header. 96 04:59.400 --> 05:04.760 And the outer header is trying to get from entries, one entry that they know to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 96 04:59.400 --> 05:04.760 And the outer header is trying to get from entries, one entry that they know to 97 05:04.760 --> 05:05.440 an entry 98 05:05.440 --> 05:08.610 that they know as the destination, which is ultimately what we care about here, 99 05:08.610 --> 05:08.960 is trying 100 05:08.960 --> 05:11.080 to get to the destination. 101 05:11.080 --> 05:15.050 So I can now receive this packet, look at the outer header, see, oh, you're 102 05:15.050 --> 05:15.600 trying to 103 05:15.600 --> 05:20.230 go to router for loopback zero subnet, whatever subnet that is, I happen to 104 05:20.230 --> 05:21.120 have an entry 105 05:21.120 --> 05:22.480 for that in my routing table. 106 05:22.480 --> 05:26.820 It says for me to send that on to router three, router three says the same 107 05:26.820 --> 05:27.480 thing. 108 05:27.480 --> 05:29.560 It says to send it over to router four. 109 05:29.560 --> 05:34.120 And now router four can bring that packet in and de encapsulate it and see that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 109 05:29.560 --> 05:34.120 And now router four can bring that packet in and de encapsulate it and see that 110 05:34.120 --> 05:34.440 it was 111 05:34.440 --> 05:36.560 destined for itself. 112 05:36.560 --> 05:41.360 Now at this point, because router four is receiving, and we've got the ethernet 113 05:41.360 --> 05:41.480 , we've 114 05:41.480 --> 05:46.690 got the outer IP and the inner IP, again, it's going to de encapsulate this, 115 05:46.690 --> 05:47.000 look at 116 05:47.000 --> 05:48.840 this, see, oh, you're destined for me. 117 05:48.840 --> 05:51.860 So now I'm going to de encapsulate the inner header or the outer header, this 118 05:51.860 --> 05:52.440 is the outer 119 05:52.440 --> 05:53.720 header. 120 05:53.720 --> 05:58.730 And now I can look at the inner header, the inner IP header and see, oh, you're 121 05:58.730 --> 05:59.400 destined 122 05:59.400 --> 06:05.450 for a host out subnet B, because the inner has a destination that we know is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 122 05:59.400 --> 06:05.450 for a host out subnet B, because the inner has a destination that we know is 123 06:05.450 --> 06:06.200 going to 124 06:06.200 --> 06:07.840 subnet B. 125 06:07.840 --> 06:10.720 So did the underlay need to know where A or B was? 126 06:10.720 --> 06:11.880 No, they didn't. 127 06:11.880 --> 06:14.400 They had no clue where A and B were. 128 06:14.400 --> 06:18.360 And yet the packet was still able to get delivered to subnet B. 129 06:18.360 --> 06:22.590 This concept is going to be mission critical as we take a look coming up at 130 06:22.590 --> 06:23.520 protocol such 131 06:23.520 --> 06:25.920 as LISP and VXLAN. 132 06:25.920 --> 06:29.120 And just tunneling in general is going to be very important for us to grasp. 133 06:29.120 --> 06:30.920 We've got to talk about VPNs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 133 06:29.120 --> 06:30.920 We've got to talk about VPNs. 134 06:30.920 --> 06:32.240 We've got to talk about GRE. 135 06:32.240 --> 06:34.720 We've got a lot to talk about with tunneling. 136 06:34.720 --> 06:38.770 But sometimes we might look at a network diagram and say, oh, yeah, we just 137 06:38.770 --> 06:39.440 have a tunnel 138 06:39.440 --> 06:41.920 going between these two routers. 139 06:41.920 --> 06:45.480 And so we just think it's all part of the same network and life is good. 140 06:45.480 --> 06:48.000 But we really are creating two separate networks. 141 06:48.000 --> 06:51.510 And if I use a different color here, we'll see that I've created an overlay 142 06:51.510 --> 06:52.120 that looks 143 06:52.120 --> 06:58.770 like this, where I'm actually writing this tunnel interface and connecting over 144 06:58.770 --> 06:59.400 to where 145 06:59.400 --> 07:01.120 subnet B exists. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 145 06:59.400 --> 07:01.120 subnet B exists. 146 07:01.120 --> 07:05.560 So this is my overlay in this situation. 147 07:05.560 --> 07:09.880 And again, the underlay needs to know nothing about those overlay subnets in 148 07:09.880 --> 07:10.760 the same way, 149 07:10.760 --> 07:15.160 by the way, that overlays devices don't need to know about underlay subnets. 150 07:15.160 --> 07:19.320 The only devices that need to know about both would be a device that supports 151 07:19.320 --> 07:19.800 both. 152 07:19.800 --> 07:22.840 And we see routers one and four are supporting both. 153 07:22.840 --> 07:27.620 They've got underlay interfaces as well as overlay interfaces, including, by 154 07:27.620 --> 07:28.240 the way, 155 07:28.240 --> 07:29.840 the tunnel interface. 156 07:29.840 --> 07:35.840 The tunnel interface is going to be part of that overlay network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 156 07:29.840 --> 07:35.840 The tunnel interface is going to be part of that overlay network. 157 07:35.840 --> 07:39.190 So with all of that in mind, we're now ready to talk about different tunneling 158 07:39.190 --> 07:40.120 mechanisms. 159 07:40.120 --> 07:47.060 And the first of which is going to be the generic routing encapsulation, 160 07:47.060 --> 07:47.920 otherwise known 161 07:47.920 --> 07:52.720 as GRE. 162 07:52.720 --> 07:55.680 GRE is actually a Cisco protocol. 163 07:55.680 --> 07:59.840 We can't run GRE on non-Cisco devices. 164 07:59.840 --> 08:03.900 And interestingly, it was developed for something we don't use a whole lot WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 164 07:59.840 --> 08:03.900 And interestingly, it was developed for something we don't use a whole lot 165 08:03.900 --> 08:04.440 anymore, which is 166 08:04.440 --> 08:11.040 actually to carry non-IP traffic inside IP networks. 167 08:11.040 --> 08:15.730 So the idea here is that we would take something like IPX traffic, which is 168 08:15.730 --> 08:16.840 really old at this 169 08:16.840 --> 08:17.840 point. 170 08:17.840 --> 08:21.480 But it was certainly an option back when GRE was around. 171 08:21.480 --> 08:27.240 And I say, hey, I've got these two disparate IPX networks. 172 08:27.240 --> 08:31.790 How do I connect them together when the only thing I have in the middle here is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 172 08:27.240 --> 08:31.790 How do I connect them together when the only thing I have in the middle here is 173 08:31.790 --> 08:32.200 IP? 174 08:32.200 --> 08:37.880 Well, I can actually tunnel IPX traffic through the IP domain. 175 08:37.880 --> 08:44.430 And the way I would do this is make this the inner header concept and the outer 176 08:44.430 --> 08:44.720 header 177 08:44.720 --> 08:49.280 I would put IP and probably ethernet or potentially something else if it's 178 08:49.280 --> 08:50.480 going across serial 179 08:50.480 --> 08:51.480 links. 180 08:51.480 --> 08:56.970 But either way, we see that we can construct this tunnel mechanism by-- and 181 08:56.970 --> 08:57.920 also include 182 08:57.920 --> 09:00.240 non-IP traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 182 08:57.920 --> 09:00.240 non-IP traffic. 183 09:00.240 --> 09:04.320 Now there's a slight caveat to this. 184 09:04.320 --> 09:10.720 And that is that we are not actually going to directly add the IP header. 185 09:10.720 --> 09:13.840 We're going to insert a GRE header in here first. 186 09:13.840 --> 09:15.440 This is sometimes known as a shim header. 187 09:15.440 --> 09:19.040 We're kind of inserting it into the middle of a packet. 188 09:19.040 --> 09:22.320 Then we'll have the IP and then ethernet. 189 09:22.320 --> 09:26.480 And so GRE is going to include its own header. 190 09:26.480 --> 09:30.610 And this just has some important information that's carried between the two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 190 09:26.480 --> 09:30.610 And this just has some important information that's carried between the two 191 09:30.610 --> 09:31.200 hosts. 192 09:31.200 --> 09:34.640 Fortunately, it's not very large here. 193 09:34.640 --> 09:37.640 It's only four bytes in size. 194 09:37.640 --> 09:41.950 But we do have to consider the fact that we're also carrying additional 195 09:41.950 --> 09:42.360 information-- or an 196 09:42.360 --> 09:44.920 additional IP header in there as well. 197 09:44.920 --> 09:48.440 So when we use it in the modern network, let's sort of shift gears here. 198 09:48.440 --> 09:53.140 So in the modern network, we're going to be looking at not really communicating 199 09:53.140 --> 09:53.480 with 200 09:53.480 --> 09:55.720 non-IP and IP. 201 09:55.720 --> 09:59.360 Instead we're still going to do what we drew over here, which is to include IP 202 09:59.360 --> 09:59.800 inside 203 09:59.800 --> 10:01.120 of IP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 203 09:59.800 --> 10:01.120 of IP. 204 10:01.120 --> 10:02.360 So why do we use GRE? 205 10:02.360 --> 10:04.120 Well, it's very simple to configure. 206 10:04.120 --> 10:06.880 It's very easy to implement. 207 10:06.880 --> 10:08.840 And why not use it? 208 10:08.840 --> 10:13.350 To carry IP traffic inside of another IP header and create that underlay and 209 10:13.350 --> 10:14.680 overlay concept. 210 10:14.680 --> 10:18.150 And so now what we're looking at here is what we have drawn out already on the 211 10:18.150 --> 10:18.680 right, which 212 10:18.680 --> 10:23.520 is some kind of maybe UDP or TCP datagram. 213 10:23.520 --> 10:29.320 And then we're going to have an inner IP header. 214 10:29.320 --> 10:32.080 And then we'll have our GRE header. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 214 10:29.320 --> 10:32.080 And then we'll have our GRE header. 215 10:32.080 --> 10:36.080 And then we're going to have an outer IP header. 216 10:36.080 --> 10:42.080 And then whatever layer two we have outside of that, probably ethernet. 217 10:42.080 --> 10:45.920 But again, it's whatever layer two mechanism we're using. 218 10:45.920 --> 10:49.570 So when we look at what we're adding here, we said we're adding four bytes for 219 10:49.570 --> 10:50.040 the GRE 220 10:50.040 --> 10:51.040 header. 221 10:51.040 --> 10:55.950 But if we think about it, this is an entire payload in and of itself, whatever 222 10:55.950 --> 10:56.480 we have 223 10:56.480 --> 11:01.120 inside of the TCP/UDP datagram. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 223 10:56.480 --> 11:01.120 inside of the TCP/UDP datagram. 224 11:01.120 --> 11:07.350 So if I'm going to be building out ethernet frames at 1500 bytes, well, 225 11:07.350 --> 11:09.240 normally I understand 226 11:09.240 --> 11:13.920 that, OK, that's going to include some amount of information here. 227 11:13.920 --> 11:16.040 So for example, it's going to include the payload. 228 11:16.040 --> 11:20.760 It's going to factor in the ethernet and outer header. 229 11:20.760 --> 11:23.160 But notice now we have an additional header. 230 11:23.160 --> 11:25.600 And an IP header is 20 bytes. 231 11:25.600 --> 11:33.120 This means that the MTU increase that we can expect is actually four bytes for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 231 11:25.600 --> 11:33.120 This means that the MTU increase that we can expect is actually four bytes for 232 11:33.120 --> 11:33.880 GRE plus 233 11:33.880 --> 11:39.880 20 additional bytes for the second IP header, which is a total of 24 bytes. 234 11:39.880 --> 11:45.860 So any time we're looking at the concept of the underlay down here, this under 235 11:45.860 --> 11:47.040 lay network 236 11:47.040 --> 11:58.840 must support an increased MTU or we have to fragment these packets. 237 11:58.840 --> 12:03.340 And I will tell you from experience that more often than not, we are fragment WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 237 11:58.840 --> 12:03.340 And I will tell you from experience that more often than not, we are fragment 238 12:03.340 --> 12:04.120 ing packets 239 12:04.120 --> 12:07.520 oftentimes without even realizing it. 240 12:07.520 --> 12:11.240 So we need to be very careful about how exactly we construct our packets. 241 12:11.240 --> 12:15.270 More often than not, it's better to increase the MTU on the underlay than it is 242 12:15.270 --> 12:15.680 to try 243 12:15.680 --> 12:23.040 to decrease the MTU on the end user devices and changing the tunnel. 244 12:23.040 --> 12:27.000 The tunnel interface MTU is actually not going to help us out, even though that 245 12:27.000 --> 12:27.840 's often cited 246 12:27.840 --> 12:31.520 as a way for us to get around this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 246 12:27.840 --> 12:31.520 as a way for us to get around this. 247 12:31.520 --> 12:35.460 Now one last tidbit of information before moving on is the fact that our IP 248 12:35.460 --> 12:36.160 header is 249 12:36.160 --> 12:40.790 going to have to have that protocol number in there to indicate what is encaps 250 12:40.790 --> 12:41.240 ulated 251 12:41.240 --> 12:42.640 inside of that. 252 12:42.640 --> 12:48.200 And for GRE, we're going to include a protocol number of 47. 253 12:48.200 --> 12:51.730 That can be important for allowing tunnels through firewalls, for example, or 254 12:51.730 --> 12:52.120 access 255 12:52.120 --> 12:54.880 control lists, whatever the situation is. 256 12:54.880 --> 12:59.560 If our GRE isn't working, we might want to make sure that this IP protocol 257 12:59.560 --> 13:00.280 number is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 257 12:59.560 --> 13:00.280 number is 258 13:00.280 --> 13:01.840 actually allowed. 259 13:01.840 --> 13:04.750 So this is how tunneling comes together, how we can create an overlay in an 260 13:04.750 --> 13:05.680 underlay, 261 13:05.680 --> 13:10.320 and how GRE is one of the options that we have for including IP traffic and 262 13:10.320 --> 13:11.480 encapsulating 263 13:11.480 --> 13:13.340 it inside of another IP header.