Every device that joins a network needs an IP address, a subnet mask, a default gateway, and usually a DNS server address. Configuring these manually on hundreds or thousands of devices is impractical and error-prone. DHCP (Dynamic Host Configuration Protocol) solves this by automatically handing out this information to devices as they connect.
This article covers DHCP from first principles, focusing specifically on the DHCP client role (a device requesting an address) and the DHCP relay role (a router forwarding DHCP requests across subnet boundaries), with full Cisco configuration, verification, Linux examples, and a Python automation example.
The Core Problem DHCP Solves
Without DHCP, an administrator would have to visit every single device and manually type in an IP address, ensuring no two devices ever get the same one. DHCP automates this entirely: a device “asks” the network for an address, and a DHCP server “answers” with one, along with all the other configuration details it needs.
The DHCP Process: DORA
DHCP address assignment happens in four steps, often remembered by the acronym DORA:
- Discover — the client broadcasts a request: “Is there a DHCP server out there?”
- Offer — a DHCP server responds with an offered IP address and configuration.
- Request — the client broadcasts back, “I accept this offer” (broadcast so other DHCP servers know their offers were declined).
- Acknowledge — the server confirms the lease with a DHCPACK.
sequenceDiagram
participant Client
participant DHCP Server
Client->>DHCP Server: DHCPDISCOVER (broadcast)
DHCP Server-->>Client: DHCPOFFER (IP + config)
Client->>DHCP Server: DHCPREQUEST (broadcast, accept offer)
DHCP Server-->>Client: DHCPACK (lease confirmed)All four of these messages use UDP, with the client sending from port 68 and the server responding on port 67.
Why DHCP Discover Is a Broadcast — And Why That’s a Problem
Because the client doesn’t yet have an IP address, it cannot send a normal unicast packet to a specific server — it doesn’t know one exists yet. So it broadcasts to 255.255.255.255. Broadcasts, by design, do not cross router boundaries — this is intentional, to prevent broadcast storms from flooding the entire network.
This creates a real problem: if your DHCP server sits in a central data center, and your clients are on a remote branch subnet behind a router, the client’s broadcast DHCPDISCOVER will never reach the server. This is exactly the problem DHCP Relay solves.
DHCP Relay — Bridging Broadcast Domains
A DHCP Relay Agent (usually the default gateway router of the client’s subnet) listens for DHCP broadcasts on its local interface, and when it hears one, it converts it into a unicast packet addressed directly to the known DHCP server, adding relay information along the way (like the giaddr field, which tells the DHCP server which subnet the request came from, so it can offer an address from the correct pool).
flowchart LR
subgraph Branch Subnet 10.10.10.0/24
PC[Client PC]
end
Router[Router - Default Gateway
ip helper-address configured]
subgraph HQ
DHCP[Central DHCP Server]
end
PC -- Broadcast DHCPDISCOVER --> Router
Router -- Unicast forwarded request --> DHCP
DHCP -- Unicast DHCPOFFER --> Router
Router -- Broadcast/Unicast to client --> PCConfiguring a Cisco Router as a DHCP Server
Router(config)# ip dhcp excluded-address 192.168.10.1 192.168.10.10
Router(config)# ip dhcp pool LAN-POOL
Router(dhcp-config)# network 192.168.10.0 255.255.255.0
Router(dhcp-config)# default-router 192.168.10.1
Router(dhcp-config)# dns-server 8.8.8.8 8.8.4.4
Router(dhcp-config)# domain-name company.local
Router(dhcp-config)# lease 7ip dhcp excluded-address reserves the first 10 addresses (often used for servers, printers, and the gateway itself) so DHCP never assigns them to a client.
Configuring a Cisco Device as a DHCP Client
On a router interface that should obtain its IP address dynamically (common on the WAN-facing interface connecting to an ISP):
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip address dhcp
Router(config-if)# no shutdownConfiguring DHCP Relay (IP Helper-Address)
On the router that sits as the default gateway for the remote client subnet:
Router(config)# interface GigabitEthernet0/1
Router(config-if)# ip helper-address 10.1.1.5Here, 10.1.1.5 is the IP address of the central DHCP server. This single command tells the router: “Any broadcast DHCP request you hear on this interface, forward it as unicast to 10.1.1.5.”
Important detail: ip helper-address doesn’t only forward DHCP — by default it forwards several types of UDP broadcasts (TFTP, DNS, Time, NetBIOS, and others too). If you only want DHCP relayed, you can restrict this using ip forward-protocol udp statements, though in most real deployments the default behavior is acceptable.
Verifying DHCP Server Operation
Router# show ip dhcp binding
Router# show ip dhcp pool
Router# show ip dhcp conflict
Router# show ip dhcp server statisticsExample show ip dhcp binding output:
IP address Client-ID/Hardware address Lease expiration Type
192.168.10.11 0063.6973.636f.2d61 Jul 24 2026 11:59 Automatic
192.168.10.12 0063.6973.636f.2d62 Jul 24 2026 11:59 AutomaticVerifying DHCP Client Operation
Router# show ip interface brief
Router# show dhcp lease
Router# show interfaces GigabitEthernet0/0Verifying DHCP Relay Operation
Router# show ip interface GigabitEthernet0/1
Router# debug ip udp
Router# show ip helper-addressThe show ip interface command on the relay interface will show the configured helper address:
GigabitEthernet0/1 is up, line protocol is up
Helper address is 10.1.1.5DHCP on Linux — Client and Server
Linux as a DHCP Client
Most Linux distributions use dhclient or NetworkManager to request an address.
sudo dhclient eth0
ip addr show eth0Or, checking via NetworkManager:
nmcli device show eth0 | grep IP4Linux as a DHCP Server (isc-dhcp-server)
sudo apt install isc-dhcp-server -y
sudo nano /etc/dhcp/dhcpd.confsubnet 192.168.10.0 netmask 255.255.255.0 {
range 192.168.10.50 192.168.10.150;
option routers 192.168.10.1;
option domain-name-servers 8.8.8.8, 8.8.4.4;
default-lease-time 600;
max-lease-time 7200;
}sudo systemctl restart isc-dhcp-server
sudo systemctl status isc-dhcp-serverCheck current leases:
cat /var/lib/dhcp/dhcpd.leasesComparison Table: DHCP Roles
| Role | Function | Example Device |
|---|---|---|
| DHCP Client | Requests an IP address configuration | End-user PC, router WAN interface |
| DHCP Server | Assigns IP addresses from a defined pool | Central router, Linux server, Windows Server |
| DHCP Relay Agent | Forwards broadcast requests across subnet boundaries to a remote server | Default gateway router of a remote subnet |
Simulating the DORA Process in Python
Understanding DORA is easier when you see it modeled in code. This simplified simulator demonstrates the message exchange logic (not a production DHCP implementation):
class DHCPServer:
def __init__(self, pool):
self.pool = pool
self.leases = {}
def offer(self, client_mac):
if self.pool:
offered_ip = self.pool.pop(0)
print(f"Server -> OFFER {offered_ip} to {client_mac}")
return offered_ip
print("Server -> No addresses available")
return None
def acknowledge(self, client_mac, ip):
self.leases[client_mac] = ip
print(f"Server -> ACK: {client_mac} leased {ip}")
def dora_process(server, client_mac):
print(f"Client {client_mac} -> DISCOVER (broadcast)")
offered_ip = server.offer(client_mac)
if offered_ip:
print(f"Client {client_mac} -> REQUEST {offered_ip} (broadcast)")
server.acknowledge(client_mac, offered_ip)
server = DHCPServer(pool=["192.168.10.11", "192.168.10.12"])
dora_process(server, "AA:BB:CC:00:11:22")
Output:
Client AA:BB:CC:00:11:22 -> DISCOVER (broadcast)
Server -> OFFER 192.168.10.11 to AA:BB:CC:00:11:22
Client AA:BB:CC:00:11:22 -> REQUEST 192.168.10.11 (broadcast)
Server -> ACK: AA:BB:CC:00:11:22 leased 192.168.10.11Best Practices
- Always exclude infrastructure addresses (gateways, servers, printers) from the DHCP pool.
- Use DHCP reservations (binding a specific IP to a specific MAC) for devices needing consistent addressing, like printers or servers.
- Keep lease times reasonable — short leases (hours) suit high-turnover networks like guest Wi-Fi; longer leases (days) suit stable office LANs.
- Configure redundant DHCP servers (using split scopes or DHCP failover) in critical environments so a single server outage doesn’t halt address assignment.
- Secure DHCP with DHCP Snooping on switches to prevent rogue DHCP servers from handing out malicious configurations.
- Document which router interface has
ip helper-addressconfigured, and to which DHCP server it points — this is easy to forget during network redesigns.
Troubleshooting
| Symptom | Likely Cause | Fix |
|---|---|---|
| Client gets no IP address (APIPA 169.254.x.x) | No DHCP server reachable, broadcast not relayed | Check ip helper-address on gateway, verify DHCP server reachable |
| Client gets IP from wrong pool | Multiple DHCP servers on network (rogue server) | Enable DHCP snooping; identify and disable rogue server |
“Address conflict” in show ip dhcp conflict | Duplicate static IP assigned outside DHCP pool | Ping-check before excluding, adjust excluded-address range |
| Relay not forwarding requests | Missing ip helper-address or wrong DHCP server IP | Verify with show ip interface, correct the helper address |
| DHCP pool exhausted | Pool too small for number of devices, or leases not expiring | Expand pool size, reduce lease time, check for stale bindings |
Real-World Example: Multi-Site DHCP Design
A company has one central DHCP server at headquarters (10.1.1.5) and three branch offices, each with its own subnet and no local DHCP server.
! Branch Router 1 - subnet 10.10.10.0/24
interface GigabitEthernet0/1
ip address 10.10.10.1 255.255.255.0
ip helper-address 10.1.1.5
! Branch Router 2 - subnet 10.10.20.0/24
interface GigabitEthernet0/1
ip address 10.10.20.1 255.255.255.0
ip helper-address 10.1.1.5On the central DHCP server, separate pools are defined per subnet, and the server uses the relay’s giaddr field to know which pool to assign from automatically:
ip dhcp pool BRANCH1
network 10.10.10.0 255.255.255.0
default-router 10.10.10.1
ip dhcp pool BRANCH2
network 10.10.20.0 255.255.255.0
default-router 10.10.20.1This design allows a single centralized DHCP server to serve an entire multi-site organization.
Conclusion
DHCP eliminates the burden of manual IP configuration by automating address assignment through the DORA process. When clients and servers live on different subnets — the normal case in any real, routed network — DHCP Relay bridges that gap by converting broadcast requests into unicast messages the central server can reach. Mastering both DHCP client behavior and relay configuration is essential for building scalable, centrally-managed networks.
References
- RFC 2131 – Dynamic Host Configuration Protocol — https://datatracker.ietf.org/doc/html/rfc2131
- Cisco Configuring DHCP — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/xe-16/dhcp-xe-16-book.html
- Cisco IP Helper-Address Explanation — https://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation-resolution/13506-30.html
- isc-dhcp-server Documentation — https://www.isc.org/dhcp/
- Linux dhclient man page — https://linux.die.net/man/8/dhclient
- RFC 3046 – DHCP Relay Agent Information Option — https://datatracker.ietf.org/doc/html/rfc3046
