Overview

DHCP sits at the heart of everyday networking. It assigns IP addresses and the basics a host needs to talk on a network—subnet mask, default gateway, DNS, lease timing, and sometimes extras like NTP or static routes. In practice, how DHCP behaves depends on where you’re looking from:

• As a Linux device on a network asking for an address (DHCP client).
• As a switch or Layer 2/Layer 3 device forwarding, inspecting, or controlling DHCP messages.

This article covers DHCP from both angles in depth, with a special focus on the DORA sequence (Discover, Offer, Request, Acknowledgement), renewal behavior, switch features like DHCP snooping and Option 82, security implications, and concrete command examples. We will not discuss running a DHCP server on Linux.

Use this as your training module for how Linux terminal process and your switching fabric team up to hand out IP addresses, keep leases healthy, and defend against rogue devices.

DHCP in 60 seconds

• DHCP is a UDP-based protocol (client uses port 68; server uses port 67) that automates client IP configuration.
• Clients often start in the dark (no IP, no server address), so they broadcast to discover a server.
• A typical lease involves: Discover → Offer → Request → Acknowledgement (DORA).
• After the initial lease, the client periodically renews it before expiry.
• Switches can operate transparently or enforce DHCP security (snooping), insert relay info (Option 82), and forward across VLANs/subnets (DHCP relay on L3 devices).

The DORA Sequence (Discover, Offer, Request, Acknowledgement)

DORA is the core handshake every IPv4 DHCP client performs to get online.

1) DHCP Discover

• When a Linux device boots or brings up an interface with DHCP enabled and has no IP, it sends a broadcast:
  • L2: destination MAC FF:FF:FF:FF:FF:FF (everyone)
  • L3: source 0.0.0.0, destination 255.255.255.255
  • UDP: client port 68 to server port 67
• The packet includes:
  • Client MAC (chaddr)
  • A Transaction ID (xid)
  • Options like Parameter Request List (what settings it wants), Hostname, Vendor Class Identifier, Requested IP (if it remembers a prior lease), and sometimes the broadcast flag.

From a Linux client’s point of view:

• Generated by a DHCP client daemon (systemd-networkd, NetworkManager’s internal client, dhclient, dhcpcd, or udhcpc).
• You can watch it live:sudo tcpdump -ni eth0 port 67 or port 68
• Typical log snippet:DHCPDISCOVER on eth0 to 255.255.255.255 port 67

From a switch’s point of view:

• It’s a broadcast frame, flooded to all ports in the same VLAN (except the one it came in on).
• With DHCP snooping enabled, the switch observes this and prepares to validate any future replies.

2) DHCP Offer

• One or more DHCP servers reply with an Offer. If the client has no IP yet (usual case), servers typically broadcast the Offer back so an unconfigured client can see it.
• The Offer proposes:
  • An IP address (yiaddr)
  • Lease time (Option 51)
  • Gateway (Option 3)
  • DNS (Option 6)
  • Subnet mask (Option 1)
  • Other options (NTP, MTU, domain search, classless static routes, etc.)

Linux client:

• Notes “DHCPOFFER from .”
• If multiple Offers arrive, the client chooses one (usually the first or according to client policy).

Switch:

• With snooping, the switch scrutinizes the Offer on untrusted ports. Only trusted ports (uplinks to servers/core) may send DHCP server messages. If a rogue Offer shows up on an untrusted port, the switch drops it.

3) DHCP Request

• The client broadcasts a Request to say “I accept this specific server’s Offer and address.” Broadcast ensures all servers see the selection—non-selected servers withdraw.

Linux client:

• Logs look like:DHCPREQUEST for 192.168.10.57 from 192.168.10.1 on eth0
• The Request includes the selected server identifier (Option 54) and the requested IP (Option 50).

Switch:

• With snooping, the Request helps the switch build or confirm the client’s binding (MAC ⇔ IP ⇔ VLAN ⇔ port).

4) DHCP Acknowledgement (ACK)

• The selected server replies with a DHCPACK (often unicast, sometimes broadcast depending on the client’s broadcast flag and local policies).
• The ACK finalizes the lease and includes the same key parameters.

Linux client:

• Configures the interface with the assigned IP and mask, sets the default route and DNS, and writes the lease to a lease file.
• On modern distributions:
  • systemd-networkd integrates via systemd-resolved; check DNS with:resolvectl status
  • NetworkManager manages DNS on your behalf; check:nmcli dev show eth0 | egrep ‘IP4.DNS|IP4.DOMAIN’

Switch:

• Updates the DHCP snooping binding table. This table becomes a foundation for other security features like IP Source Guard and Dynamic ARP Inspection.

At this point, the client is online. The server starts a lease timer; the client tracks renewal thresholds.

What happens after DORA: Lease Renewal and Rebinding

DHCP isn’t a one-and-done event. The client must renew before the lease expires.

• T1 (Renewal Time, Option 58): usually 50% of the lease. The client unicasts a DHCPREQUEST to the server to extend the lease.
• T2 (Rebinding Time, Option 59): usually around 87.5% of the lease. If renewal didn’t happen (server didn’t respond), the client broadcasts a DHCPREQUEST hoping any server can help.
• Expiry: If the lease fully expires, the client gives up the address and returns to INIT, sending a new Discover.

Linux signals you can see:

DHCPREQUEST for 192.168.10.57 on eth0 DHCPACK of 192.168.10.57 from 192.168.10.1

Switch behavior:

• Renewals may be unicast and look like normal unicast traffic. DHCP snooping (if enabled) refreshes timers for the binding.

Edge cases:

• DHCPNAK: The server can NAK a renewal if the address is no longer valid, forcing the client to discover again.
• DECLINE: If a client detects the offered IP is already in use (e.g., via ARP probe), it may send a DECLINE and ask for another address.

Linux as a DHCP Client: Components, Behavior, and Commands

Linux directory has multiple DHCP clients. You’ll typically see one of these:

• systemd-networkd: Native to systemd-based systems; tight integration with systemd-resolved.
• NetworkManager: Common on desktops and laptops; can use its own client or dhclient depending on version/config.
• dhclient: The classic ISC client; still found on many systems.
• dhcpcd: Lightweight client; common on Arch, Alpine, and embedded.
• udhcpc (BusyBox): Minimalist client for embedded Linux.

How a Linux client brings up DHCP

1. Interface goes up (carrier detected):
   • Kernel signals link up.
   • The network service (NM or networkd) applies the profile which often says “DHCP = yes.”
2. Client sends DHCPDISCOVER:
   • Includes PRL (Parameter Request List), Hostname, and possibly a Requested IP.
3. On DHCPACK:
   • The client configures the IP, mask, and route:ip addr add 192.168.10.57/24 dev eth0 ip route add default via 192.168.10.1 dev eth0
   • DNS is set:
     • With systemd-resolved:resolvectl dns eth0 192.168.10.1 9.9.9.9 resolvectl domain eth0 example.local(Normally done automatically by the DHCP client.)
     • With resolvconf or direct /etc/resolv.conf management, the file is updated with name server lines.
4. It writes leases to a file:
   • dhclient: under /var/lib/dhcp/ or /var/lib/NetworkManager/
   • systemd-networkd: under /run/systemd/netif/leases/
5. It renews at T1/T2 and logs events to journald or syslog.

Useful Linux commands

• Check link and IP:ip link show dev eth0 ip addr show dev eth0 ip route show
• Check DNS (systemd-resolved):resolvectl status
• Release and renew (varies by client):
  • dhclient:sudo dhclient -r eth0 sudo dhclient -v eth0
  • systemd-networkd (bounce interface):sudo networkctl down eth0 sudo networkctl up eth0
  • NetworkManager:nmcli device reapply eth0 nmcli device disconnect eth0 && nmcli device connect eth0
• Observe DHCP traffic:sudo tcpdump -ni eth0 port 67 or port 68
• View logs:journalctl -u systemd-networkd –since -1h journalctl -u NetworkManager –since -1h

What the Linux client typically requests

In the Parameter Request List (PRL), you’ll see common options:

• 1 Subnet Mask
• 3 Router (Default Gateway)
• 6 DNS Servers
• 15 Domain Name
• 51 Lease Time
• 58/59 T1/T2 timers
• 121 Classless Static Routes
• 42 NTP
• 119 Domain Search

Not every server will honor everything, but most include the basics: address, mask, router, DNS, lease.

Broadcast vs unicast replies

Some clients set the DHCP broadcast flag to request that servers broadcast their replies, useful if the NIC or OS can’t handle receiving unicast before the IP is configured. Linux clients usually don’t need this and accept unicast replies, but behavior depends on the client and driver. If you see Offers/ACKs consistently broadcast, it may be intentional or due to a flag.

DHCP From the Switch Perspective

A switch can be a simple L2 forwarder or an intelligent policy enforcement point. How your switch treats DHCP frames determines your security posture, how well clients get addresses, and how you prevent rogue devices.

L2 forwarding (no special features)

• Unmanaged or basic switches flood the client’s DISCOVER to all ports in the VLAN.
• Any server on that VLAN can reply with an OFFER.
• The switch doesn’t filter or inspect DHCP—good for simplicity, bad for security.

DHCP Snooping

DHCP snooping lets a managed switch distinguish “trusted” and “untrusted” ports for DHCP server traffic.

• Trusted ports: uplinks to your legitimate DHCP server or core.
• Untrusted ports: client-facing edge ports.

What it does:

• Drops server-type DHCP messages (OFFER, ACK, NAK) arriving on untrusted ports. This blocks rogue DHCP servers plugged into wall jacks.
• Builds a DHCP snooping binding table:
  • IP address
  • MAC address
  • VLAN
  • Interface (switchport)
  • Lease timer
• Feeds other features:
  • IP Source Guard: permits traffic only if source IP/MAC matches the snooping binding on that port.
  • Dynamic ARP Inspection (DAI): blocks ARP spoofing by checking ARP packets against the snooping table.

Operational notes:

• Enable DHCP snooping per VLAN.
• Mark the correct uplink(s) as trusted.
• Rate-limit DHCP messages on untrusted ports (helps stop starvation attacks).

Symptoms when misconfigured:

• “No DHCPOFFERS received” on clients because the switch is dropping server replies that arrive via an untrusted port.
• Inconsistent bindings or blocked traffic if the snooping table is out-of-date or the port/VLAN mapping changed.

Typical checks (vendor-specific, conceptually similar across platforms):

• Show snooping status
• Show snooping bindings
• Confirm trusted vs untrusted ports
• Check rate-limiting counters and drops

Option 82 (DHCP Relay Agent Information)

Option 82 tags a DHCP request with metadata about where it entered the network. It typically includes:

• Circuit ID (e.g., VLAN and port)
• Remote ID (e.g., switch MAC, chassis, or string)

Benefits:

• The DHCP server can assign addresses or options based on where the device is connected (per-floor, per-port, per-VLAN policies).
• Helps troubleshooting: you can track which physical port a lease came from.

Where it comes from:

• L3 DHCP relay (router/layer-3 switch) inserts Option 82 when relaying a client’s broadcast to a server in another subnet.
• Many managed L2 switches can also insert Option 82 even if they are not routing, as part of DHCP snooping/information insertion features. Behavior varies by vendor—often configurable.

Caution:

• Don’t break Option 82 by stripping it where the server expects it.
• Ensure “trusted” ports are correctly set; otherwise, the switch may drop legitimate server replies with Option 82.

DHCP Relay (L3 “ip helper” style)

If the DHCP server is in a different subnet, L3 devices relay DHCP requests:

• Client sends broadcast in VLAN X.
• The first-hop L3 interface receives it and forwards it as a unicast to the DHCP server, setting the GIADDR (Gateway IP Address) to the interface address. Option 82 may be added as well.
• The server replies to the relay agent, which then sends the response back to the client on the original VLAN.

Why it matters:

• The server uses GIADDR to pick the correct scope/pool for that subnet.
• Without relay, broadcasts won’t cross routers, and clients won’t get leases from a remote server.

Troubleshooting gotchas:

• Incorrect helper address → no Offers.
• ACLs or firewalls blocking UDP/67,68 between relay and server.
• Missing Option 82 expectations at the server (some setups require it).

Other switch-side protections

• DHCP Guard: Blocks DHCP server messages on unauthorized ports.
• Storm control: Limits broadcast rates; if set too low, it can starve DORA broadcasts.
• Port security: Locks a port to specific MAC addresses; changes can disrupt clients if the MAC count is exceeded.
• VLAN consistency: The VLAN the client is on must match the scope on the server (directly or via proper relay configuration).

Security: Rogue Servers, Starvation, and ARP Ties

DHCP is a tempting target for attackers.

• Rogue DHCP servers: An attacker can plug in a device that hands out addresses with a malicious default gateway or DNS. Users suddenly route through an attacker-controlled box.
  • Mitigation: Enable DHCP snooping; mark only uplinks as trusted. Use DHCP Guard features. Combine with DAI and IP Source Guard.
• Starvation attacks: Attacker sends a flood of DISCOVERs with random MACs, exhausting the address pool.
  • Mitigation: Rate-limit DHCP on edge ports, use port security to limit MAC churn, and monitor logs.
• ARP spoofing after DHCP: Even with a correct lease, an attacker can poison ARP to hijack traffic.
  • Mitigation: Dynamic ARP Inspection tied to the snooping table.
• Option 82 abuse: Tampering with relay info to trick the server into assigning addresses from the wrong scope.
  • Mitigation: Insert Option 82 only on trusted network elements; ensure the server validates it.

Observability: Reading DHCP on the Wire and in Logs

On Linux, you can learn a lot by reading packets and logs.

Packet captures

• Live capture:sudo tcpdump -ni eth0 -vvv -s0 -w dhcp.pcap port 67 or port 68
  • Use -w to write a pcap and inspect in Wireshark for full option details.
  • Expect to see: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, plus options like 53 (message type), 54 (server identifier), 50 (requested IP), 51 (lease), 58/59 (T1/T2), 1/3/6 (mask/router/DNS), and sometimes 121 (classless static routes).
• Quick console view:sudo tcpdump -ni eth0 port 67 or port 68

Logs and lease files

• systemd-networkd:
  • Logs: journalctl -u systemd-networkd
  • Leases: /run/systemd/netif/leases/
  • DNS: resolvectl status
• NetworkManager:
  • Logs: journalctl -u NetworkManager
  • Status: nmcli device show eth0
  • Leases often under /var/lib/NetworkManager/
• dhclient:
  • Verbose: sudo dhclient -v eth0
  • Leases: /var/lib/dhcp/dhclient.eth0.leases (path varies by distro)

What to look for:

• “No DHCPOFFERS received” → server unreachable, relay missing, snooping misconfig, ACL/firewall issue, or broadcast suppressed by storm control.
• Repeated DISCOVER → Offers never arrive or are dropped.
• NAK during renew → server reclaimed the address or scope changed.

Linux quirks and edge cases

• Link flaps: When the link drops and comes back, the client may try to renew its existing lease if the lease hasn’t expired; otherwise, it restarts DORA. Rapid flaps can cause short bursts of DHCP traffic.
• Broadcast flag: Some network designs rely on broadcast replies. Linux often handles unicast fine before it has an address, but drivers or NIC offload can influence behavior.
• ARP probing: Many clients probe for address conflicts before committing. If a conflict is detected, the client sends a DECLINE and requests a new IP.
• Multiple interfaces: If a host has Wi‑Fi and Ethernet up simultaneously, each interface runs its own DHCP state machine unless you force policy otherwise. Be clear which interface your route and DNS are tied to.
• Containers and VMs: Docker, Podman, and similar usually use a private bridge and NAT; they don’t directly run DHCP on your physical LAN. KVM/virt and cloud-init setups can either use DHCP on bridged interfaces or inject static config.

From Switch Eyes: What the Frame Looks Like

When a Linux client sends a DISCOVER:

• Source MAC: client MAC
• Dest MAC: FF:FF:FF:FF:FF:FF (broadcast)
• VLAN tag: present if the port is an access port in a specific VLAN (untagged on that access), or if the client tags (rare for end hosts).
• Switch learns the source MAC on that port and floods the frame to all other ports in the VLAN.
• With snooping, the switch records that it has seen a DISCOVER from a given MAC/port/VLAN.

When the server replies with an OFFER:

• If the server is on the same VLAN and sends a broadcast, the switch floods it back.
• With snooping, if the OFFER comes from an untrusted port, it gets dropped. From a trusted port, it is forwarded and can seed a tentative binding.

Post-ACK:

• The snooping binding becomes active, and IP Source Guard and DAI can rely on it.
• If the client moves ports without a new DHCP process, IP Source Guard may block it until it re-DHCPs (that’s by design).

With relay (L3):

• The L3 interface receives the broadcast, encapsulates it into a unicast to the server, and sets GIADDR.
• The return path is a unicast back to the relay, which then emits an L2 frame to the client. Option 82 often rides along.

Practical lab: See DORA in action on Linux

Try this on a non-production interface or during a maintenance window.

1. Clean start:sudo dhclient -r eth0 sudo ip addr flush dev eth0
2. Start capture:sudo tcpdump -ni eth0 -vvv -s0 port 67 or port 68
3. Request a lease:
   • With dhclient:sudo dhclient -v eth0
   • Or bounce the interface via NetworkManager:nmcli device reapply eth0
   • Or via systemd-networkd:sudo networkctl down eth0 && sudo networkctl up eth0
4. Watch for:
   • DHCPDISCOVER → DHCPOFFER → DHCPREQUEST → DHCPACK
   • Check what options the server returns (DNS, router, lease time).
5. Verify configuration:ip addr show dev eth0 ip route show resolvectl status
6. Renewal:
   • Wait past T1 or force a renew by releasing and re-requesting.

If you don’t see Offers, suspect:

• Wrong VLAN or trunk/access mismatch on the switch.
• Missing DHCP relay (no “ip helper” equivalent) between client VLAN and server subnet.
• DHCP snooping not trusting the uplink carrying server traffic.
• Storm control or ACLs blocking broadcasts or UDP 67/68.

Switch configuration patterns and checks (vendor-neutral concepts)

While syntax differs, the concepts are consistent:

• Enable DHCP snooping for the VLANs where clients live.
• Mark uplinks toward your DHCP server/core as trusted.
• Verify the snooping binding table fills as clients get leases.
• Enable DAI and IP Source Guard if you want tighter security tied to snooping.
• Configure DHCP relay on L3 interfaces for client VLANs whose servers sit in other subnets.
• Consider Option 82 insertion to give the server topology context.
• Rate-limit DHCP on edge ports to blunt starvation attacks.
• Ensure broadcast and DHCP UDP ports aren’t inadvertently blocked by ACLs or storm control.

Checks to run:

• Show snooping status and bindings.
• Show relay status (helper addresses) on L3 SVI interfaces.
• Confirm which ports are trusted.
• Inspect counters for dropped DHCP messages.

Common problems and how to fix them

1. The Linux concept host says “No DHCPOFFERS received.”
   • Is the port in the correct VLAN? Check access vs trunk configuration.
   • If the server is not in the same subnet, is there a DHCP relay configured on the L3 interface?
   • Is DHCP snooping enabled but uplinks are not trusted? Mark the correct ports as trusted.
   • Are ACLs blocking UDP/67-68 between relay and server?
   • Is storm control suppressing broadcast too aggressively?
2. The lease renewals fail and the client falls off the network.
   • Server down or unreachable? Check reachability between client and server/relay.
   • T1/T2 timers misaligned? Rare, but watch logs for NAKs.
   • Switch dropping unicast renewal traffic because of IP Source Guard? Verify the snooping binding exists and hasn’t aged out incorrectly.
3. The client gets an IP but can’t reach anything.
   • Wrong default gateway or missing route delivered by DHCP.
   • DNS misconfiguration; verify resolvectl or /etc/resolv.conf.
   • IP Source Guard or DAI blocking traffic because the binding is missing or mismatched (e.g., MAC changed, moved port).
4. Intermittent issues on Wi‑Fi vs Ethernet.
   • Multiple interfaces up can cause route competition. Check the routing table and metrics.
   • If a laptop roams, the DHCP lease might persist across networks; ensure NetworkManager handles per-connection DHCP cleanly.
5. Rogue DHCP server detected.
   • Enable DHCP snooping and DHCP Guard on edge ports.
   • Audit uplink trust settings.
   • Track down the MAC of the rogue Offer sender via switch MAC table and port.

DHCPv6 quick note (contrast, not a deep dive)

While this article focuses on IPv4 and DORA, be aware DHCPv6 uses a different message set (SOLICIT, ADVERTISE, REQUEST, REPLY) and doesn’t rely on L2 broadcast in the same way (uses link-local multicast). Switch features like RA Guard (for IPv6 Router Advertisements) complement DHCPv6 security. Many operational ideas carry over—relay, option insertion, and client logging—but packet shapes differ.

Practical tips for Linux admins

• Prefer system tools to inspect live state:
  • ip addr, ip route, resolvectl status, nmcli dev show.
• When debugging, always run a packet capture during the problem. It reveals whether the client is sending DISCOVERs and whether Offers are returning.
• If you see Offers in the capture but the client still fails, check for:
  • MTU issues, VLAN tagging mismatches, or NIC offload quirks.
  • Local firewall rules blocking DHCP (rare on client, but possible).
• Keep an eye on lease files to confirm what the client believes is current.
• If multiple DHCP clients could run on the same interface (e.g., NetworkManager and systemd-networkd), pick one and disable the other to avoid conflicts.

Practical tips for switch/network teams

• Treat DHCP snooping as a baseline control. Tie it to IP Source Guard and DAI for a solid security trio.
• Classify ports correctly:
  • Edge/user ports: untrusted
  • Uplinks to server/core: trusted
• If your server is remote, configure relay on the client VLAN SVI and verify GIADDR and Option 82 behavior with your server team.
• Adjust storm control and broadcast limits so DHCP can operate during peak periods.
• Keep documentation on VLAN-to-scope mappings; nothing breaks DHCP faster than mismatched VLAN or helper addresses.
• Monitor the snooping binding table as part of your NOC dashboards. It’s a goldmine for tracking where a host is connected.

Bringing it all together

• From the Linux host’s seat: DHCP is a small set of broadcasts and replies, a lease file, and a few routes and DNS settings that keep the machine reachable. DORA gets you online; T1/T2 keep you online.
• From the switch’s seat: DHCP is a set of control messages that must be allowed, steered, and policed. With snooping and relay, the switch prevents bad actors from spoofing server roles and steers client requests to the right server across VLAN boundaries.
• Both sides benefit from visibility. Packet captures, logs, and the snooping binding table together tell a full story: who asked for what, from where, and with what outcome.

If you remember only one thing: DORA is the handshake, but your switch’s DHCP features determine whether DORA is safe and reliable at scale. Configure snooping and relay right, and Linux clients will just work—cleanly, predictably, and securely—no manual IPs required.