DHCP Explained for System Administrators

By Kokil Thapa | Last reviewed: September 2026

Every laptop, phone, and server on your LAN needs an IP address before it can reach DNS, gateways, or your applications. DHCP Explained for System Administrators starts here: Dynamic Host Configuration Protocol hands out addresses and network parameters automatically so you do not manually configure hundreds of devices. On production Ubuntu servers I maintain for Linux system administration clients, DHCP sits beside DNS, firewall rules, and deployment pipelines as core infrastructure. This guide walks through the protocol, Linux server setup, scopes, and the failures that actually show up after office moves or VLAN changes.

What is DHCP and why do system administrators rely on it?

DHCP is defined in RFC 2131 and extended by later RFCs for options like vendor classes and relay behaviour. A DHCP server maintains a pool of usable addresses and leases them for a defined time. When a lease expires, the address returns to the pool unless the client renews.

Without DHCP, each device needs a static IP, subnet mask, default gateway, and DNS servers typed by hand. That works for three servers. It breaks at thirty workstations and becomes a nightmare at three hundred. DHCP centralises those values in one configuration file or database.

System administrators use DHCP because it scales onboarding. A new employee connects to Wi-Fi and gets a valid address in seconds. You change the default gateway once on the server instead of visiting every machine. For domain registration and hosting projects where office LANs feed into web servers, consistent gateway and DNS settings prevent subtle routing bugs.

DHCP also carries options beyond the IP address. Option 3 is the default router. Option 6 lists DNS servers. Option 15 sets the DNS domain name. Option 51 defines lease time in seconds. Vendor-specific options can push NTP servers, PXE boot filenames, or VoIP settings.

On shared EC2 infrastructure where I run Deployer-based sites, office VLANs and staging subnets still depend on DHCP or closely managed static pools. The protocol is not glamorous. It is load-bearing.

How does the DHCP four-way handshake (DORA) work?

When a client boots or joins a network, it has no IP address. It sends a DHCPDISCOVER broadcast to 255.255.255.255 on UDP port 67. Every DHCP server on the segment hears it. Each server that can serve that subnet replies with DHCPOFFER, proposing an IP and options.

The client picks one offer and broadcasts DHCPREQUEST. That broadcast tells other servers their offers were declined. The chosen server responds with DHCPACK, confirming the lease. If the requested address is unavailable, the server sends DHCPNAK instead.

After ACK, the client configures its interface and may perform ARP checks to detect duplicate addresses. This sequence is called DORA: Discover, Offer, Request, Acknowledge.

Renewal and rebinding phases

Leases are temporary. At 50% of lease time (T1), the client unicasts DHCPREQUEST to the original server to renew. At 87.5% (T2), if renewal failed, the client broadcasts to any server on the segment. At expiry, the client must restart DORA from scratch.

Short leases suit guest Wi-Fi where devices come and go. Long leases suit stable server VLANs where churn is low. A common mistake is setting lease time to five minutes on a busy office LAN. That floods the server with renewal traffic.

Capturing this traffic with tcpdump -i eth0 port 67 or port 68 resolves many "works on Wi-Fi, fails on Ethernet" tickets. You see whether DISCOVER leaves the client and whether OFFER returns. Related reading: SELinux basics for administrators when firewall contexts block DHCP relay replies.

How do you configure a DHCP server on Linux?

Linux offers several DHCP servers. ISC Kea is the modern successor to isc-dhcp-server. dnsmasq suits small office routers and hypervisor bridges. Windows Server and enterprise appliances use their own stacks, but the concepts transfer.

For a dedicated Ubuntu 24.04 host serving 192.168.10.0/24, Kea is a solid choice. Install it from your distribution packages, then define a subnet in JSON configuration.

Example Kea DHCPv4 configuration

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "eth0" ]
    },
    "subnet4": [
      {
        "subnet": "192.168.10.0/24",
        "pools": [
          { "pool": "192.168.10.100 - 192.168.10.200" }
        ],
        "option-data": [
          { "name": "routers", "data": "192.168.10.1" },
          { "name": "domain-name-servers", "data": "192.168.10.2, 8.8.8.8" },
          { "name": "domain-name", "data": "office.example.com" }
        ],
        "valid-lifetime": 86400
      }
    ],
    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/dhcp4.leases"
    }
  }
}

Validate syntax with kea-dhcp4 -t /etc/kea/kea-dhcp4.conf before restarting the service. Kea documentation at kea.readthedocs.io covers hooks, high availability, and PostgreSQL lease backends for larger deployments.

dnsmasq for lightweight setups

On a small office gateway, dnsmasq combines DNS caching and DHCP in one daemon. A minimal /etc/dnsmasq.d/lan.conf might look like this:

interface=eth0
dhcp-range=192.168.50.50,192.168.50.150,255.255.255.0,12h
dhcp-option=3,192.168.50.1
dhcp-option=6,192.168.50.1,1.1.1.1
dhcp-authoritative

The dhcp-authoritative flag tells clients this server is the sole authority on the segment. That speeds up boot when stale leases linger elsewhere.

DHCP relay across VLANs

DHCP broadcasts do not cross routers. When your DHCP server sits on VLAN 10 and clients live on VLAN 20, configure a relay agent on the L3 gateway. On Linux with dhcrelay or on Cisco IOS with ip helper-address, the relay forwards DISCOVER packets to the server's unicast address.

1. Place the DHCP server on a management VLAN with routable access to all client subnets.
2. Define one subnet block per VLAN in the server config.
3. Enable relay on each VLAN interface pointing at the server IP.
4. Open UDP 67/68 between relay and server through firewalls.
5. Test with a client on each VLAN before closing the change ticket.

I have seen production outages where relay was configured but capacity planning ignored lease file growth on disk. Monitor lease database size the same way you monitor CPU and RAM.

What are DHCP scopes, reservations, exclusions, and options?

A scope (or subnet declaration) is the address range a server may assign within one broadcast domain. The pool must exclude network and broadcast addresses. For a /24, usable host addresses are typically .1 through .254 depending on design.

Reservations map a MAC address to a fixed IP inside the pool. The client still uses DHCP, but always receives the same address. Use reservations for printers, access points, and NAS boxes that other systems reference by IP. This beats pure static config because you change the reservation centrally.

Exclusions remove addresses from the dynamic pool without assigning them. Reserve 192.168.10.1 for the gateway and exclude it from the pool so the server never leases it to a laptop.

Kea reservations use host reservations keyed by hardware address:

"reservations": [
  {
    "hw-address": "aa:bb:cc:dd:ee:ff",
    "ip-address": "192.168.10.50",
    "hostname": "office-printer"
  }
]

Validate JSON structure with a JSON formatter before pushing config to production. A trailing comma in Kea JSON has caused more downtime than you might expect.

For multi-site businesses in Nepal, document scopes in a shared runbook alongside Nepali date converter utilities and other ops tools your team already uses daily. Consistency beats tribal knowledge when Dashain leave rotates staff.

How do you troubleshoot common DHCP failures in production?

DHCP problems look like "no internet" or "cannot reach internal apps." Users rarely report DHCP by name. Your job is to narrow the layer quickly.

Symptom: client gets 169.254.x.x (APIPA)

Windows and some Linux configs assign a link-local address when DHCP fails entirely. No DISCOVER reply reached the client, or every OFFER was rejected. Check cable, VLAN, relay, and whether the server service is running.

Symptom: duplicate IP conflicts

Someone statically configured .105 while the pool also leases .105. Exclude static ranges from the pool. Enable conflict detection if your server supports it. Kea can ping before ACK on some builds.

Symptom: pool exhausted

Every address is leased and none expired. Shorten lease time temporarily, expand the subnet, or prune stale reservations. On one client project, abandoned IoT devices held hundreds of week-long leases until we cut lifetime to four hours on that VLAN.

Diagnostic commands

# Linux client: release and renew
sudo dhclient -r eth0 && sudo dhclient -v eth0

# Inspect current lease
cat /var/lib/dhcp/dhclient.leases

# Server-side Kea lease list
kea-shell --host 127.0.0.1 --port 8000 --service dhcp4 \
  --command lease4-get-all

# Capture DHCP traffic
sudo tcpdump -ni eth0 'udp port 67 or udp port 68'

Cross-check firewall rules. AWS Systems Manager fleet automation does not replace on-prem DHCP, but hybrid teams often forget security groups block UDP 67 between VPC peers. The same logic applies to UFW on Ubuntu gateways.

Log correlation matters. Match MAC addresses from server logs to switch port maps. For sites I maintain with GitLab CI and Deployer, the app servers use static IPs while staff VLANs stay on DHCP. Mixing those models without documentation causes midnight pages.

Pair DHCP monitoring with broader health checks from support and maintenance contracts. Alert when pool utilisation crosses 85%. That gives you time to expand before users notice.

When should you use DHCP versus static IP addresses?

Not every device belongs in a dynamic pool. Production database servers, load balancers with fixed DNS records, and infrastructure that must survive DHCP outages often deserve static configuration or reservations.

• Use DHCP for workstations, mobile devices, guest networks, and lab VMs with short lifetimes.
• Use reservations when a device needs a predictable IP but you still want central control.
• Use static IPs on servers referenced in firewall rules, TLS certificates, or hard-coded API allowlists where a lease change would break integrations.
• Use DHCP options to push NTP and DNS rather than baking them into golden images.

On Notary Kathmandu and sister legal-tech sites sharing a Deployer pipeline, web servers sit on static addresses behind a reverse proxy. Office staff remain on DHCP. That split is deliberate and documented.

Cloud VPCs blur the line. AWS assigns private IPs at ENI creation time, which behaves like static from the instance perspective. You still automate allocation via infrastructure-as-code. The mental model matches reservations: predictable, centrally managed, auditable.

For Kubernetes clusters, CKA prep guides stress stable node networking. Worker nodes may DHCP on bare metal labs, but production clusters almost always use fixed addressing or CNI-managed IPs independent of traditional DHCP pools.

Security considerations belong here too. Rogue DHCP servers on a flat LAN can redirect clients to malicious gateways. Enable DHCP snooping on managed switches. Restrict who can attach unknown routers to office ports. RFC 3118 covers authentication extensions, but most SMB networks rely on VLAN segmentation and port security instead.

High availability pairs two DHCP servers with split scopes or Kea HA hooks. Each server owns half the pool, or they share a lease database backend. Failover testing should be scheduled. A backup server that never claimed leases will not help during a Friday outage.

IPv6 adds DHCPv6 and SLAAC. Many admins run router advertisements for address assignment and DHCPv6 only for DNS options (stateless DHCPv6). Dual-stack planning is its own topic, but the administrator mindset matches IPv4: define pools, document reservations, monitor utilisation.

Cost is negligible for software. Kea and dnsmasq are free. Your expense is engineer time for design, documentation, and incident response. Budget roughly Rs 15,000–40,000 (~USD 110–300) for a consultant to audit a multi-VLAN office if your internal team lacks networking depth. That is cheaper than a day of company-wide downtime.

Integrate DHCP changes into change management. A wrong default gateway in option 3 affects every renewal on that scope. Use a regex tester to validate hostname patterns in dynamic DNS updates if you couple DHCP with BIND or Windows DNS.

Developers building LAN-connected apps should understand lease behaviour. A long-running desktop app that caches an IP at startup may break when the OS renews mid-session if the app assumes immutability. Server-side apps on web development stacks rarely touch DHCP directly, but IoT integrations and office printing workflows do.

Backup lease databases nightly if you use file-backed storage. After server rebuild, an empty lease file means mass reassignments and possible conflicts until clients renew. PostgreSQL backends simplify restore but add dependency management aligned with Well-Architected reliability practices.

Performance tuning rarely limits DHCP unless you serve tens of thousands of clients from one daemon. CPU load spikes during Monday morning boot storms. Spread lease times slightly with randomisation if your server supports it. That avoids synchronized mass renewals at the top of each hour.

Documentation templates should list scope name, VLAN ID, subnet, pool range, gateway, DNS, lease time, relay IP, and owner. Link to your portfolio infrastructure projects only when explaining real multi-site patterns, not as filler. Operators reading system design interview prep material will recognise DHCP as a small but critical dependency in overall topology diagrams.

Finally, test guest and IoT VLANs separately from corporate SSIDs. IoT devices often assume /24 networks and break on restrictive options. A printer that ignores option 6 and uses hard-coded Google DNS will bypass your split-tunnel VPN policies. DHCP pushes policy, but clients choose whether to obey.

Key Takeaways

• DHCP automates IP, gateway, and DNS assignment through the DORA handshake—know it before you debug "no network" tickets.
• Define scopes with clear pools, exclusions, and MAC reservations; never let dynamic pools overlap static infrastructure addresses.
• Use relay agents when the DHCP server and clients sit on different VLANs; verify UDP 67/68 end to end.
• Monitor pool utilisation and lease database health; alert at 85% capacity before users hit APIPA addresses.
• Reserve static or reserved IPs for servers in firewall rules; use DHCP for workstations and transient devices.
• Capture tcpdump on port 67/68 when logic says the server is fine but clients still fail—packets do not lie.

People Also Ask

What ports does DHCP use?

DHCP clients send from UDP port 68 to server port 67. Relay agents forward between segments on the same ports. Firewalls must allow this traffic between clients, relays, and servers or discovery never completes.

How long should a DHCP lease time be?

Guest Wi-Fi often uses 1–4 hours. Corporate LANs commonly use 8–24 hours. Stable device VLANs may use multiple days. Shorter leases reclaim addresses faster but increase server traffic.

Can two DHCP servers share one scope?

Yes, with split scopes or HA failover where each server holds a non-overlapping portion of the pool, or both share a central lease database. Never run two independent servers assigning from the same full range without coordination.

What is the difference between DHCP and DNS?

DHCP assigns IP configuration to clients. DNS resolves hostnames to addresses. DHCP option 6 tells clients which DNS servers to use—they work together but serve different roles in network stack setup.

Build reliable infrastructure from the ground up

DHCP explained for system administrators is foundational knowledge, not a footnote. You will configure scopes on day one and debug them after every office expansion. Pair solid DHCP design with documented VLAN maps, monitored lease pools, and tested failover before you need it. If your team wants help auditing office networks, cloud VPCs, or the Linux hosts that sit behind them, review our Linux administration services or reach out through contact us to plan a stable baseline for 2026 and beyond. More infrastructure reading lives on the blog, including guides for startup infrastructure and about the engineer behind these deployments. See also customer reviews and testing and optimization for post-launch reliability work.