WEBVTT 1 00:00.240 --> 00:02.310 So to really appreciate some of the benefits 2 00:02.310 --> 00:05.340 of NSX, let's draw a simplified topology. 3 00:05.340 --> 00:07.620 And let's start off with a rack 4 00:07.620 --> 00:09.300 that would be in a data center. 5 00:09.300 --> 00:12.300 So this is gonna represent rack number one. 6 00:12.300 --> 00:14.790 And then over here, let's go ahead and put in another rack. 7 00:14.790 --> 00:18.060 And I'm gonna go ahead and name this one rack number nine. 8 00:18.060 --> 00:19.710 And I'm labeling this one rack number nine, 9 00:19.710 --> 00:21.420 just to give us an idea that these don't have 10 00:21.420 --> 00:23.190 to be like right next to each other. 11 00:23.190 --> 00:24.900 Now each of the racks is very likely gonna 12 00:24.900 --> 00:26.490 have a couple switches. 13 00:26.490 --> 00:28.320 They're called top of rack switches. 14 00:28.320 --> 00:30.780 So I'll put a couple switches at the top of each one. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 14 00:28.320 --> 00:30.780 So I'll put a couple switches at the top of each one. 15 00:30.780 --> 00:33.180 I'll label it TOR for top of rack switch. 16 00:33.180 --> 00:36.330 We'll call this one switch A and switch B. 17 00:36.330 --> 00:38.490 And over here the top of rack switches, 18 00:38.490 --> 00:40.500 got switch A and switch B. 19 00:40.500 --> 00:43.080 And then those would connect up into a spine layer 20 00:43.080 --> 00:44.460 for a spine-leaf architecture. 21 00:44.460 --> 00:46.350 So we'd have some fault tolerance there. 22 00:46.350 --> 00:48.120 So there's one of our switches apart of the spine 23 00:48.120 --> 00:50.400 and it's very likely in a fault-tolerant environment. 24 00:50.400 --> 00:51.720 We'd have multiple spines 25 00:51.720 --> 00:53.400 and if we had multiple spine switches, 26 00:53.400 --> 00:54.990 we'd have additional connections from each of 27 00:54.990 --> 00:57.360 the top of rack switches to the additional spines. 28 00:57.360 --> 00:58.800 So for our drawing, I'll just represent 29 00:58.800 --> 01:00.510 one spine right here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 29 00:58.800 --> 01:00.510 one spine right here. 30 01:00.510 --> 01:02.130 And so the idea also I wanna point out here 31 01:02.130 --> 01:05.070 with the spine-leaf architecture is that we are routing. 32 01:05.070 --> 01:07.260 So we're routing between our racks. 33 01:07.260 --> 01:10.830 We don't have one contiguous Layer 2 broadcast domain. 34 01:10.830 --> 01:13.020 We have routed networks. 35 01:13.020 --> 01:14.670 So in each of our racks, let's go ahead 36 01:14.670 --> 01:16.440 and put it in ESXi host. 37 01:16.440 --> 01:19.860 So let's call this one ESXi-A. 38 01:19.860 --> 01:22.920 And over here this will be ESXi-B. 39 01:22.920 --> 01:24.780 And each of those ESXi hosts are gonna have 40 01:24.780 --> 01:27.420 their physical connections go to our top of rack switches. 41 01:27.420 --> 01:29.820 I'll just draw one to each of the switches. 42 01:29.820 --> 01:31.380 Even though an ESXi host is likely WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 01:29.820 --> 01:31.380 Even though an ESXi host is likely 43 01:31.380 --> 01:33.960 to have multiple physical network interface cards, 44 01:33.960 --> 01:35.820 also known as vmnics. 45 01:35.820 --> 01:38.460 So I'll draw a couple over here as well as a representation 46 01:38.460 --> 01:40.140 of the physical connectivity. 47 01:40.140 --> 01:43.410 And over here, lemme go ahead and put VM-A. 48 01:43.410 --> 01:47.040 And over here I'll put VM-B to represent a virtual machine 49 01:47.040 --> 01:49.860 that's being hosted by those respective ESXi hosts. 50 01:49.860 --> 01:52.230 And here's the magic, hold onto your hats, 51 01:52.230 --> 01:54.090 instead of connecting these virtual machines 52 01:54.090 --> 01:56.730 to a traditional distributed port group 53 01:56.730 --> 01:59.370 that would allow them to be, for example, on the same VLAN 54 01:59.370 --> 02:02.010 but instead we are gonna have a new segment, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 54 01:59.370 --> 02:02.010 but instead we are gonna have a new segment, 55 02:02.010 --> 02:04.050 this new Layer 2 segment. 56 02:04.050 --> 02:07.800 And specifically this will be a Layer 2 NSX segment. 57 02:07.800 --> 02:08.940 And even more specifically, 58 02:08.940 --> 02:13.140 we could call this a Layer 2 NSX overlay segment. 59 02:13.140 --> 02:14.730 So from an administration perspective, 60 02:14.730 --> 02:17.070 it just looks like a port group that's representing 61 02:17.070 --> 02:20.910 that segment and we simply connect the respective PCs to it. 62 02:20.910 --> 02:23.370 So even though these two hosts, ESXi-A 63 02:23.370 --> 02:26.400 and ESXi-B, do not have the same connectivity 64 02:26.400 --> 02:28.260 to the same Layer 2 VLAN 65 02:28.260 --> 02:32.040 if we implement a Layer 2 NSX overlay segment, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 65 02:28.260 --> 02:32.040 if we implement a Layer 2 NSX overlay segment, 66 02:32.040 --> 02:33.870 again, think of it like a VLAN 67 02:33.870 --> 02:36.540 because what it really is is a Layer 2 broadcast domain, 68 02:36.540 --> 02:39.000 that segment will show up like a port group on each 69 02:39.000 --> 02:40.320 of our distributed switches. 70 02:40.320 --> 02:42.570 We connect VM-A to it, we connect VM-B to it, 71 02:42.570 --> 02:45.180 and boom, those two VMs are logically connected 72 02:45.180 --> 02:47.490 to the same Layer 2 broadcast domain. 73 02:47.490 --> 02:48.750 So lemme give some IP addresses here. 74 02:48.750 --> 02:51.840 I'll give this one 10.10.0.10. 75 02:51.840 --> 02:55.830 And we'll give this one the IP address of 10.10.0.11. 76 02:55.830 --> 02:57.720 Now on the backend we have a little problem to solve, 77 02:57.720 --> 03:00.300 and that is we don't have the same WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 77 02:57.720 --> 03:00.300 and that is we don't have the same 78 03:00.300 --> 03:03.450 Layer 2 VLAN connectivity from rack one 79 03:03.450 --> 03:06.030 over here all the way over here to rack nine 80 03:06.030 --> 03:07.980 because we have routing at the spine layer 81 03:07.980 --> 03:09.120 between both of those. 82 03:09.120 --> 03:12.750 So how in the world if VM-A tries to communicate with VM-B, 83 03:12.750 --> 03:15.360 how is that communication actually possible? 84 03:15.360 --> 03:16.380 And here is the magic. 85 03:16.380 --> 03:20.580 We are gonna create a tunnel between ESXi-A and ESXi-B. 86 03:20.580 --> 03:22.650 So there are the two ends of the tunnel. 87 03:22.650 --> 03:25.080 I'll go ahead and make a nice macaroni shape 88 03:25.080 --> 03:26.850 there to represent the tunnel. 89 03:26.850 --> 03:28.020 I'm even gonna label it. 90 03:28.020 --> 03:31.590 And this tunnel between ESXi-A and ESXi-B that was created WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 03:28.020 --> 03:31.590 And this tunnel between ESXi-A and ESXi-B that was created 91 03:31.590 --> 03:34.830 by NSX are gonna be terminated at VMkernel 92 03:34.830 --> 03:36.600 adapters on each of the hosts. 93 03:36.600 --> 03:39.887 Over here, perhaps we're using VMK 10 94 03:39.887 --> 03:42.840 and over here we could use VMK 10 as well. 95 03:42.840 --> 03:45.150 And in association with these VMkernel adapters, 96 03:45.150 --> 03:46.650 we're also gonna have an IP address 97 03:46.650 --> 03:47.580 for each end of the tunnel. 98 03:47.580 --> 03:49.347 So maybe over here at ESXi-A, 99 03:49.347 --> 03:53.580 VMK 10 is using 10.11.11.11 100 03:53.580 --> 03:54.720 with the 24-bit mask. 101 03:54.720 --> 03:58.380 And over here at ESXi-B for its VMkernel 10 adapter, 102 03:58.380 --> 04:00.750 which is acting as the tunnel endpoint on this side, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 102 03:58.380 --> 04:00.750 which is acting as the tunnel endpoint on this side, 103 04:00.750 --> 04:04.890 maybe it's using 10.22.22.22. 104 04:04.890 --> 04:07.380 So TEP is an acronym for tunnel endpoint. 105 04:07.380 --> 04:09.390 So think of it like a VMkernel adapter 106 04:09.390 --> 04:11.340 with an IP address representing the end 107 04:11.340 --> 04:13.260 of the tunnel here on ESXi-A 108 04:13.260 --> 04:15.570 and the other end over here at ESXi-B. 109 04:15.570 --> 04:18.210 And I intentionally used different subnets for each 110 04:18.210 --> 04:20.700 of the tunnel endpoints to reinforce the concept 111 04:20.700 --> 04:23.910 that we're routing between the two devices, 112 04:23.910 --> 04:25.350 between the two ends of the tunnel. 113 04:25.350 --> 04:28.440 So although in some typologies we could place both tunnel 114 04:28.440 --> 04:30.870 endpoints in the same exact subnet, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 114 04:28.440 --> 04:30.870 endpoints in the same exact subnet, 115 04:30.870 --> 04:33.660 I intentionally put these tunnel endpoints in two separate 116 04:33.660 --> 04:35.430 subnets, just to reinforce the concept 117 04:35.430 --> 04:37.860 that we're not just bridging the traffic here, 118 04:37.860 --> 04:40.770 we are with our tunnel, we're routing the traffic 119 04:40.770 --> 04:43.380 between two reachable IP addresses. 120 04:43.380 --> 04:48.380 So over here at VM-A, if it did a ping to 10.10.0.11 121 04:49.530 --> 04:51.990 that traffic would be forwarded out the VM 122 04:51.990 --> 04:55.110 into this port group, ESXi would see it and see 123 04:55.110 --> 04:58.500 that it came in on this Layer 2 NSX overlay segment. 124 04:58.500 --> 04:59.880 And then take that entire frame, 125 04:59.880 --> 05:01.860 we're talking about Layer 2 and everything higher than WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 125 04:59.880 --> 05:01.860 we're talking about Layer 2 and everything higher than 126 05:01.860 --> 05:05.070 that, that this client was sending it will encapsulate that 127 05:05.070 --> 05:06.360 and then it will route it 128 05:06.360 --> 05:08.820 through the tunnel over to ESXi-B. 129 05:08.820 --> 05:11.310 So if the original message here is in pink, I'll go ahead 130 05:11.310 --> 05:14.070 and put that into the tunnel, it gets encapsulated. 131 05:14.070 --> 05:16.890 So the original content is effectively now the payload 132 05:16.890 --> 05:20.400 and the tunnel traffic will look like it's coming from 133 05:20.400 --> 05:24.677 10.11.11.11 being routed to 10.22.22.22. 134 05:24.677 --> 05:26.940 And at this end it would de-encapsulate it 135 05:26.940 --> 05:29.640 and then forward it down to the intended recipient. 136 05:29.640 --> 05:31.530 So from the client's perspective, it just looks WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 136 05:29.640 --> 05:31.530 So from the client's perspective, it just looks 137 05:31.530 --> 05:34.950 and feels like a common Layer 2 broadcast domain that 138 05:34.950 --> 05:37.980 VM-A and VM-B are in, but behind the scenes, 139 05:37.980 --> 05:41.340 these two ESXi hosts, which are enabled for NSX, 140 05:41.340 --> 05:44.490 have set up tunnel endpoints and they are encapsulating 141 05:44.490 --> 05:47.070 and routing the traffic over that tunnel back 142 05:47.070 --> 05:49.830 and forth on behalf of VMs that are connected to 143 05:49.830 --> 05:51.180 that Layer 2 segment. 144 05:51.180 --> 05:52.920 And you know what, it would only take a couple of moments 145 05:52.920 --> 05:54.480 to demonstrate this in action. 146 05:54.480 --> 05:57.600 And before I take you to the interface, let me reinforce 147 05:57.600 --> 06:01.680 the concept here that my goal isn't to have us memorize all WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 147 05:57.600 --> 06:01.680 the concept here that my goal isn't to have us memorize all 148 06:01.680 --> 06:03.420 the details on how to configure this. 149 06:03.420 --> 06:05.130 That's coming up in later skills. 150 06:05.130 --> 06:07.649 But my intention right now is just to get a comfort level 151 06:07.649 --> 06:10.170 that that encapsulation is happening 152 06:10.170 --> 06:12.179 by simply connecting these two VMs 153 06:12.179 --> 06:14.670 to an NSX Layer 2 segment. 154 06:14.670 --> 06:17.340 So as a demonstration, here is the vSphere Client 155 06:17.340 --> 06:18.390 that we know and love. 156 06:18.390 --> 06:20.640 And here I'm on the networking tab 157 06:20.640 --> 06:23.640 and I'm looking at a distributed switch called DS for NSX. 158 06:23.640 --> 06:25.770 And a few of these segments here, 159 06:25.770 --> 06:27.000 notice that if we click on this 160 06:27.000 --> 06:29.610 what looks like a port group, it has a big N there. 161 06:29.610 --> 06:30.960 And what that big N represents is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 161 06:29.610 --> 06:30.960 And what that big N represents is 162 06:30.960 --> 06:33.840 that this is not just a normal distributed port group 163 06:33.840 --> 06:35.580 as part of a distributed switch, 164 06:35.580 --> 06:38.340 but instead this is an NSX segment 165 06:38.340 --> 06:40.507 and it has a virtual network identifier, 166 06:40.507 --> 06:41.910 this number right there. 167 06:41.910 --> 06:43.440 But the case in point is I just wanna point out 168 06:43.440 --> 06:47.280 that these are how they look from the vSphere Client. 169 06:47.280 --> 06:48.990 They simply look like port groups. 170 06:48.990 --> 06:51.205 So this is the NSX manager will have lots 171 06:51.205 --> 06:53.280 of time in playing here later. 172 06:53.280 --> 06:54.420 But for now, I just wanna go ahead 173 06:54.420 --> 06:56.220 and create a brand new segment. 174 06:56.220 --> 06:57.990 Again, this segment's just gonna show up on 175 06:57.990 --> 06:59.280 the distributed switch. 176 06:59.280 --> 07:01.230 It's gonna look a lot like a port group. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 176 06:59.280 --> 07:01.230 It's gonna look a lot like a port group. 177 07:01.230 --> 07:04.560 So I'm gonna create a new segment by going to segments here 178 07:04.560 --> 07:06.300 and clicking on add segment. 179 07:06.300 --> 07:09.150 And I'll call it Fun Demo for fundamentals demo. 180 07:09.150 --> 07:10.200 And I'm gonna go ahead 181 07:10.200 --> 07:12.450 and associate with a transport zone called 182 07:12.450 --> 07:13.980 Our Overlay Transport Zone. 183 07:13.980 --> 07:15.900 We'll talk about that also here in just a moment. 184 07:15.900 --> 07:17.760 And we'll scroll down and click on save. 185 07:17.760 --> 07:20.640 So all we did here in this tool called NSX Manager, 186 07:20.640 --> 07:22.830 we just created this new segment called Fun Demo. 187 07:22.830 --> 07:25.230 We hop over to the vSphere Client, check it out, 188 07:25.230 --> 07:27.630 there it is, looks just like a port group. 189 07:27.630 --> 07:30.480 So to demonstrate this segment being used, lemme go ahead WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 189 07:27.630 --> 07:30.480 So to demonstrate this segment being used, lemme go ahead 190 07:30.480 --> 07:31.920 and deploy a couple VMs 191 07:31.920 --> 07:34.710 and I'll put 'em on separate ESXi hosts. 192 07:34.710 --> 07:36.270 So if I go back to my VM and templates view, 193 07:36.270 --> 07:38.580 I've got a folder called templates here, 194 07:38.580 --> 07:40.920 and lemme create a new VM or tube from this template. 195 07:40.920 --> 07:42.510 So I'll right click on this template 196 07:42.510 --> 07:45.270 and from the menu, I'll click on new VM from this template 197 07:45.270 --> 07:47.310 and I'll call this VM on host A. 198 07:47.310 --> 07:49.170 And lemme go ahead and lemme just put it here 199 07:49.170 --> 07:50.520 for Discovered virtual machine. 200 07:50.520 --> 07:51.360 Click on next. 201 07:51.360 --> 07:53.130 And then lemme go ahead and place this 202 07:53.130 --> 07:54.960 on EXSi-A right there. 203 07:54.960 --> 07:56.010 Click on next. 204 07:56.010 --> 07:57.510 I'll choose the data store. 205 07:57.510 --> 07:58.470 Click on next. 206 07:58.470 --> 07:59.850 And I'll customize to make sure 207 07:59.850 --> 08:01.380 I put it on the right segment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 207 07:59.850 --> 08:01.380 I put it on the right segment. 208 08:01.380 --> 08:02.610 And then we'll go ahead and power it on. 209 08:02.610 --> 08:03.540 Click on next. 210 08:03.540 --> 08:06.540 And I wanna put this VM on that new segment we just made, 211 08:06.540 --> 08:08.820 which is this one right here, the Fun Demo. 212 08:08.820 --> 08:12.390 So that's the NSX overlay network segment that we just made. 213 08:12.390 --> 08:13.890 Again, it just looks like a port group 214 08:13.890 --> 08:15.000 on the distributed switch. 215 08:15.000 --> 08:17.280 So we'll connect it there and click on okay. 216 08:17.280 --> 08:19.470 And click on next and finish. 217 08:19.470 --> 08:20.790 All right, one down, one to go. 218 08:20.790 --> 08:22.080 We'll right click on our template again. 219 08:22.080 --> 08:26.460 New VM from this template, we'll call this VM on host B. 220 08:26.460 --> 08:28.560 I'll put it in Discovered virtual machines, in that folder. 221 08:28.560 --> 08:29.550 Click on next. 222 08:29.550 --> 08:31.980 And then I'll go ahead and choose the right host for this, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 222 08:29.550 --> 08:31.980 And then I'll go ahead and choose the right host for this, 223 08:31.980 --> 08:33.660 which is gonna be ESXi-B. 224 08:33.660 --> 08:34.620 Click on next. 225 08:34.620 --> 08:35.880 Choose the data store. 226 08:35.880 --> 08:38.880 Click on next and customize and power it on. 227 08:38.880 --> 08:41.370 So I wanna customize it because I wanna place it on 228 08:41.370 --> 08:42.750 that same port group, 229 08:42.750 --> 08:45.840 or in this case the same NSX segment, 230 08:45.840 --> 08:47.700 which is right here called Fun Demo. 231 08:47.700 --> 08:50.070 And we'll click on, okay and click on next. 232 08:50.070 --> 08:51.270 And we'll click on finish. 233 08:51.270 --> 08:53.310 And now both those VMs are powering up. 234 08:53.310 --> 08:56.160 So let's go ahead and let's bring a console to them. 235 08:56.160 --> 08:59.640 So lemme go to VM on host B and launch a web console there. 236 08:59.640 --> 09:00.510 Great, that's booting up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 236 08:59.640 --> 09:00.510 Great, that's booting up. 237 09:00.510 --> 09:02.430 And let's go to VM on host A 238 09:02.430 --> 09:04.080 and open a web console there. 239 09:04.080 --> 09:06.150 And let's also configure IP addresses. 240 09:06.150 --> 09:08.400 So here in the top left hand corner showing us which VM 241 09:08.400 --> 09:10.110 we're on, this is VM on host A. 242 09:10.110 --> 09:11.790 So let's give it an IP address, the pseudo I have 243 09:11.790 --> 09:13.860 config ethernet zero. 244 09:13.860 --> 09:17.790 And the address we want on VM-A is 10.10.0.10. 245 09:17.790 --> 09:20.280 And we'll put a 24-bit mask on there as well. 246 09:20.280 --> 09:23.490 We'll do an ifconfig for ethernet zero, just to confirm. 247 09:23.490 --> 09:24.450 All right, that looks great, 248 09:24.450 --> 09:26.130 let's go over to the VM on host B. 249 09:26.130 --> 09:27.900 So here's the VM on host B. 250 09:27.900 --> 09:31.440 So we'll configure its IP address as 10.10.0.11 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 250 09:27.900 --> 09:31.440 So we'll configure its IP address as 10.10.0.11 251 09:31.440 --> 09:33.000 with a 24-bit mask. 252 09:33.000 --> 09:36.630 And we'll confirm that with an ifconfig for ethernet zero. 253 09:36.630 --> 09:37.860 And that looks good. 254 09:37.860 --> 09:39.600 So before we do a ping test, 255 09:39.600 --> 09:41.160 let's just go verify real quick that 256 09:41.160 --> 09:43.230 they are both on the same segment. 257 09:43.230 --> 09:44.520 So if we click on network here 258 09:44.520 --> 09:46.320 and then we go down to our distributed switch, then click on 259 09:46.320 --> 09:48.900 that Fun Demo, let's click on VMs. 260 09:48.900 --> 09:52.500 And sure enough, we have both VMs that are on that segment. 261 09:52.500 --> 09:53.550 They're both connected there. 262 09:53.550 --> 09:55.980 And the first VM is running on ESXi-A. 263 09:55.980 --> 09:58.950 And the second VM is running on ESXi-B. 264 09:58.950 --> 09:59.940 Let's verify connectivity 265 09:59.940 --> 10:02.340 with the ping from the VM on host A, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 265 09:59.940 --> 10:02.340 with the ping from the VM on host A, 266 10:02.340 --> 10:04.110 which is at 10.10.0.10 267 10:04.110 --> 10:06.600 and let's ping 10.10.0.11, 268 10:06.600 --> 10:09.780 press enter and that seems to be working no problem. 269 10:09.780 --> 10:12.990 But behind the scenes, the ESXi hosts are taking 270 10:12.990 --> 10:16.560 that traffic, tunneling it and forwarding it to each other. 271 10:16.560 --> 10:19.860 So from an end user's perspective, it looks totally normal, 272 10:19.860 --> 10:22.410 like "Hey, we're just on the same Layer 2 broadcast domain." 273 10:22.410 --> 10:25.830 But behind the scenes, the two ESXi hosts are tunneling 274 10:25.830 --> 10:27.270 that traffic back and forth. 275 10:27.270 --> 10:29.340 And the visual representation of that is right here. 276 10:29.340 --> 10:31.530 So VM-A and VM-B, they're both connected WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 276 10:29.340 --> 10:31.530 So VM-A and VM-B, they're both connected 277 10:31.530 --> 10:35.280 to the same Layer 2 overlay segment as part of NSX, 278 10:35.280 --> 10:37.050 the same Layer 2 broadcast domain. 279 10:37.050 --> 10:38.100 And for the traffic, 280 10:38.100 --> 10:39.630 it's actually being sent over the tunnel 281 10:39.630 --> 10:42.000 between ESXi-A and ESXi-B. 282 10:42.000 --> 10:44.580 And sometimes it's a good idea just to verify that 283 10:44.580 --> 10:47.100 what we think is happening is really happening. 284 10:47.100 --> 10:49.680 So through the magic of some packet captures, 285 10:49.680 --> 10:52.230 let me go ahead and put a packet capture on this. 286 10:52.230 --> 10:53.850 We'll send some traffic over again 287 10:53.850 --> 10:56.880 and then take a close look at capturing the traffic right 288 10:56.880 --> 10:58.860 here as it crosses the network. 289 10:58.860 --> 11:00.660 All right, so in the background I've got a packet capture WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 289 10:58.860 --> 11:00.660 All right, so in the background I've got a packet capture 290 11:00.660 --> 11:02.550 running this to that same exact ping again 291 11:02.550 --> 11:04.137 from the VM on host A 292 11:04.137 --> 11:06.360 to the IP address of the VM over on host B. 293 11:06.360 --> 11:07.800 We'll let that go a few times. 294 11:07.800 --> 11:09.450 We'll do a control C to stop it. 295 11:09.450 --> 11:11.700 And let's take a look at that packet capture. 296 11:11.700 --> 11:13.110 All right, and here we go. 297 11:13.110 --> 11:15.240 So lemme also explain this part right here. 298 11:15.240 --> 11:18.540 The first four lines here represent the encapsulation 299 11:18.540 --> 11:22.980 and the forwarding of the data from my ESXi host over 300 11:22.980 --> 11:24.300 to my management computer, 301 11:24.300 --> 11:27.240 and that was using GRE, so the actual traffic 302 11:27.240 --> 11:30.113 that was generated and then forwarded from ESXi-A WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 302 11:27.240 --> 11:30.113 that was generated and then forwarded from ESXi-A 303 11:30.113 --> 11:33.180 over to ESXi-B starts right here. 304 11:33.180 --> 11:36.120 So the source address was 10.11.11.11, 305 11:36.120 --> 11:38.550 and that's the tunnel endpoint on ESXi-A. 306 11:38.550 --> 11:42.510 And the destination address is 10.22.22.22, 307 11:42.510 --> 11:45.210 which is the tunnel endpoint over on ESXi-B. 308 11:45.210 --> 11:46.650 So to forward to those destinations, 309 11:46.650 --> 11:49.110 we used a local Layer 2 address here MAC address. 310 11:49.110 --> 11:51.030 And then this second MAC address 311 11:51.030 --> 11:52.500 for the destination is the MAC address 312 11:52.500 --> 11:55.290 of the default gateway that was being used to reach 313 11:55.290 --> 11:58.770 and forward in the direction of 10.22.22.22. 314 11:58.770 --> 12:00.786 So this packet sent from ESXi-A WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 314 11:58.770 --> 12:00.786 So this packet sent from ESXi-A 315 12:00.786 --> 12:03.870 to ESXi-B had a payload that was UDP. 316 12:03.870 --> 12:06.840 So the UDP payload is tested to the well-known port 317 12:06.840 --> 12:08.820 of 6081 that's being used 318 12:08.820 --> 12:11.580 for the encapsulation, used for the tunnel. 319 12:11.580 --> 12:14.400 So ESXi one shows a high currently unused port 320 12:14.400 --> 12:17.067 and then sent it to the well known port of 6081. 321 12:17.067 --> 12:20.389 And because ESXi-B was listening on port 6081 322 12:20.389 --> 12:23.550 for UDP, it continued to open up and de-encapsulate. 323 12:23.550 --> 12:26.610 And as ESXi-B continued to de-encapsulate, 324 12:26.610 --> 12:30.240 it saw generic network virtualization encapsulation, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 324 12:26.610 --> 12:30.240 it saw generic network virtualization encapsulation, 325 12:30.240 --> 12:34.080 which the acronym for that is G-E-N-E-V-E 326 12:34.080 --> 12:37.530 or GENEVE for generic network virtualization encapsulation. 327 12:37.530 --> 12:40.530 And that's what NSX uses for the encapsulation 328 12:40.530 --> 12:43.770 of the traffic between in this example ESXi-A 329 12:43.770 --> 12:45.060 and ESXi-B. 330 12:45.060 --> 12:46.350 So after the GENEVE header, 331 12:46.350 --> 12:48.600 then we have the original payload, 332 12:48.600 --> 12:51.780 the original frame and packet that was sent by VM-A 333 12:51.780 --> 12:53.280 that was being sent over to VM-B. 334 12:53.280 --> 12:56.940 So we looked at the source MAC address here of 0050, 335 12:56.940 --> 12:59.520 et cetera, et cetera, ending in 2C1A. 336 12:59.520 --> 13:03.240 That is the MAC address associated with VM-A. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 336 12:59.520 --> 13:03.240 That is the MAC address associated with VM-A. 337 13:03.240 --> 13:05.070 And to confirm that here on VM host A, 338 13:05.070 --> 13:07.620 we could do an ifconfig, press enter, 339 13:07.620 --> 13:10.590 and here we can verify its MAC address right there. 340 13:10.590 --> 13:12.270 Also, while we're right here looking at the VMs, 341 13:12.270 --> 13:15.390 let's also take a look at the Layer 2 MAC address 342 13:15.390 --> 13:17.310 on the VM that's running on host B. 343 13:17.310 --> 13:18.840 So here is host B 344 13:18.840 --> 13:22.173 and there's its MAC address right here ending in 0A1B. 345 13:23.430 --> 13:26.010 And that's what we should have seen inside the trace 346 13:26.010 --> 13:28.110 as the destination in the payload. 347 13:28.110 --> 13:29.790 So let's verify that as well. 348 13:29.790 --> 13:31.680 So if we go back to our packet capture, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 348 13:29.790 --> 13:31.680 So if we go back to our packet capture, 349 13:31.680 --> 13:33.300 there's the destination address right there 350 13:33.300 --> 13:34.230 ending in 0A1B. 351 13:35.250 --> 13:37.980 So the traffic was sourced from 10.10.0.10 352 13:37.980 --> 13:40.890 that's the VM on host A going to the IP address 353 13:40.890 --> 13:42.660 of the VM on host B. 354 13:42.660 --> 13:43.830 And again, just as a reminder, 355 13:43.830 --> 13:48.180 everything from this line going up was 356 13:48.180 --> 13:51.840 just the traffic in delivering this packet capture over 357 13:51.840 --> 13:53.310 to my management computer 358 13:53.310 --> 13:56.370 and my management computer's right here at .151. 359 13:56.370 --> 13:59.130 And then everything from right here below is all 360 13:59.130 --> 14:01.170 of our traffic related to NSX WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 360 13:59.130 --> 14:01.170 of our traffic related to NSX 361 14:01.170 --> 14:03.690 with the original payload being right here. 362 14:03.690 --> 14:05.640 And the traffic rigor on the tunnel is everything from 363 14:05.640 --> 14:07.440 here to here. 364 14:07.440 --> 14:09.180 So I'll label that part as the tunnel. 365 14:09.180 --> 14:10.710 Again, that's the GENEVE tunnel. 366 14:10.710 --> 14:13.200 And then the payload of that is the original traffic 367 14:13.200 --> 14:16.170 that was going from the VM on host A going over 368 14:16.170 --> 14:17.610 to the VM on host B. 369 14:17.610 --> 14:19.080 And again, we'll also have more opportunities 370 14:19.080 --> 14:20.550 to both configure and verify this, 371 14:20.550 --> 14:22.140 but I just wanna reinforce the concept 372 14:22.140 --> 14:23.417 that it is really happening 373 14:23.417 --> 14:27.120 and it is really that easy once NSX 374 14:27.120 --> 14:28.410 is set up and configured. 375 14:28.410 --> 14:32.790 So one of the benefits is extended Layer 2 broadcast WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 375 14:28.410 --> 14:32.790 So one of the benefits is extended Layer 2 broadcast 376 14:32.790 --> 14:35.700 domains, even when we have ESXi hosts that are not attached 377 14:35.700 --> 14:38.490 to the same common Layer 2 broadcast domains. 378 14:38.490 --> 14:40.950 And again, the way that NSX pulls this off is using 379 14:40.950 --> 14:43.560 the GENEVE tunnels and tunneling the traffic 380 14:43.560 --> 14:45.633 from one EXSi host to another. 381 14:46.470 --> 14:47.810 Another benefit that NSX brings 382 14:47.810 --> 14:49.950 to the table is security. 383 14:49.950 --> 14:52.440 So for any VMs that are part of our infrastructure 384 14:52.440 --> 14:55.320 where NSX is involved, we have several security features, 385 14:55.320 --> 14:57.720 including what's known as a distributed firewall. 386 14:57.720 --> 14:59.040 And think of a distributed firewall 387 14:59.040 --> 15:01.260 as a firewall that just hovers everywhere. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 387 14:59.040 --> 15:01.260 as a firewall that just hovers everywhere. 388 15:01.260 --> 15:04.710 So we could be very granular in what we want to permit 389 15:04.710 --> 15:08.040 or allow or deny between any two VMs, 390 15:08.040 --> 15:11.640 even two VMs that are on the same exact broadcast domain. 391 15:11.640 --> 15:15.450 So if we want to allow SSH or HTTPs or ICMP 392 15:15.450 --> 15:17.400 or anything else using the security services, 393 15:17.400 --> 15:19.470 we can control what is or is not allowed 394 15:19.470 --> 15:20.397 between the two VMs. 395 15:20.397 --> 15:22.710 And that also would apply to two VMs 396 15:22.710 --> 15:24.720 that are sitting on the same ESXi host. 397 15:24.720 --> 15:27.390 So over here at ESXi-B, if we had VM-B 398 15:27.390 --> 15:30.600 and VM-C who's also connected to that same segment, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 398 15:27.390 --> 15:30.600 and VM-C who's also connected to that same segment, 399 15:30.600 --> 15:32.310 we can also control what's allowed back 400 15:32.310 --> 15:34.770 and forth between those two VMs as well. 401 15:34.770 --> 15:37.140 Another big benefit of NSX is the ability 402 15:37.140 --> 15:38.940 to do Layer 3 routing. 403 15:38.940 --> 15:40.260 And with NSX, instead of having to do 404 15:40.260 --> 15:43.380 that on our physical environment with our physical routers 405 15:43.380 --> 15:45.540 and switches and doing the routing there, 406 15:45.540 --> 15:47.700 we can do the routing logically in software. 407 15:47.700 --> 15:48.870 So lemme give you a quick 408 15:48.870 --> 15:50.310 diagram of what that could look like. 409 15:50.310 --> 15:53.130 Let's say imagine we have a router here, this router one, 410 15:53.130 --> 15:56.520 and let's imagine we have router two and router three, 411 15:56.520 --> 15:58.350 and then this guy goes up to the internet. 412 15:58.350 --> 15:59.910 We have some connections here. 413 15:59.910 --> 16:01.350 Then down here, let's imagine we have a few network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 413 15:59.910 --> 16:01.350 Then down here, let's imagine we have a few network 414 16:01.350 --> 16:04.380 segments, the 10.10 network and the 10.20 network 415 16:04.380 --> 16:07.440 and the 10.30 network and the 10.40 network. 416 16:07.440 --> 16:09.300 Let's go ahead and put some connectivity there. 417 16:09.300 --> 16:10.800 So we'll have this router router two connect 418 16:10.800 --> 16:12.150 to those two network segments 419 16:12.150 --> 16:14.100 and over here are three connected there. 420 16:14.100 --> 16:16.340 Let's put some VMs there on those segments as well. 421 16:16.340 --> 16:18.390 So we'll put one VM there, I'll put 'em in blue, 422 16:18.390 --> 16:20.700 this guy be in yellow, and this VM will be in pink. 423 16:20.700 --> 16:22.590 And I'll put this VM here in green. 424 16:22.590 --> 16:25.050 So for the routing, we can do routing east-west, 425 16:25.050 --> 16:27.180 that'd be routing within our infrastructure. 426 16:27.180 --> 16:29.820 We can also do routing for north-south traffic as well. 427 16:29.820 --> 16:32.010 So let's imagine this VM represents customer one, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 427 16:29.820 --> 16:32.010 So let's imagine this VM represents customer one, 428 16:32.010 --> 16:35.970 and this yellow represents a VM that's a web server. 429 16:35.970 --> 16:37.950 And the pink represents an app server 430 16:37.950 --> 16:40.140 and the green represents a database server. 431 16:40.140 --> 16:42.180 So for east-west traffic, we can route the traffic 432 16:42.180 --> 16:43.530 between those VMs. 433 16:43.530 --> 16:44.850 And for our traffic that needs to go out 434 16:44.850 --> 16:46.530 of our enterprise, out to the internet, 435 16:46.530 --> 16:48.300 for example, we could also implement 436 16:48.300 --> 16:49.920 the north-south routing. 437 16:49.920 --> 16:51.390 And in conjunction with these routers, 438 16:51.390 --> 16:54.690 which in a NSX environment, they refer to them as gateways, 439 16:54.690 --> 16:56.730 we could also implement network services, such as 440 16:56.730 --> 17:01.530 network address translation and DHCP and load balancing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 440 16:56.730 --> 17:01.530 network address translation and DHCP and load balancing 441 17:01.530 --> 17:06.120 and VPNs and stable firewall services and many, many more. 442 17:06.120 --> 17:08.220 And to help reinforce what that might look like inside 443 17:08.220 --> 17:10.800 of an NSX environment, let me give you a sneak peek. 444 17:10.800 --> 17:12.480 So here's an example of what that would look like. 445 17:12.480 --> 17:13.710 We have a router here. 446 17:13.710 --> 17:15.960 We have another router here and here. 447 17:15.960 --> 17:17.250 Then we've got four network segments. 448 17:17.250 --> 17:18.510 So I've got one here, 449 17:18.510 --> 17:21.060 that I'm using the 10.10.0 address base on. 450 17:21.060 --> 17:23.520 I've got another Layer 2 broadcast domain here 451 17:23.520 --> 17:26.580 for segment 20 where I'm using the 10.20.0 address base. 452 17:26.580 --> 17:27.930 I've got a third one right here 453 17:27.930 --> 17:30.090 where we're using the 10.30.0 address base. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 453 17:27.930 --> 17:30.090 where we're using the 10.30.0 address base. 454 17:30.090 --> 17:31.920 And then I've got another segment over here, 455 17:31.920 --> 17:33.180 another Layer 2 broadcast domain 456 17:33.180 --> 17:35.550 where I'm using the 10.40.0 address base. 457 17:35.550 --> 17:37.560 And the way these segments are represented is they simply 458 17:37.560 --> 17:41.130 show up and look like port groups on our distributed switch. 459 17:41.130 --> 17:43.260 So we simply connect our VMs to the segments, 460 17:43.260 --> 17:44.730 which again look like port groups 461 17:44.730 --> 17:46.170 that we want them to be a part of. 462 17:46.170 --> 17:48.030 And then the logical routing services inside 463 17:48.030 --> 17:50.730 of NSX are providing the IP addresses 464 17:50.730 --> 17:53.310 and the routing to do the east-west routing as well 465 17:53.310 --> 17:55.683 as the north-south routing for those clients.