We recently released a new Dynamic Host Configuration Protocol (DHCP) Relay feature for VMware Cloud on AWS. Discover how the DHCP upgrade allows for more sophisticated IP Address Management for virtual desktops and more, whether on-prem or in the cloud.
.terminal {
border: 1px grey dashed;
padding: 10px;
background-color: whiteSmoke;
color: black;
font-family: “Lucida Console”, Monaco, monospace;
font-size: small;
line-height: 1.5;
}
This blog post will focus on DHCP (Dynamic Host Configuration Protocol) on VMware Cloud on AWS and the benefits provided by the recently-released DHCP Relay feature.
First, you might want to read Humair‘s post on NSX releases on VMC 1.7– he covers some aspects of DHCP Relay but I just wanted to provide a bit more details for those not familiar with the concept.
Second, you might want to read (or re-read) my Internal Networking on VMware Cloud on AWS post.
By default, VMware Cloud on AWS comes with its own DHCP server. It’s a functionality NSX has offered for a while now. When you launch your VMC SDDC, we integrate a NSX DHCP Server and attach it to the Compute Gateway (CGW).11
The integrated NSX DHCP Server is fine and you can do the bare minimal which is specifying the DHCP range you want to offer to your VMs. The default gateway is also known as it’s how you define the segment IP range in the VMC console.
While this is fine for many of our customers, we also needed to provide:
- More sophisticated IP Address Management (IPAM) functionalities for virtual desktops (as this use case is extremely popular on VMware Cloud on AWS)
- Consistency with existing IPAM infrastructure (customers wanted to manage a single DHCP server).
Based on customer feedback, we’ve now released the DHCP Relay feature which helps customers forward DHCP requests to a 3rd party DHCP server.
How does DHCP Relay work?
DHCP Relay tends to work in a consistent manner regardless of whether you’re using VMware Cloud on AWS, VMware or a physical infrastructure.
In our example below, we have a couple of VMs attached to a router acting as a DHCP relay. The screenshots and packet captures below are from a VMware Cloud on AWS environment (and the DHCP Server is actually on a different continent from the VMware Cloud on AWS VMs) but this should apply anywhere.
The sequence of events is roughly the following:
- Blue VM boots up and looks out for a DHCP server via a DHCP Discovery (“I need an IP !! Somebody out there, please! I feel naked without one.”)
Source: 0.0.0.0 Destination: 255.255.255.255 UDP 67 DHCP Discover
- DHCP Relay forwards the DHCP Discovery to DHCP server specified in the DHCP Relay configuration (“Hang in there, Blue VM – I’ll forward your request to this great DHCP server I know. Its IP is 172.20.0.129.”).
Source: 172.30.118.1 Destination: 172.20.0.129 UDP 67 DHCP Discover
- DHCP server proposes an IP back (DHCP Offer) to DHCP Relay who sends it back to Blue VM (“I have this great IP for you, Blue VM – please confirm if you want it otherwise I will give it to your nemesis Orange VM”).
Source: 172.20.0.129 Destination: 172.30.118.1 UDP 67 DHCP Offer (172.30.118.11/24)
- Blue VM confirms it wants this IP by sending a DHCP Request to DHCP Relay who sends it back to the DHCP Server (“How did you know 172.30.118.11 was the IP I had my heart set on? Thank you, DHCP Server, I will happily take this IP. Go to hell, Orange VM”)
Source: 172.30.118.1 Destination: 172.20.0.129 UDP 67 DHCP Request (172.30.118.11)
- DHCP Server acknowledges good reception of the DHCP Request and sends a DHCP ACK back to DHCP Relay who forwards it back to Blue VM (“I’m glad I can be of help, Blue VM. By the way, I don’t like Orange VM either.”)
Source: 172.20.0.129 Destination: 172.30.118.1 UDP 67 DHCP ACK
And if you really want to know how that works, there’s no better way than to look at the actual packets. The gallery below shows the 8 DHCP packets exchanged in the process.
How does DHCP Relay work on VMware Cloud on AWS?
We’ve added a DHCP option in the recent 1.7 release in the Networking and Security Tab in the VMware Cloud on AWS console.
In our lab below, we’ve set up a DHCP Relay with the 172.20.0.129. Remember to “Attach to Compute Gateway”.
You cannot use the NSX DHCP Server and a 3rd Party DHCP. It’s one or the other. So make sure you don’t have any “DHCP Enabled” network segments before enabling DHCP relay. Otherwise you will get this error message:
You can specify one or multiple DHCP servers (it will try to reach the first one and if it does not respond, it will move onto the next one).
As I mentioned before, in my scenario, the DHCP Server is on-prem and we are communicating with it over a route-based VPN.
As Humair mentioned in his blog, you could use a DHCP Server on-prem, in the Connected VPC or even within VMware Cloud on AWS. We just need IP connectivity and UDP ports 67/68 open to allow the DHCP traffic through.
Next thing you need to do is create the subnet in the “Segments” page with the “DHCP Enabled” option and specify the DHCP range. It might feel a bit counter-intuitive but that’s the way we have done it today (it will be clarified in the future).
Make sure you have your DHCP lease set up on your DHCP server.
And then you’re good to go! Spin up a VM. This one has no IP once I release the DHCP lease.
Once I start the DHCP process, the sequence of events described in the previous section occurs and you can see the allocated IP address.
On my DHCP server, 172.30.118.11 is allocated as we expect. What actually happens is that the DHCP Server receives a request coming from 172.30.118.1 (the DHCP Relay’s IP) and will then allocate an IP from that subnet to the end user.
This is what it looks like in a 12-seconds video:
I hope this post was helpful. Thanks for reading!
