WEBVTT 1 00:00.000 --> 00:02.720 So for our discussion regarding segment profiles, 2 00:02.720 --> 00:06.600 let's talk for a moment about where we can apply a segment profile. 3 00:06.600 --> 00:09.760 There's a bunch of segment profiles that are in place by default, 4 00:09.760 --> 00:13.080 and their primary location is on a segment. 5 00:13.080 --> 00:16.340 By default, we're going to have a set of segment profiles applied 6 00:16.340 --> 00:20.680 to the segments 10 and 20 here off the blue tier 1 gateway. 7 00:20.680 --> 00:25.020 We're going to have segment profiles by default applied to this segment right 8 00:25.020 --> 00:25.520 here, 9 00:25.520 --> 00:29.120 off of our tier 1 gateway off the primary tier 0. 10 00:29.120 --> 00:32.220 And we're also going to have a set of default segment profiles applied right WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:29.120 --> 00:32.220 And we're also going to have a set of default segment profiles applied right 11 00:32.220 --> 00:33.840 here to segment green. 12 00:33.840 --> 00:37.120 And the way that a segment profile works is sort of like a waterfall. 13 00:37.120 --> 00:40.080 So if you imagine a waterfall starting here and then it goes down, 14 00:40.080 --> 00:41.520 that's how it works with our segments. 15 00:41.520 --> 00:45.040 If we have a segment profile applied right here to segment 10 16 00:45.040 --> 00:47.440 and the same default 1's to segment 20, 17 00:47.440 --> 00:52.000 any VMs connected to those segments are going to inherit those properties. 18 00:52.000 --> 00:54.080 And the same thing right here for this segment, 19 00:54.080 --> 00:56.400 whatever segment profiles are applied here, 20 00:56.400 --> 01:00.610 these VMs, because they're directly connected to the segments via their logical WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 20 00:56.400 --> 01:00.610 these VMs, because they're directly connected to the segments via their logical 21 01:00.610 --> 01:01.200 network interface 22 01:01.200 --> 01:04.830 cards and the logical ports on those segments, they are going to inherit those 23 01:04.830 --> 01:05.440 settings. 24 01:05.440 --> 01:08.800 Now, what if we have 200 VMs on a segment and we all of a sudden decide, 25 01:08.800 --> 01:13.770 oh no, we have two or three VMs of those hundreds that need specific or 26 01:13.770 --> 01:14.400 different settings. 27 01:14.400 --> 01:17.520 What we can also do is take a segment profile that's different 28 01:17.520 --> 01:20.960 and we can apply that directly to a VM should we choose to do that. 29 01:20.960 --> 01:24.640 So if at the segment level, we have one segment profile. 30 01:24.640 --> 01:26.000 We'll go ahead and call it A. 31 01:26.000 --> 01:28.640 And then at the individual VM that's connected to that segment, 32 01:28.640 --> 01:32.000 we've directly applied a different segment profile of B WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 32 01:28.640 --> 01:32.000 we've directly applied a different segment profile of B 33 01:32.000 --> 01:33.760 to the port where that VM is connected. 34 01:33.760 --> 01:37.740 For those settings there in profile B, they're applied directly to the VMs port 35 01:37.740 --> 01:38.000 . 36 01:38.000 --> 01:41.520 Those are going to take precedence and override any conflicting settings 37 01:41.520 --> 01:44.640 that might be the segment profile applied to the segment itself. 38 01:44.640 --> 01:48.240 So again, the segment level applies to all VMs by default, 39 01:48.240 --> 01:52.640 unless there's a more specific segment profile applied directly to a VM. 40 01:52.640 --> 01:56.240 The next thing I'd love to chat about is the types of segment profiles 41 01:56.240 --> 01:58.000 that we can use on our segment. 42 01:58.000 --> 02:01.680 And the first one is a quality of service segment profile. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 01:58.000 --> 02:01.680 And the first one is a quality of service segment profile. 43 02:01.680 --> 02:05.440 When you think of quality of service, think about applications like voice over 44 02:05.440 --> 02:05.840 IP 45 02:05.840 --> 02:09.360 or real-time voice applications that need to have priority treatment. 46 02:09.360 --> 02:12.000 If push comes to shove, there's not enough bandwidth in the network, 47 02:12.000 --> 02:14.640 we may want to give some traffic like voice traffic, 48 02:14.640 --> 02:17.040 higher preference to be forwarded through the network 49 02:17.040 --> 02:20.560 compared to some other application that can survive a few hundred milliseconds 50 02:20.560 --> 02:21.200 of latency 51 02:21.200 --> 02:25.040 or delay or jitter, like email or transferring a file 52 02:25.040 --> 02:28.240 or some other application like that that we wouldn't even notice the difference 53 02:28.240 --> 02:31.200 if there's slight latency in the delivery of those packets. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 53 02:28.240 --> 02:31.200 if there's slight latency in the delivery of those packets. 54 02:31.200 --> 02:34.640 So as an example, let's imagine that we have a computer right here. 55 02:34.640 --> 02:40.080 I'll call that PC and that is daisy-chain from an IP phone right here. 56 02:40.080 --> 02:42.640 And then that goes into a switch. 57 02:42.640 --> 02:45.600 We'll call that a layer two switch, which then goes down at some point to a 58 02:45.600 --> 02:46.720 logical router, 59 02:46.720 --> 02:49.040 which leads off to other points of the network. 60 02:49.040 --> 02:50.960 And let's go ahead and draw another router in there. 61 02:50.960 --> 02:53.040 And then I'll draw a cloud to represent the rest. 62 02:53.040 --> 02:57.120 And let's imagine that this PC is communicating with a server right here. 63 02:57.120 --> 03:00.880 And let's also imagine that there's a phone call being made over the IP network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 63 02:57.120 --> 03:00.880 And let's also imagine that there's a phone call being made over the IP network 64 03:00.880 --> 03:00.880 . 65 03:00.880 --> 03:05.120 And this phone could be either a physical phone or software that's being run 66 03:05.120 --> 03:06.720 for the voice over IP. 67 03:06.720 --> 03:10.800 And let's imagine the other phone is right here that's being called. 68 03:10.800 --> 03:14.080 So this will be phone number one up here and it'll be phone number two. 69 03:14.080 --> 03:16.560 And ideally, if everything's moving nice and smoothly, 70 03:16.560 --> 03:19.040 everything gets delivered, the voice of IP calls going great. 71 03:19.040 --> 03:20.800 There's not excessive latency there. 72 03:20.800 --> 03:24.430 However, if there's congestion in the network where there isn't enough 73 03:24.430 --> 03:25.680 bandwidth or throughput 74 03:25.680 --> 03:28.950 sent all the traffic in a timely manner, the network can be trained to pay 75 03:28.950 --> 03:29.760 attention 76 03:29.760 --> 03:34.800 to QoS quality of service markings inside the packets and the layer two headers WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 76 03:29.760 --> 03:34.800 to QoS quality of service markings inside the packets and the layer two headers 77 03:34.800 --> 03:34.880 . 78 03:34.880 --> 03:38.000 And then based on that, they can give preferential treatment to that. 79 03:38.000 --> 03:41.200 Think of it like having a grocery store with several checkout lanes. 80 03:41.200 --> 03:44.560 So these are checkout lanes one, two, and three. 81 03:44.560 --> 03:47.440 And let's imagine it's a slow day and there's not a whole bunch of people in 82 03:47.440 --> 03:47.680 line 83 03:47.680 --> 03:49.040 every checking out fairly quickly. 84 03:49.040 --> 03:53.120 But as it gets busy, which is a network world we could refer to as congestion, 85 03:53.120 --> 03:56.710 perhaps at these checkouts at the grocery store, we have this right here as a 86 03:56.710 --> 03:57.920 priority lane 87 03:57.920 --> 04:00.480 for people who are wearing blue hats. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 87 03:57.920 --> 04:00.480 for people who are wearing blue hats. 88 04:00.480 --> 04:03.280 So if you're wearing a blue hat, you can go to this priority lane and check out 89 04:03.280 --> 04:04.160 fairly quickly. 90 04:04.160 --> 04:07.520 And if you don't have a blue hat, you have to get into one of these other lanes 91 04:07.520 --> 04:07.520 . 92 04:07.520 --> 04:10.320 And so you get better service if you're in this lane right here. 93 04:10.320 --> 04:12.160 So let's imagine our router for a traffic. 94 04:12.160 --> 04:13.600 Let's imagine we have a little backup there. 95 04:13.600 --> 04:15.840 We have lots of packets that need to be sent. 96 04:15.840 --> 04:19.520 If we're implementing QoS, it's a lot like having a special lane that's looking 97 04:19.520 --> 04:20.240 for 98 04:20.240 --> 04:21.200 people with blue hats. 99 04:21.200 --> 04:24.400 Except this time we're looking for packets that have certain markings. 100 04:24.400 --> 04:28.080 Let's imagine that this packet right here and this packet right here have been 101 04:28.080 --> 04:29.200 given effectively 102 04:29.200 --> 04:30.400 a blue hat. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 102 04:29.200 --> 04:30.400 a blue hat. 103 04:30.400 --> 04:33.190 And when the router sees that traffic, it's going to go ahead and forward those 104 04:33.190 --> 04:33.680 first. 105 04:33.680 --> 04:36.320 And then all the other packets and frames that don't have a blue hat, 106 04:36.320 --> 04:39.630 they're going to be forwarded normally, which may include some additional 107 04:39.630 --> 04:40.080 latency. 108 04:40.080 --> 04:44.160 But at least we've identified our blue hat packets and have been able to 109 04:44.160 --> 04:45.520 forward them more quickly. 110 04:45.520 --> 04:47.280 And that's an example of using QoS. 111 04:47.280 --> 04:51.040 Now, instead of using hats, as we have over here in our checkout lines with IP 112 04:51.040 --> 04:51.920 packets 113 04:51.920 --> 04:54.080 and with layer two frames, we're going to do markings. 114 04:54.080 --> 04:58.160 So layer two that marking is referred to as COS class of service. 115 04:58.160 --> 05:03.120 And then at layer three, we have DSCP, which stands for differentiated services WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 115 04:58.160 --> 05:03.120 And then at layer three, we have DSCP, which stands for differentiated services 116 05:03.120 --> 05:03.760 code point. 117 05:03.760 --> 05:08.000 Think of it like just some special markings like a blue hat in the IP header. 118 05:08.000 --> 05:13.070 And all by themselves, those DSCP markings, for example, if we mark the packets 119 05:13.070 --> 05:14.000 as EAF, 120 05:14.000 --> 05:16.160 which in decimal is number 46. 121 05:16.160 --> 05:19.200 These routers, by default, don't care about looking at the IP header and 122 05:19.200 --> 05:20.800 looking for whatever markings 123 05:20.800 --> 05:24.960 might be there inside of the IP header representing expedited forwarding. 124 05:24.960 --> 05:28.480 So in addition to getting the correct markings on our traffic, for example, 125 05:28.480 --> 05:31.200 we can mark all of our voice traffic with EAF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 125 05:28.480 --> 05:31.200 we can mark all of our voice traffic with EAF. 126 05:31.200 --> 05:34.160 And to actually give that traffic preferential treatment as it gets routed 127 05:34.160 --> 05:35.120 through the network, 128 05:35.120 --> 05:39.210 each of these layer three router devices need to be trained that when there is 129 05:39.210 --> 05:39.760 congestion, 130 05:39.760 --> 05:43.840 they need to look at that layer three header information regarding DSCP. 131 05:43.840 --> 05:46.960 And then based on that information and how they've been programmed to go ahead 132 05:46.960 --> 05:47.200 and give 133 05:47.200 --> 05:48.800 preferential treatment to that. 134 05:48.800 --> 05:52.000 So how does this QoS that we've talked about in a network environment, 135 05:52.000 --> 05:54.000 how does that relate to segment profiles? 136 05:54.000 --> 05:58.880 And the answer is we can create a QoS segment profile. 137 05:58.880 --> 06:02.320 And with that segment profile applied, for example, right here to segment 10, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 137 05:58.880 --> 06:02.320 And with that segment profile applied, for example, right here to segment 10, 138 06:02.320 --> 06:05.360 which then would be inherited and applied here to the port that this VM is 139 06:05.360 --> 06:06.400 connected to segment 10 140 06:06.400 --> 06:08.560 with, we could then implement QoS. 141 06:08.560 --> 06:11.680 For example, if we wanted to go ahead and do certain markings at the layer 142 06:11.680 --> 06:12.320 three header for the 143 06:12.320 --> 06:16.160 benefit of the rest of the network to do expedited forwarding for that traffic, 144 06:16.160 --> 06:21.280 we could actually have our QoS profile on the segment inject that marking. 145 06:21.280 --> 06:24.240 So that way, if we have traffic that's entering the segment from a VM, 146 06:24.240 --> 06:27.440 we can with a QoS profile modify the markings. 147 06:27.440 --> 06:30.650 So as that traffic makes it out to the rest of the world and cross other WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 147 06:27.440 --> 06:30.650 So as that traffic makes it out to the rest of the world and cross other 148 06:30.650 --> 06:31.120 routers, 149 06:31.120 --> 06:33.760 if those other routers, if they've been trained to look at that IP header 150 06:33.760 --> 06:34.640 information 151 06:34.640 --> 06:38.110 and then do preferential forwarding based on that, they can go ahead and do 152 06:38.110 --> 06:38.400 that. 153 06:38.400 --> 06:42.790 Another cool thing we can do with a QoS segment profile is we can do bandwidth 154 06:42.790 --> 06:43.520 throttling. 155 06:43.520 --> 06:47.030 So even if we have, for example, one gig or maybe even 10 gig here on the 156 06:47.030 --> 06:47.520 segment, 157 06:47.520 --> 06:53.520 we could based on our QoS segment profile, we could limit the ingress or egress 158 06:53.520 --> 06:53.520 , 159 06:53.520 --> 06:57.590 which are fancy ways of saying inbound or outbound traffic for any of the VMs 160 06:57.590 --> 06:58.400 on that segment. 161 06:58.400 --> 07:02.480 So if we wanted to limit, for example, the maximum bandwidth that any single VM WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 161 06:58.400 --> 07:02.480 So if we wanted to limit, for example, the maximum bandwidth that any single VM 162 07:02.480 --> 07:03.120 would use, 163 07:03.120 --> 07:06.960 we could include that in a QoS segment profile, apply that to the segment, and 164 07:06.960 --> 07:07.920 boom, we've just 165 07:07.920 --> 07:11.370 limited HVM connected to that segment, and they're going to be constrained as 166 07:11.370 --> 07:12.160 far as how fast they 167 07:12.160 --> 07:16.490 can forward traffic based on the settings in our QoS segment profile. All right 168 07:16.490 --> 07:16.960 , so with that 169 07:16.960 --> 07:20.160 cleaned up, let me go ahead and do a little quick note there that QoS is one of 170 07:20.160 --> 07:21.200 our segment profile 171 07:21.200 --> 07:27.040 types. Another type is a segment profile called IP Discovery. And unlike a QoS 172 07:27.040 --> 07:27.680 segment profile, 173 07:27.680 --> 07:31.950 which is not applied to our segment's by default, there is a default IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 173 07:27.680 --> 07:31.950 which is not applied to our segment's by default, there is a default IP 174 07:31.950 --> 07:32.720 Discovery 175 07:32.720 --> 07:36.930 segment profile applied to all of our segments. And the reason that's important 176 07:36.930 --> 07:38.080 is because NSX is 177 07:38.080 --> 07:43.650 using a lot of information based on that IP Discovery profile that NSX can use 178 07:43.650 --> 07:44.160 for making the 179 07:44.160 --> 07:48.080 network work better. For example, an IP Discovery segment profile is going to 180 07:48.080 --> 07:49.440 be doing DHCP snooping. 181 07:49.440 --> 07:53.460 Think of it like eavesdropping, looking at all the DHCP traffic going back and 182 07:53.460 --> 07:54.000 forth between 183 07:54.000 --> 07:58.480 clients and their DHCP server, or in the case of a DHCP relay between the VM 184 07:58.480 --> 07:59.440 and the relay. 185 07:59.440 --> 08:03.840 And it's using that to learn the layer three and layer two address mappings of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 185 07:59.440 --> 08:03.840 And it's using that to learn the layer three and layer two address mappings of 186 08:03.840 --> 08:04.880 each of the VMs. 187 08:04.880 --> 08:08.400 It's also doing ARP snooping as well, paying attention to the ARP messages 188 08:08.400 --> 08:09.040 being sent back and 189 08:09.040 --> 08:12.900 forth from the VMs and building that into a table. And if you're running IP 190 08:12.900 --> 08:13.920 version six, 191 08:13.920 --> 08:18.850 it's also building tables based on neighbor discovery, which is used by IPV six 192 08:18.850 --> 08:19.360 , including 193 08:19.360 --> 08:24.560 things like router advertisements and neighbor advertisements and so forth. And 194 08:24.560 --> 08:25.360 also as part of 195 08:25.360 --> 08:29.390 an IP Discovery segment profile, including the default one that's applied to 196 08:29.390 --> 08:30.240 our segments, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 196 08:29.390 --> 08:30.240 our segments, 197 08:30.240 --> 08:34.390 it's also leveraging VMware tools that's running on the VMs to report 198 08:34.390 --> 08:36.080 information about that specific 199 08:36.080 --> 08:40.500 VM. Now the benefit of NSX having all this information, it can do things like 200 08:40.500 --> 08:42.000 ARP suppression. So if 201 08:42.000 --> 08:47.420 this little VM here is running on ESXIA, and this little VM here is running on 202 08:47.420 --> 08:48.960 ESXIB, two different 203 08:48.960 --> 08:53.280 hosts. Let's imagine it's the 10 network here. So this is 10 dot 10 dot 0 dot 204 08:53.280 --> 08:54.560 150. And this is 205 08:54.560 --> 08:59.130 dot 151. If this client needs to communicate with that second host on the same 206 08:59.130 --> 08:59.600 subnet, 207 08:59.600 --> 09:02.490 when it does an ARP request, instead of that ARP request actually being WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 207 08:59.600 --> 09:02.490 when it does an ARP request, instead of that ARP request actually being 208 09:02.490 --> 09:04.240 forwarded as a broadcast 209 09:04.240 --> 09:09.380 over to ESXIB, NSX, who knows, due to the IP Discovery segment profile that's 210 09:09.380 --> 09:10.240 in place, 211 09:10.240 --> 09:16.100 it knows the layer two addresses and the IP addresses. And as a result, ESXIA, 212 09:16.100 --> 09:16.960 which is a transport 213 09:16.960 --> 09:20.070 node, can actually respond back to that VM saying, Oh, here's your response to 214 09:20.070 --> 09:21.120 that ARP request or 215 09:21.120 --> 09:24.770 IPV six, it can respond back with the information that the client was 216 09:24.770 --> 09:26.400 requesting without sending that 217 09:26.400 --> 09:30.520 traffic over the tunnel over the network. So we're able to suppress a lot of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 217 09:26.400 --> 09:30.520 traffic over the tunnel over the network. So we're able to suppress a lot of 218 09:30.520 --> 09:31.440 that ARP and neighbor 219 09:31.440 --> 09:35.650 discovery traffic from ever leaving the host, because that information gleaned 220 09:35.650 --> 09:36.560 via an IP Discovery 221 09:36.560 --> 09:40.410 segment profile has collected all that information. And as a result, we don't 222 09:40.410 --> 09:41.200 have to actually send 223 09:41.200 --> 09:45.170 those broadcast other types of requests across the network. We can feed it 224 09:45.170 --> 09:46.880 directly back from NSX 225 09:46.880 --> 09:49.960 without ever bothering the remote host. All right, let's clean that up a little 226 09:49.960 --> 09:51.280 bit. So that's two 227 09:51.280 --> 09:55.650 of our segment profiles. Let's go ahead and talk about a third for our third 228 09:55.650 --> 09:56.880 segment profile. 229 09:56.880 --> 10:01.590 It's called spoof guard. So behind the scenes, NSX, it knows about VMS IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 229 09:56.880 --> 10:01.590 It's called spoof guard. So behind the scenes, NSX, it knows about VMS IP 230 10:01.590 --> 10:02.640 addresses, there are 231 10:02.640 --> 10:06.160 layer two addresses got a lot of that information from the IP Discovery, 232 10:06.160 --> 10:07.360 including the use of VMware 233 10:07.360 --> 10:12.200 tools to report that. And in the event that this VM right here, which is at 10. 234 10:12.200 --> 10:14.000 10.0.150, 235 10:14.000 --> 10:18.510 let's imagine someone at this VM attempts to at that VM with the guest OS, 236 10:18.510 --> 10:20.080 change its IP address. 237 10:20.080 --> 10:24.670 So instead of being 10 10 0 150, which was all learned via IP Discovery, now 238 10:24.670 --> 10:25.520 the user changes it 239 10:25.520 --> 10:31.420 to 10.10.0.151. Well, if the user does that, what spoof guard is going to do, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 239 10:25.520 --> 10:31.420 to 10.10.0.151. Well, if the user does that, what spoof guard is going to do, 240 10:31.420 --> 10:31.920 if it's enabled, 241 10:31.920 --> 10:34.840 it's going to say, you know what, you're not allowed to go ahead and change 242 10:34.840 --> 10:35.760 your IP address. 243 10:35.760 --> 10:40.060 I already know says NSX what that IP address slash Mac combination is for the V 244 10:40.060 --> 10:40.960 land that you're in. 245 10:40.960 --> 10:44.600 So if the user tries to change their address with spoof guard, because NSX 246 10:44.600 --> 10:46.000 knows the IP address 247 10:46.000 --> 10:49.210 is involved because of the snooping and the Mac address is involved, it's going 248 10:49.210 --> 10:49.520 to say, 249 10:49.520 --> 10:52.480 you know what, you can't change that IP address. Or maybe you can try to change 250 10:52.480 --> 10:53.040 your IP address to 251 10:53.040 --> 10:57.120 the guest OS, maybe they'll let you. But as a function of spoof guard, I'm not 252 10:57.120 --> 10:57.600 going to let you 253 10:57.600 --> 11:00.830 send any packets into the network. If you're trying to come from an IP address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 253 10:57.600 --> 11:00.830 send any packets into the network. If you're trying to come from an IP address 254 11:00.830 --> 11:01.840 that's not the one 255 11:01.840 --> 11:04.650 that I believe you have. All right, let me clean that up just a little bit. And 256 11:04.650 --> 11:05.120 let's talk about 257 11:05.120 --> 11:09.120 yet another type of segment profile. And the next type of segment profile like 258 11:09.120 --> 11:09.760 to chat about is 259 11:09.760 --> 11:14.260 called a segment security profile, or the full name would be a segment security 260 11:14.260 --> 11:15.120 segment profile. 261 11:15.120 --> 11:19.440 In either case, with a segment security profile, we can protect against several 262 11:19.440 --> 11:20.480 things in our network, 263 11:20.480 --> 11:24.560 and some are related to spanning tree protocol. So for example, this VM right 264 11:24.560 --> 11:26.240 here has absolutely 265 11:26.240 --> 11:30.940 no need to receive any type of bridge protocol data units. We can simply do WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 265 11:26.240 --> 11:30.940 no need to receive any type of bridge protocol data units. We can simply do 266 11:30.940 --> 11:32.080 filtering as part 267 11:32.080 --> 11:36.890 of the segment security segment profile and specify that we want to filter and 268 11:36.890 --> 11:38.080 not send BPDs 269 11:38.080 --> 11:42.110 down to our VMs. So we'll save a little bit of bandwidth in doing that. Also, 270 11:42.110 --> 11:43.120 if we have an attacker 271 11:43.120 --> 11:48.190 on one of our segments, we probably don't want to be sending in STP information 272 11:48.190 --> 11:49.200 , including bridge 273 11:49.200 --> 11:53.000 protocol data units to a hacker who may want to use that information to try to 274 11:53.000 --> 11:53.840 compromise our 275 11:53.840 --> 11:57.960 network at layer two. Another element as part of a segment security segment 276 11:57.960 --> 11:59.520 profile is regarding 277 11:59.520 --> 12:03.760 dynamic host configuration protocol. So let's imagine we have this VM right WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 277 11:59.520 --> 12:03.760 dynamic host configuration protocol. So let's imagine we have this VM right 278 12:03.760 --> 12:04.880 here that one day, 279 12:04.880 --> 12:09.370 either somebody either accidentally or intentionally is using some tools, 280 12:09.370 --> 12:11.360 trying to become or act as 281 12:11.360 --> 12:15.990 a DHCP server. So when this client, if it's got the as a DHCP client, it sends 282 12:15.990 --> 12:16.800 a discover message 283 12:16.800 --> 12:20.230 to the network. If this device right here, if it's acting as a DHCP server, 284 12:20.230 --> 12:21.600 could send an offer. 285 12:21.600 --> 12:25.430 And if we trick this VM into taking the offer from this VM right here from the 286 12:25.430 --> 12:26.480 attacker machine, 287 12:26.480 --> 12:30.880 or if it's accidental from the accidental user here, we could totally give the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 287 12:26.480 --> 12:30.880 or if it's accidental from the accidental user here, we could totally give the 288 12:30.880 --> 12:31.600 wrong information 289 12:31.600 --> 12:35.390 regarding IP address, default gateway, DNS, etc. And if it's an attacker and 290 12:35.390 --> 12:36.160 that attacker is 291 12:36.160 --> 12:39.940 malicious, the attacker could intentionally give this VM incorrect information 292 12:39.940 --> 12:40.400 saying, 293 12:40.400 --> 12:44.950 Hey, if they're DNS server, use me or for your default gateway, use me. And at 294 12:44.950 --> 12:46.000 that point, 295 12:46.000 --> 12:50.130 all the traffic can be going through this attacker VM before 40 out to the rest 296 12:50.130 --> 12:50.800 of the network. 297 12:50.800 --> 12:54.160 And that would create a man in the middle attack. So if we want to prevent that 298 12:54.160 --> 12:54.400 , if we want to 299 12:54.400 --> 12:58.600 prevent DHCP server messages, we can do that as part of a segment security 300 12:58.600 --> 12:59.760 segment profile. 301 12:59.760 --> 13:04.320 And by default, filtering DHCP server messages are already included in the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 301 12:59.760 --> 13:04.320 And by default, filtering DHCP server messages are already included in the 302 13:04.320 --> 13:05.600 default segment security 303 13:05.600 --> 13:08.950 segment profile that's applied to all of our segments. Now, one thing that that 304 13:08.950 --> 13:09.680 does not apply 305 13:09.680 --> 13:14.630 to is if we have DHCP relay setup, where we have our gateway, for example, that 306 13:14.630 --> 13:15.680 's taking our DHCP 307 13:15.680 --> 13:19.410 request and forwarding that to the real DHCP server, even if we're filtering 308 13:19.410 --> 13:20.800 DHCP server messages, 309 13:20.800 --> 13:23.750 the actual relay function is still going to work fine right here on this 310 13:23.750 --> 13:24.320 segment. 311 13:24.320 --> 13:29.280 So the default behavior of stopping any DHCP server type messages that weren't 312 13:29.280 --> 13:30.080 sourced from WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 312 13:29.280 --> 13:30.080 sourced from 313 13:30.080 --> 13:34.320 NSX itself, or weren't going through an appropriate relay, those server decline 314 13:34.320 --> 13:34.880 messages are going 315 13:34.880 --> 13:39.200 to be blocked to protect against devices like this one becoming a rogue or 316 13:39.200 --> 13:40.880 unauthorized DHCP server. 317 13:40.880 --> 13:44.880 And another component of a segment security profile would be router 318 13:44.880 --> 13:46.320 advertisement information. 319 13:46.320 --> 13:50.450 So just like we don't want this VM right here to start advertising itself as a 320 13:50.450 --> 13:51.680 DHCP server and 321 13:51.680 --> 13:56.240 giving out DHCP offers, we also don't want this device right here to try to 322 13:56.240 --> 13:57.280 trick the network with 323 13:57.280 --> 14:01.040 router advertisements for IPv6 to try to trick the network that this device WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 323 13:57.280 --> 14:01.040 router advertisements for IPv6 to try to trick the network that this device 324 14:01.040 --> 14:02.160 right here in its IP 325 14:02.160 --> 14:06.390 address is a valid router on that segment. And the fifth segment profile I'd 326 14:06.390 --> 14:07.200 love to chat with you 327 14:07.200 --> 14:10.800 about is Mac Discovery. So let's imagine this VM right here. And let's also 328 14:10.800 --> 14:11.440 just realize that 329 14:11.440 --> 14:14.590 there's IP Discovery involved with an IP Discovery segment applied to this 330 14:14.590 --> 14:16.000 segment by default. And so 331 14:16.000 --> 14:19.950 NSX knows all about the layer two address of this VM and as the layer three 332 14:19.950 --> 14:21.520 address of this VM. 333 14:21.520 --> 14:26.120 However, what if this VM needs to go ahead and change their layer two address? 334 14:26.120 --> 14:26.720 Well, as part of 335 14:26.720 --> 14:30.800 a Mac Discovery profile, if we configure one that allows the user to change WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 335 14:26.720 --> 14:30.800 a Mac Discovery profile, if we configure one that allows the user to change 336 14:30.800 --> 14:31.840 their Mac address, 337 14:31.840 --> 14:35.390 then that user in the guest OS can change their layer two address and the NSX 338 14:35.390 --> 14:36.240 segment will continue 339 14:36.240 --> 14:39.650 to allow frames from that new layer two address, even though it wasn't the one 340 14:39.650 --> 14:40.960 originally configured 341 14:40.960 --> 14:45.930 on that VM. Another function of a Mac Discovery segment profile is the learning 342 14:45.930 --> 14:47.120 of Mac addresses. 343 14:47.120 --> 14:50.840 And I'm putting that in plural right there because perhaps on this VM, we have 344 14:50.840 --> 14:51.920 not only this VM's 345 14:51.920 --> 14:54.940 network interface card with its own layer two address, but also maybe we're 346 14:54.940 --> 14:56.320 running some function 347 14:56.320 --> 15:01.660 or proxy service inside that VM, which includes yet a second or a third or more WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 347 14:56.320 --> 15:01.660 or proxy service inside that VM, which includes yet a second or a third or more 348 15:01.660 --> 15:02.640 layer two addresses 349 15:02.640 --> 15:05.880 that are going to be coming into the segment via this VM's network interface 350 15:05.880 --> 15:06.720 card. Well, if we 351 15:06.720 --> 15:09.920 want to allow that to happen and allow those additional sources for the layer 352 15:09.920 --> 15:11.040 two addresses to be sent 353 15:11.040 --> 15:14.670 into the segment, we can use a Mac Discovery segment profile either applied to 354 15:14.670 --> 15:15.680 the segment itself or 355 15:15.680 --> 15:20.050 applied directly to the VM as an override to allow multiple layer two addresses 356 15:20.050 --> 15:21.120 to be coming in 357 15:21.120 --> 15:25.360 from that single VM NIC. Also, while we're right here talking about profiles, 358 15:25.360 --> 15:26.320 let's also talk about 359 15:26.320 --> 15:29.840 one other profile that's not specifically a segment profile, but it's pretty 360 15:29.840 --> 15:31.200 important to be aware WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 360 15:29.840 --> 15:31.200 important to be aware 361 15:31.200 --> 15:35.520 and it's called an edge bridge profile. And an edge bridge profile can come in 362 15:35.520 --> 15:37.040 super handy if 363 15:37.040 --> 15:41.770 we need to merge or bridge, for example, a overlay segment like this network 10 364 15:41.770 --> 15:42.320 10 zero, 365 15:42.320 --> 15:46.480 which is on this non VRF segment right here off of this T1 gateway. And let's 366 15:46.480 --> 15:47.360 say we need to have 367 15:47.360 --> 15:50.700 these VMs right here, we'll call them VM number one and VM number two. And let 368 15:50.700 --> 15:51.440 's also imagine we 369 15:51.440 --> 15:55.010 have a VLAN over here. And we have a couple more computers over here on the 370 15:55.010 --> 15:56.000 physical network. 371 15:56.000 --> 15:59.400 So this could be computer three and computer four. And let's say we want to 372 15:59.400 --> 16:00.800 have these two devices WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 372 15:59.400 --> 16:00.800 have these two devices 373 16:00.800 --> 16:05.870 also logically be on that same network segment. So this is VLAN based on our 374 16:05.870 --> 16:06.720 physical network. 375 16:06.720 --> 16:10.000 And this is our overlay segment. So how do we bridge those two together? And 376 16:10.000 --> 16:10.560 the answer is, 377 16:10.560 --> 16:14.210 I'm going to color code this, we're going to use an edge bridge profile that 378 16:14.210 --> 16:14.800 basically says, 379 16:14.800 --> 16:18.100 you know what, for this segment right here, and for this VLAN, let's go ahead 380 16:18.100 --> 16:18.800 and call this say, 381 16:18.800 --> 16:23.220 say, let's say, for example, VLAN 25, we can use an edge bridge profile and 382 16:23.220 --> 16:24.560 logically bridge those 383 16:24.560 --> 16:27.470 together. Now behind the scenes, it's our edge transport nodes that are doing 384 16:27.470 --> 16:28.320 the actual bridging 385 16:28.320 --> 16:32.810 of that traffic from this network segment, the 1010 zero up here on this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 385 16:28.320 --> 16:32.810 of that traffic from this network segment, the 1010 zero up here on this 386 16:32.810 --> 16:33.840 overlay segment 387 16:33.840 --> 16:37.430 down to this VLAN. So if we want these computers to talk, we need to use IP 388 16:37.430 --> 16:38.640 addresses over here 389 16:38.640 --> 16:42.720 in that same address space of 10 dot 10. So if we had D should be services 390 16:42.720 --> 16:43.360 right here, 391 16:43.360 --> 16:47.600 being provided by tier one gateway A for the segment, and we set up the bridge, 392 16:47.600 --> 16:47.920 we could 393 16:47.920 --> 16:51.170 actually have these clients act as D should be clients. And they could actually 394 16:51.170 --> 16:52.080 get IP addresses 395 16:52.080 --> 16:56.480 from the D should be services over here, because logically, it's like one giant 396 16:56.480 --> 16:57.520 layer two broadcast 397 16:57.520 --> 17:01.310 domain, which includes this segment here and this VLAN here. And again, that's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 397 16:57.520 --> 17:01.310 domain, which includes this segment here and this VLAN here. And again, that's 398 17:01.310 --> 17:02.400 pulled off by using an 399 17:02.400 --> 17:03.840 edge bridge profile.