Un PC, un téléphone ou un point d'accès qui n'obtient jamais d'adresse IP est un problème client-serveur avec quatre couches possibles entre les deux, et chaque couche a sa propre commande display dhcp. Voici l'ordre qui trouve la panne le plus vite — plus le cas du port périphérique STP qui bloque silencieusement les appareils à démarrage rapide, et les vérifications DHCP Snooping qui reviennent sans cesse.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Un client qui ne peut pas obtenir d'adresse IP est un problème qui peut se situer sur l'un des quatre appareils du chemin — identifiez la couche avant de lire la configuration.
Un PC, un téléphone, une caméra ou un point d'accès qui n'obtient jamais d'adresse via DHCP divise le chemin en quatre appareils et trois segments réseau : le client, le commutateur d'accès auquel il est branché, un relais DHCP ou un appareil DHCP Snooping optionnel, et le serveur DHCP lui-même. Le ping seul ne peut pas indiquer où le DHCP échoue réellement, car ICMP et DHCP sont des types de paquets entièrement différents — une liaison qui ping correctement peut quand même abandonner silencieusement des messages DHCP Discover.
Voici l'arbre de panne sur lequel ce texte s'appuie, les commandes display dhcp server / relay / snooping statistics pour chaque couche, cinq causes profondes qui reviennent sans cesse — dont un cas de port périphérique STP qui fait échouer spécifiquement le DHCP sur les PC à démarrage rapide — et quelques réponses de FAQ tirées de cas de terrain réels.
Les pannes DHCP se répartissent selon l'appareil de la chaîne qui abandonne réellement la conversation — client, commutateur, Snooping/relais, ou serveur.
Deux tests rapides placent le symptôme sur cet arbre avant tout le reste : mettez une IP statique sur le client pour confirmer ou exclure entièrement le DHCP, et — si un relais est impliqué — branchez le client directement sur le segment du serveur DHCP lui-même pour isoler le serveur de tout ce qui est en aval.
Les libellés du diagramme sont conservés en anglais pour plus de clarté technique.
Une IP statique sur le client confirme ou exclut le DHCP en quelques secondes. À partir de là, les quatre cases en haut de l'arbre ne sont qu'une question de savoir quels compteurs display dhcp ... statistics bougent réellement — cela seul indique quel appareil ne plus soupçonner.
Quatre couches, quatre commandes différentes, et quelques tests rapides qui indiquent quelle couche ne plus soupçonner.
Si le commutateur n'apprend jamais l'adresse MAC du client en premier lieu, rien en aval n'a encore d'importance.
<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 DHCPLa joignabilité par ping ne dit rien sur le DHCP — Discover/Offer/Request/ACK est un type de paquet entièrement différent qui doit être tracé séparément.
<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 se situe entre le client et le serveur uniquement pour valider et enregistrer — une interface de confiance manquante bloque le client directement, pas seulement l'enregistrement de liaison.
<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 enableSi tout en amont est propre et que la requête atteint bien le serveur, il ne reste que le pool du serveur lui-même et toute politique de filtrage de paquets.
<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 2Une fois que vous savez dans quelle couche se trouve la panne, ces cinq causes expliquent la plupart de ce qui ne va vraiment pas.
SYMPTÔMECertains modèles d'ordinateurs portables — le signalement de terrain concerne généralement une marque particulière de portable professionnel — n'arrivent pas à obtenir une adresse IP spécifiquement lors d'un démarrage à froid (ou de certaines séquences de démarrage de carte réseau), tandis que d'autres appareils sur le même commutateur fonctionnent bien.
CAUSELorsque certaines cartes réseau s'initialisent au démarrage, elles font brièvement clignoter le lien avant de se stabiliser. Si le port du commutateur n'est pas configuré comme port périphérique STP, ce clignotement est traité comme un changement de topologie et déclenche un recalcul STP complet — jusqu'à 30 secondes pendant lesquelles le port ne transfère aucun trafic. Le client DHCP du client n'envoie que quatre tentatives Discover au total ; si les quatre tombent dans cette fenêtre noire de 30 secondes, le client abandonne et signale une panne DHCP qui n'a rien à voir avec la configuration DHCP elle-même.
CORRECTIFConfigurez chaque port d'accès connecté à des appareils utilisateurs finaux comme port périphérique STP. Un port périphérique saute entièrement le délai d'écoute/apprentissage à la mise en service du lien, donc un clignotement au démarrage ne déclenche jamais de recalcul de topologie en premier lieu.
<HUAWEI> system-view
[HUAWEI] interface GigabitEthernet1/0/1
[HUAWEI-GigabitEthernet1/0/1] stp edged-port enableSYMPTÔMEUn client derrière un relais DHCP n'obtient jamais d'adresse, spécifiquement dans des topologies où un commutateur avec DHCP Snooping activé se situe entre le relais et le serveur plutôt que directement sur le segment d'accès du client.
CAUSELorsque le client et le serveur sont sur des sous-réseaux différents, le relais DHCP du premier saut inscrit sa propre adresse IP dans le champ GIADDR de la requête avant de la transférer. Si dhcp snooping check dhcp-giaddr enable est configuré sur un appareil Snooping situé en aval de ce relais, il voit un GIADDR non nul sur ce qui devrait être une requête de premier saut et abandonne le paquet comme suspect.
CORRECTIFSans changer la topologie, désactivez la vérification GIADDR sur cet appareil Snooping. La correction structurellement correcte est de déplacer DHCP Snooping sur l'appareil de couche d'accès ou le relais du premier saut lui-même, qui est l'endroit où il est conçu pour se situer — Snooping existe pour enregistrer la vraie MAC et le port du client, et cette information n'est disponible qu'au premier saut.
[HUAWEI] undo dhcp snooping check dhcp-giaddr enableSYMPTÔMELe client obtient bien une adresse IP, mais display dhcp snooping user-bind all n'affiche jamais d'entrée pour lui — la fonctionnalité de sécurité semble simplement ne pas fonctionner.
CAUSELe fait qu'une entrée de liaison dynamique soit créée dépend à la fois de la configuration côté utilisateur et côté réseau ensemble, pas de l'une seule. Si le port côté utilisateur n'a pas dhcp snooping enable, ou si le port/VLAN côté réseau n'est pas marqué comme interface de confiance, le client peut souvent quand même obtenir une adresse via le commutateur — mais Snooping ne capture jamais la transaction dont il avait besoin pour construire un enregistrement de liaison.
CORRECTIFActivez dhcp snooping enable sur le port orienté client et configurez dhcp snooping trusted sur le port orienté réseau (ou le VLAN dans son ensemble) afin que le chemin de réponse soit reconnu comme légitime et que la paire requête/réponse soit enregistrée ensemble.
[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 trustedSYMPTÔMEAprès qu'un commutateur ait fonctionné un certain temps, les nouveaux clients branchés sur un port donné ne peuvent pas obtenir d'adresse IP et ne peuvent pas du tout atteindre la passerelle — alors que les clients existants déjà connectés ne sont pas affectés.
CAUSELa sécurité de port avec MAC collant convertit chaque adresse MAC apprise dynamiquement en une entrée collante permanente. Une fois le nombre maximum de MAC configuré atteint, le port cesse entièrement d'apprendre de nouvelles adresses et abandonne silencieusement les trames provenant de toute MAC qu'il ne reconnaît pas déjà — y compris le Discover DHCP d'un tout nouveau client, qui n'atteint même pas le point où le DHCP lui-même pourrait répondre.
CORRECTIFVérifiez display mac-address pour un port bloqué à son maximum configuré avec chaque entrée affichant type sticky. Si l'intention n'a jamais été de verrouiller le port sur un seul appareil, augmentez port-security enable maximum à un plafond raisonnable pour le nombre d'appareils devant légitimement partager ce port, ou supprimez complètement la sécurité de port si elle n'est pas réellement nécessaire ici.
<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 64SYMPTÔMELes clients d'un VLAN ou sous-réseau particulier ne peuvent pas obtenir d'adresse alors que tout le reste du réseau n'est pas affecté, et cela a tendance à s'aggraver au cours de la journée plutôt que d'être constant.
CAUSELa colonne Idle de display ip pool est le nombre d'adresses réellement disponibles à distribuer en ce moment. Un pool qui atteint Idle=0 — parce qu'il y a plus d'appareils sur le segment que ce pour quoi le pool a été initialement dimensionné, ou un bail assez long pour que les entrées obsolètes d'appareils déconnectés n'aient pas encore expiré — n'a tout simplement plus rien à offrir, indépendamment du bon fonctionnement de la conversation DHCP elle-même.
CORRECTIFRéduisez la durée du bail pour que les entrées expirées se recyclent plus vite, divisez le VLAN pour ajouter un autre pool d'interface, ou élargissez le masque de sous-réseau du pool si le plan IP le permet — à peu près dans cet ordre de perturbation de chaque changement sur le réseau existant.
<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 4Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Deux tests avant de toucher à toute configuration de commutateur. D'abord, mettez une IP statique sur le client et testez la connectivité — si cela échoue aussi, c'est un problème de joignabilité de couche 2/3, pas le DHCP. Ensuite, si un relais est impliqué, branchez le client directement sur le segment du serveur DHCP lui-même ; s'il obtient une adresse là, le serveur va bien et tout ce qui est en aval — relais, Snooping, commutateur d'accès — est là où regarder.
C'est le schéma du port périphérique STP. Certaines cartes réseau font brièvement clignoter le lien pendant leur propre séquence de démarrage avant de se stabiliser. Sur un port qui n'est pas configuré comme port périphérique STP, ce clignotement ressemble à un changement de topologie et déclenche un recalcul complet — jusqu'à 30 secondes sans transfert. Un client DHCP ne retente Discover que quatre fois au total, et si les quatre tentatives tombent dans cette fenêtre, il abandonne. D'autres appareils qui ne font pas clignoter leur lien au démarrage ne déclenchent jamais le problème, ce qui explique pourquoi cela semble spécifique à la marque plutôt qu'à l'ensemble du commutateur.
Une interface de confiance basée sur le VLAN ne s'applique qu'aux paquets DHCP appartenant à ce VLAN spécifique qui la traversent ; un port de confiance basé sur l'interface s'applique à chaque paquet DHCP reçu par le port, quel que soit le VLAN. Utilisez la confiance basée sur l'interface sur une liaison montante simple transportant un ou quelques VLAN vers le serveur, et la confiance basée sur le VLAN lorsque la même liaison montante physique doit aussi rester non fiable pour d'autres VLAN qu'elle transporte.
L'activation de DHCP Snooping n'insère pas automatiquement l'Option 82. L'insertion doit être explicitement configurée — sur le VLAN côté utilisateur ou l'interface côté utilisateur elle-même — comme une étape distincte de l'activation de Snooping. Vérifiez display dhcp option82 configuration sur l'appareil d'accès pour confirmer que l'insertion est réellement activée là où le trafic du client entre, pas seulement que Snooping fonctionne quelque part sur le chemin.
Sur l'appareil de couche d'accès auquel le client est directement connecté, ou sur le relais DHCP du premier saut — jamais plus loin en aval que cela. Tout l'objectif de Snooping est d'enregistrer la vraie adresse MAC, le VLAN et le port du client dans une table de liaison, et cette information n'est visible qu'au premier saut ; un appareil Snooping situé plus profondément dans le réseau ne voit que des paquets relayés avec la propre adresse du relais substituée, ce qui est aussi ce qui déclenche le faux positif de vérification GIADDR décrit ci-dessus.
Un ping fonctionnel ne confirme que la joignabilité ICMP ; le DHCP est un échange de quatre messages entièrement différent (Discover/Offer/Request/ACK) qui doit être tracé selon ses propres termes. Vérifiez display mac-address pour confirmer que le commutateur apprend réellement le client en couche 2, puis utilisez display dhcp ... statistics à chaque saut (snooping, relais, serveur) pour voir précisément où le compteur de paquets spécifique au DHCP cesse d'augmenter — un ping sain ne vous dit rien de tout cela.
Cette note s'appuie sur le modèle de classification des pannes DHCP du commutateur Huawei série S et ses commandes display dhcp server / relay / snooping statistics, display ip pool, display mac-address et display dhcp snooping, ainsi que les cas de terrain qui les sous-tendent. Si votre équipement d'accès ou d'agrégation est d'un autre fournisseur, les commandes exactes changent, mais la logique en couches sous-jacente — client/port d'accès, traçage du chemin des paquets, confiance et liaison DHCP Snooping, pool et politique du serveur — s'applique directement. Elle ne couvre pas en profondeur les flux DHCPv6 sans état/PD spécifiques, ni le comportement de relais DHCP spécifique aux contrôleurs sans fil au-delà de ce qui s'applique également à un commutateur d'accès filaire.
Dites-nous à quelle couche ça bloque — client/port, Snooping, relais ou serveur — ainsi que la sortie de display dhcp ... statistics, et nous vous aiderons à l'interpréter.