DHCP Troubleshooting Scenarios

The router's interface is configured with the no ip forward-protocol udp bootps command.

Why it fails: The `no ip forward-protocol udp bootps` command disables the forwarding of UDP broadcasts destined for BOOTPS/DHCP port 67 by the relay agent. However, the router here is acting as the DHCP server itself, not as a relay. A local DHCP server receives DHCPDISCOVER broadcasts natively on its directly connected interface, so this command has no effect on the server's ability to see those broadcasts. This option is incorrect because it targets the relay function rather than the local server reception.

The DHCP pool is configured with the wrong default-router option.

Why it fails: The `default-router` option in a DHCP pool sets the gateway address that the client will configure via the DHCPOFFER message. This option does not influence whether the router receives the DHCPDISCOVER or whether the server responds to it. A wrong default-router address would cause the client to have an incorrect gateway after obtaining an address, but it would not prevent the client from being assigned an IP. Therefore, this cannot explain a complete failure to receive broadcast messages.

The router's DHCP server is disabled globally with the no service dhcp command.

Why it fails: The global `no service dhcp` command disables both the DHCP server and relay functionality on the router. If this were the cause, the router would not respond to any DHCP requests, but when an engineer attempts to configure a DHCP pool, Cisco IOS displays an error like 'DHCP is disabled on this router' or requires the `service dhcp` command to be enabled. Since the pool is presumably configured and active, the service must be running, making this option unlikely. This option is incorrect because the failure mode would be immediately apparent during configuration, not a silent absence of DHCPDISCOVER reception.

Use a Type 2 hypervisor on a desktop PC at the branch.

Why it fails: A Type 2 hypervisor, such as VirtualBox or VMware Workstation, runs as an application on top of a desktop operating system, competing with other processes for CPU, memory, and I/O. This introduces additional latency and reduces stability, making it unsuitable for hosting production network functions like a Cisco ISRv that require predictable throughput and high availability. Furthermore, a desktop PC lacks the server-grade components (redundant power, ECC memory, remote management) and the centralized enterprise management capabilities that are mandatory for branch network infrastructure.

Run the ISRv and DHCP server as containers on the same host.

Why it fails: Containers share the host OS kernel and lack a full guest operating system, so they cannot run a Cisco ISRv router, which requires its own dedicated kernel and hypervisor-level isolation to support network functions like routing protocols. This option is tempting because containerisation reduces overhead and simplifies deployment for stateless applications, and would be correct if the scenario involved lightweight microservices rather than a virtual router needing full OS resources.

Install the ISRv directly on physical hardware without virtualization.

Why it fails: Cisco ISRv is distributed as a virtual appliance or disk image that expects to run under a hypervisor; it does not install as a standalone OS on bare-metal hardware like a traditional physical router. Installing it directly on physical hardware would be unsupported and would also forfeit the core reasons for virtualization in the first place—snapshots for rollback, cloning for rapid provisioning, resource overcommit, and encrypted VM backups. A physical installation would tie the ISRv to one machine, eliminating the flexibility to migrate or restore the router after hardware failure without reconfiguration.

The port connected to the DHCP server should be untrusted for DAI to work correctly.

Why it fails: The DHCP server port must be configured as trusted, not untrusted, for DAI to operate correctly. DAI does not inspect ARP packets that arrive on trusted ports; an untrusted DHCP server port would cause DAI to drop the server's ARP messages, breaking DHCP and subsequent security verification.

The DHCP server is in a different VLAN, and DAI cannot validate cross-VLAN ARP.

Why it fails: DAI inspects ARP packets on a per-VLAN basis using the DHCP snooping binding table, which contains entries for multiple VLANs. The location of the DHCP server is irrelevant because its port is trusted and its ARP traffic is exempt from inspection; only the hosts' ARP messages are validated against their own VLAN's bindings.

DAI is checking the destination MAC address, which does not match the expected value.

Why it fails: DAI does not validate the destination MAC address in an Ethernet or ARP frame. Instead, it validates the sender hardware address and sender protocol address against the DHCP snooping binding table, then checks the frame's source MAC address. The destination is irrelevant to the binding check; DAI only cares who is speaking, not to whom the packet is directed.

The router will assign IP addresses from 10.10.10.1 to 10.10.10.254.

Why it fails: This is incorrect because the pool also contains excluded-address 10.10.10.1 10.10.10.10, which removes the first ten addresses from dynamic assignment. As a result, the routable pool is 10.10.10.11 through 10.10.10.254, not .1 through .254. The excluded range is often used to reserve addresses for static devices or the router interface, and those addresses will never be handed out by DHCP.

The default lease is used because the lease command is incomplete.

Why it fails: The lease command is not incomplete; its full syntax is lease {days [hours [minutes]]}, and specifying only days and hours is perfectly valid. Here, lease 0 12 is interpreted as 0 days and 12 hours, which is a legal configuration. The default lease of 1 day only applies when no lease command is present in the DHCP pool, so this option misidentifies the situation.

The DNS server is set to 8.8.8.8, but clients will ignore it.

Why it fails: The DNS server is incorrectly assumed to be ignored; in this pool, the dns-server 8.8.8.8 command sends option 6 (DNS server) to DHCP clients, and typical clients will use that address for name resolution. The statement that clients ignore it is false; clients accept the DNS server from DHCP unless they are manually configured with a different server or their OS policy overrides DHCP-provided DNS. Thus the configuration effectively sets the DNS server for all clients that accept DHCP options.

12 hours

Why it fails: A 12-hour lease equals 43,200 seconds and is not the factory default on Cisco IOS; you must configure it with the lease 0 12 0 command in DHCP pool configuration mode. While this shorter lease would cause clients to renew twice as often, it is not what the server uses out of the box. Therefore, 12 hours is incorrect for a default.

2 days

Why it fails: Two days corresponds to 172,800 seconds, which would require an explicit lease 2 0 0 statement to take effect. Cisco's default lease is only one day, regardless of the address pool or client request, so 2 days is not a default value. This option is wrong because it assumes a longer lease than the standard 86400-second default.

Infinite

Why it fails: An infinite lease means the IP address never expires, but Cisco IOS does not set this by default; you must enter lease infinite in the pool configuration. This is sometimes used for DHCP reservations or static-like assignments, but it is an intentional non-default choice. Thus, infinite is not the default lease time and is incorrect.

ip dhcp pool 10.1.1.1

Why it fails: The 'ip dhcp pool' command creates a DHCP pool with a name, not an address exclusion. It does not exclude addresses; instead, it defines a pool of addresses to lease. The argument is a pool name, not an IP address. This command alone would not prevent the router's address from being assigned.

ip dhcp relay information option

Why it fails: This command enables the DHCP relay agent to insert option 82 information, which is used for relayed DHCP requests. It does not exclude addresses from a pool. It is relevant when the router acts as a relay, not as a DHCP server excluding its own address.

ip dhcp excluded-address 10.1.1.0 10.1.1.255

Why it fails: This command would exclude the entire subnet, leaving no addresses available for DHCP clients. While it does exclude the router's address, it is overly broad and incorrect for the scenario. The requirement is to exclude only the router's address, not the whole range.

DHCP snooping must be disabled for IP Source Guard to function with static addresses.

Why it fails: DHCP snooping must be enabled for IPSG to use the dynamic binding table. Disabling DHCP snooping would remove the source of dynamic bindings and break IPSG for DHCP clients. For static addresses, DHCP snooping can remain enabled; you simply add a static binding. Therefore, disabling it is not required and would be counterproductive.

IP Source Guard only works with IPv6 addresses, so IPv4 static addresses are not supported.

Why it fails: IP Source Guard supports both IPv4 and IPv6. For IPv4, it validates against the DHCP snooping binding table or static IP source bindings. IPv6 support uses similar mechanisms. The issue is not address family but the lack of a binding for the static IP, so this statement is incorrect.

The laptop must be configured with a DHCP address even if a static IP is desired, because IPSG blocks all non-DHCP traffic.

Why it fails: IPSG does not block all non-DHCP traffic; it blocks traffic that does not match an entry in the DHCP snooping binding table or a static IP source binding. A statically configured IP can work if a static binding is added. The requirement is not to use DHCP, but to have a valid binding, so this option is misleading.

Path Trace

Why it fails: Path Trace is a tool used to trace the path of packets between two endpoints, showing the hop-by-hop forwarding and any ACL or QoS policies applied. It does not capture wireless onboarding events such as association, authentication, or DHCP. Therefore, it cannot provide the detailed onboarding timeline the administrator needs.

Application Health Dashboard

Why it fails: The Application Health Dashboard focuses on application performance and network latency for specific applications. It does not track client onboarding phases or wireless association details. The administrator needs client-centric onboarding data, not application-level metrics, so this dashboard would not provide the required timeline.

Network Health Dashboard

Why it fails: The Network Health Dashboard gives an aggregate view of network health across sites, devices, and clients. It does not provide per-client onboarding timelines or detailed phase breakdowns. While it can highlight that onboarding time is generally high, it lacks the drill-down capability to see individual client events, making it unsuitable for this specific troubleshooting task.

ip dhcp pool

Why it fails: The 'ip dhcp pool' command creates a DHCP pool and enters DHCP pool configuration mode. It is used to define the network, default gateway, DNS server, and other parameters for the pool. It does not exclude addresses; rather, it defines the pool from which addresses are allocated. Exclusions are configured separately.

ip dhcp snooping

Why it fails: The 'ip dhcp snooping' command is used to enable DHCP snooping, a security feature that filters untrusted DHCP messages and builds a binding table. It is not used to exclude addresses from a DHCP server's pool. Therefore, it does not meet the requirement of excluding addresses from dynamic assignment.

ip dhcp relay information

Why it fails: The 'ip dhcp relay information' command is used to configure the DHCP relay agent to insert option 82 information into DHCP requests. It is not related to excluding addresses from a DHCP server's pool. This command is used on relay agents, not on DHCP servers for address exclusion.

The DHCP snooping database agent is not configured.

Why it fails: The DHCP snooping database agent is used to store bindings persistently across reboots. It does not affect the forwarding of DHCP offers in real time. Without a database agent, bindings are lost on reload, but DHCP operation continues normally. The dropped offers are not caused by a missing database agent, which is an optional configuration for binding persistence.

The client ports are configured as trusted.

Why it fails: If client ports were trusted, DHCP snooping would not inspect their traffic, but that would not cause server offers to be dropped. Trust on client ports is a security risk because it allows rogue DHCP servers, but it does not explain the drop of legitimate server offers. The issue is on the server-facing port, which must be trusted to receive server messages.

DHCP snooping is not enabled on the VLAN of the client ports.

Why it fails: The scenario states DHCP snooping is enabled on VLAN 10, which is the VLAN of the client ports. If snooping were not enabled on the VLAN, DHCP would pass through without inspection, and offers would not be dropped. The symptom of dropped offers points to a trust issue, not a VLAN enablement issue. Enabling snooping on the wrong VLAN would cause other problems, but not this specific drop.

ip dhcp excluded-address 10.1.1.1

Why it fails: The ip dhcp excluded-address command prevents the router from assigning specific addresses to clients. While it might be used to exclude the router's own address from the pool, it does not provide the default gateway information to clients. It is not the correct command for setting the gateway.

ip default-gateway 10.1.1.1 in global configuration mode

Why it fails: The ip default-gateway command is used on a device that does not have routing enabled, such as a Layer 2 switch, to set its own default gateway. It does not affect DHCP clients. This command is for the device itself, not for the DHCP pool configuration.

ip helper-address 10.1.1.1 under the router's interface

Why it fails: The ip helper-address command is used on a DHCP relay agent to forward broadcast DHCP requests to a DHCP server. It does not configure the default gateway that clients receive in their DHCP lease. This command is irrelevant to the DHCP server configuration task.