WEBVTT 1 00:00.210 --> 00:01.230 So in this video, 2 00:01.230 --> 00:03.270 we're gonna take a look at predicting 3 00:03.270 --> 00:06.030 and verifying the actual traffic flows 4 00:06.030 --> 00:07.320 when traffic is being routed, 5 00:07.320 --> 00:08.940 and also take a look at who 6 00:08.940 --> 00:12.450 is doing the actual routing logic or the routing decision. 7 00:12.450 --> 00:13.380 And when I'm talking about who, 8 00:13.380 --> 00:15.900 I'm talking about like, for example, is it ESXi-A 9 00:15.900 --> 00:17.190 that's making the decision 10 00:17.190 --> 00:19.500 or is it ESXi-B making the decision 11 00:19.500 --> 00:21.720 from the perspective of the router. 12 00:21.720 --> 00:25.020 So when it comes to routing in NSX, 13 00:25.020 --> 00:27.000 we are going to make that routing decision 14 00:27.000 --> 00:30.150 as close to the source as possible. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 14 00:27.000 --> 00:30.150 as close to the source as possible. 15 00:30.150 --> 00:31.530 And here's what I mean by that 16 00:31.530 --> 00:34.500 presuming that ESXi-A and ESXi-B 17 00:34.500 --> 00:36.030 both have the distributed router, 18 00:36.030 --> 00:38.040 which we already verified in previous video, 19 00:38.040 --> 00:40.860 so they both have information on reachability 20 00:40.860 --> 00:41.970 and the routing tables. 21 00:41.970 --> 00:44.850 So, for example, if we want to either of these hosts 22 00:44.850 --> 00:46.830 and said, regarding this distributed router, 23 00:46.830 --> 00:49.314 they would both indicate they can reach the 10.10 24 00:49.314 --> 00:50.790 and the 10.20 networks respectively. 25 00:50.790 --> 00:53.040 So as far as making the routing decision 26 00:53.040 --> 00:54.750 and being close to the source, 27 00:54.750 --> 00:56.520 it depends on where the source of the traffic 28 00:56.520 --> 00:57.353 is coming from. 29 00:57.353 --> 00:58.920 So let's imagine for this first scenario, 30 00:58.920 --> 01:01.080 it's VM-1, which is right there, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 30 00:58.920 --> 01:01.080 it's VM-1, which is right there, 31 01:01.080 --> 01:03.750 who's gonna talk to or send traffic to VM-2. 32 01:03.750 --> 01:05.970 So from a client perspective, 33 01:05.970 --> 01:08.940 it just knows that the target is on a remote network, 34 01:08.940 --> 01:11.730 so it's going to use its default gateway. 35 01:11.730 --> 01:14.010 So logically, the traffic would flow like this, 36 01:14.010 --> 01:16.710 VM-1 would say, "Oh, the target's not my local network," 37 01:16.710 --> 01:18.390 so it's gonna send it to its default gateway 38 01:18.390 --> 01:20.700 and use the layer 2 address of its default gateway 39 01:20.700 --> 01:21.720 for the frame, 40 01:21.720 --> 01:25.050 the router would then pick it up or receive that packet 41 01:25.050 --> 01:26.760 and take a look at the destination address, 42 01:26.760 --> 01:28.560 which is 10.20.0.20, 43 01:28.560 --> 01:29.850 it would see from its routing table 44 01:29.850 --> 01:31.140 that it's directly connected WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 44 01:29.850 --> 01:31.140 that it's directly connected 45 01:31.140 --> 01:33.360 and then resolve that layer 2 address of the destination 46 01:33.360 --> 01:35.670 if it didn't already have it in cache and then forward it. 47 01:35.670 --> 01:37.230 So even though logically, 48 01:37.230 --> 01:40.980 it looks like this process from the VM through Segment 10 49 01:40.980 --> 01:43.920 to the router through Segment 20 down to this VM, 50 01:43.920 --> 01:45.300 all that logic for the forwarding 51 01:45.300 --> 01:47.850 is done here in the brains of ESXi-A. 52 01:47.850 --> 01:50.610 And that's because ESXi-A is the host 53 01:50.610 --> 01:52.410 that is providing the compute resources 54 01:52.410 --> 01:55.410 for both VM-1 and VM-2. 55 01:55.410 --> 01:58.140 So logically, it would go through this process 56 01:58.140 --> 02:00.240 of, you know, traffic coming from the VM WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 56 01:58.140 --> 02:00.240 of, you know, traffic coming from the VM 57 02:00.240 --> 02:02.070 through the segment, through the router, 58 02:02.070 --> 02:04.230 out this interface on the router down to this VM. 59 02:04.230 --> 02:05.520 And that logically can all happen 60 02:05.520 --> 02:07.080 because we have a copy effectively 61 02:07.080 --> 02:10.170 of the distributed router right here on this host 62 02:10.170 --> 02:12.540 but no traffic for that communication 63 02:12.540 --> 02:14.220 ever needs to leave the uplinks 64 02:14.220 --> 02:15.570 or go over the transit network 65 02:15.570 --> 02:18.270 because it's all happening on the same host. 66 02:18.270 --> 02:19.530 So to verify all that, 67 02:19.530 --> 02:23.640 let's go ahead and use Traceflow inside of the NSX Manager 68 02:23.640 --> 02:24.780 and let's just ask it, 69 02:24.780 --> 02:28.680 hey, if we were gonna send a packet from this VM to that VM, 70 02:28.680 --> 02:30.900 what is the logical flow that would be used WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 70 02:28.680 --> 02:30.900 what is the logical flow that would be used 71 02:30.900 --> 02:33.720 and which host would provide all that processing? 72 02:33.720 --> 02:35.910 So back at the NSX Manager, 73 02:35.910 --> 02:38.280 let's go right here to Plan & Troubleshoot. 74 02:38.280 --> 02:39.720 Also, let's just take a moment 75 02:39.720 --> 02:43.050 and go to Networking and Network Topology 76 02:43.050 --> 02:45.120 just to make sure everything is like we think it is. 77 02:45.120 --> 02:48.750 So I've got two VMs that are connected to Segment 10 78 02:48.750 --> 02:51.480 and two VMs that are connected to Segment 20, 79 02:51.480 --> 02:54.540 so it's VMs 1 and 3 on Segment 10 80 02:54.540 --> 02:57.030 and VMs 2 and 4 on Segment 20, 81 02:57.030 --> 03:00.150 and let me just do a visual check on our topology WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 81 02:57.030 --> 03:00.150 and let me just do a visual check on our topology 82 03:00.150 --> 03:01.770 to make sure that I have it right. 83 03:01.770 --> 03:06.060 So VM-1 and VM-3 are on Segment 10, perfect, in yellow 84 03:06.060 --> 03:10.320 and VM-2 and VM-4 are on Segment 20 on pink, 85 03:10.320 --> 03:13.170 and these two VMs are being hosted by ESXi-A 86 03:13.170 --> 03:16.500 and these two VMs 3 and 4 being hosted by ESXi-B. 87 03:16.500 --> 03:18.780 All right, so back to the NSX Manager, 88 03:18.780 --> 03:21.300 let's go here to Plan & Troubleshoot, 89 03:21.300 --> 03:24.060 and on the left, we'll go down to Traffic Analysis 90 03:24.060 --> 03:27.750 and then we'll click here on getting started with Traceflow, 91 03:27.750 --> 03:29.940 where it's going to actually inject packets 92 03:29.940 --> 03:31.020 that we tell it to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 92 03:29.940 --> 03:31.020 that we tell it to 93 03:31.020 --> 03:33.870 and then tell us whether or not that traffic flow 94 03:33.870 --> 03:34.710 would be successful, 95 03:34.710 --> 03:36.180 and if it is, it'll also tell us 96 03:36.180 --> 03:37.590 the logical path it's taking. 97 03:37.590 --> 03:39.150 So we'll click here to get started. 98 03:39.150 --> 03:40.230 And then here, we can specify 99 03:40.230 --> 03:41.610 the type of traffic we must send 100 03:41.610 --> 03:44.940 and by default it's gonna simulate using ICMP, 101 03:44.940 --> 03:46.710 which is protocol number one. 102 03:46.710 --> 03:48.960 So later on as we set up firewalls 103 03:48.960 --> 03:50.730 and we set up restrictions, 104 03:50.730 --> 03:53.340 you could also further test with specific protocols 105 03:53.340 --> 03:55.140 just to verify whether or not they're going through. 106 03:55.140 --> 03:55.973 So for now, 107 03:55.973 --> 03:58.650 we're just gonna verify basic connectivity with ICMP, 108 03:58.650 --> 03:59.670 and for the source, 109 03:59.670 --> 04:03.810 it's going to be VM-1 at 10.10.0.11, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 109 03:59.670 --> 04:03.810 it's going to be VM-1 at 10.10.0.11, 110 04:03.810 --> 04:04.643 so select that, 111 04:04.643 --> 04:05.476 and if we scroll down a little bit, 112 04:05.476 --> 04:08.070 it'll also show us the actual MAC address 113 04:08.070 --> 04:11.130 associated with that client at 10.10.0.11. 114 04:11.130 --> 04:13.740 And then for the destination, based on this initial test, 115 04:13.740 --> 04:16.410 we wanna select the virtual machine from the dropdown, 116 04:16.410 --> 04:18.150 we're gonna select VM-2, 117 04:18.150 --> 04:21.150 which is on a different segment, it's on segment 20, 118 04:21.150 --> 04:24.030 but being hosted still by ESXi-A. 119 04:24.030 --> 04:26.820 So there's the details for VM-2 120 04:26.820 --> 04:28.200 and we'll scroll down a little bit more 121 04:28.200 --> 04:29.820 and we'll click on TRACE. 122 04:29.820 --> 04:32.520 So this literally injects traffic on the network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 122 04:29.820 --> 04:32.520 So this literally injects traffic on the network. 123 04:32.520 --> 04:35.130 I put a packet capture on the transport network 124 04:35.130 --> 04:37.680 for stuff that would have to go between ESXi-A and B 125 04:37.680 --> 04:40.590 and sure enough, the packet captures off the wire 126 04:40.590 --> 04:43.050 showed literal traffic as a result 127 04:43.050 --> 04:44.490 of this traceflow being run. 128 04:44.490 --> 04:47.580 So here's a visual representation of what just happened. 129 04:47.580 --> 04:49.140 Let me make that full screen. 130 04:49.140 --> 04:51.930 So this is showing us that the traffic from VM-1, 131 04:51.930 --> 04:54.030 which is on the network 10.10.0, 132 04:54.030 --> 04:56.130 was forwarded through the yellow segment, 133 04:56.130 --> 04:58.110 it was received by the gateway, 134 04:58.110 --> 05:00.450 effectively the layer 3 router here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 134 04:58.110 --> 05:00.450 effectively the layer 3 router here, 135 05:00.450 --> 05:02.910 and that layer three router made a routing decision, 136 05:02.910 --> 05:04.380 forwarded it down at the interface, 137 05:04.380 --> 05:05.880 going to the pink segment, 138 05:05.880 --> 05:09.270 and then forwarding and finally to the client at 10.20.0.20. 139 05:09.270 --> 05:10.103 And then off to the left 140 05:10.103 --> 05:11.670 is showing us the resource that was being used. 141 05:11.670 --> 05:16.050 So a resource in NSX could be an actual host transport node 142 05:16.050 --> 05:18.450 in the case of ESXi-A or ESXi-B, 143 05:18.450 --> 05:19.950 or it could be an edge node 144 05:19.950 --> 05:23.700 in the event we had to forward traffic over to an edge node 145 05:23.700 --> 05:25.650 for some service that required the edge node, 146 05:25.650 --> 05:27.900 like active/active or active/standby 147 05:27.900 --> 05:30.540 or doing NAT services or other services WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 147 05:27.900 --> 05:30.540 or doing NAT services or other services 148 05:30.540 --> 05:33.870 that may require sending it over to the edge nodes. 149 05:33.870 --> 05:34.950 However, for this topology, 150 05:34.950 --> 05:36.390 especially for this traceflow, 151 05:36.390 --> 05:38.730 because VM-1 and VM-2 are the same host, 152 05:38.730 --> 05:40.650 we just click over here on the host icon, 153 05:40.650 --> 05:41.810 it was ESXi-A, 154 05:41.810 --> 05:44.610 and then we click here on Segment 10 on the host, 155 05:44.610 --> 05:45.630 it's ESXi-A. 156 05:45.630 --> 05:48.420 If we click on the logical router, the distributed router, 157 05:48.420 --> 05:49.830 it was ESXi-A. 158 05:49.830 --> 05:51.990 And then as that traffic was logically routed 159 05:51.990 --> 05:54.060 down through Segment 20, if we click here, 160 05:54.060 --> 05:55.860 it's still ESXi-A. 161 05:55.860 --> 05:57.720 And then as it got delivered to the final client, 162 05:57.720 --> 05:59.790 which is also hosted on ESXi-A, 163 05:59.790 --> 06:01.410 ESXi-A was responsible for that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 163 05:59.790 --> 06:01.410 ESXi-A was responsible for that. 164 06:01.410 --> 06:06.270 So this traffic flow was all happening right at ESXi-A 165 06:06.270 --> 06:10.950 and doing the logical routing between 10.10.0 and 10.20.0. 166 06:10.950 --> 06:12.330 All right, let's go ahead and close that, 167 06:12.330 --> 06:15.090 and then it's showing us also the details right here. 168 06:15.090 --> 06:16.590 So that traffic was sent in 169 06:16.590 --> 06:19.050 as if it was coming in from that VM. 170 06:19.050 --> 06:20.880 It was received at ESXi-A. 171 06:20.880 --> 06:23.340 Logically, there was a distributed firewall 172 06:23.340 --> 06:25.110 with a distributed firewall rule 173 06:25.110 --> 06:27.270 that by default is permitting all traffic, 174 06:27.270 --> 06:29.640 so it's showing that logically, it had to go through that 175 06:29.640 --> 06:32.070 but the distributed firewall was permitting it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 175 06:29.640 --> 06:32.070 but the distributed firewall was permitting it. 176 06:32.070 --> 06:34.890 Later on, we'll talk about implementing security 177 06:34.890 --> 06:36.270 with a distributed firewall. 178 06:36.270 --> 06:37.260 And once it passed the rule, 179 06:37.260 --> 06:39.090 it then went through Segment 10 180 06:39.090 --> 06:42.120 and then it went to the logical layer 3 interface 181 06:42.120 --> 06:45.090 on Segment 10 for our Tier-1 gateway. 182 06:45.090 --> 06:47.820 Now again, it's all ESXi-A doing it 183 06:47.820 --> 06:49.170 using the distributed router. 184 06:49.170 --> 06:52.050 The traffic never had to leave ESXi-A. 185 06:52.050 --> 06:54.090 So once that traffic was received on one interface 186 06:54.090 --> 06:55.320 of the logical router, 187 06:55.320 --> 06:57.960 it was then forwarded out the other interface right here 188 06:57.960 --> 06:59.430 down through Segment 20, 189 06:59.430 --> 07:01.140 and then before it was delivered to the client, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 189 06:59.430 --> 07:01.140 and then before it was delivered to the client, 190 07:01.140 --> 07:03.000 there's also a distributed firewall and a rule 191 07:03.000 --> 07:05.340 that by default are permitting the traffic, 192 07:05.340 --> 07:08.250 and it was delivered successfully to VM-2, 193 07:08.250 --> 07:09.690 who lives on Segment 20. 194 07:09.690 --> 07:13.290 All right, so that is one example of routing 195 07:13.290 --> 07:15.630 using a single ESXi host to do it. 196 07:15.630 --> 07:16.890 So up here, we'll make a little note, 197 07:16.890 --> 07:21.890 it was all ESXi-A leveraging the distributed router 198 07:23.340 --> 07:24.423 that it has.