A PC, phone or AP that never gets an IP address is a client-to-server problem with four possible layers in between, and each layer has its own display dhcp command. This is the order that finds it fastest — plus the STP edge-port case that silently blocks fast-booting devices, and the DHCP Snooping checks that come up again and again.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
A client that can't get an IP address is a problem that can sit at any of four devices along the path — read the layer before you read the config.
A PC, phone, camera or AP that never gets an address through DHCP splits the path into four devices and three network segments: the client, the access switch it's plugged into, an optional DHCP relay or DHCP Snooping device, and the DHCP server itself. Ping alone can't tell you where DHCP is actually breaking down, because ICMP and DHCP are different packet types entirely — a link that pings fine can still be silently dropping DHCP Discover messages.
What follows is the fault tree this is built on, the display dhcp server / relay / snooping statistics commands for each layer, five root causes that show up again and again — including an STP edge-port case that fails DHCP specifically on fast-booting PCs — and a handful of FAQ answers pulled from real field cases.
DHCP failures split by which device in the chain is actually dropping the conversation — client, switch, Snooping/relay, or server.
Two quick tests place the symptom on this tree before anything else: put a static IP on the client to rule DHCP in or out entirely, and — where a relay is involved — plug the client straight into the DHCP server's own segment to isolate the server from everything downstream of it.
Diagram labels are kept in English for engineering clarity.
A static IP on the client rules DHCP in or out in seconds. From there, the four boxes at the top of the tree are strictly a matter of which display dhcp ... statistics counters actually move — that alone tells you which device to stop suspecting.
Four layers, four different commands, and a couple of quick tests that tell you which layer to stop suspecting.
If the switch never learns the client's MAC address in the first place, nothing downstream matters yet.
<HUAWEI> display mac-address mac-address 00e0-fc74-32d3
// if this returns nothing, the switch never saw a frame from this client --
// check whether the VLAN exists here and is allowed on the port, then check the next hop
<HUAWEI> display interface GigabitEthernet1/0/1
// Up but error-packet counters climbing -> suspect the cable, not DHCPPing reachability doesn't tell you anything about DHCP — Discover/Offer/Request/ACK is an entirely different packet type that has to be traced on its own.
<HUAWEI> display dhcp snooping statistics
// packet counters per DHCP message type -- confirms whether Discover/Offer/
// Request/ACK actually transited this device, independent of ICMP reachability
<HUAWEI> debugging dhcp snooping error
// error debug for the DHCP Snooping module specifically -- repeat for
// client / relay / server depending on which role this device playsDHCP Snooping sits between the client and the server purely to validate and record — a missing trusted interface blocks the client outright, not just the binding record.
<HUAWEI> display dhcp snooping interface 10GE1/0/1
DHCP snooping running information for interface 10GE1/0/1 :
DHCP snooping : Enable
Trusted interface : No (default)
// no trusted interface configured on the network side -> server replies get dropped
[HUAWEI] interface 10GE1/0/2
[HUAWEI-10GE1/0/2] dhcp snooping trusted
<HUAWEI> display dhcp snooping user-bind all
DHCP Dynamic Bind-table:
IP Address MAC Address VSI/VLAN(O/I/P) Interface Lease
------------------------------------------------------------------
10.1.1.254 00e0-fc74-32d3 100/-- /-- 10GE1/0/1 2026.07.17-16:36
print count: 1 total count: 1
// GIADDR already non-zero because Snooping sits after the first relay hop
[HUAWEI] undo dhcp snooping check dhcp-giaddr enableIf everything upstream is clean and the request is definitely reaching the server, the server's own pool and any packet-filtering policy are what's left.
<HUAWEI> display ip pool interface Vlanif100
Pool-name : Vlanif100
...
-------------------------------------------------------------------------------
Network section
Start End Total Used Idle(Expired) Conflict Disabled
-------------------------------------------------------------------------------
192.168.4.1 192.168.4.254 254 0 254(0) 0 0
-------------------------------------------------------------------------------
// Idle = 254 here -- if this instead read 0, the pool itself is out of addresses
// shrink the lease on an interface pool so addresses recycle faster:
[HUAWEI-Vlanif100] dhcp server lease day 0 hour 2Once you know which layer the fault is in, these five account for most of what's actually wrong.
SYMPTOMSpecific laptop models — the field report is usually a particular brand of business notebook — fail to get an IP address specifically when booting from a cold start (or from certain network-card boot sequences), while other devices on the same switch work fine.
CAUSEWhen some network cards initialize during boot, they briefly flap the link before settling. If the switch port isn't configured as an STP edge port, that flap is treated as a topology change and triggers a full STP recalculation — up to 30 seconds during which the port doesn't forward traffic at all. The client's DHCP client only sends four Discover attempts total; if all four land inside that 30-second blackout, the client gives up and reports a DHCP failure that has nothing to do with the DHCP configuration itself.
FIXConfigure every access port connected to end-user devices as an STP edge port. An edge port skips the listening/learning delay entirely on link-up, so a boot-time flap never triggers a topology recalculation in the first place.
<HUAWEI> system-view
[HUAWEI] interface GigabitEthernet1/0/1
[HUAWEI-GigabitEthernet1/0/1] stp edged-port enableSYMPTOMA client behind a DHCP relay never gets an address, specifically in topologies where a DHCP Snooping-enabled switch sits between the relay and the server rather than directly on the client's access segment.
CAUSEWhen client and server are on different subnets, the first-hop DHCP relay stamps its own IP address into the request's GIADDR field before forwarding. If dhcp snooping check dhcp-giaddr enable is configured on a Snooping device positioned downstream of that relay, it sees a non-zero GIADDR on what should be a first-hop request and drops the packet as suspicious.
FIXWithout changing the topology, disable the GIADDR check on that Snooping device. The structurally correct fix is to move DHCP Snooping onto the access-layer device or the first-hop relay itself, which is where it's designed to sit — Snooping exists to record the client's real MAC and port, and that information is only available at the first hop.
[HUAWEI] undo dhcp snooping check dhcp-giaddr enableSYMPTOMThe client gets an IP address successfully, but display dhcp snooping user-bind all never shows an entry for it — the security feature appears to simply not be working.
CAUSEWhether a dynamic binding entry gets created depends on both the user-side and network-side configuration together, not either one alone. If the user-side port doesn't have dhcp snooping enable, or the network-side port/VLAN isn't marked as a trusted interface, the client can often still get an address through the switch — but Snooping never captures the transaction it needed to build a binding record from.
FIXEnable dhcp snooping enable on the client-facing port and configure dhcp snooping trusted on the network-facing port (or the VLAN as a whole) so the reply path is recognized as legitimate and the request/reply pair gets recorded together.
[HUAWEI] interface 10GE1/0/1
[HUAWEI-10GE1/0/1] dhcp snooping enable
[HUAWEI-10GE1/0/1] quit
[HUAWEI] interface 10GE1/0/2
[HUAWEI-10GE1/0/2] dhcp snooping trustedSYMPTOMAfter a switch has been running for a while, new clients plugged into a given port can't get an IP address and can't reach the gateway at all — while existing, already-connected clients are unaffected.
CAUSEPort security with sticky MAC converts every dynamically learned MAC address into a permanent sticky entry. Once the configured maximum MAC count is reached, the port stops learning new addresses entirely and silently drops frames from any MAC it doesn't already recognize — including a brand-new client's DHCP Discover, which never even reaches the point where DHCP itself could respond.
FIXCheck display mac-address for a port stuck at its configured maximum with every entry showing type sticky. If the intent was never to hard-lock the port to one device, raise port-security enable maximum to a sensible ceiling for how many devices should legitimately share that port, or remove port security entirely if it isn't actually required there.
<HUAWEI> display mac-address
MAC Address VLAN/VSI/BD Learned-From Type Age
-------------------------------------------------------------
0000-0000-0001 100/-/- 10GE1/0/1 sticky 15825
...
0000-0000-0030 100/-/- 10GE1/0/1 sticky 15825
Total items: 30
// port already at its configured maximum of 30 sticky MACs -- a 31st device is refused
[HUAWEI-10GE1/0/1] port-security enable maximum 64SYMPTOMClients in one particular VLAN or subnet can't get an address while everything else on the network is unaffected, and it tends to get worse through the day rather than being constant.
CAUSEdisplay ip pool's Idle column is the number of addresses genuinely available to hand out right now. A pool that reaches Idle=0 — from more devices on the segment than the pool was originally sized for, or a lease time long enough that stale entries from disconnected devices haven't aged out yet — simply has nothing left to offer, independent of whether the DHCP conversation itself is working correctly.
FIXShrink the lease time so expired entries recycle faster, split the VLAN to add another interface pool, or widen the pool's subnet mask if the IP plan allows it — in roughly that order of how disruptive each change is to the existing network.
<HUAWEI> display ip pool interface Vlanif100
Network section
Start End Total Used Idle(Expired) Conflict Disabled
192.168.4.1 192.168.4.254 254 254 0(0) 0 0
// Idle = 0 -- the pool has nothing left, regardless of DHCP itself being healthy
[HUAWEI-Vlanif100] dhcp server lease day 0 hour 4Pulled straight from the field — the ones worth having an answer ready for.
Two tests before touching any switch configuration. First, put a static IP on the client and test connectivity — if that also fails, it's a Layer 2/3 reachability problem, not DHCP. Second, where a relay is involved, plug the client directly into the DHCP server's own segment; if it gets an address there, the server is fine and everything downstream of it — relay, Snooping, the access switch — is where to look.
This is the STP edge-port pattern. Some network cards briefly flap the link during their own boot sequence before settling. On a port that isn't configured as an STP edge port, that flap looks like a topology change and triggers a full recalculation — up to 30 seconds of no forwarding. A DHCP client only retries Discover four times total, and if all four attempts land inside that window, it gives up. Other devices that don't flap their link on boot never trigger the problem, which is why it looks brand-specific rather than switch-wide.
A VLAN-based trusted interface only applies to DHCP packets belonging to that specific VLAN passing through it; an interface-based trusted port applies to every DHCP packet the port receives, regardless of VLAN. Use interface-based trust on a simple uplink carrying one or a few VLANs toward the server, and VLAN-based trust when the same physical uplink also needs to stay untrusted for other VLANs it's carrying.
DHCP Snooping being enabled does not automatically insert Option 82. The insertion has to be explicitly configured — on the user-side VLAN or the user-side interface itself — as a separate step from enabling Snooping. Check display dhcp option82 configuration on the access device to confirm insertion is actually turned on where the client's traffic enters, not just that Snooping is running somewhere in the path.
On the access-layer device the client is directly connected to, or on the first-hop DHCP relay — never further downstream than that. Snooping's entire purpose is recording the client's real MAC address, VLAN and port in a binding table, and that information is only visible at the first hop; a Snooping device sitting deeper in the network only sees relayed packets with the relay's own address substituted in, which is also what triggers the GIADDR-check false positive described above.
A working ping only confirms ICMP reachability; DHCP is a completely different four-message exchange (Discover/Offer/Request/ACK) that has to be traced on its own terms. Check display mac-address to confirm the switch is actually learning the client at Layer 2, then use display dhcp ... statistics at each hop (snooping, relay, server) to see exactly where the DHCP-specific packet count stops climbing — a healthy ping tells you nothing about any of that.
This note is built around the Huawei S-series switch's DHCP fault-classification model and its display dhcp server / relay / snooping statistics, display ip pool, display mac-address and display dhcp snooping commands, plus the field cases behind them. If your access or aggregation gear is a different vendor, the exact commands change, but the underlying layered logic — client/access port, packet-path tracing, DHCP Snooping trust and binding, server pool and policy — carries over directly. It doesn't cover DHCPv6-specific stateless/PD flows in depth, or wireless-controller-specific DHCP relay behavior beyond what applies equally to a wired access switch.
Tell us which layer it's stuck at — client/port, Snooping, relay, or server — plus the display dhcp ... statistics output, and we'll help you read it.