WEBVTT 1 00:00.000 --> 00:04.760 So at this point in our journey, let's go ahead and create a gateway and a 2 00:04.760 --> 00:09.000 segment that is stretched or can be used effectively by both sites. 3 00:09.000 --> 00:12.330 And so for the gateway, let's create a tier one gateway. We'll call it tier one 4 00:12.330 --> 00:16.000 dash S short for stretched and we'll also create a segment. 5 00:16.000 --> 00:19.470 Let's create a segment called SEG 50 S again. The S reminding us it's a stretch 6 00:19.470 --> 00:24.000 segment and then we'll test it. We'll put a couple VMs one here at site one. 7 00:24.000 --> 00:27.910 We'll connect it to segment 50 S. We'll take another VM over here at site two 8 00:27.910 --> 00:31.570 connected that same shared segment. We'll set up some IP addressing and verify WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 8 00:27.910 --> 00:31.570 connected that same shared segment. We'll set up some IP addressing and verify 9 00:31.570 --> 00:34.000 that they can communicate with each other. 10 00:34.000 --> 00:37.580 We can also use trace flow to verify that packets are making it. And then just 11 00:37.580 --> 00:41.560 for fun, let's also configure a distributed firewall at the global manager to 12 00:41.560 --> 00:45.000 control what is or isn't allowed for that site to site traffic. 13 00:45.000 --> 00:49.340 So here at the global manager and I'm looking at this global manager interface 14 00:49.340 --> 00:52.680 and I realized I left off. We were working with the edge notes. So I'm going to 15 00:52.680 --> 00:54.000 click right here on NSX. 16 00:54.000 --> 00:57.060 And that's going to take us back to the global manager. I'll click here on 17 00:57.060 --> 01:01.000 system just to confirm. Sure enough, we're back at the NSX global manager. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 17 00:57.060 --> 01:01.000 system just to confirm. Sure enough, we're back at the NSX global manager. 18 01:01.000 --> 01:05.130 And if he's called down, we have two sites site one and site two fantastic. So 19 01:05.130 --> 01:09.560 here at the global manager, let's click on networking and let's create a brand 20 01:09.560 --> 01:11.000 new tier one gateway. 21 01:11.000 --> 01:14.940 This can be stretched across both sites and then we'll follow it up by creating 22 01:14.940 --> 01:19.000 a segment connected to that gateway, which is also stretched across both sites. 23 01:19.000 --> 01:23.720 So we'll start off here with the tier one gateways. So there's our four tier 24 01:23.720 --> 01:27.820 one gateways to a site one and to a site two. And we're going to create a new 25 01:27.820 --> 01:29.000 one right here at the global manager. 26 01:29.000 --> 01:33.230 So we'll click on add tier one gateway. As far as linking this to a tier zero WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 26 01:29.000 --> 01:33.230 So we'll click on add tier one gateway. As far as linking this to a tier zero 27 01:33.230 --> 01:37.170 gateway, if we also had a stretch tier zero gateway that we created, we could 28 01:37.170 --> 01:38.000 link to that. 29 01:38.000 --> 01:42.140 So for the demo, I'm not going to associate this with a tier zero gateway. And 30 01:42.140 --> 01:45.000 then as we scroll down a little bit under locations, check this out. 31 01:45.000 --> 01:48.500 I'm going to specify that I want this associate with site one and we'll click 32 01:48.500 --> 01:52.000 right here on add location. I also want it associated with site two. 33 01:52.000 --> 01:55.500 And effectively, that's what makes it a stretch gateway that's available at 34 01:55.500 --> 01:59.000 both sites. And we're going to the resources against supported at site one. 35 01:59.000 --> 02:02.260 We're going to choose our edge cluster up there and at site two, we're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 35 01:59.000 --> 02:02.260 We're going to choose our edge cluster up there and at site two, we're going to 36 02:02.260 --> 02:04.000 choose our edge cluster over there. 37 02:04.000 --> 02:06.940 And then for route advertisements in the future, if we ever connect this to a 38 02:06.940 --> 02:10.070 tier zero gateway, I want to advertise my route. So I'm going to go ahead and 39 02:10.070 --> 02:12.000 enable that right now. So don't forget later. 40 02:12.000 --> 02:17.360 And then we'll click on safe. And there is our new here one gateway. So if we 41 02:17.360 --> 02:21.370 went over and looked at the local NSX manager at site one or site two, in fact, 42 02:21.370 --> 02:23.000 let's go over to site two for a moment. 43 02:23.000 --> 02:26.390 So here at site two, I'm using dark mode. So if we click on system, just to 44 02:26.390 --> 02:30.290 confirm where the right device. So if I click on appliances right here, we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 44 02:26.390 --> 02:30.290 confirm where the right device. So if I click on appliances right here, we're 45 02:30.290 --> 02:33.000 at site two, which is the virtual IP address of dot 14 and the virtual IP 46 02:33.000 --> 02:33.000 address. 47 02:33.000 --> 02:37.600 And here's a site two, if we click on location manager, it's showing us that we 48 02:37.600 --> 02:43.020 're synced up with the global manager. And here's the details for that global 49 02:43.020 --> 02:47.500 manager. If we scroll down here, it has a list of remote locations, which from 50 02:47.500 --> 02:50.000 site two's perspective is site one. 51 02:50.000 --> 02:52.900 And here is site two, if we went to networking, and then on the left, if we 52 02:52.900 --> 02:56.640 clicked on tier one gateways, check it out. There's our tier one stretch 53 02:56.640 --> 03:00.000 gateway that was just configured at the global manager. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 54 03:00.000 --> 03:03.870 So if we have similar results over at site one at the local manager there, you 55 03:03.870 --> 03:08.110 would also see this tier one stretched tier one gateway. However, if we go to 56 03:08.110 --> 03:11.350 segments here, we don't have any common stretch segments yet. And that's 57 03:11.350 --> 03:14.000 because we haven't created one yet over at the global manager. 58 03:14.000 --> 03:18.360 So let's go back to the global manager. And let's create a stretched segment 59 03:18.360 --> 03:23.310 that both site one and site two can use. So back at the global manager will go 60 03:23.310 --> 03:25.000 to the networking tab. 61 03:25.000 --> 03:28.300 And on the left, we'll click on segments currently is showing us the segments 62 03:28.300 --> 03:32.230 available at site one and site two. And what we want to do is create a stretch WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 62 03:28.300 --> 03:32.230 available at site one and site two. And what we want to do is create a stretch 63 03:32.230 --> 03:35.000 segment. So we'll click here add segment. 64 03:35.000 --> 03:38.810 So we'll call this seg 50 stretched and as far as the connected gateway, we're 65 03:38.810 --> 03:42.450 going to connect that to the stretched gateway, which is right here T one 66 03:42.450 --> 03:45.480 stretched. And now that it's connected, or will be once we click on save to 67 03:45.480 --> 03:48.000 that tier one stretch tier one gateway. 68 03:48.000 --> 03:51.590 So as site one and site two already have that stretch gateway, they are also 69 03:51.590 --> 03:55.620 going to have this segment available to them. So over here in locations is 70 03:55.620 --> 04:00.000 showing site one and site two with their default over the transport zones WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 71 04:00.000 --> 04:03.000 selected one in each of the two sites. 72 04:03.000 --> 04:07.480 And before we leave this let's also put in a default gateway address and let's 73 04:07.480 --> 04:13.200 use 10.50.0.1 with a slash 24. Now currently the tier one gateway that is 74 04:13.200 --> 04:17.260 connected to the segment isn't connected to the outside world or to a tier zero 75 04:17.260 --> 04:18.000 gateway. 76 04:18.000 --> 04:21.040 So we're going to have some limited connectivity until we flesh it all out. 77 04:21.040 --> 04:24.850 However, for the meantime, we can still use this seg 50 stretch segment, 78 04:24.850 --> 04:27.000 because it'll be available at both sites. 79 04:27.000 --> 04:31.250 So we'll scroll down and click on save. All right, it's been successfully WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 79 04:27.000 --> 04:31.250 So we'll scroll down and click on save. All right, it's been successfully 80 04:31.250 --> 04:34.630 created. Do we want to continue. I'll say, no, that's enough for now for the 81 04:34.630 --> 04:35.000 demo. 82 04:35.000 --> 04:38.890 So next let's go to site one and site two to the vSphere client will connect 83 04:38.890 --> 04:42.860 some VMs to that respective shared segment and then verify they can communicate 84 04:42.860 --> 04:44.000 with each other. 85 04:44.000 --> 04:47.370 Now currently over here under subnets, it's not showing as a hyperlink because 86 04:47.370 --> 04:51.510 I don't currently have D H P services. So we'll manually set up our IP 87 04:51.510 --> 04:53.000 addresses on the two VMs. 88 04:53.000 --> 04:56.960 And for more details on setting up options for D H P, please check out the 89 04:56.960 --> 05:01.340 skill on D H P services. But for now for this demo, we'll just do manual WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 89 04:56.960 --> 05:01.340 skill on D H P services. But for now for this demo, we'll just do manual 90 05:01.340 --> 05:03.000 configuration of our two VMs. 91 05:03.000 --> 05:07.210 So for the game plan, let's use a little VM called tiny VM a that's running on 92 05:07.210 --> 05:11.450 ESXi host a over here at site one will connect it to the segment, give it this 93 05:11.450 --> 05:12.000 IP address. 94 05:12.000 --> 05:16.350 Then over at site two, we'll use a little VM called tiny VM Y, which is running 95 05:16.350 --> 05:20.590 on host Y over here at site two will also connect it to the same common segment 96 05:20.590 --> 05:24.000 , which is the stretch segment being provided by the NSX federation. 97 05:24.000 --> 05:27.350 And we'll use this IP address right here and then we'll test connectivity back 98 05:27.350 --> 05:31.760 and forth. So here is the site one vSphere client and let me go ahead and grab WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 05:27.350 --> 05:31.760 and forth. So here is the site one vSphere client and let me go ahead and grab 99 05:31.760 --> 05:34.000 a little VM that we can play with. 100 05:34.000 --> 05:37.920 Let's take a look at ESXi a and see what VMs are over there. And I've got this 101 05:37.920 --> 05:42.000 little VM here. I'm going to rename that. So right click and rename it. 102 05:42.000 --> 05:47.280 And we'll call it tiny VM a and I'm also going to add site dash one just for gr 103 05:47.280 --> 05:50.970 ins and click on OK. So now that that VM is renamed, let's also go ahead and put 104 05:50.970 --> 05:52.000 on the correct segment. 105 05:52.000 --> 05:55.500 So let's also verify that segment exists. So here's the segment that was 106 05:55.500 --> 05:59.000 created as part of our NSX federation called SEG 50 stretched. 107 05:59.000 --> 06:03.120 And let's go grab that VM, which is right there. We'll right click edit WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 107 05:59.000 --> 06:03.120 And let's go grab that VM, which is right there. We'll right click edit 108 06:03.120 --> 06:07.750 settings and we'll place its network interface card on that new stretch segment 109 06:07.750 --> 06:08.000 . 110 06:08.000 --> 06:12.610 So we'll scroll down and there it is right there. We'll connect it and click on 111 06:12.610 --> 06:15.000 OK. And we'll click on OK one more time. 112 06:15.000 --> 06:18.620 So just to confirm, we'll put into the network tab here in the vSphere client 113 06:18.620 --> 06:22.000 and went down to the segment 50 stretched and clicked on VMs. 114 06:22.000 --> 06:26.310 So go ahead and right click and we'll power that guy on. And I'll also open up 115 06:26.310 --> 06:30.000 a remote console over to it, which we'll use here in a moment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 116 06:30.000 --> 06:33.330 All right. So for site one, we now have a VM connected to that segment. Let's 117 06:33.330 --> 06:36.000 go do the similar treatment over at site two. 118 06:36.000 --> 06:41.390 So over here at site two in dark mode to help differentiate it. Let's go find a 119 06:41.390 --> 06:46.000 VM. So let's go to our host ESXY and click on the VMs tab. 120 06:46.000 --> 06:50.700 And there's a little tiny VM there. Let me rename it to match our plan. So I'll 121 06:50.700 --> 06:53.000 right click from the drop down, click on rename. 122 06:53.000 --> 06:57.900 And I'll read in that tiny VM Y meaning it's running on host Y at site two and 123 06:57.900 --> 06:59.000 click on OK. 124 06:59.000 --> 07:02.390 Let's also modify the details for that and put it on that common stretch WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 124 06:59.000 --> 07:02.390 Let's also modify the details for that and put it on that common stretch 125 07:02.390 --> 07:07.470 segment of segment 50. So we'll right click on the tiny VM, click on edit 126 07:07.470 --> 07:08.000 settings. 127 07:08.000 --> 07:11.650 And then for its network adapter, let's go ahead and click on browse. And then 128 07:11.650 --> 07:16.000 we'll select that network segment right here, SEG 50 stretched and click on OK. 129 07:16.000 --> 07:19.950 Then we'll click on OK again. Then we'll power it on. So I'll click on power on 130 07:19.950 --> 07:23.000 . And let's also open a remote console to that VM as well. 131 07:23.000 --> 07:28.200 So let me bring those guys in. So there's the remote console for tiny VM A that 132 07:28.200 --> 07:30.000 's running on host A over here at site one. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 133 07:30.000 --> 07:35.460 And let me bring in the one for the VM running over here at site two, which is 134 07:35.460 --> 07:39.000 running on host Y. And let me make the screen a little bit bigger. 135 07:39.000 --> 07:43.250 So for the machine here at the left, I have config and specify the IP address 136 07:43.250 --> 07:47.000 of 1050 011 with the 24 bit mask for ethernet zero. 137 07:47.000 --> 07:51.520 So there's the IP address right there based on our plan 1050 011. And let's do 138 07:51.520 --> 07:54.000 a similar treatment over here for the VM at the right. 139 07:54.000 --> 07:58.010 And this is the VM over at site two and for its IP address, it's going to end 140 07:58.010 --> 08:01.680 in dot 22. So we'll do an I have config to specify the IP address, then we'll WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 140 07:58.010 --> 08:01.680 in dot 22. So we'll do an I have config to specify the IP address, then we'll 141 08:01.680 --> 08:05.000 do an I have config for ethernet zero just to verify its IP address. 142 08:05.000 --> 08:10.110 And that looks good. So the IP address is involved or on the VM at site one. We 143 08:10.110 --> 08:14.000 have the IP address of 1050 011 connected to that common segment. 144 08:14.000 --> 08:19.120 And at site two, we have this little VM, which is running ESX i host Y with the 145 08:19.120 --> 08:24.460 IP address of 1050 022. So for that traffic flow, the traffic we go from the 146 08:24.460 --> 08:29.590 host that's hosting that VM, it'd be forwarded over to the edge node that would 147 08:29.590 --> 08:30.000 use its remote WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 148 08:30.000 --> 08:34.640 address, send it over the tunnel, the genieve tunnel from the edge node at site 149 08:34.640 --> 08:38.760 one over to an edge node at site two, who in D encapsulate that forwarded to 150 08:38.760 --> 08:43.000 the host that's supporting this VM here on the right, who would then deliver it 151 08:43.000 --> 08:43.000 to that client. 152 08:43.000 --> 08:46.920 So let's verify that that ping works here between the two VMs. So starting off 153 08:46.920 --> 08:52.530 on the left hand side, let's do a ping over to 10 dot 50 dot 0 dot 22. And that 154 08:52.530 --> 08:56.000 is the virtual machine over at site two will press enter. 155 08:56.000 --> 09:00.840 And that is flying. So all of that traffic is being tunneled from the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 155 08:56.000 --> 09:00.840 And that is flying. So all of that traffic is being tunneled from the 156 09:00.840 --> 09:06.020 respective host A here that the tiny VM is running on is being tunnel over to 157 09:06.020 --> 09:09.000 the local edge node who's using the R. 158 09:09.000 --> 09:13.470 Tap to send her to the remote edge node at site two. And then that edge notice 159 09:13.470 --> 09:17.810 site two is doing a tunnel over to host Y who then receives that traffic then 160 09:17.810 --> 09:20.000 forwards it to the VM on the right. 161 09:20.000 --> 09:24.270 And the cool thing is we can verify that all with trace flow from the global 162 09:24.270 --> 09:27.860 manager. So here at the global manager. If we click on the plan and troublesh 163 09:27.860 --> 09:31.000 oot, we have here as well the option of using trace flow. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 163 09:27.860 --> 09:31.000 oot, we have here as well the option of using trace flow. 164 09:31.000 --> 09:35.050 So here for trace flow, we're going to use ICMP by default, we can change that 165 09:35.050 --> 09:38.090 if we need to. I see people work great for this test. And then for the source, 166 09:38.090 --> 09:40.000 let's go ahead and use a virtual machine. 167 09:40.000 --> 09:43.830 And then it's asking us to specify the location. So we'll start from site one 168 09:43.830 --> 09:48.930 and then select a VM from that location. Let's go ahead and grab the tiny VMA 169 09:48.930 --> 09:50.000 site one. 170 09:50.000 --> 09:53.030 And it's also showing us confirming for us the IP address that we have there. 171 09:53.030 --> 09:56.590 And then for the destination, we'll go ahead and select the location of site 172 09:56.590 --> 09:57.000 two. 173 09:57.000 --> 10:01.690 And then with insight to will choose the VM of tiny VM Y at site two. It's also WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 173 09:57.000 --> 10:01.690 And then with insight to will choose the VM of tiny VM Y at site two. It's also 174 10:01.690 --> 10:05.000 confirming for us here. The IP addresses involved fantastic. 175 10:05.000 --> 10:09.230 And then we'll scroll down and click on trace. So that's going to actually 176 10:09.230 --> 10:14.000 inject the literal traffic, the ICMP traffic and then verify hop by hop by hop. 177 10:14.000 --> 10:17.640 All the paths it's going through and whether or not that traffic actually makes 178 10:17.640 --> 10:22.010 it. Now we know from the ping we just did that the traffic actually succeeds. 179 10:22.010 --> 10:24.000 It's not being dropped by a firewall. 180 10:24.000 --> 10:28.420 So trace flow is a nice visual representation of exactly which edge nodes were 181 10:28.420 --> 10:32.970 involved and which taps and for intersite communications, which are taps were WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 181 10:28.420 --> 10:32.970 involved and which taps and for intersite communications, which are taps were 182 10:32.970 --> 10:37.490 being used. So here's the diagram, we make that full screen and make that a 183 10:37.490 --> 10:38.000 little bit bigger. 184 10:38.000 --> 10:42.360 So this represents the flow of the traffic from the tiny VM at site one. That's 185 10:42.360 --> 10:46.410 going over our stretch segment, the segment 50 going down to the tiny VM at 186 10:46.410 --> 10:51.230 site two. If we go ahead and collapse that, we can also take a look here at the 187 10:51.230 --> 10:52.000 play by play, 188 10:52.000 --> 10:57.140 which starts at site one at ESXIA and make that a little bit bigger, who 189 10:57.140 --> 11:00.690 logically processed the distributed firewall rules that all passed, and then it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 189 10:57.140 --> 11:00.690 logically processed the distributed firewall rules that all passed, and then it 190 11:00.690 --> 11:03.780 handed it over to the edge nodes. And over here on the left, we have the 191 11:03.780 --> 11:08.000 physical hop count, which represents every time it was sent over a network. 192 11:08.000 --> 11:12.120 So we have the tunnel from ESXIA going to edge one using the tunnel endpoint 193 11:12.120 --> 11:17.000 addresses for that forwarding, then edge one is logical routing and processing. 194 11:17.000 --> 11:20.600 If we scroll down that continues. And then right here, we have it being 195 11:20.600 --> 11:25.730 forwarded from edge one over to lab to edge one, and also over here in the 196 11:25.730 --> 11:28.770 physical hop count is showing us how it's actually going over a transport 197 11:28.770 --> 11:29.000 network. 198 11:29.000 --> 11:32.840 So there are the remote tunnel endpoint addresses involved right here on the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 198 11:29.000 --> 11:32.840 So there are the remote tunnel endpoint addresses involved right here on the 199 11:32.840 --> 11:36.560 right. And if he's scroll down, then lab two is doing its work of logical 200 11:36.560 --> 11:39.630 processing that packet flow until it decided, Oh, you know what, I need to 201 11:39.630 --> 11:45.000 forward this over to ESXIA that host at this point edge one use the local 202 11:45.000 --> 11:47.000 tunnel endpoint address of 77, etc. 203 11:47.000 --> 11:53.510 So we have the local endpoint address on host ESXIA, which is 66, etc. So ESXIA 204 11:53.510 --> 11:57.970 received that. It did the logical processing as well, distributed firewall 205 11:57.970 --> 12:01.000 rules, and finally that traffic was delivered as shown right here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 205 11:57.970 --> 12:01.000 rules, and finally that traffic was delivered as shown right here. 206 12:01.000 --> 12:04.510 And as the last piece, let's also create a simple distributed firewall rule 207 12:04.510 --> 12:08.130 that would prevent that traffic from happening. So since we're sitting at the N 208 12:08.130 --> 12:12.000 SS global manager, let's go ahead and click on security. 209 12:12.000 --> 12:15.320 And after we'll click on distributed firewall, and let's simply create a policy 210 12:15.320 --> 12:19.150 and a rule that denies that traffic. So we'll click on add policy. I'll 211 12:19.150 --> 12:21.000 collapse the left hand side gives a little more room. 212 12:21.000 --> 12:25.340 Let's call this our global policy will add a rule and we'll deny ICMP. And for 213 12:25.340 --> 12:28.910 more details on the nitty gritty regarding distributed firewalls and their 214 12:28.910 --> 12:31.940 policies and rules, feel free to check out our separate skill just on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 214 12:28.910 --> 12:31.940 policies and rules, feel free to check out our separate skill just on 215 12:31.940 --> 12:33.000 distributed firewall. 216 12:33.000 --> 12:36.680 However, for now, I just want to go ahead and demonstrate how we can use this 217 12:36.680 --> 12:41.390 at the global level to also implement policy. So we'll say deny ICMP. And I'm 218 12:41.390 --> 12:45.350 going to go ahead and specify for the source. Again, we could use group 219 12:45.350 --> 12:48.000 membership for this, but I'm going to go ahead and just put addresses in. 220 12:48.000 --> 12:53.000 I'm going to say any traffic from 10.50 anything. So that'd be 1050 zero zero 221 12:53.000 --> 12:57.230 with a 16 bit mask for the source, click on apply. And for the destination, we 222 12:57.230 --> 13:00.000 could also specify the destination of 1050 anything. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 223 13:00.000 --> 13:02.630 But if we do a source, all of our traffic on that segment is going to be 224 13:02.630 --> 13:05.540 sourced from that IP address. That'll be enough. And this is going to be 225 13:05.540 --> 13:07.000 applied to the distributed firewall. 226 13:07.000 --> 13:10.170 And the default action is allow. Let's go ahead and change that to drop. And 227 13:10.170 --> 13:14.000 before we publish that and push it out, let's just test our ping one more time. 228 13:14.000 --> 13:18.760 So here's our tiny little VM over at site one. I'll do that ping over to the 229 13:18.760 --> 13:24.730 remote site VM at 1050 zero 22. Now what we'll do is this is go ahead and 230 13:24.730 --> 13:27.000 publish this rule. This distributed firewall rule. 231 13:27.000 --> 13:31.190 So we'll click on publish. Let's bring back that VM and it is going to stop in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 231 13:27.000 --> 13:31.190 So we'll click on publish. Let's bring back that VM and it is going to stop in 232 13:31.190 --> 13:35.000 its track. So it's no longer sending traffic because it's being dropped. 233 13:35.000 --> 13:39.240 We can also verify that with trace flow go back to plan and troubleshoot. And 234 13:39.240 --> 13:43.780 we simply do the same exact retrace again and proceed with that. That'll help 235 13:43.780 --> 13:47.000 us to confirm that is the actual distributed firewall that we just deployed 236 13:47.000 --> 13:49.000 that is preventing that traffic from flowing. 237 13:49.000 --> 13:53.160 And so here in the output is showing us right there that is being dropped. So 238 13:53.160 --> 13:58.370 he's six. I a right here is dropping that traffic. So if we go back to security 239 13:58.370 --> 14:02.000 and I just realized that I that I call that rule. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 239 13:58.370 --> 14:02.000 and I just realized that I that I call that rule. 240 14:02.000 --> 14:07.130 I see in P when we're really doing is we're denying anything sourced from 10 241 14:07.130 --> 14:10.990 anything. So here in our policy, I should have named that deny. For example, 242 14:10.990 --> 14:15.000 source traffic coming from 1050 because I didn't specify any services here. 243 14:15.000 --> 14:19.140 So they go ahead and disable this rule and publish it out and let's bring back 244 14:19.140 --> 14:22.820 our client. So now at our client, that ping is now picking up. So it missed a 245 14:22.820 --> 14:27.670 whole bunch more than 100 as we had it blocked for a while. But now it's pe 246 14:27.670 --> 14:28.000 aking once again. 247 14:28.000 --> 14:31.430 Also to tidy this up a little bit, I'm going to go ahead and edit the services WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 247 14:28.000 --> 14:31.430 Also to tidy this up a little bit, I'm going to go ahead and edit the services 248 14:31.430 --> 14:36.640 column. And here I'm going to search for ICMP and press enter and specify one 249 14:36.640 --> 14:39.000 of match on ICMP and click on apply. 250 14:39.000 --> 14:44.050 And that way, once this is applied, it'll be traffic source from 1050 anything. 251 14:44.050 --> 14:48.180 And if it's ICMP at that point, it'll be dropped if we have this enforced. So I 252 14:48.180 --> 14:52.000 'll go ahead. I'm going to leave it disabled, but I'm going to publish this. 253 14:52.000 --> 14:55.410 And that way I'll have that new rule in place if I ever want to enable it and 254 14:55.410 --> 14:58.940 it'll be correctly named of deny ICMP because that's now really what we're 255 14:58.940 --> 15:03.000 doing again for a deeper dive on setting up and testing distributive firewalls. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 255 14:58.940 --> 15:03.000 doing again for a deeper dive on setting up and testing distributive firewalls. 256 15:03.000 --> 15:06.340 Please check out our separate skill, which is dedicated to the distributed 257 15:06.340 --> 15:10.600 firewall. So if we reflect back on our game plan here, we've now implemented 258 15:10.600 --> 15:15.880 and verified site to site communications by leveraging NSX Federation with a 259 15:15.880 --> 15:21.000 global manager in charge of these two sites and a stretch gateway and stretch 260 15:21.000 --> 15:21.000 segment. 261 15:21.000 --> 15:28.000 That's now available to the vSphere client and its VMs in each of the sites.