Loading...

Custom DHCP support in Azure

Custom DHCP support in Azure

Dynamic Host Configuration Protocol (DHCP) is a network protocol used to dynamically assign IP addresses and other network parameters to devices on a network.  

 

ipconfig-all.png

 

How DHCP works

 

The DORA process

 

When a device joins a network, it sends a broadcast message requesting an IP address. A DHCP server on the network captures this message and responds by providing an available IP address and other necessary network configuration parameters, such as subnet mask and default gateway.

DORA (Discover, Offer, Request, Acknowledge) is the four-step process used by DHCP for communication between DHCP servers and clients. The communication is carried out using the UDP transport protocol and ports 67 and 68.

 

DORA.png

 

In the Discovery stage: The DHCP client searches for a DHCP server. The DHCP client broadcasts a DHCPDISCOVER message and only DHCP servers respond to the message.

The Offer stage consists for a DHCP Server to offer an unassigned IP address (selected from a pre-defined pool) to the DHCP client, along with other config parameters for a given amount of time (lease time).

During the Request stage, the DHCP client selects an IP address in the case for example of multiple DHCP servers answering to its discover message and broadcasts to each DHCP server a DHCPREQUEST message containing the selected IP address.

The Ack phase is when the DHCP server acks the IP address selected by the client.

 

Lease renewal

 

When an IP address is automatically assigned, there is also a time limit for that assignment, the lease time, which applies to other network configuration parameters as well.

To continue using the same IP address and network parameters, the device must request a new DHCP lease before the lease time expires. If the lease is not renewed, the IP address may be assigned to another device on the network. 

 

DORA-renewal.png

When the IP address lease reaches 50% (T1), the DHCP client automatically sends a DHCP Request message to the DHCP server to renew the IP address lease. If a DHCP ACK message is received, the IP address lease is successfully renewed. If a DHCP NAK message is received, the DHCP client re-initiates the renewal procedure.

When the IP address lease reaches 87.5% (T2), if the DHCP client has not received a DHCP ACK message yet, it broadcasts a DHCP Request message to renew its IP address lease. If a DHCP ACK message is received, the IP address lease is successfully renewed. If a DHCP NAK message is received, the DHCP client re-initiates the renewal procedure.

If the DHCP client receives no response before the IP address lease expires, the DHCP client stops using the current IP address and sends a DHCP Discover message to request a new IP address.

 

DHCP Relay

 

In larger enterprises where there are multiple subnets or VLANs, having a DHCP server per subnet would become difficult to manage. DHCP Relay is used when the DHCP server and the DHCP client are not on the same subnet.

A DHCP Relay allows a DHCP client to obtain an IP address lease from a DHCP server that is not on the same subnet by intercepting and forwarding DHCP messages between DHCP clients and DHCP servers.

 Using a central DHCP server with local DHCP Relays also provides better control and visibility over the network, as all IP address leases are managed from a single location.

 

DHCP-relay.png

 

DHCP renewal with Relay

 

After understanding the initial DORA process facilitated by DHCP Relay in almost all customer environments, let's delve into what happens during the renewal phase.


DHCP-relay-renewal.png

 

At T1 (50% of the overall lease time), the client sends a renewal request directly to the DHCP server (unicast, port 68-67), bypassing the Relay agent.
At T2 (87.5% of the lease time), the Relay agent intercepts the client's renewal request and forwards it to the DHCP server (unicast, port 67-67).


It's also worth noting that the source port differs during these two stages

 

 

How DHCP works in Azure natively

 

Azure natively provides DHCP services to all virtual networks created within an Azure subscription. The DHCP service is automatically enabled for each virtual network.

A native service running on Azure hypervisors is taking care of the DHCP functions for a given virtual network.

 

dhcp-in-azure.png

 

Historical custom DHCP limitations in Azure

 

Until recently, the official stance on custom DHCP services in Azure was that they were not supported neither for providing IP addresses to on-premises clients nor for Azure virtual machines deployed in an Azure virtual network.

 

DHCP traffic has indeed faced 2 main limitations in Azure:

  1. Broadcast traffic is not supported in Azure. Since many aspects of the DHCP protocol rely on broadcast messages in the direct client-server model, any DHCP packet sent to Azure will fail delivery. As a result, direct client to  server communication cannot be honored in Azure.broadcast-not-supported.png
  2. While the DHCP-relay based solution may seem like a convenient alternative due to its unicast packet transmission, its effectiveness is limited by historical rate-limiting of DHCP Relay traffic in Azure.

dhcp-throttling.png

 

Previously, different workarounds were proposed to customers who required custom DHCP solutions in Azure due to the lack of support for such solutions:

  1. custom DHCP deployed in Azure VMware Solution (AVS), as AVS does not rate-limit DHCP relay traffic.avs-workaround.png

     

  2. using an IPSec tunnel between the DHCP Relay and the DHCP server, which hides the relayed traffic from the Azure platform.tunneling-workaround.png

Current status

 

Recently, rate-limiting for DHCP relayed traffic has been removed, enabling the support of the DHCP-relay based solution in Azure.

throttling removed.png

 

Limitations:

 

  1. Any custom DHCP server in Azure deployed before the rate-limiting removal may have to be redeployed.
  2. Only UDP 67 > 67 / UDP 68 > 68 has been unblocked. UDP 68 > 67 is still throttled and UDP 67 > 68 (the return) is blocked. Therefore, there will still be NO support for the T1 DHCP Renewals, only T2 renewals will come through.

t1-not-supported.png

 

Please note that this is not expected to affect in any way the successfulness of the DHCP renewal process.

azure-doc.png

Published on:

Learn more
Azure Networking Blog articles
Azure Networking Blog articles

Azure Networking Blog articles

Share post:

Related posts

Improve security posture in Azure service connections with AzurePipelinesCredential

Learn about the new AzurePipelinesCredential, designed to support federated identity credential authentication through Azure Service Connectio...

1 hour ago

Join us in July for Securing AI Apps on Azure!

Join us in July for a series of free live-streams sharing best practices for securing your AI apps on Azure. You'll learn about managed id...

9 hours ago

Announcing Azure Monitoring Agent support in Azure Landing Zones

Introduction   Hello and welcome to another blog post about Azure Landing Zones, the best practice framework for accelerating your cloud...

3 days ago

Out-of-band updates to address Azure Synapse SQL issue caused by Windows updates

Microsoft has issued an out-of-band update to resolve an issue with Azure Synapse SQL Serverless Pool databases entering a "Recovery pending" ...

3 days ago

[Mitigated] Azure Lab Services - Lab Plan Outage

Azure Lab Service is experiencing an outage that is affecting Lab Plans, but not Lab Accounts. This outage intermittently impacts all operatio...

3 days ago

Azure Lab Services Tutorial Video

This is a complete tutorial about Azure Lab Services' features. It walks through the steps of setting up a Lab Account, creating a Lab, and ac...

3 days ago

What's new in the Azure Lab Services

This is a presentation highlighting the new features introduced in the latest preview for Azure Lab Services.

3 days ago
Stay up to date with latest Microsoft Dynamics 365 and Power Platform news!
* Yes, I agree to the privacy policy