Understand what the client expects DHCP to provide

DHCPv4 automates delivery of settings such as an IPv4 address, subnet mask, default gateway, DNS resolver addresses and lease duration. A typical new-client exchange follows the Discover, Offer, Request and Acknowledgment sequence, sometimes abbreviated DORA. A client initially lacking an IPv4 address broadcasts a Discover on its local segment. A server or appropriately configured relay makes that request available to a DHCP server, which selects a lease from its scope according to the network and reservation rules.

The server’s offer is not proof that the client received a usable lease. The request and acknowledgment stages establish what address the client actually accepts; client software may subsequently perform address-conflict detection. A DHCP negative acknowledgment can cause the client to restart discovery. Retransmission timing and vendor implementations vary, so the absence of a neat four-packet sequence in a narrow capture does not automatically mean the server is down.

A leased address must match the client’s Layer 2 VLAN and intended IP subnet. A workstation with 192.0.2.53/24 and a gateway of 198.51.100.1 has received contradictory information for an ordinary lab design. The problem could be a scope option, relay association or unauthorized server rather than a routing process. Check not only whether the host obtained any IPv4 address but also the complete lease: mask, router option, resolver option and lifetime. A successful lease can still leave applications unusable.

Separate same-VLAN delivery from remote-server relay delivery

A DHCP broadcast ordinarily does not pass through routers by default. If the DHCP server resides in another subnet, a relay must forward the relevant exchange while preserving information the server can use to choose the client network. On many Cisco IOS and IOS XE Layer 3 interfaces, an ip helper-address configuration performs this relay role for selected UDP services, including DHCP. The helper address belongs on the client-facing routed interface or SVI, not at some arbitrary location along the server route.

Consider a switch SVI for VLAN 30 with client addresses in 192.0.2.0/24. The central server lives across a routed link in 198.51.100.0/24. If VLAN 30 has no appropriate relay, clients may broadcast Discover successfully but the server never sees a forwarded request. If the helper points to an old server address, the request may be forwarded and then dropped at the wrong endpoint. If the source SVI is down, the relay configuration can appear correct in a saved config while having no operational effect.

Test the relay chain in segments. Verify that the client and SVI share VLAN 30 and that the SVI is operational. Confirm the relay’s configured destination and the route to the DHCP server. Verify that the server has a scope or policy for the originating client subnet and a route back to the relay. Then inspect whether requests and replies traverse intermediary security devices. A DHCP server that answers direct same-subnet requests may still reject or misclassify requests carried by a relay.

Troubleshoot the address pool, options, and lease lifecycle

A server may run out of free addresses even when the underlying route is fine. Check pool exclusions, active leases, reservations, conflicts and whether stale or long-lived leases consume the scope. Repeated attempts by the same endpoint may be explained by an old reservation for a different MAC address or a client identifier, depending on server and device behavior. The right fix is not always expanding a subnet; first determine whether available addresses are genuinely exhausted and whether the intended network is correct.

DHCP options need separate quality checks. An incorrect default-router option can isolate the client beyond its subnet. Wrong DNS servers may make applications fail by name even when IP reachability works. An unusually short lease can increase renewal traffic, while a very long lease can delay planned configuration changes on laptops that frequently move between networks. Options are part of the service contract and should be tested along with address assignment.

Existing clients may continue using valid leases after a temporary server failure, making the problem appear intermittent. A freshly connected device fails while older devices still browse normally. That pattern points toward service availability, a depleted pool, or relay failure rather than necessarily the switch’s entire VLAN. Use a test client without disturbing production leases, and record timestamps so a DHCP outage can be correlated with device logs and server activity.

Distinguish DHCP failure from Layer 2 security protection

DHCP snooping can protect a switched network against untrusted DHCP replies, but a mistaken trust boundary can block the legitimate server or relay. In a common design, ports toward ordinary endpoints are untrusted, while an uplink toward the authorized service path may be explicitly trusted according to topology. If the trusted direction is wrong, offers may arrive at a switch and never reach the client. Security features do not disappear from the diagnosis merely because the switch reports that the interface is physically up.

DHCP snooping also provides binding information used by other protections such as Dynamic ARP Inspection on some platforms. A client configured with a static IPv4 address may not appear in a DHCP snooping table, creating policy considerations for that segment. Do not indiscriminately disable the feature to make leases work. First confirm where the server response enters the device, which port is trusted, whether rate limits or filtering are triggered, and whether the observed bindings align with legitimate users.

A rogue DHCP server can provide seemingly correct addresses but malicious DNS or gateway settings. A client that receives a lease too quickly from an unexpected server can indicate competing offers. In a controlled lab, use packet captures or DHCP transaction records to identify the server identifier and offered options. In production, coordinate corrective actions with security operations before changing access-layer trust or quarantine configuration.

Option 82, where supported, can convey information about a circuit or subscriber attachment through a relay or access infrastructure. That information may affect which scope or policy the DHCP server selects. It is not enough to assume all requests arriving from one relay address should receive identical settings: a server policy might also consider relay-agent metadata. If only one access segment fails while another segment using the same relay works, inspect the supplied relay information and the server’s scope-selection logic before rebuilding the entire service.

A client that holds a valid lease can renew it differently from a brand-new client. Renewal may initially contact a known server directly rather than repeat the first broadcast discovery sequence. That difference helps explain why long-connected devices appear healthy while new devices are unable to join. Test both workflows in a controlled environment, and record lease expiration and renewal timing rather than forcing production clients to release addresses indiscriminately.

Use packet evidence and platform output to identify the broken stage

On a client, inspect the assigned address and lease details and attempt a managed renew as appropriate for the operating system. Windows ipconfig /all and Linux network-management tooling present different views, so document the common fields rather than copy a command indiscriminately. On a Cisco device, show ip interface can help confirm a relay or interface configuration, while appropriate DHCP server and snooping commands depend on whether the device acts as server, relay or switch. Capture which role a given device serves before expecting it to have a lease table.

A capture can reveal Discover without Offer, Offer without acceptance, duplicate offers from different server identifiers or repeated acknowledgments followed by client failure. If a relay is used, capture on both the client segment and the routed path if allowed. A packet seen on one interface is not proof it emerged from the other. Compare times and transaction identifiers where possible. In a segmented network, the lack of a relay packet can be more informative than an endpoint log saying only that automatic addressing failed.

A controlled exercise should introduce five different faults: DHCP server unreachable, absent ip helper-address, wrong pool mask, exhausted scope, and a legitimate server reply blocked by snooping. Predict each symptom before making the change. A client getting no offer is not the same as a client getting the wrong gateway. The best lab notes include packet stage, received configuration, router path and the smallest verified change that restored correct service.

Apply the version-specific CCNA objectives to an operational result

The current CCNA 200-301 v1.1 objectives include understanding DHCP and DNS roles and configuring and verifying a DHCP client and relay. Cisco’s announced v2.0 for February 2027 is more explicit about troubleshooting DHCPv4 client, server and relay on IOS devices. The important extension is the server’s involvement and the expectation of a diagnostic method rather than just a known helper command.

The IPv4 subnetting reference supports scope sizing and gateway validation, while the CCNA 200-301 destination provides certification context. Check Cisco’s v1.1 blueprint and v2.0 exam topics for the version applicable to the scheduled test. A successful lab proves that a client receives the correct address, mask, gateway, DNS option and lease from the intended server—and documents why those same settings were missing when the service failed.