NSX VLAN DHCP
In this blog I am going to start referring NSX-T as NSX since that is now the official name.
https://blogs.vmware.com/partnernews/2022/04/nsx-data-center-name-change.html
So it is quite common to use DHCP when deploying workloads to provide IP addressing and in NSX land is provided by a DHCP server that runs on an Edge Transport Node.
DHCP for overlay segments is quite straight forward so I will quickly cover the requirements, however the main crux of the article are little gotcha that will prevent DHCP from being advertised on the network, and thus prevent workloads acquiring a network address. By default for VLAN networks NSX security will block and broadcasting of DHCP services.
So as normal we will have our DHCP server configured and assigned to an Edge Cluster
NSX DHCP Server
Our basic DHCP configuration is created on our NSX VLAN Segment
VLAN Segment DHCP Configuration
Now at this stage you expect DHCP to be available, however this is not the case for VLAN based DHCP as it will get blocked based on the default Segment Security and needs to be updated.
Segment Security
If we take a look at the default Segment Security Profile we can see that DHCP Server Block and Server Block – IPv6 is enabled.
Default Segment Security
We need to create a new Segment Security Profile with these two options disabled and then apply it to the VLAN segment
New Segment Security
Applied Segment Security
So to validate that DHCP is working as expect obviously the easiest thing to check is whether or our test VM actually gets a DHCP lease, however we can also see this process on the Edge Transport Node by doing a packet capture on the fast path interfaces.
In the following example I am doing a packet capture on fp-eth0 on the primary Edge Transport Node and we can see the lease request.
transport-edge-06> set capture session 0 interface fp-eth0 direction dual
transport-edge-06> set capture session 0 expression vlan 600
08:50:48.332308 00:50:56:a3:62:08 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 600, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:50:56:a3:62:08, length 300
08:50:48.332308 00:50:56:a3:62:08 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 600, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:50:56:a3:62:08, length 300
08:50:48.362746 00:50:56:a3:62:08 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 600, p 0, ethertype ARP, Request who-has 192.16.60.1 tell 192.16.60.2, length 46
DHCP Recieved
If we look at the Edge Transport Node Cluster we can also see the lease applied to the test VM.
Edge Transport DHCP Lease
While DHCP is not the most fascinating of topics and in my experience, for VLANs it is done external to NSX via TOR SVIs, Windows / Linux servers, Core Routing etc, however I think it is about time that we start thinking of where the network broadcast is coming from to provide DHCP, and like all good things in NSX we can keep it local to the infrastructure especially if your running HPE / Cisco / <enter vendor here> chassis that have fabric networking. An excellent example of the use for DHCP is in the use of TKG, where DHCP is required for Worker Node IP assignment. So ditch your old deprecated VLAN DHCP and move to NSX !.