CCNA DHCPv4: Client, Server and Relay on Cisco IOS

A DHCPv4 client gets its address through a four-message exchange, usually remembered as DORA: Discover, Offer, Request, Acknowledge. The client starts with no address and no idea where a server is, so the messages it sends are broadcasts; the server's replies carry the lease and its options.

The client sends from UDP port 68 to the server port, UDP 67. The REQUEST is broadcast on purpose, even though the client already knows which server it wants: it carries the server identifier (option 54) of the chosen server, so every server that made an offer hears the outcome. The chosen server answers with an ACK; the others return their offered addresses to their pools. No separate "rejection" message is sent to the losing servers.

So when a capture shows two offers and one lease, it is the broadcast REQUEST that tells the second server it lost. The client and server messages are also easy to keep apart: the client sends DISCOVER and REQUEST, the server sends OFFER and ACK.

A lease is renewed long before it runs out, in two stages timed as fractions of the lease length (RFC 2131 defaults):

A successful renewal ends with a DHCPACK that restarts the lease clock. Work the timers as fractions of whatever lease is configured: a two-day (48-hour) lease renews at hour 24 and rebinds at hour 42. The rule behind the two stages: the T1 request is unicast to the server identifier recorded in the lease, so only that server can answer it; any other server, including one at a new address, can only answer the broadcast sent at T2. A client is never told that its server went away, so it keeps using a valid lease and acts only when its timers fire.

A DISCOVER is never a renewal message. It appears only for a client with no usable lease: a new client, an expired lease, or a client whose request was refused.

An IOS DHCP server is a named pool that defines the subnet to lease from and the options to hand out, plus global exclusions for addresses that must never be leased.

ip dhcp excluded-address 172.16.80.1 172.16.80.15
!
ip dhcp pool VLAN80
 network 172.16.80.0 255.255.255.0
 default-router 172.16.80.1
 dns-server 172.31.5.53
 domain-name branch.example
 lease 2 6

• network takes a subnet mask or prefix length (/24), never a wildcard mask. The mask sets which addresses the pool can lease and the mask the clients receive.
• default-router sends the gateway (option 3). dns-server sends name servers (option 6). domain-name takes a DNS suffix such as corp.example, not an address.
• lease reads days, hours, minutes, left to right. lease 3 is three days, lease 2 6 is two days and six hours, lease 0 0 45 is forty-five minutes. The default is one day; lease infinite also exists.
• ip dhcp excluded-address is a global command, not a pool subcommand.

Several global commands look like pool options but only affect the router itself:

Exclude every address that is already in use by something configured statically: the gateway SVI, other router interfaces, servers, printers, cameras. The server then never considers those addresses, so it cannot hand them out.

• The syntax is ip dhcp excluded-address low [high], and the range is inclusive at both ends. With exclusions 10.40.8.1–.15 and 10.40.8.240–.254 on a 10.40.8.0/24 pool, the leasable range is .16 to .239: each named endpoint is itself excluded.
• Name the addresses to keep out, not the addresses to hand out. Reversing the logic and excluding everything above the statics leaves only the statics leasable.
• Several excluded-address lines can coexist; each removes its own range.

Gateways with HSRP

With a first-hop redundancy protocol (HSRP, VRRP or GLBP), the rule is: hand out the virtual IP as default-router, and exclude every address the routers use, the virtual IP plus each router's own interface address. The virtual IP moves to whichever router is active; a physical interface address dies with its router.

default-router does accept a list of several gateway addresses, in order of preference, but a list of the routers' physical addresses is not a substitute for the virtual IP. Most clients use only the first gateway in the list and do not fail over to the next one quickly, if at all, so when that router fails they lose off-subnet access. The redundancy has to live in the shared virtual address, not in the client's option list.

Exclusions are the real control. The server's ping check (next section) is a safety net that only catches hosts which answer pings; it is not a substitute for excluding known statics.

Conflict detection

Before offering an address, the IOS DHCP server pings it (by default two echo requests with a short timeout). If something replies, the address is already in use: the server records a conflict, skips that address and offers another. The client side has its own check: after the ACK, a client may ARP for its new address, and if another host answers it sends a DHCPDECLINE and starts over. IOS also sets a declined address aside.

R3# show ip dhcp conflict
IP address        Detection method   Detection time
172.16.80.142     Ping               Mar 03 2027 02:15 PM

Reading the table: Ping means the server's own pre-offer probe got a reply (the other method shown is gratuitous ARP). An address in this table is withheld from leases until the entry is cleared; do not rely on it ageing out.

Conflicts that keep coming back

If the same addresses reappear as conflicts every time they are cleared, a static host sits inside the pool's range without an exclusion. Clearing only puts the address back up for offer; the next ping finds the host again. The permanent fix is ip dhcp excluded-address for those statics, then a final clear. Turning off the ping check (ip dhcp ping packets 0) silences the log by creating the duplicate it was preventing.

The ping check can only find hosts that answer echo requests. A static device whose host firewall drops ICMP (a badge reader, for instance) is invisible to it however the check is tuned, so its address can be offered; the problem then surfaces later, at the client's own ARP check or as a duplicate address. The general rule: anything with a static address inside a pool's range needs an exclusion.

A DHCP relay agent lets clients lease from a server on another subnet. Routers do not forward broadcasts, so a DISCOVER dies at the first router unless the interface that receives it relays it. On IOS the relay is ip helper-address server-ip, an interface command placed on the client-facing interface (the SVI or LAN port) and pointing at the server.

interface Vlan35
 ip address 10.35.0.1 255.255.255.0
 ip helper-address 172.31.5.10
 ip helper-address 172.31.5.11

• A helper on the uplink or WAN interface relays nothing for the LAN, because the clients' broadcasts never arrive there.
• Configure one helper line per server. With two servers, the relay sends each request to both and the client accepts one offer, which gives resilience if the servers hold non-overlapping parts of the scope.
• The helper address is the server's unicast address. Pointing it at a subnet's broadcast address depends on directed-broadcast forwarding, which is off by default on IOS.
• DHCP/BOOTP is already in the default list of UDP services a helper forwards (others include TFTP and DNS). ip forward-protocol udp adds or removes services globally; it is not needed to make DHCP relay work.

The server chooses a pool from the giaddr (gateway IP address) field that the relay writes into the request. The relay unicasts the client's DISCOVER to the helper address and sets giaddr to the address of the interface that received the broadcast, not its uplink. The server then looks for a pool whose network statement, mask included, contains that giaddr, and replies to the giaddr.

• No matching pool, no offer. If the server has no pool covering the giaddr subnet, it receives and counts the DISCOVER but sends nothing back.
• The pool mask matters. A pool written as 172.20.64.0/26 covers only .0 to .63, so a giaddr of 172.20.64.129 (on a /24 SVI) matches nothing. Write the pool with the same mask as the VLAN's subnet.
• Primary address only. On an interface with secondary addresses, the relay uses the primary address as giaddr. If the server only has a pool for the secondary subnet, either make that address primary or enable the global ip dhcp smart-relay, which makes the relay switch giaddr to a secondary address after its relayed requests go unanswered.
• The default-router value and the exclusions do not affect pool selection; only the pool's network does.

Option 82 (relay agent information) can also be inserted by a relay, but it does not change giaddr. Option 82 trust with DHCP snooping belongs to Layer 2 security (task 4.7) and is covered there.

The server sends its OFFER and ACK to the giaddr, so it needs a route back to the client subnet, and any firewall in between must allow DHCP in both directions.

• Routing back. If the server's routing table has no route (and no default) covering the giaddr subnet, its replies cannot be delivered. The symptom is DISCOVERs arriving at a server that has a matching pool with free addresses, yet no bindings and no addresses on the clients. Fix it with a static route on the server toward the relay, or by advertising the client subnet into the routing protocol the server learns from. A route on the relay toward the server fixes the wrong direction.
• Ports. Clients send from UDP 68 to 67. Between relay and server, both directions use UDP 67: relay to the server's port 67, server back to the relay agent's port 67. Only the last hop, relay to client, uses port 68. A firewall rule that allows only 68 back from the server drops the replies.

service dhcp switches off server and relay together

service dhcp, on by default, enables both the IOS DHCP server and the DHCP relay agent. no service dhcp, which some hardening templates apply, stops every local pool from leasing and stops every helper address from relaying, even though their configuration is still present.

Because it is one switch for both roles, it cannot retire a single VLAN's service. The scope of a change should match the scope of the problem: a pool is removed with no ip dhcp pool name, and relaying for a VLAN is added or removed with the helper on that VLAN's interface.

A pool is exhausted when leased plus excluded addresses equal its total. show ip dhcp pool shows the numbers:

R4# show ip dhcp pool LOBBY
Pool LOBBY :
 Total addresses                : 510
 Leased addresses               : 498
 Excluded addresses             : 12

Then find out why it filled, because the fix differs:

Shortening leases helps only when idle or departed devices hold addresses; active clients renew at T1 and keep theirs. Any manual clean-up of bindings treats the symptom once; the pool fills again until the cause is fixed. A pool whose mask is narrower than the SVI also hands clients the wrong mask, so fixing the network statement corrects both problems.

An IOS interface becomes a DHCPv4 client with ip address dhcp, typical on an ISP-facing Ethernet link. Similar-looking commands do something else: ip address negotiated uses PPP/IPCP, ipv6 address dhcp is the DHCPv6 client, and ip dhcp client client-id only tunes what an existing DHCP client sends.

R1# show ip interface brief
Interface              IP-Address      OK? Method Status    Protocol
GigabitEthernet0/0     unassigned      YES DHCP   up        up

The Method column shows where the address comes from: DHCP for ip address dhcp, NVRAM or manual for static addresses, unset when no address command exists. DHCP with unassigned on an up/up interface means the client is configured but has no lease yet; look at the ISP side or the exchange itself.

show dhcp lease is the client's view: the leased address, the server that granted it, the lease length and the renewal and rebinding times.

The DHCP-learned default route

When the server supplies a default router, IOS installs a default route with administrative distance 254. That matters for backup designs. The rule: the lower distance wins, so any static default with a distance below 254 is preferred over the DHCP route and carries all traffic, and a distance of 255 means "never trust this route", so it is never installed. A static can only be a backup to the DHCP route if the DHCP route's distance is lower than the static's. The fix is to lower the DHCP route's distance on the client interface with ip dhcp client default-router distance n (below the static's value), so the DHCP route wins while it exists and the static takes over when it disappears.

Troubleshoot by asking how far the exchange got, then use the command that proves it:

Reading the counters

• DISCOVER received does not rise when clients boot: the requests never arrive. Look between client and server: a missing helper on the SVI, a mistyped helper address, or relay disabled. The server counts every DISCOVER it receives, whatever its pools contain, so a flat counter is a delivery problem, not a pool problem.
• DISCOVERs rise, OFFERs stay flat: the server receives but has nothing to offer, usually no pool matching the giaddr, or an exhausted pool.
• DISCOVERs arrive, a matching pool has free addresses, but no bindings form for the subnet: the replies are not getting back, usually no route from the server to the giaddr subnet or a filter on the return path.
• Clients lease normally but cannot leave the subnet: the pool's default-router is missing or wrong. An incomplete ARP entry for the gateway on a client means the advertised gateway does not exist.

DHCPNAK and DHCPDECLINE

The server sends DHCPNAK when a client requests an address that is wrong for its current subnet, for example a tablet carried to another floor's subnet that asks to keep the address it leased on the first floor. The server compares the request with the subnet of the relay's giaddr, refuses, and the client starts over with a DISCOVER. The client sends DHCPDECLINE when its own ARP check after the ACK finds the address in use. NAK flows only from server to client; DECLINE, RELEASE (giving back a lease it holds) and INFORM (asking for options only) are client messages.

The client operating system's own view (ipconfig, ip addr, 169.254 self-assigned addresses) is covered with client connectivity in task 1.6.