Troubleshooting DHCP — Clients Not Getting Addresses

A host that cannot obtain an IP address via DHCP is completely isolated from the network — it cannot reach its gateway, resolve DNS names, or communicate with any other device. DHCP failures are among the most common help-desk escalations in enterprise networks, yet the root causes are almost always one of a small set of well-understood faults: the DHCP server pool is exhausted, a critical address range was over-excluded, the ip helper-address is missing or points to the wrong server, or the DHCP server itself is misconfigured. The DORA handshake (Discover → Offer → Request → Acknowledge) breaks at a predictable point for each of these faults — knowing where it breaks tells you exactly what to fix.

The three primary diagnostic tools for DHCP troubleshooting are show ip dhcp binding (who has been assigned what address), show ip dhcp pool (pool utilisation and available addresses), and debug ip dhcp server events (live view of the DORA exchange as it happens). Together they reveal whether the server is receiving Discovers, whether it has addresses available to offer, whether Requests are completing into bindings, and whether conflicts are being detected.

This guide assumes Layer 1, Layer 2, and Layer 3 are confirmed healthy. If a client cannot even reach the DHCP server due to a physical or routing fault, fix those first using Troubleshooting Layer 1, Troubleshooting Layer 2, and Troubleshooting Layer 3. For DHCP configuration context see DHCP Server Configuration and DHCP Relay Agent.

1. DHCP — Core Concepts & The DORA Process

The DORA Handshake — Step by Step

Every successful DHCP lease begins with a four-message exchange. Understanding each message's source, destination, and purpose allows you to identify exactly which step failed when a client receives no address:

  CLIENT                                                     SERVER
    │                                                           │
    │──── DHCPDISCOVER ────────────────────────────────────────►│
    │  Src: 0.0.0.0:68   Dst: 255.255.255.255:67               │
    │  Client has no IP — broadcasts to find any DHCP server    │
    │                                                           │
    │◄─── DHCPOFFER ────────────────────────────────────────────│
    │  Src: 192.168.10.1:67  Dst: 255.255.255.255:68           │
    │  Server offers an IP, subnet mask, gateway, DNS, lease    │
    │                                                           │
    │──── DHCPREQUEST ─────────────────────────────────────────►│
    │  Src: 0.0.0.0:68   Dst: 255.255.255.255:67               │
    │  Client formally requests the offered address             │
    │  (still broadcast — notifies other servers of choice)     │
    │                                                           │
    │◄─── DHCPACK ──────────────────────────────────────────────│
    │  Src: 192.168.10.1:67  Dst: 255.255.255.255:68           │
    │  Server acknowledges — lease is now active                │
    │                                                           │
  ── Lease Active ─────────────────────────────────────────────────
    │                                                           │
    │  At 50% of lease time: client sends unicast DHCPREQUEST   │
    │  to renew with the same server                            │
    │                                                           │
    │  At 87.5% of lease: broadcast DHCPREQUEST to any server   │
    │  (rebind — original server unreachable)                   │
    │                                                           │
    │  DHCPRELEASE: client voluntarily returns the address      │
    │  DHCPDECLINE: client detected the offered IP is in use    │
    │               (ARP probe conflict) — triggers conflict log│

DORA Failure Points — What Breaks at Each Step

DORA Step	Failure Mode	Cause	Diagnostic
Discover never reaches server	Client broadcasts but server receives nothing — client stays at 169.254.x.x (APIPA)	Missing `ip helper-address` on the router interface facing the client's subnet. DHCP Discover is a broadcast — it cannot cross a router without relay	`show running-config interface [client-facing]` — check for `ip helper-address`
Discover received — no Offer sent	Server receives Discover (visible in debug) but sends no Offer	Pool exhausted (no available addresses), all addresses excluded, wrong network statement in pool, or server is excluded from serving that subnet	`show ip dhcp pool` — check available addresses. `debug ip dhcp server events`
Offer sent — no Request follows	Server sends Offer but client does not Request — client stays at 169.254.x.x	Offer lost in transit (rare), multiple DHCP servers sending competing Offers, client rejects Offer due to wrong options — prevent rogue servers with DHCP Snooping	`debug ip dhcp server events` — look for OFFER then absence of REQUEST
Request received — NAK sent instead of ACK	Client receives a DHCPNAK — rejects its offered address and restarts DORA	Requested address is no longer available (another server ACKed it first), or client is requesting renewal for an address that expired	`debug ip dhcp server events` — look for DHCPNAK messages
ACK sent — client declines	Client sends DHCPDECLINE — address conflict detected	Client ARPs for the offered IP before using it and receives a reply — the address is already in use by a static host	`show ip dhcp conflict` — lists addresses that triggered DECLINE. `show ip dhcp binding`

DHCP Diagnostic Command Reference

Command	Purpose	Key Output Fields
`show ip dhcp binding`	Lists all active leases — IP address, MAC address, lease expiry, and binding type	IP Address, Hardware Address, Lease Expiration, Type (automatic/manual)
`show ip dhcp pool`	Shows pool configuration, total/leased/available address counts, and utilisation	Network, Available/Leased/Excluded counts, Current/Next index
`show ip dhcp conflict`	Lists IP addresses that triggered a DHCPDECLINE — the server will not re-offer these until cleared	IP Address, Detection Method (ping/gratuitous ARP), Detection Time
`show ip dhcp server statistics`	Counts of each message type sent and received — Discovers, Offers, Requests, ACKs, NAKs, Declines, Releases	Message counters — high NAK or Decline counts indicate address conflict issues
`debug ip dhcp server events`	Live event trace — shows each Discover received, Offer sent, Request received, ACK/NAK sent in real time	DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, DHCPNAK, DHCPDECLINE events with client MAC and offered IP
`debug ip dhcp server packet`	Full packet decode — more verbose than events, shows option fields	All DHCP option fields (option 53 type, option 54 server ID, option 51 lease time, option 3 gateway, option 6 DNS)
`show running-config \| section dhcp`	Shows the complete DHCP server configuration — pools, excluded ranges, options	ip dhcp pool, network, default-router, dns-server, lease, domain-name statements

APIPA (Automatic Private IP Addressing): When a Windows client cannot obtain a DHCP address after four DORA attempts, it self-assigns an address in the 169.254.0.0/16 range. This is the most visible symptom of a DHCP failure on Windows hosts. Linux and macOS clients may stay at 0.0.0.0 or show no address at all. An APIPA address on any host is an immediate indicator to investigate DHCP — it never appears on a correctly functioning DHCP deployment.

2. Lab Topology & Scenario

This lab covers six DHCP fault scenarios across a two-site topology where NetsTuts_R1 acts as both the DHCP server for the local VLAN 10 segment and the DHCP relay agent for VLAN 20 and VLAN 30, which receive addresses from a centralised DHCP server (NetsTuts_SRV1):

  VLAN 10 — 192.168.10.0/24 (R1 is DHCP server)
  [PC1..PC30]──SW1──Gi0/1──NetsTuts_R1
                             │ Gi0/2
                             │──── VLAN 20 — 192.168.20.0/24
                             │     [PC31..PC60] — relay to SRV1
                             │ Gi0/3
                             │──── VLAN 30 — 192.168.30.0/24
                             │     [PC61..PC90] — relay to SRV1
                             │ Gi0/0
                    10.0.12.0/30 WAN link
                             │
                      NetsTuts_SRV1 (192.168.99.10)
                      DHCP Server for VLAN 20 and VLAN 30

  R1 DHCP Pool (VLAN 10):
    Network:        192.168.10.0/24
    Excluded:       192.168.10.1 – 192.168.10.10 (routers, printers, servers)
    Range:          192.168.10.11 – 192.168.10.254  (244 addresses)
    Default router: 192.168.10.1
    DNS:            8.8.8.8
    Lease:          1 day

  SRV1 DHCP Pool (VLAN 20):
    Network:        192.168.20.0/24
    Excluded:       192.168.20.1 – 192.168.20.20
    Range:          192.168.20.21 – 192.168.20.254

  SRV1 DHCP Pool (VLAN 30):
    Network:        192.168.30.0/24
    Excluded:       192.168.30.1 – 192.168.30.10
    Range:          192.168.30.11 – 192.168.30.254

  Fault Scenarios:
    Scenario 1 — PC1 gets 169.254.x.x (VLAN 10 — helper-address not needed but pool misconfigured)
    Scenario 2 — New clients in VLAN 10 get no address (pool exhausted)
    Scenario 3 — Clients in VLAN 10 get wrong addresses (over-excluded range)
    Scenario 4 — PC31 gets 169.254.x.x (VLAN 20 — ip helper-address missing on R1)
    Scenario 5 — VLAN 30 clients get 169.254.x.x (helper-address points to wrong IP)
    Scenario 6 — Clients repeatedly getting and losing addresses (DHCP conflicts)

Scenario	Affected Subnet	Symptom	Root Cause
1	VLAN 10	PC1 gets 169.254.x.x — no DHCP offer received	Pool network statement uses wrong subnet mask
2	VLAN 10	New clients get no address after existing clients renew	Pool exhausted — all 244 addresses are leased
3	VLAN 10	Only 4 addresses available despite /24 pool	Excluded range accidentally covers nearly the entire pool
4	VLAN 20	All VLAN 20 clients get 169.254.x.x	`ip helper-address` missing on R1's VLAN 20 interface
5	VLAN 30	All VLAN 30 clients get 169.254.x.x	`ip helper-address` points to 192.168.99.11 (wrong IP — SRV1 is .10)
6	VLAN 10	Clients get addresses then immediately lose them — repeated DHCPDECLINE in debug	Static hosts using IPs inside the DHCP pool range cause address conflicts

3. Scenario 1 — Pool Network Statement Misconfigured

PC1 in VLAN 10 shows a 169.254.x.x address — DHCP failed. R1 is the DHCP server for VLAN 10 and the client is on the same router interface (no relay needed). Layer 1 and 2 are confirmed healthy. The DHCP service is running on R1.

Step 1 — Confirm the Symptom and Check Bindings

NetsTuts_R1#show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address      Client-ID/ Hardware address  Lease expiration  Type
! ── Empty — no bindings at all ──────────────────────────────────

An empty show ip dhcp binding when clients are actively requesting addresses means the server is not completing any DORA exchanges. This rules out pool exhaustion (which would show many bindings) and points to a problem earlier in the DORA process — either the server is not receiving Discovers, or it is receiving them but cannot match them to a pool.

Step 2 — Check the Pool Configuration

NetsTuts_R1#show running-config | section dhcp
ip dhcp excluded-address 192.168.10.1 192.168.10.10
!
ip dhcp pool VLAN10
 network 192.168.10.0 255.255.0.0
 default-router 192.168.10.1
 dns-server 8.8.8.8
 lease 1

The pool network statement reads network 192.168.10.0 255.255.0.0 — a /16 mask. The actual subnet is 192.168.10.0/24, which requires 255.255.255.0. With a /16 mask, the pool covers 192.168.0.0 through 192.168.255.255. When R1 receives a DHCP Discover from a client on 192.168.10.x, it looks for a pool whose network statement matches the client's source subnet. Because the Discover arrives on Gi0/1 (192.168.10.1/24), IOS looks for a pool matching 192.168.10.0/24 — but the pool is defined as 192.168.10.0/16. The mask mismatch means IOS cannot correctly match the pool to the client's subnet, and no Offer is sent.

Step 3 — Use debug to Confirm

NetsTuts_R1#debug ip dhcp server events
DHCP server event debugging is on

! ── Trigger a DHCP request from PC1 (release/renew) ─────────────
DHCPD: DHCPDISCOVER received from client 0063.6973.636f on interface Gi0/1
DHCPD: No subnet for 192.168.10.0 with mask 255.255.255.0
DHCPD: No pool configured for interface 192.168.10.1
DHCPD: Sending DHCPNAK to client 0063.6973.636f

NetsTuts_R1#undebug all

The debug message

No subnet for 192.168.10.0 with mask
    255.255.255.0

is the exact confirmation — IOS is looking for a pool matching /24 but the only pool defined uses /16. The server cannot match the incoming Discover to any valid pool and sends a DHCPNAK. Always run undebug all immediately after capturing the needed output. On a busy router, debug ip dhcp server events generates one line per DHCP message — manageable. Avoid debug ip dhcp server packet on production devices as it is significantly more verbose.

Step 4 — Fix the Pool Network Statement

! ── Remove the existing pool and recreate with correct mask ──────
NetsTuts_R1(config)#no ip dhcp pool VLAN10
NetsTuts_R1(config)#ip dhcp pool VLAN10
NetsTuts_R1(config-dhcp)#network 192.168.10.0 255.255.255.0
NetsTuts_R1(config-dhcp)#default-router 192.168.10.1
NetsTuts_R1(config-dhcp)#dns-server 8.8.8.8
NetsTuts_R1(config-dhcp)#lease 1
NetsTuts_R1(config-dhcp)#exit

! ── Verify pool is correctly defined ─────────────────────────────
NetsTuts_R1#show ip dhcp pool

Pool VLAN10 :
 Utilization mark (high/low)    : 100 / 0
 Subnet size (first/next)       : 0 / 0
 Total addresses                : 254
 Leased addresses               : 0
 Pending event                  : none
 1 subnet is currently in the subnet pool
 Range of addresses             : 192.168.10.1 – 192.168.10.254
 Current index                  : 192.168.10.11

The pool now shows 254 total addresses with the correct range starting at 192.168.10.11 (after the excluded range 192.168.10.1–10 is applied). The current index at 192.168.10.11 confirms the first 10 addresses are excluded. Within 30 seconds of saving the corrected pool, PC1 should complete DORA and receive an address. Trigger a release/renew on PC1 to speed up the process: ipconfig /release then ipconfig /renew on Windows.

4. Scenario 2 — Pool Exhaustion

The VLAN 10 network has been running for months without issues. Suddenly, new devices being connected to the network — a new batch of laptops — cannot obtain addresses. Existing devices retain their addresses. The pool configuration has not changed.

Step 1 — Check Pool Utilisation

NetsTuts_R1#show ip dhcp pool

Pool VLAN10 :
 Utilization mark (high/low)    : 100 / 0
 Subnet size (first/next)       : 0 / 0
 Total addresses                : 254
 Leased addresses               : 244
 Pending event                  : none
 1 subnet is currently in the subnet pool
 Range of addresses             : 192.168.10.1 – 192.168.10.254
 Current index                  : 192.168.10.255

Total 254 addresses, leased 244 — all addresses available to the pool (254 total minus 10 excluded = 244 leasable addresses) are currently leased. The current index at 192.168.10.255 confirms the server has cycled through the entire range. Any new Discover is received but the server has no available address to offer — the Discover is silently dropped. The pool is 100% exhausted.

Step 2 — Identify Who Has Leases

NetsTuts_R1#show ip dhcp binding | include 192.168.10
IP address       Client-ID/ Hardware address   Lease expiration        Type
192.168.10.11    0100.1a2b.3c4d.5e             Mar 08 2026 08:15 AM   Automatic
192.168.10.12    0100.aabb.ccdd.ee12            Mar 08 2026 09:22 AM   Automatic
192.168.10.13    0100.1234.5678.9abc            Mar 08 2026 07:40 AM   Automatic
...
192.168.10.254   0100.ffee.ddcc.bb11            Mar 08 2026 11:05 AM   Automatic

! ── Count total bindings ─────────────────────────────────────────
NetsTuts_R1#show ip dhcp binding | count 192.168.10
244

All 244 addresses are leased and every binding shows an active expiry. A common cause of unexpected pool exhaustion is stale bindings — devices that have been removed or powered off but whose leases have not yet expired. With a 1-day lease, a device powered off at 8 AM will retain its binding until 8 AM the following day, even though it is no longer on the network. The pool effectively runs out because the lease time is too long relative to how quickly devices connect and disconnect.

Step 3 — Immediate Relief and Long-Term Fix

! ── Option A: Clear stale bindings for specific offline hosts ────
NetsTuts_R1#clear ip dhcp binding 192.168.10.150
NetsTuts_R1#clear ip dhcp binding 192.168.10.151

! ── Option B: Clear ALL bindings (use during maintenance only) ───
NetsTuts_R1#clear ip dhcp binding *
! ── Warning: This forces ALL clients to re-request addresses.
!    Active sessions will drop briefly during DORA re-exchange.

! ── Long-term fix 1: Reduce lease time ──────────────────────────
NetsTuts_R1(config)#ip dhcp pool VLAN10
NetsTuts_R1(config-dhcp)#lease 0 8
!                                ^^^^  0 days, 8 hours
NetsTuts_R1(config-dhcp)#exit

! ── Long-term fix 2: Expand the pool (if subnet allows) ──────────
! ── e.g., use a /23 supernet to double available addresses ────────
! ── Requires IP addressing plan change ───────────────────────────

! ── Long-term fix 3: Add a second DHCP pool / subnet ─────────────
! ── Assign a new VLAN for overflow devices ────────────────────────

! ── Verify addresses now available ───────────────────────────────
NetsTuts_R1#show ip dhcp pool
 Total addresses    : 254
 Leased addresses   : 180
 Pending event      : none
 Current index      : 192.168.10.191

Clearing stale bindings immediately frees addresses for new clients. The long-term solution depends on the environment: for highly transient networks (conference rooms, guest Wi-Fi), reduce the lease time to 2–8 hours so addresses recycle quickly. For stable enterprise networks with fixed workstations, a 1-day or 8-day lease is appropriate. Consider allocating a separate VLAN with its own DHCP pool for guest or BYOD devices rather than mixing them with the corporate device pool.

show ip dhcp server statistics — Message Counter Analysis

NetsTuts_R1#show ip dhcp server statistics
Memory usage          : 42389
Address pools         : 1
Database agents       : 0
Automatic bindings    : 244
Manual bindings       : 0
Expired bindings      : 12
Malformed messages    : 0

                    Received  Sent
Messages
BOOTREQUEST         2891
DHCPDISCOVER        2891
DHCPOFFER                     2647    ← Fewer Offers than Discovers
DHCPREQUEST         2647
DHCPACK                       2647
DHCPNAK                       244     ← NAKs sent when pool was full
DHCPDECLINE         0
DHCPRELEASE         388
DHCPINFORM          0

The server statistics reveal the full picture: 2891 Discovers received, only 2647 Offers sent — 244 Discovers were received when the pool was full and got no Offer (silently dropped or NAKed). The DHCPNAK count of 244 matches the number of times a client attempted to renew an expired lease that the server had already reassigned. High NAK counts always warrant investigation — they indicate either pool exhaustion, address conflicts, or clients trying to reclaim expired leases from a different server.

5. Scenario 3 — Over-Excluded Address Range

After a network audit, only four DHCP addresses appear to be available in the VLAN 10 pool despite it being a /24. All new clients beyond the existing four can receive addresses get 169.254.x.x. The router was recently reconfigured by a junior engineer who was asked to "reserve the first 250 addresses for static assignment."

Step 1 — Check the Exclusion Range

NetsTuts_R1#show running-config | section dhcp
ip dhcp excluded-address 192.168.10.1 192.168.10.10
ip dhcp excluded-address 192.168.10.11 192.168.10.250
!
ip dhcp pool VLAN10
 network 192.168.10.0 255.255.255.0
 default-router 192.168.10.1
 dns-server 8.8.8.8
 lease 1

Two exclusion statements exist — the original (192.168.10.1–10.10) and a new one (192.168.10.11–10.250). Together they exclude 192.168.10.1 through 192.168.10.250, leaving only 192.168.10.251–10.254 available — exactly four addresses. The junior engineer's intent was to reserve the first 250 addresses, but the exclusion overlaps with the original exclusion and extends to 10.250, leaving virtually no usable DHCP range. The pool configuration looks valid; only the exclusions reveal the problem.

Step 2 — Confirm with show ip dhcp pool

NetsTuts_R1#show ip dhcp pool

Pool VLAN10 :
 Total addresses                : 254
 Leased addresses               : 4
 Pending event                  : none
 Range of addresses             : 192.168.10.1 – 192.168.10.254
 Current index                  : 192.168.10.255

The pool shows only 4 leased addresses and the current index is already at 192.168.10.255 — the end of the range — despite only 4 leases. This is the key indicator of over-exclusion: the current index has advanced past most of the range without creating bindings, because the addresses were skipped as excluded. show ip dhcp pool does not explicitly show the count of excluded addresses — the available count must be calculated: total (254) minus excluded (250) minus leased (4) = 0 remaining.

Step 3 — Fix the Exclusion Range

! ── Remove the overly broad exclusion ────────────────────────────
NetsTuts_R1(config)#no ip dhcp excluded-address 192.168.10.11 192.168.10.250

! ── Add correct exclusion for static devices only ─────────────────
! ── Example: reserve .1-.10 (already done) and .200-.254 for ─────
! ── servers and printers with static IPs in upper range ──────────
NetsTuts_R1(config)#ip dhcp excluded-address 192.168.10.200 192.168.10.254

! ── Verify exclusions and pool ────────────────────────────────────
NetsTuts_R1#show running-config | section dhcp
ip dhcp excluded-address 192.168.10.1 192.168.10.10
ip dhcp excluded-address 192.168.10.200 192.168.10.254

NetsTuts_R1#show ip dhcp pool
 Total addresses    : 254
 Leased addresses   : 4
 Pending event      : none
 Current index      : 192.168.10.12

! ── Available: 254 - 10 (1-10) - 55 (200-254) - 4 (leased) = 185 ─

After correcting the exclusion range, the current index resets to 192.168.10.12 (the first non-excluded, non-leased address) and 185 addresses are now available. The best practice for DHCP address planning is to keep static device IPs either at the very bottom of the range (covered by a low exclusion like .1–.20) or at the very top (.200–.254), with the DHCP pool occupying the middle. This creates a clean, non-overlapping boundary between statically and dynamically assigned addresses.

DHCP Address Planning Best Practices

Address Range	Purpose	Configuration
192.168.10.1 – 192.168.10.10	Network infrastructure — router interfaces, L3 switch SVIs, management IPs	`ip dhcp excluded-address 192.168.10.1 192.168.10.10`
192.168.10.11 – 192.168.10.199	DHCP pool — dynamically assigned to workstations, laptops, phones	Pool range (no exclusion needed in this range)
192.168.10.200 – 192.168.10.254	Static devices — servers, printers, IP cameras, APs with static IPs	`ip dhcp excluded-address 192.168.10.200 192.168.10.254`

6. Scenario 4 — Missing ip helper-address (DHCP Relay)

All clients in VLAN 20 (192.168.20.0/24) are showing 169.254.x.x addresses. The DHCP server for VLAN 20 is SRV1 at 192.168.99.10, reached through R1. VLAN 10 clients (served by R1 locally) are getting addresses without issues. VLAN 20 is a separate subnet on R1's Gi0/2 interface.

Why ip helper-address is Needed

  DHCP Discovers are Layer 2 broadcasts (destination 255.255.255.255).
  Routers do not forward broadcasts between subnets by default.

  Without ip helper-address:
    PC31 sends DHCPDISCOVER → 255.255.255.255 (broadcast)
    R1 receives it on Gi0/2 (192.168.20.1) — drops it silently
    SRV1 never receives the Discover → never sends an Offer
    PC31 waits, retries 4 times, assigns 169.254.x.x (APIPA)

  With ip helper-address 192.168.99.10 on Gi0/2:
    PC31 sends DHCPDISCOVER → 255.255.255.255 (broadcast)
    R1 receives it on Gi0/2 — RELAY AGENT kicks in:
      - Changes source IP to R1's Gi0/2 address (192.168.20.1)
      - Changes destination to 192.168.99.10 (unicast to SRV1)
      - Adds Option 82 (relay agent info) including the
        giaddr field = 192.168.20.1 (tells server which subnet)
    SRV1 receives the unicast Discover, looks up which pool
      matches giaddr 192.168.20.1 → selects VLAN20 pool
    SRV1 unicasts the Offer back to R1
    R1 relays the Offer back to PC31 as a broadcast

Step 1 — Confirm Missing Helper on R1

NetsTuts_R1#show running-config interface GigabitEthernet0/2
Building configuration...
interface GigabitEthernet0/2
 ip address 192.168.20.1 255.255.255.0
 no shutdown
!

! ── No ip helper-address — broadcasts will not be relayed ────────

NetsTuts_R1#show running-config interface GigabitEthernet0/3
Building configuration...
interface GigabitEthernet0/3
 ip address 192.168.30.1 255.255.255.0
 ip helper-address 192.168.99.10
 no shutdown
!
! ── VLAN 30 has helper-address — VLAN 20 does not ────────────────

The absence of ip helper-address on Gi0/2 (the VLAN 20 interface) is immediately visible in the running config. VLAN 30's Gi0/3 shows the correct helper-address — this makes VLAN 20 clearly the outlier. The DHCP server SRV1 never receives any Discovers from VLAN 20 clients because R1 drops them at the router boundary. This is confirmed by the fact that VLAN 10 (local pool on R1) and VLAN 30 (correct helper) both work.

Step 2 — Confirm with debug on R1

NetsTuts_R1#debug ip dhcp server events

! ── PC31 sends a Discover — watch what R1 does ───────────────────
DHCPD: DHCPDISCOVER received from client 0100.aabb.1234.5678
       on interface GigabitEthernet0/2
DHCPD: No subnet for 192.168.20.0 with mask 255.255.255.0
DHCPD: No relay configured for interface 192.168.20.1

NetsTuts_R1#undebug all

The debug message

No relay configured for interface
    192.168.20.1

is the explicit confirmation — R1 received the Discover but has no relay configuration for that interface, so it cannot forward it to SRV1. Note that R1 also shows "No subnet for 192.168.20.0" because R1 itself has no DHCP pool for 192.168.20.0 — it is expected to relay, not serve. Without the helper, the Discover goes nowhere.

Step 3 — Add the Helper Address

NetsTuts_R1(config)#interface GigabitEthernet0/2
NetsTuts_R1(config-if)#ip helper-address 192.168.99.10
NetsTuts_R1(config-if)#exit

! ── Verify ────────────────────────────────────────────────────────
NetsTuts_R1#show running-config interface GigabitEthernet0/2
interface GigabitEthernet0/2
 ip address 192.168.20.1 255.255.255.0
 ip helper-address 192.168.99.10
 no shutdown

! ── Confirm DHCP relay is forwarding ─────────────────────────────
NetsTuts_R1#debug ip dhcp server events
DHCPD: DHCPDISCOVER received from client 0100.aabb.1234.5678
       on interface GigabitEthernet0/2
DHCPD: Forwarding DHCPDISCOVER to 192.168.99.10
DHCPD: DHCPOFFER received from server 192.168.99.10
DHCPD: Forwarding DHCPOFFER to client 0100.aabb.1234.5678

NetsTuts_R1#undebug all

The relay is now working — R1 forwards the Discover to SRV1 (192.168.99.10) and relays the Offer back to PC31. Within seconds PC31 completes DORA and receives a 192.168.20.x address. The ip helper-address command is per-interface — it must be configured on every router interface that faces a client subnet where the DHCP server is not local. Multiple helper-addresses can be configured on a single interface to relay to multiple DHCP servers simultaneously (for redundancy).

ip helper-address — What It Forwards

By default, ip helper-address relays eight UDP broadcast protocols — not just DHCP. Understanding the full list is important for environments where other broadcast-based services are also in use:

UDP Port	Protocol	Notes
67/68	DHCP / BOOTP	Primary use case — always relayed
69	TFTP	Legacy — relayed by default but rarely needed
37	Time (RFC 868)	Legacy time protocol — NTP preferred instead
49	TACACS	Legacy authentication — TACACS+ uses TCP
53	DNS	DNS queries broadcast — relayed to helper IP
137	NetBIOS Name Service	Windows name resolution broadcast
138	NetBIOS Datagram	Windows broadcast datagram
9	Discard (Wake-on-LAN)	Magic packet forwarding

7. Scenario 5 — Wrong Helper Address

VLAN 30 clients (192.168.30.0/24) are all showing 169.254.x.x. The interface Gi0/3 on R1 does have an ip helper-address configured — so the relay is set up. SRV1 (the correct DHCP server) is at 192.168.99.10.

Step 1 — Inspect the Helper Address

NetsTuts_R1#show running-config interface GigabitEthernet0/3
interface GigabitEthernet0/3
 ip address 192.168.30.1 255.255.255.0
 ip helper-address 192.168.99.11
 no shutdown

! ── SRV1 is at 192.168.99.10 — helper points to .11 (wrong) ─────

The helper-address is 192.168.99.11 — a non-existent host. SRV1 is at 192.168.99.10. R1 relays DHCP Discovers to 192.168.99.11, which has no DHCP service. The Discover disappears into the void — no Offer is ever returned. This is a one-character typo (11 instead of 10) but causes a complete DHCP outage for the entire VLAN 30 subnet.

Step 2 — Confirm with debug

NetsTuts_R1#debug ip dhcp server events
DHCPD: DHCPDISCOVER received on interface GigabitEthernet0/3
DHCPD: Forwarding DHCPDISCOVER to 192.168.99.11
! ── No DHCPOFFER ever follows — 192.168.99.11 does not respond ───
! ── After timeout, client retries — same pattern repeats ─────────

NetsTuts_R1#undebug all

! ── Verify 192.168.99.11 is unreachable ──────────────────────────
NetsTuts_R1#ping 192.168.99.11
Sending 5, 100-byte ICMP Echos to 192.168.99.11:
.....
Success rate is 0 percent (0/5)

NetsTuts_R1#ping 192.168.99.10
Sending 5, 100-byte ICMP Echos to 192.168.99.10:
!!!!!
Success rate is 100 percent (5/5)

The debug confirms relaying is happening — but to the wrong destination. The ping test quickly validates which IP is the real SRV1: 192.168.99.10 responds, 192.168.99.11 does not. When troubleshooting a wrong helper-address, always ping the configured helper IP from the router — if it does not respond, either the IP is wrong, the server is down, or there is a routing problem between the router and the DHCP server.

Step 3 — Fix the Helper Address

NetsTuts_R1(config)#interface GigabitEthernet0/3
NetsTuts_R1(config-if)#no ip helper-address 192.168.99.11
NetsTuts_R1(config-if)#ip helper-address 192.168.99.10
NetsTuts_R1(config-if)#exit

! ── Verify ────────────────────────────────────────────────────────
NetsTuts_R1#show running-config interface GigabitEthernet0/3
interface GigabitEthernet0/3
 ip address 192.168.30.1 255.255.255.0
 ip helper-address 192.168.99.10
 no shutdown

! ── Test: Trigger DHCP on a VLAN 30 client ───────────────────────
! ── On PC61: ipconfig /release then ipconfig /renew ──────────────
! ── Expected: PC61 receives 192.168.30.x address ─────────────────

NetsTuts_R1#show ip dhcp binding | include 192.168.30
192.168.30.11   0100.beef.cafe.0061   Mar 08 2026 14:30 PM   Automatic

The binding for PC61 appears with an address in the correct 192.168.30.x range — DORA completed successfully through the corrected relay. When removing and re-adding the helper-address, always use no ip helper-address [old-ip] with the full incorrect IP — using no ip helper-address alone without specifying the address removes all helper addresses on that interface, which may be unintended if multiple helpers are configured.

8. Scenario 6 — DHCP Address Conflicts

VLAN 10 clients are intermittently losing their DHCP-assigned addresses shortly after receiving them. Syslog shows repeated DHCPDECLINE messages. Some clients cycle between 169.254.x.x and a DHCP address every few minutes. Investigation reveals that several printers and servers in VLAN 10 were configured with static IPs inside the DHCP pool range.

Step 1 — Observe the Decline Pattern in debug

NetsTuts_R1#debug ip dhcp server events
DHCPD: DHCPDISCOVER from client 0100.1111.2222.3333 on Gi0/1
DHCPD: Sending DHCPOFFER of 192.168.10.25 to client
DHCPD: DHCPREQUEST for 192.168.10.25 from client
DHCPD: Sending DHCPACK of 192.168.10.25 to client
DHCPD: DHCPDECLINE of 192.168.10.25 from client
!      ^^^^^^^^^^^^^^^^ Client ARPed for .25, got a reply from the
!      printer at .25 — conflict detected, client declines address
DHCPD: Adding 192.168.10.25 to conflict table
DHCPD: DHCPDISCOVER from client 0100.1111.2222.3333 on Gi0/1
DHCPD: Sending DHCPOFFER of 192.168.10.30 to client
! ── Pattern repeats as each conflicted address is offered ─────────

NetsTuts_R1#undebug all

The DORA exchange completes (Discover → Offer → Request → ACK) but the client immediately sends DHCPDECLINE after the ACK. This is the address conflict detection mechanism — before using a DHCP-assigned address, a client sends an ARP probe (ARP for the offered IP with source IP 0.0.0.0). If any device replies to that ARP, the offered IP is already in use. The client declines the address and informs the server. The server records the address in its conflict table and will not re-offer it until the conflict is manually cleared.

Step 2 — Check the Conflict Table

NetsTuts_R1#show ip dhcp conflict

IP address        Detection method   Detection time          VRF
192.168.10.25     Gratuitous ARP     Mar 07 2026 10:15:22
192.168.10.30     Gratuitous ARP     Mar 07 2026 10:17:44
192.168.10.45     Gratuitous ARP     Mar 07 2026 10:22:09
192.168.10.50     Ping               Mar 07 2026 09:55:01
192.168.10.51     Ping               Mar 07 2026 09:55:14

Five addresses are in the conflict table — the server will not offer any of these until they are explicitly cleared, even if the conflicting static device is removed from the network. Note two detection methods: Gratuitous ARP (detected during the client's ARP probe after receiving ACK) and Ping (the Cisco DHCP server itself pings an address before offering it — if a reply comes back, the address is recorded as conflicted before it is even offered). The Cisco IOS DHCP server pings an address one or two times before offering it as a proactive conflict-avoidance mechanism.

Step 3 — Identify the Conflicting Static Hosts

! ── ARP table shows who has the conflicted addresses ─────────────
NetsTuts_R1#show arp | include 192.168.10.25
Internet  192.168.10.25   5    00aa.bb11.2233   ARPA  GigabitEthernet0/1

NetsTuts_R1#show arp | include 192.168.10.30
Internet  192.168.10.30   3    00aa.bb11.4455   ARPA  GigabitEthernet0/1

! ── Use MAC addresses to identify the devices ─────────────────────
! ── Check switch MAC address table ───────────────────────────────
NetsTuts_SW1#show mac address-table address 00aa.bb11.2233
          Mac Address Table
-------------------------------------------
Vlan  Mac Address     Type     Ports
----  -----------     ----     -----
  10  00aa.bb11.2233  STATIC   Fa0/12    ← Printer on Fa0/12 with static .25

The ARP table reveals which MAC addresses own the conflicted IPs, and the MAC address table on the switch maps those MACs to physical ports. The printer on Fa0/12 is statically configured with 192.168.10.25, which is inside the DHCP pool range (192.168.10.11–254). The printer's static IP was never excluded from the DHCP pool, so the server can offer that address to a DHCP client — triggering the conflict.

Step 4 — Fix: Exclude Conflicted Addresses

! ── Option A: Exclude all static device IPs from the DHCP pool ──
NetsTuts_R1(config)#ip dhcp excluded-address 192.168.10.25
NetsTuts_R1(config)#ip dhcp excluded-address 192.168.10.30
NetsTuts_R1(config)#ip dhcp excluded-address 192.168.10.45
NetsTuts_R1(config)#ip dhcp excluded-address 192.168.10.50
NetsTuts_R1(config)#ip dhcp excluded-address 192.168.10.51

! ── Option B: Move static devices to the excluded upper range ─────
! ── Reconfigure printer from 192.168.10.25 to 192.168.10.210 ─────
! ── (in the excluded 192.168.10.200-254 range) ───────────────────

! ── Clear the conflict table so those addresses can be used ───────
NetsTuts_R1#clear ip dhcp conflict *

! ── Verify conflict table is empty ───────────────────────────────
NetsTuts_R1#show ip dhcp conflict
! ── Empty ─────────────────────────────────────────────────────────

! ── Verify no conflicted addresses in binding ────────────────────
NetsTuts_R1#show ip dhcp binding | include 192.168.10
192.168.10.11  0100.1111.2222.3333  Mar 08 2026 14:00   Automatic
192.168.10.12  0100.4444.5555.6666  Mar 08 2026 14:05   Automatic

clear ip dhcp conflict * clears the entire conflict table — the server can now re-offer those addresses (after they have been properly excluded or the static devices have been moved). Always clear conflicts after fixing the underlying cause, not before — clearing without fixing means the conflict will reoccur immediately when the server offers the address again. Option B (moving static devices to the excluded upper range) is the cleaner long-term solution because it eliminates the problem at its source and requires no per-address exclusions.

9. Full Diagnostic Command Reference & Decision Tree

show ip dhcp binding — Complete Field Guide

NetsTuts_R1#show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address      Client-ID/ Hardware address  Lease expiration         Type
192.168.10.11   0100.1a2b.3c4d.5e6f         Mar 08 2026 08:00 AM    Automatic
192.168.10.12   0100.aabb.ccdd.ee12         Mar 08 2026 09:22 AM    Automatic
192.168.10.13   0100.1234.5678.9abc         Infinite                 Manual

! ── Field meanings ───────────────────────────────────────────────
! IP address       : Address currently leased to this client
! Client-ID        : 01 + MAC address (01 = Ethernet ARP type)
!                    or DHCP client-identifier option 61 string
! Lease expiration : When this binding expires — "Infinite" = manual
! Type             : Automatic = DHCP pool assigned
!                    Manual    = Static DHCP binding (ip dhcp pool /
!                                host command)

! ── Useful filters ────────────────────────────────────────────────
NetsTuts_R1#show ip dhcp binding | count           ! total leases
NetsTuts_R1#show ip dhcp binding | include [vlan]  ! filter by subnet
NetsTuts_R1#show ip dhcp binding | include Infinite ! manual bindings only

debug ip dhcp server events — Annotated Output

NetsTuts_R1#debug ip dhcp server events

! ── Successful DORA ───────────────────────────────────────────────
DHCPD: DHCPDISCOVER received from client 0100.cafe.babe.0001  ← D
       on interface GigabitEthernet0/1
DHCPD: Sending DHCPOFFER of 192.168.10.15 to client           ← O
DHCPD: DHCPREQUEST for 192.168.10.15 from client              ← R
DHCPD: Sending DHCPACK of 192.168.10.15 to client 0100.cafe.babe.0001 ← A

! ── Pool exhaustion ───────────────────────────────────────────────
DHCPD: DHCPDISCOVER received from client 0100.dead.beef.0002
DHCPD: There are no addresses available in pool VLAN10

! ── Wrong network statement ───────────────────────────────────────
DHCPD: DHCPDISCOVER received from client 0100.1234.5678.9999
DHCPD: No subnet for 192.168.10.0 with mask 255.255.255.0
DHCPD: No pool configured for interface 192.168.10.1

! ── Missing relay ─────────────────────────────────────────────────
DHCPD: DHCPDISCOVER received from client 0100.aabb.1234.5678
       on interface GigabitEthernet0/2
DHCPD: No relay configured for interface 192.168.20.1

! ── Address conflict ──────────────────────────────────────────────
DHCPD: DHCPDECLINE of 192.168.10.25 from client
DHCPD: Adding 192.168.10.25 to conflict table

! ── Relay working ─────────────────────────────────────────────────
DHCPD: Forwarding DHCPDISCOVER to 192.168.99.10
DHCPD: DHCPOFFER received from server 192.168.99.10

NetsTuts_R1#undebug all

DHCP Troubleshooting Decision Tree

Symptom	First Command	Key Finding	Fix
Client gets 169.254.x.x — same subnet as server	`show ip dhcp pool`	Pool misconfigured (wrong mask) or all addresses excluded	Fix `network` statement mask or adjust `ip dhcp excluded-address`
Client gets 169.254.x.x — different subnet from server	`show run interface [client-facing]`	Missing `ip helper-address`	Add `ip helper-address [server-ip]` to the client-facing interface
Relay configured but still 169.254.x.x	`ping [helper-ip]` from router + `debug ip dhcp server events`	Wrong helper IP, server unreachable, or server has no pool for that subnet	Correct helper IP; fix routing to server using show ip route; add matching pool on server
Some clients get addresses, new ones cannot	`show ip dhcp pool`	Leased count equals total available — pool exhausted	`clear ip dhcp binding *` (maintenance); reduce lease time; expand pool
Very few addresses available despite /24 pool	`show run \| section dhcp`	Over-broad `ip dhcp excluded-address` range	`no ip dhcp excluded-address [start] [end]` for the incorrect range, add correct narrower exclusion
Clients get addresses then immediately lose them	`debug ip dhcp server events`	DHCPDECLINE messages — address conflict	`show ip dhcp conflict` → identify static hosts → exclude those IPs or move static devices
Clients get addresses from wrong pool/subnet	`show ip dhcp binding` + `show run \| section dhcp`	Pool network statement matches wrong subnet, or rogue DHCP server on segment	Fix pool network statement; use `debug ip dhcp server events` to find rogue server MAC; deploy DHCP Snooping to block rogue servers
Specific client never gets address (others fine)	`show ip dhcp binding` + `debug ip dhcp server events`	Client's MAC in conflict table, or client has static IP configured despite requesting DHCP	`clear ip dhcp conflict [ip]`; check client NIC settings for static IP override
DHCP works but clients cannot reach gateway	`show ip dhcp binding` + client `ipconfig`	Wrong `default-router` in pool, or no default-router configured	Add/correct `default-router [gateway-ip]` in the DHCP pool
DHCP works but DNS resolution fails	`show run \| section dhcp`	Missing or wrong `dns-server` statement in pool	Add/correct `dns-server [dns-ip]` in the DHCP pool

Key Points & Exam Tips

A client showing 169.254.x.x (APIPA on Windows) or no address means DORA failed — begin diagnosis at the first step where the process breaks: Discover not reaching the server, no Offer returned, or DHCPDECLINE after ACK.
ip helper-address is required on every router interface facing a client subnet when the DHCP server is on a different subnet. DHCP Discovers are broadcasts — routers block them without the relay configured.
The ip helper-address relays eight UDP broadcast protocols by default — not just DHCP (ports 67/68). Use no ip forward-protocol udp [port] to disable specific protocols from being relayed if needed.
show ip dhcp pool shows total, leased, and available address counts — the fastest way to confirm pool exhaustion. If leased equals total-minus-excluded, the pool is full.
When adding VLANs to an existing exclusion list, always use separate exclusion ranges at the top and bottom of the /24 — never a single exclusion that spans the middle of the pool.
DHCPDECLINE means the client detected a conflict — the server offered an address that is already in use by a static device. The server adds that address to its conflict table and will not re-offer it until cleared with clear ip dhcp conflict [ip] or clear ip dhcp conflict *.
The Cisco IOS DHCP server pings an address before offering it as a proactive conflict check — if a ping reply comes back, the address is added to the conflict table instead of being offered.
debug ip dhcp server events is the most useful DHCP debug — it shows each DORA step in real time without the excessive verbosity of debug ip dhcp server packet. Always follow with undebug all. Persistent DHCP event logging without debug can be achieved via Syslog.
Multiple ip helper-address statements can be configured on one interface for DHCP redundancy — the Discover is forwarded to each helper IP simultaneously and the client uses the first Offer received.
On the CCNA exam: know the DORA message sequence and what each message uses as source/destination IPs, the purpose and placement of ip helper-address, how to read show ip dhcp pool for exhaustion, and what DHCPDECLINE indicates.

Next Steps: With DHCP confirmed operational, verify DNS resolution is working — a client may get a correct IP address but still fail to resolve names if the dns-server option in the DHCP pool is missing or incorrect. See DNS for an overview of how DNS and DHCP work together. For DHCP server configuration from scratch see DHCP Server Configuration. For relay agent configuration detail see DHCP Relay Agent. For access control issues after DHCP succeeds see Extended ACL Configuration. For Layer 3 issues that prevent relayed DHCP from reaching the server see Troubleshooting Layer 3.

TEST WHAT YOU LEARNED

1. A Windows client in VLAN 20 shows an IP address of 169.254.45.12. The DHCP server for VLAN 20 is on a different subnet. R1 has an interface in VLAN 20 with an IP address. What is the most likely cause, and which command on R1 confirms it?

A. The DHCP server pool for VLAN 20 is exhausted — confirmed with show ip dhcp pool on the server B. ip helper-address is missing on R1's VLAN 20 interface — DHCP Discovers are broadcast and cannot cross a router without relay. Confirmed with show running-config interface [VLAN20-interface] on R1 — absence of an ip helper-address line is the fault. The 169.254.x.x (APIPA) address confirms the client sent multiple Discovers and received no Offer C. The client's NIC is faulty — 169.254.x.x indicates a hardware-level failure D. The VLAN 20 interface on R1 is administratively shut — the Discover cannot leave the client's NIC

Correct answer is B. A 169.254.x.x (APIPA) address on Windows means the client sent DHCPDISCOVER broadcasts but received no DHCPOFFER within the timeout period. When the DHCP server is on a different subnet, DHCP Discovers (which are Layer 2 broadcasts, destination 255.255.255.255) cannot cross a router boundary without a relay agent. The ip helper-address command on the router's client-facing interface converts the broadcast Discover into a unicast packet forwarded to the DHCP server. Its absence means every Discover is silently dropped at R1's interface. The definitive check is show running-config interface [VLAN20-interface] — if no ip helper-address line is present, that is the cause. Pool exhaustion (Option A) would require the server to have received and processed many Discovers first, which cannot happen if they never reach the server. A shut interface (Option D) would cause Layer 1/2 failure visible in show interfaces, not a DHCP-specific failure.

2. `show ip dhcp pool` shows: Total addresses: 254, Leased addresses: 244, Current index: 192.168.10.255. A new client sends a DHCPDISCOVER. What happens, and what are the two correct long-term fixes?

A. The server sends a DHCPNAK — the pool is full. Fix: increase the lease time so addresses are retained longer B. The server assigns the next available address above 192.168.10.255 — the current index wraps to 192.168.10.11 C. The server checks for expired bindings in real time and immediately offers one to the new client D. The server has no available addresses — it drops the Discover silently and the client gets no Offer. The pool is exhausted (244 leasable addresses = 254 total minus 10 excluded, all leased). Two correct long-term fixes: (1) reduce the lease time so addresses recycle faster when devices disconnect — use lease 0 8 for 8 hours in transient environments; (2) expand the address space by using a larger subnet or adding a new VLAN/subnet for overflow devices

Correct answer is D. When the DHCP pool is completely exhausted, the server receives the Discover but has no address to offer — it simply drops the Discover. The client receives no Offer and will retry up to four times before assigning an APIPA address. The current index at 192.168.10.255 (the broadcast address, past the end of the range) confirms the pool has been cycled through completely. The immediate relief is clear ip dhcp binding * during a maintenance window to force all clients to re-request — stale bindings from powered-off devices will not renew and those addresses become available. Long-term: reducing lease time means addresses from disconnected devices recycle faster. Option A is incorrect — DHCPNAK is sent when a client requests a specific address that is no longer valid (e.g., from an expired lease), not when the pool is generally exhausted from a new Discover. Option B is incorrect — DHCP pools do not dynamically expand beyond their configured network range.

3. `debug ip dhcp server events` shows: `DHCPD: DHCPDECLINE of 192.168.10.50 from client` followed by `DHCPD: Adding 192.168.10.50 to conflict table`. This pattern repeats for several addresses. What is happening and what is the root cause?

A. The DHCP server is misconfigured — it is offering the same IP to multiple clients simultaneously B. The clients have static IPs configured and are rejecting DHCP offers to keep their static addresses C. The DORA exchange is completing (ACK is sent) but the client sends DHCPDECLINE after performing an ARP probe for the offered IP — another device replied to the ARP, indicating the address is already in use. The root cause is that static hosts have IPs inside the DHCP pool range that have never been excluded. The fix requires identifying those static devices (via show ip dhcp conflict then show arp), excluding their IPs with ip dhcp excluded-address, and clearing the conflict table with clear ip dhcp conflict * D. The DHCP pool's lease time is too short — clients are declining renewals because the lease expired before they could use the address

Correct answer is C. DHCPDECLINE is sent by the client, not the server, and it means the client completed DORA (received an ACK) but detected that the offered IP is already in use before applying it. The detection mechanism is an ARP probe — the client broadcasts an ARP request for the offered IP with its own source IP set to 0.0.0.0. If any device on the segment replies, the client knows there is a conflict and sends DHCPDECLINE to the server. The server then adds the address to its conflict table and will never re-offer it until explicitly cleared. The root cause in this scenario is static devices (printers, servers) that were assigned IPs inside the DHCP range without corresponding exclusions in the pool configuration. The fix is two-part: exclude the static device IPs from the pool (so the server never offers them), and clear the existing conflict table entries. Note that the server's own proactive ping mechanism may also add entries to the conflict table if it pings an address before offering it and receives a reply.

4. A DHCP pool is configured as: `network 192.168.10.0 255.255.255.0`, `ip dhcp excluded-address 192.168.10.1 192.168.10.10`, and `ip dhcp excluded-address 192.168.10.11 192.168.10.249`. How many addresses are available for DHCP assignment and what is the fix?

A. Only 5 addresses are available: 192.168.10.250 through 192.168.10.254 — the two exclusion ranges together cover .1 through .249. The /24 broadcast address (.255) and network address (.0) are not assignable. Fix: remove the second over-broad exclusion with no ip dhcp excluded-address 192.168.10.11 192.168.10.249 and replace with a narrower exclusion that only covers the actual static devices B. 244 addresses — the two exclusion ranges are cumulative from .1 to .10 only, and the second range starts fresh C. 0 addresses — overlapping exclusion ranges cause the entire pool to be invalidated D. 239 addresses — IOS automatically merges overlapping exclusion ranges and deduplicates them

Correct answer is A. The two exclusion ranges are cumulative and do not overlap — the first covers 192.168.10.1 through 192.168.10.10, the second covers 192.168.10.11 through 192.168.10.249. Together they exclude 192.168.10.1 through 192.168.10.249 — a total of 249 addresses. The /24 network has 254 usable host addresses (.1 through .254). After removing all excluded addresses, only .250, .251, .252, .253, and .254 remain — five addresses. The network address (.0) and broadcast (.255) are never assignable regardless. This is the over-exclusion scenario — the junior engineer intended to reserve the first 249 addresses for static use but accidentally excluded nearly the entire pool. The fix is to remove the second exclusion and add a more targeted one that covers only the actual static device IPs, leaving the majority of the pool available for DHCP.

5. R1 has `ip helper-address 10.0.0.5` on its VLAN 10 interface. VLAN 10 clients are getting APIPA addresses. `ping 10.0.0.5` from R1 returns all exclamation marks. `debug ip dhcp server events` shows Discovers being forwarded to 10.0.0.5, but no Offer is returned. What is the most likely cause?

A. The ip helper-address is wrong — 10.0.0.5 is not the DHCP server B. R1's DHCP relay is disabled — run service dhcp to enable it C. The DHCP server at 10.0.0.5 is reachable but has no pool configured for the 192.168.10.0/24 subnet — it receives the relayed Discover, checks its pools for one matching the client's giaddr (192.168.10.1), finds no matching pool, and silently discards the Discover without sending an Offer. Fix: add a DHCP pool for 192.168.10.0/24 on the server at 10.0.0.5 D. The firewall between R1 and 10.0.0.5 is blocking UDP port 67 — DHCP relay uses TCP

Correct answer is C. The diagnostic sequence here is methodical: the ping to 10.0.0.5 succeeds (rules out wrong helper IP and routing problems), the debug shows forwarding is happening (rules out missing helper or relay misconfiguration), but no Offer returns. The relay is working correctly — the problem is on the server side. When a DHCP relay agent forwards a Discover, it sets the giaddr (gateway IP address) field in the DHCP packet to the IP of the interface that received the original Discover — in this case, 192.168.10.1 (R1's VLAN 10 interface). The DHCP server uses giaddr to determine which pool to assign from — it looks for a pool whose network statement matches the giaddr's subnet. If no pool for 192.168.10.0/24 exists on the server, it discards the Discover silently. Option A is ruled out by the successful ping. Option D is incorrect — DHCP uses UDP (not TCP) port 67 for server-side communication. DHCP relay traffic between the relay agent and the DHCP server uses UDP 67 in both directions.

6. What is the purpose of the `giaddr` field in a relayed DHCP Discover packet, and why is it critical for correct server operation?

A. It contains the gateway (default router) that the DHCP server should assign to the client in the Offer B. It identifies the MAC address of the relay agent so the server knows where to send the Offer C. It contains the broadcast address of the client's subnet so the server can calculate available addresses D. The giaddr (Gateway IP Address) field is set by the relay agent to the IP address of the interface that received the client's original DHCP Discover. The DHCP server uses giaddr to determine which pool to select — it looks for a pool whose network statement matches the subnet containing giaddr. Without giaddr, the server cannot determine which subnet the client is on and cannot select the correct pool. It also tells the server where to send the Offer (unicast back to the relay agent's giaddr IP) rather than broadcasting

Correct answer is D. The giaddr field is the mechanism that makes DHCP relay work across multiple subnets with a single server. When R1 relays a Discover from VLAN 10 (its interface IP is 192.168.10.1), it sets giaddr = 192.168.10.1. The server receives this, identifies that the client is on the 192.168.10.0/24 subnet, and selects the pool whose network statement matches that subnet. The Offer is then unicast back to 192.168.10.1 (R1), which relays it back to the client as a broadcast. This is why a DHCP server must have a pool for every client subnet it serves — the pool network must match the subnet of each relay agent's giaddr. Option A is a common confusion — the default router for clients is configured in the pool's default-router statement, not derived from giaddr. The giaddr is used for pool selection and reply routing, not for client gateway assignment (though they happen to be the same IP in many cases).

7. A network has 50 VLAN 10 clients all with valid 192.168.10.x addresses. A new client PC51 gets 169.254.x.x. `show ip dhcp pool` shows 44 leased addresses out of 244 available. `debug ip dhcp server events` shows the Discover is received and an Offer of 192.168.10.75 is sent, but a Request never follows. What is the most likely cause?

A. The DHCP pool lease time is too short — PC51's lease expired before the Request was sent B. A rogue DHCP server on the segment is also responding to PC51's Discover with a competing Offer. PC51 may be accepting the rogue server's Offer (which could be from a different subnet or contain invalid options) and sending its Request to the rogue server instead of R1. Confirmed by checking if PC51 gets an address but from an unexpected range, or by capturing the Offer packets to see if two Offers arrive C. PC51's NIC is configured with a static IP — it broadcasts Discovers out of habit but ignores all Offers D. The Offer packet from R1 was dropped by a port-security violation on the switch — PC51's MAC triggered a violation

Correct answer is B. When an Offer is sent but no Request follows, it means either the Offer never reached the client, or the client chose a different server's Offer instead. Since DHCP Discovers are broadcast, any DHCP server on the segment will respond. If a rogue DHCP server (an unauthorized server — perhaps someone's router connected to the network, or a misconfigured virtual machine) is also sending Offers, PC51 may receive two Offers and choose the rogue server's. The client then sends its Request directly to the rogue server (identified in the Request's Option 54 — Server Identifier field), which R1 does not see as addressed to it and ignores. The rogue server sends an ACK, and PC51 gets an address from the rogue server — but it may be in the wrong subnet, have an incorrect gateway, or no DNS. On Cisco switches, use DHCP Snooping (ip dhcp snooping) to prevent rogue DHCP servers — it allows only trusted ports (uplinks to legitimate servers) to send DHCP Offers and NAKs, silently dropping Offers on untrusted ports (access ports facing clients).

8. An engineer wants to pre-assign a specific IP address (192.168.10.100) to a server based on its MAC address (00AA.BB11.2233) so it always gets the same IP from DHCP. What is the correct Cisco IOS configuration?

A. ip dhcp excluded-address 192.168.10.100 — excluding an address pre-assigns it to the device with that IP B. ip dhcp pool VLAN10 then reserved-address 192.168.10.100 00AA.BB11.2233 C. Create a separate named DHCP pool with host 192.168.10.100 255.255.255.0 and hardware-address 00AA.BB11.2233. This creates a manual binding — when that specific MAC sends a Discover, the server offers exactly 192.168.10.100 regardless of what is in the main pool. The pool requires its own name: ip dhcp pool SERVER1 D. Configure a static ARP entry: arp 192.168.10.100 00AA.BB11.2233 ARPA — this binds the MAC to the IP for DHCP purposes

Correct answer is C. A manual DHCP binding (also called a static DHCP reservation) is created by making a separate named pool with the host command instead of the network command, and specifying the client's hardware (MAC) address. The full configuration is: ip dhcp pool SERVER1 / host 192.168.10.100 255.255.255.0 / hardware-address 00AA.BB11.2233 / default-router 192.168.10.1. When that MAC sends a Discover, the server matches it to this pool and always offers 192.168.10.100. This binding appears in show ip dhcp binding as Type: Manual. The IP should also be excluded from the main dynamic pool (ip dhcp excluded-address 192.168.10.100) to prevent the server from accidentally offering .100 to another client if the reservation doesn't match first. Option A is incorrect — excluding an address just prevents it from being offered to any client; it does not reserve it for a specific MAC.

9. After running `clear ip dhcp binding *` on a production router during business hours, what immediate impact occurs and why?

A. All DHCP clients temporarily lose their IP addresses and must complete a full DORA exchange to get new ones. Active TCP sessions (file transfers, VoIP calls, database connections) will drop during the re-acquisition period. The router deletes all binding records simultaneously — clients attempting to renew find their lease is gone and must rediscover. This command should only be run during a maintenance window or when targeting specific stale bindings with clear ip dhcp binding [specific-ip] B. No impact — the clients retain their IP addresses until their individual leases naturally expire, at which point they renew normally C. Only clients that are currently powered off lose their bindings — active clients automatically re-register their leases D. The router reboots its DHCP process and assigns new addresses starting from the beginning of the pool — clients keep their existing IPs but receive a notification to renew

Correct answer is A. clear ip dhcp binding * is one of the most disruptive DHCP commands available — it instantly deletes every lease record from the server's binding table. From the server's perspective, no clients have valid leases. Clients that are actively using their IP addresses are not immediately notified — they continue using their current IPs until they attempt to renew (at 50% of lease time) or until someone runs ipconfig /release and /renew on them. However, if any client tries to renew before receiving a new lease from a new DORA exchange, the server responds with DHCPNAK because it has no record of that binding — the client must then restart DORA from the beginning. During this period (which can last seconds to minutes depending on the number of clients), connectivity is disrupted. The correct approach for clearing only stale bindings is to target specific IPs: clear ip dhcp binding 192.168.10.150 — only that one binding is cleared, leaving all other active leases untouched.

10. A client successfully receives a DHCP address in the correct subnet with the correct gateway and DNS server. However, the client cannot reach any resources on the network. What Layer 3 and above issues should be investigated next, in order?

A. Run debug ip dhcp server events again — the DHCP exchange may have errors in the ACK options B. Clear the DHCP binding and force the client to get a new address — the current address may be corrupted in transit C. Check the VLAN assignment on the switch port — the client may be in the wrong VLAN despite having a valid IP D. DHCP is confirmed working — the fault is now a Layer 3 or higher issue. Investigate in this order: (1) ping the default gateway from the client — if it fails, check the gateway IP in the DHCP pool is correct and that the router interface is up; (2) ping a known host by IP — if this works but DNS fails, the dns-server option in the DHCP pool may be wrong; (3) check for ACLs on the router blocking traffic from the client's subnet; (4) verify routing — the router must have routes for all destinations the client needs to reach

Correct answer is D. When a client successfully receives a DHCP address with all the correct options (IP, mask, gateway, DNS), DHCP itself is confirmed working. The troubleshooting methodology then moves up the stack. The first test is always to ping the default gateway — this confirms whether the client can reach its first hop at Layer 3. If the gateway ping fails, the problem could be an incorrect gateway IP in the pool, an ACL on the router blocking ICMP, or a routing issue. If the gateway ping succeeds but pinging other IPs fails, the issue is routing beyond the gateway. If IP pings work but name resolution fails, the DNS server IP in the DHCP pool is wrong or the DNS server itself is unreachable. Option C (VLAN mismatch) would prevent the client from reaching the DHCP server in the first place — if DHCP succeeded, the VLAN assignment is almost certainly correct. Re-clearing the DHCP binding (Option B) when DHCP is confirmed working wastes time and disrupts the client's connectivity unnecessarily.

Back to Home