DHCP Troubleshooting Scenarios

DHCPDISCOVER

Why it fails: DHCPDISCOVER is the initial broadcast a client sends to locate any available server when it has no lease, so it cannot renew an existing one. It is tempting because DISCOVER begins the DHCP handshake, and it is the correct choice when a client boots without a lease or after its address has been released.

DHCPACK

Why it fails: DHCPACK is the server's acknowledgement confirming offered parameters; it is a response, not a client-initiated renewal request. It is tempting because ACK completes the renewal exchange, and it is the correct message when the server confirms the client's requested lease extension.

DHCPRELEASE

Why it fails: DHCPRELEASE tells the server the client is relinquishing its address and cancelling the remaining lease, the opposite of renewal. It is tempting because it is a client-to-server lease-management message, and it is the correct choice when a client shuts down cleanly and no longer needs its assigned address.

The DHCP server has received 200 DHCPREQUEST messages.

Why it fails: The output lists 180 DHCPREQUEST messages received, not 200; 200 is the DHCPDISCOVER count. The figure is tempting because both appear in the same Received column, but reading the row label correctly is the whole task.

The DHCP server has 10 malformed messages, indicating a configuration issue.

Why it fails: Malformed messages shows 0, so no malformed traffic was received; the 10 belongs to Expired bindings, an unrelated counter. The value is tempting because it sits in the same statistics block, but it tracks leases that lapsed, not corrupt packets.

The DHCP server has 2 database agents configured.

Why it fails: Database agents reads 0, meaning no external database agent is configured; the 2 belongs to Address pools. The number is tempting because it appears in the same list, but it counts configured pools, not agents.

The DHCPv6 server has assigned only an IPv6 address to the client.

Why it fails: The binding shows both an IA NA address (2001:DB8:1::100) and an IA PD delegated prefix (2001:DB8:1::/48), so address-only assignment is contradicted by the prefix entry. It is tempting because IA NA alone is the common case for hosts; prefix delegation applies when the client is a requesting router needing downstream subnets.

The DHCPv6 client is using stateless autoconfiguration (SLAAC) because no address is shown.

Why it fails: An address is present (2001:DB8:1::100), and SLAAC bypasses DHCPv6 binding state entirely, so no binding would appear. It is tempting because SLAAC also autoconfigures addresses, but it uses router advertisements, not the DHCPv6 server's binding table shown here.

The DHCPv6 server has a pool with only one prefix available.

Why it fails: The binding shows one client holding one IA_NA address and one IA_PD prefix; it says nothing about pool size or remaining prefixes, since bindings list active leases only. It tempts because a single prefix appears, but pool exhaustion would require checking pool configuration or statistics, not this per-client binding table.

The DHCPv6 relay agent is not functioning because messages are not being forwarded.

Why it fails: The debug shows SOLICIT, ADVERTISE, REQUEST and REPLY each forwarded in both directions, so relay is working end to end. This option would fit if messages arrived but no forwarding lines appeared, indicating a relay configuration fault.

The DHCPv6 server is unreachable because no REPLY is received.

Why it fails: The log shows a REPLY received from 2001:DB8:2::1 and forwarded to the client, so the server is demonstrably reachable and the four-message exchange completed. It is tempting because a missing REPLY is the classic signature of an unreachable DHCPv6 server, but that symptom would appear as repeated SOLICIT retransmissions with no ADVERTISE or REPLY.

The DHCPv6 client is using a global unicast address as its link-local address.

Why it fails: Every client message arrives from FE80::1, a link-local address, which is the expected source for DHCPv6 clients on the local segment. It is tempting because a client misconfigured with a global address as its link-local would look similar in a capture, but the FE80:: prefix here proves the address is genuinely link-local.

The DHCP guard policy is applied only if the snooping database is present.

Why it fails: The DHCP guard attach-policy and snooping database file commands are independent; the policy applies regardless of whether the database file exists. It is tempting because snooping databases feed binding validation, but DHCP guard enforces server and client roles directly. Database presence affects binding lookups, not policy attachment.

The interface will not forward any DHCP messages until the database is populated.

Why it fails: DHCP guard filters server or client messages based on the attached policy; forwarding is not suspended pending database population. The snooping database file merely persists bindings across reloads. It is tempting because snooping must learn bindings, but DHCP guard enforcement does not wait on the database, and normal DHCP relay and client traffic continues.

The snooping database is used to validate DHCP server messages.

Why it fails: The snooping database stores IPv6-to-MAC bindings learned from ND and DHCP snooping; it does not validate DHCP server messages. DHCP guard performs that role-based validation. It is tempting because both features relate to DHCP security, but the database is a binding repository, not a server-message validator.

It sets the trust level for ND inspection.

Why it fails: ND inspection trust is configured with 'ipv6 nd inspection policy' and the 'device-role' keyword there, not inside a DHCP guard policy. The DHCP guard device-role instead labels a port as 'server' or 'client' to decide which ports may send DHCP server messages, so it is tempting because both features share the device-role syntax.

It defines the VLAN membership for the interface.

Why it fails: VLAN membership is set by the interface's switchport configuration or subinterface encapsulation, not by device-role. The command labels a port as 'server' or 'client' so DHCP guard knows which ports may legitimately relay or serve DHCPv6; it is tempting because device-role is applied per interface, which superficially resembles a per-port VLAN assignment.

It enables IPv6 routing on the interface.

Why it fails: IPv6 routing is enabled by 'ipv6 unicast-routing' globally and 'ipv6 address' on the interface, not by device-role. The command marks a port as 'server' or 'client' so DHCP guard permits or blocks DHCPv6 server messages; it is tempting because device-role is entered under interface configuration, where routing commands also live.

The client is using SLAAC instead of DHCPv6.

Why it fails: The presence of an IA NA binding with a server-assigned address, DUID and T1/T2 timers proves stateful DHCPv6 address assignment occurred. SLAAC produces no server binding entry. This option would be correct if the client had formed its address from a received prefix via router advertisement.

The client's lease has expired.

Why it fails: The binding shows a valid lifetime of 2592000 seconds with an expiry timestamp in the future, so the lease remains active. Expired leases are removed from the binding table or shown with zero remaining lifetime. This option would be correct if the Expires field showed a past date.

The client is not authorized.

Why it fails: The binding lists Username: unknown, which reflects that no authentication or authorisation was configured for this client, not a rejection. The address was still assigned successfully. This option would be correct if the server had refused the request and no binding existed.

ip dhcp excluded-address 192.168.100.1 192.168.100.10 192.168.100.254

Why it fails: The ip dhcp excluded-address command accepts only a single range or a single address per command. It does not support three separate arguments in one line. To exclude multiple non-contiguous addresses or ranges, multiple commands are required. This syntax is invalid and will be rejected by the router.

ip dhcp excluded-address 192.168.100.1 192.168.100.10 and ip dhcp excluded-address 192.168.100.254

Why it fails: The keyword 'and' is not valid in Cisco IOS configuration syntax. You cannot combine two separate commands with 'and' on a single line. Each exclusion must be configured as a separate command. This option is syntactically incorrect and would cause an error when entered.

ip dhcp excluded-address 192.168.100.1 192.168.100.10

Why it fails: This command excludes only the first 10 addresses (192.168.100.1 through 192.168.100.10) from the DHCP pool. It does not exclude the last address (192.168.100.254), which is also required to be excluded. Therefore, it does not fully meet the requirement of excluding both the first 10 addresses and the last address.

The relay agent R2 is missing the 'ip dhcp relay information option' command.

Why it fails: The relay information option inserts circuit and remote IDs for DHCP snooping and option 82 handling; it is not required for basic DISCOVER forwarding. It is tempting because option 82 relates to relayed DHCP, but R1's failure to respond stems from pool or giaddr matching, not missing option 82.

The DHCP pool on R1 is missing the 'default-router' command.

Why it fails: A missing default-router only omits the gateway address in the DHCP offer; it does not stop R1 from selecting a pool and replying. It is tempting because the client needs a gateway, but the symptom is no response at all, indicating pool selection failure.

The 'ip helper-address' on R2 should point to the server's loopback address, not the interface IP.

Why it fails: The helper address correctly targets the server's reachable interface, and giaddr is already being set, so redirecting to a loopback changes nothing. It is tempting because loopback addresses are stable, but reachability is proven by the successful ping.

The pools are configured in the wrong order; the server uses the first pool that matches the client's MAC address.

Why it fails: DHCP pool selection is not a first-come, first-served MAC match. The server chooses a pool by comparing the giaddr or the receiving interface's subnet to the pool's network statement; MAC addresses are used only for manual reservations (host statements), not for ordering. Even if pools were listed in a particular order, the server does not iterate pools by client MAC, so reordering pools cannot change which pool is chosen for a relayed client.

The router has 'ip dhcp smart-relay' enabled, which overrides pool selection.

Why it fails: The 'ip dhcp smart-relay' feature does not override or alter the pool-selection logic; it simply enables the router to insert a giaddr for broadcast DHCP packets on interfaces without an 'ip helper-address' configuration, using the interface IP as the gateway address. Instead of causing the wrong pool, smart relay would actually improve the chance that the server receives a correct giaddr and selects the proper pool. Thus, this option misidentifies the feature's purpose.

The DHCP server is configured with 'network' statements that overlap.

Why it fails: Overlapping 'network' statements in DHCP pools are a separate misconfiguration that can produce pool conflicts or server startup errors, and they are generally rejected or cause address clashes, not a clean handoff of subnet B clients to subnet A's pool. The symptom described is a relay/giaddr failure scenario, where the server sees no valid giaddr and falls back to the first available pool. Overlapping pools would not change how giaddr is processed, so they cannot be the root cause here.

The DHCP server has three static bindings configured.

Why it fails: Automatic in the Type column denotes dynamic pool leases, not manually configured static host entries; static bindings appear as Manual. Static bindings are what you would expect when a client MAC is hard-coded to a fixed address outside the dynamic pool.

The DHCP server is out of IP addresses because all bindings are in use.

Why it fails: Lease expiry timestamps show active leases, not pool exhaustion; the server would log ICMP or DHCPDECLINE failures and offer no addresses instead. It is tempting because a full binding table can suggest saturation, but this command lists current leases, and it would be the correct indicator only if the pool's address range were genuinely depleted.

The DHCP server is using relay agents because the client IDs are long hexadecimal strings.

Why it fails: Client IDs appear as hexadecimal because clients send client-identifier option 61, not because relay agents are involved; relay agents are identified by the giaddr field in DHCP packets. It is tempting since relayed requests carry extra identifiers, but relay usage would be the correct answer only when bindings show addresses from remote subnets via giaddr.

The DHCP server failed to create a binding for the client.

Why it fails: The log explicitly shows 'Adding binding for client 0050.7966.6800' followed by a DHCPACK, so the server created the binding and leased the address successfully. The DHCPINFORM and final ACK simply confirm the client already holds its address and is requesting extra options.

The DHCP client is using a relay agent because the DISCOVER was received on a different interface.

Why it fails: The debug shows the DISCOVER arriving on GigabitEthernet0/0 and the OFFER leaving via the same interface, so no relay agent is involved. Relay agents are used when the DHCP server sits on a different subnet from clients, forwarding requests via a helper address.

The DHCP server rejected the DHCPREQUEST because no binding was found.

Why it fails: "No binding found" is normal for a first-time client; the server then adds the binding and sends the DHCPACK. Rejection would show a DHCPNAK. A DHCPREQUEST is refused when the requested address is wrong for the subnet or the lease has expired.

The DHCP server is working normally; conflicts are automatically resolved.

Why it fails: The output lists addresses the server marked as conflicted after ping or gratuitous ARP detected another host using them; they are quarantined, not resolved automatically. It is tempting because DHCP does reclaim addresses eventually, but only after the conflict ages out or is cleared manually.

The DHCP server is not responding to client requests.

Why it fails: Conflicts recorded here mean the server detected another device already using the address, not that it failed to answer clients. It is tempting because a client unable to obtain a lease often indicates a non-responding server, but the conflict table proves the server was operating.

The DHCP pool is misconfigured with overlapping subnets.

Why it fails: Overlapping subnets would prevent the pool from initialising, not produce individual conflict entries naming detection methods and times. It is tempting because overlapping pools do cause addressing faults, yet the ping and gratuitous ARP columns point to duplicate addresses in use.