DHCP Troubleshooting Scenarios

Check the DHCP server logs to see if it is receiving Discover messages.

Why wrong: Checking the DHCP server logs for Discover messages is premature in this scenario. Because the DHCP server resides on a different subnet than the clients, server-side logs will only show Discover packets if the router's VLAN 20 interface has an IP helper-address configured to forward broadcast DHCP requests. If the helper-address is missing, the router drops the broadcast at the VLAN boundary, and the server never sees any Discover traffic—so the absence of such messages in the logs would merely confirm the relay misconfiguration, not diagnose it. This step is valid only after confirming that the relay configuration is correct, and it wastes troubleshooting time by skipping the most fundamental cause.

Attempt to ping the DHCP server's IP address from the host's APIPA address.

Why wrong: The host's APIPA address (169.254.x.x) is a link-local address. Without a default gateway or a routable IP, pinging an address on a different subnet will not work, even if the DHCP server is reachable. This test does not confirm DHCP functionality and is not a standard troubleshooting step for DHCP failures.

Restart the DHCP service on the server and recheck the host.

Why wrong: Restarting the DHCP service is a disruptive action and should not be the first step, especially when the root cause likely lies in the network configuration (missing relay). It does not address the underlying issue and may cause unnecessary downtime.

1. Enable DHCP relay on the VLAN 20 interface. 2. Configure the DHCP pool for VLAN 10. 3. Exclude addresses from the pool. 4. Verify DHCP operations.

Why wrong: This is incorrect because DHCP relay should be configured after the DHCP server pool is set up. Enabling relay before the server is ready may cause clients to send requests that cannot be answered.

1. Exclude addresses from the pool. 2. Enable DHCP relay on the VLAN 20 interface. 3. Configure the DHCP pool for VLAN 10. 4. Verify DHCP operations.

Why wrong: This is incorrect because the DHCP pool must be created before excluding addresses. Exclusions are part of the pool configuration and cannot be applied before the pool exists.

1. Configure the DHCP pool for VLAN 10. 2. Enable DHCP relay on the VLAN 20 interface. 3. Exclude addresses from the pool. 4. Verify DHCP operations.

Why wrong: This is incorrect because exclusions should be configured before enabling relay. Although the pool is created first, exclusions are part of the pool configuration and should be done before moving to relay.

Configure a default gateway on PC-A with the IP address 192.168.10.1.

Why wrong: This is incorrect because PC-A has an APIPA address (169.254.23.45), which indicates it did not receive a DHCP lease. Manually setting a default gateway does not resolve the underlying issue of DHCP failure. The PC must first obtain a valid IP address via DHCP before a default gateway can be used.

Change the VLAN on SW1's interface connected to PC-A from VLAN 10 to VLAN 1.

Why wrong: This is incorrect because PC-A is configured for VLAN 10, and the DHCP pool is on subnet 192.168.10.0/24, which is associated with VLAN 10. Changing to VLAN 1 would place PC-A in a different subnet, preventing it from receiving a DHCP lease from R1's pool. The VLAN configuration is correct as is.

Add the 'ip helper-address' command on R1's interface connected to SW1.

Why wrong: This is incorrect because the DHCP server is on R1 itself, not on a remote server. The 'ip helper-address' command is used to forward DHCP broadcasts to a DHCP server on a different subnet. Since R1 is the DHCP server, no helper address is needed; the router will respond to DHCP requests on its directly connected interface.

On R1, change the helper-address to 192.168.10.255 and the excluded-address range to 192.168.10.1 192.168.10.10. On SW1, enable DHCP snooping globally and for VLAN 10, and set all ports as trusted.

Why wrong: This is incorrect because the helper-address should be the DHCP server's IP (192.168.10.1), not the broadcast address (192.168.10.255). Also, setting all ports as trusted defeats the purpose of DHCP snooping, as it would allow rogue servers on any port.

On R1, change the helper-address to 192.168.10.1 and the excluded-address range to 192.168.10.1 192.168.10.254. On SW1, enable DHCP snooping globally and for VLAN 10, and set interface G0/1 as untrusted.

Why wrong: This is incorrect because the excluded-address range excludes almost all addresses (192.168.10.1 through 192.168.10.254), leaving only the broadcast address for clients, which is not usable. Also, the port facing the DHCP server (R1) must be trusted, not untrusted.

On R1, change the helper-address to 192.168.10.1 and the excluded-address range to 192.168.10.1 192.168.10.10. On SW1, enable DHCP snooping globally and for VLAN 10, and set interface G0/1 as untrusted.

Why wrong: This is incorrect because the port facing the DHCP server (R1) must be trusted. Setting it as untrusted would cause DHCP snooping to drop DHCP server messages (OFFER, ACK) from R1, preventing clients from obtaining IP addresses.

The DHCP pool is misconfigured: the excluded-address range should be 192.168.50.1 192.168.50.9, but the helper-address on GigabitEthernet0/0 is correct because it forwards DHCP requests to the remote server. The relay agent configuration is missing on GigabitEthernet0/1.

Why wrong: This is incorrect because the helper-address on GigabitEthernet0/0 is not needed; R1 is the DHCP server for that subnet, so broadcasts should not be forwarded elsewhere. Adding a helper-address would cause DHCP requests to be forwarded to the remote server unnecessarily.

The DHCP pool is correctly configured with excluded-address 192.168.50.1 192.168.50.9. The issue is that the 'ip helper-address' on GigabitEthernet0/1 is missing; it should be added to forward requests to the remote server. Additionally, the 'ip helper-address' on GigabitEthernet0/0 is correct because it forwards requests from VLAN 50 to the remote server.

Why wrong: This is incorrect because the excluded-address range is correct, but the helper-address on GigabitEthernet0/0 is still unnecessary and should be removed. The problem statement says clients on VLAN 50 are not receiving addresses, which is due to the excluded-address covering the entire pool, not the helper-address on G0/0.

The DHCP pool is misconfigured: the excluded-address range should be 192.168.50.1 192.168.50.9. The 'ip helper-address' on GigabitEthernet0/0 should be removed. The relay agent configuration is correct because 'ip helper-address 203.0.113.10' is already configured on GigabitEthernet0/1.

Why wrong: This is incorrect because the relay agent configuration is missing; the helper-address on GigabitEthernet0/1 is not present. The option claims it is already configured, but the problem states that the relay agent configuration is missing.

interface GigabitEthernet0/0.10 encapsulation dot1Q 10 ip helper-address 192.168.10.100

Why wrong: This places the helper-address on the VLAN 10 subinterface, which does not help VLAN 20 hosts because broadcasts from VLAN 20 are not received on this interface.

interface GigabitEthernet0/0.20 encapsulation dot1Q 20 ip dhcp relay information option

Why wrong: The ip dhcp relay information option command adds DHCP option 82 information but does not forward broadcasts to a specific server; it is not a substitute for ip helper-address.

ip dhcp pool VLAN20 network 192.168.20.0 255.255.255.0 default-router 192.168.20.1

Why wrong: This configures R1 as a DHCP server for VLAN 20, but the requirement is to forward broadcasts to an existing server, not to have R1 act as a server.

Remove the 'ip dhcp excluded-address 192.168.1.1 192.168.1.10' command because it excludes too many addresses.

Why wrong: This is incorrect because excluding 10 addresses from a /24 subnet (254 usable addresses) is not excessive. The exclusion is necessary to reserve addresses for static devices like the router interface. The APIPA issue is not caused by this exclusion.

Change the DHCP pool network to 192.168.1.0/24 and add the default-router 192.168.1.1 command.

Why wrong: This change is unnecessary and would not resolve the problem because the DHCP pool on R1 already contains the correct 'network 192.168.1.0 255.255.255.0' and 'default-router 192.168.1.1' statements. The configuration as written is valid and would lease addresses properly if the DHCP service were enabled. Simply rewriting or re-adding these commands does nothing to activate the router's DHCP server engine, which is disabled by default and requires the 'service dhcp' global command. Without that global enable, the client will continue receiving no DHCP replies and will fall back to an APIPA address.

Configure the 'ip helper-address' command on the client's VLAN interface to forward DHCP requests to the server.

Why wrong: This is incorrect because the DHCP server is on the same router (R1) as the client's subnet. The 'ip helper-address' command is used to forward DHCP broadcasts to a remote server, which is unnecessary here. The client and server are on the same device.

DHCP is used primarily to translate private addresses into public addresses.

Why wrong: DHCP is not designed for address translation between private and public address spaces; that function belongs to Network Address Translation (NAT), typically implemented on routers or firewalls. DHCP's role is limited to dynamically assigning IP configuration—such as IP address, subnet mask, default gateway, and DNS servers—to hosts within a local network. While DHCP may work alongside NAT in many enterprise environments, conflating the two misidentifies their distinct purposes, as DHCP does not modify or translate IP headers.

DHCP replaces the need for subnet masks and default gateways.

Why wrong: DHCP does not eliminate the need for subnet masks and default gateways; rather, it automates the delivery of these essential parameters to clients. A subnet mask is still required to determine the network and host portions of an IP address, and a default gateway is essential for routing traffic outside the local subnet. Without these values, a client would be unable to determine which destinations are local or how to reach remote networks—DHCP simply distributes them automatically, saving administrators from manual configuration and reducing errors.

DNS and DHCP are both Layer 1 technologies.

Why wrong: DNS and DHCP operate at the application layer (Layer 7) of the OSI model, not at Layer 1. Layer 1 is the physical layer, which involves the transmission and reception of raw bit streams over physical media like cables, fiber, or radio waves. In contrast, DNS and DHCP use higher-layer protocols—DNS primarily uses UDP port 53 or TCP port 53, while DHCP uses UDP ports 67 and 68—and depend on Layer 3 (IP) and Layer 4 (UDP/TCP) services for their operation, making them clearly not Layer 1 technologies.

Enable DHCP snooping globally and on VLAN 20, configure interface G0/1 as trusted, and change the ip helper-address on the SVI for VLAN 20 from 10.0.0.3 to 10.0.0.2.

Why wrong: This is incorrect because the access port (G0/1) should remain untrusted, not trusted. Trusting the access port would allow rogue DHCP servers connected to that port to send replies, defeating the purpose of DHCP snooping.

Enable DHCP snooping globally and on VLAN 20, configure interface G0/0 as trusted, and keep the ip helper-address as 10.0.0.3 because that is the correct server address.

Why wrong: Although trusting the uplink G0/0 is correct, the ip helper-address remains incorrectly set to 10.0.0.3. The DHCP server actually resides at 10.0.0.2, so the relay agent will forward client broadcasts to the wrong destination, and no DHCP replies will return. The command 'ip helper-address' must point to the real server IP; otherwise DHCP snooping alone does not fix the broken relay path.

Enable DHCP snooping globally and on VLAN 20, configure both interfaces G0/0 and G0/1 as trusted, and change the ip helper-address on the SVI for VLAN 20 from 10.0.0.3 to 10.0.0.2.

Why wrong: Configuring both G0/0 and G0/1 as trusted completely undermines DHCP snooping's security model. The access port G0/1 is the attachment point for end users, and a rogue DHCP server there would be allowed to send replies if trusted. Only the uplink G0/0 to the legitimate DHCP server should be trusted; all other ports should remain untrusted to filter unauthorized DHCP traffic.

It is configured on the DHCP server interface to allow replies to reach clients on remote subnets.

Why wrong: The ip helper-address is configured on the router interface facing the clients, not on the server.

It automatically forwards all UDP broadcasts by default.

Why wrong: By default, only DHCP and a few other UDP services (like TFTP, DNS, and Time) are forwarded. Not all UDP broadcasts.

It prevents DHCP spoofing by validating the source MAC address of DHCP packets.

Why wrong: This describes DHCP snooping, not the ip helper-address command.

DNS server option

Why wrong: The DNS Server option provides the client with the IP addresses of name servers used to resolve hostnames to IP addresses. If this option is wrong, the client can still exchange IP packets with remote networks by typing an IP address directly, but it will fail to resolve DNS names. It does not affect the forwarding path or the default gateway's operation.

Lease time option

Why wrong: Lease time is the DHCP option that defines how long the client can use the assigned IP address before it must renew its lease. It controls address expiration and renewal timing, but has no influence on the client's routing table or its ability to reach remote subnets. Even a very short lease time does not block off-subnet traffic while the address is valid.

TFTP server option

Why wrong: The TFTP Server option is typically used for network booting, such as Cisco IP phones or diskless workstations, to download configuration files or operating system images. For an ordinary client PC, a TFTP server has no role in basic IP connectivity, and the client does not require TFTP to route traffic to remote networks. Misconfiguring this option will not interfere with the client's ability to communicate outside its subnet.

OSPF area number

Why wrong: OSPF area numbers are routing protocol construct that partition an autonomous system for link-state advertisement scoping; they are not DHCP options because DHCP distributes host TCP/IP settings, not routing daemon parameters. The router's OSPF process uses area numbers on its own interfaces to build the routing table, but clients never need this value, as they do not run OSPF. Sending such a value via DHCP would be meaningless and protocol-incompatible.

Switch port duplex setting

Why wrong: Switch port duplex settings define physical-layer negotiation behavior (half/full duplex) on an Ethernet port, which is configured locally on the switch interface via CLI or autonegotiation. DHCP operates at L3/L4 and carries customer premise configuration like IP address and lease duration; it never instantiates L1 physical interface parameters. A client receiving a DHCP lease would have no mechanism to apply a duplex value to its NIC or to the switch port it is attached to.

STP root bridge priority

Why wrong: STP root bridge priority is a bridge parameter used in spanning-tree elections on L2 switches to determine which switch becomes the root; it's a control-plane setting applied to the switch itself. DHCP, on the other hand, operates at the application layer to lease L3 addressing and endpoint configuration details. Even if the router also runs STP on its switchports, the root priority is not something a DHCP client could receive or use.

Enter global configuration mode, create the DHCP pool, configure the network and default gateway, exclude addresses, enable DHCP relay on the required interface, and verify.

Why wrong: Here the pool is created and its network/default gateway are set, but exclusion is postponed until after pool creation. In Cisco IOS, a DHCP pool can be created without exclusions, and if the service is active or the pool is used before the exclusion is added, the server may lease out addresses intended for static assignment, leading to conflicts. Enabling relay last does not mitigate this risk because the pool is already operational with an incomplete address reservation policy.

Enter global configuration mode, enable DHCP relay on the required interface, create the DHCP pool, configure the network and default gateway, exclude addresses, and verify.

Why wrong: This option enables DHCP relay on the interface before any DHCP pool is created. At this point, the relay agent will receive client discover messages but has no valid pool configuration on the server to forward them to, causing all DHCP requests to fail or time out. Furthermore, exclusion is placed after the pool is created, so the server could issue addresses that were meant to be reserved. The relay must be enabled only after the pool and its network/default gateway are fully defined.

Enter global configuration mode, create the DHCP pool, enable DHCP relay on the required interface, configure the network and default gateway, exclude addresses, and verify.

Why wrong: This sequence creates the DHCP pool but then enables DHCP relay before the network and default gateway are configured. The relay agent can forward client broadcasts, but the server has no subnet definition to match the giaddr to, so requests are likely to be dropped or time out. Additionally, exclusion occurs only after pool creation, leaving a window where addresses reserved for static devices could be leased out, causing IP conflicts.

Set the subnet mask to 255.255.0.0 and the default gateway to 192.168.1.1

Why wrong: Using a /16 subnet mask (255.255.0.0) is incorrect for a /24 network. This would cause the workstation to consider a much larger range of addresses as local, leading to incorrect routing decisions and potential connectivity problems.

Set the subnet mask to 255.255.255.0 and leave the default gateway blank

Why wrong: With a /24 subnet mask (255.255.255.0), the workstation knows that addresses in the range 192.168.1.1–192.168.1.254 are local and reachable via ARP, but it has no route for any destination outside that subnet. When the default gateway is left blank, the workstation's routing table contains only the connected route to 192.168.1.0/24, so any packet destined for a non-local IP address (e.g., an internet server) is considered unreachable and is dropped with an error such as 'Destination Host Unreachable' or 'No Route to Host.' Local devices on the same subnet still communicate, but the workstation cannot reach the internet, a corporate WAN, or any other VLAN, making this configuration incomplete for typical network connectivity.

Set the subnet mask to 255.255.255.0 and the default gateway to 192.168.1.50

Why wrong: Setting the default gateway to 192.168.1.50 (the workstation's own IP) is invalid. The gateway must be a different device (typically a router) on the same subnet; otherwise, the workstation would try to route traffic to itself, which fails.