Objectif
Déterminer pourquoi un poste Windows ne reçoit pas de bail DHCP valide et tombe en APIPA ou conserve une mauvaise configuration, en séparant le diagnostic du client, de la couche 2, du VLAN, du relay, de l’étendue et du serveur DHCP avant d’appliquer une correction.
Prérequis
- VLAN et sous-réseau attendus pour le poste.
- Nom ou IP du serveur DHCP et connaissance du relay/IP helper si le serveur est dans un autre réseau.
- Accès au switch ou au Wi-Fi
- Accès au serveur DHCP ou à l’équipement qui distribue les baux.
- Un client fonctionnel de comparaison si possible.
Procédure pas à pas
Lire la configuration reçue par le client
Commencez par ipconfig /all et notez l’adresse, le masque, la passerelle, les DNS, le serveur DHCP et l’heure du bail. Une adresse APIPA 169.254.x.x montre qu’aucun bail IPv4 valide n’a été reçu. Vérifiez aussi que l’interface est réellement configurée en DHCP et qu’une ancienne configuration statique ou alternative n’est pas active.
ipconfig /allGet-NetIPConfigurationGet-NetIPInterface -AddressFamily IPv4- L’état DHCP du client et le réseau attendu sont clairement identifiés.
Vérifier lien, carte et VLAN avant le serveur
Contrôlez l’état de la carte, le câble, le SSID et le port de switch. Comparez avec un poste fonctionnel sur le même port ou VLAN lorsque c’est possible. Si un autre poste échoue au même endroit, le problème est probablement en couche 2/VLAN ou en amont ; si le poste fonctionne ailleurs, inspectez son port ou SSID.
Get-NetAdapter | Format-Table Name,Status,LinkSpeed,MacAddress- Le client est connecté au bon réseau physique/logique.
Forcer un nouveau cycle DHCP et conserver le message
Libérez puis renouvelez le bail. Microsoft recommande ces commandes comme point de collecte côté client. Notez l’erreur exacte de renew. Si le poste reçoit immédiatement une adresse correcte, recherchez pourquoi le renouvellement précédent avait échoué au lieu de considérer le problème définitivement résolu.
ipconfig /releaseipconfig /renew- Le résultat du renouvellement est connu et reproductible.
Comparer avec un autre client du même VLAN
Testez un second appareil sur le même segment. Si tous les clients échouent, inspectez scope, relay et serveur. Si un seul client échoue, concentrez-vous sur sa carte, son driver, sa configuration, une réservation erronée, un filtre MAC/NAC ou une adresse précédente problématique. Cette comparaison évite de modifier un serveur sain.
- Le diagnostic est classé comme client unique ou incident de segment.
Contrôler l’étendue DHCP
Vérifiez que le scope correspondant au VLAN est activé, possède encore des adresses libres et que le masque, la passerelle, DNS et exclusions sont cohérents. Recherchez une plage épuisée, des réservations excessives ou un scope désactivé. Sur Windows Server, utilisez les cmdlets DHCP si le rôle est installé.
Get-DhcpServerv4ScopeGet-DhcpServerv4ScopeStatistics -ScopeId <SCOPE-ID>- Le scope est actif et dispose d’adresses disponibles.
Vérifier le relay ou IP helper
Lorsque le client et le serveur DHCP sont sur des sous-réseaux différents, confirmez que l’interface L3 du VLAN relaie les requêtes vers la bonne IP de serveur. Vérifiez également le chemin retour et les ACL/firewall. Une mauvaise adresse de relay peut affecter un seul VLAN alors que les autres scopes fonctionnent.
- Les requêtes du VLAN sont relayées vers le serveur DHCP prévu.
Analyser DORA et UDP 67/68
Le cycle initial suit Discover, Offer, Request, Acknowledge. Si nécessaire, capturez simultanément côté client et serveur pour voir où le processus s’arrête. Microsoft recommande une collecte des deux côtés lors des problèmes persistants. Un Discover sans Offer oriente vers relay, serveur ou filtrage ; un Offer reçu mais pas accepté peut indiquer une autre cause client ou réseau.
pktmon start --capture --pkt-size 0pktmon stop- L’étape DORA qui échoue est identifiée au lieu de deviner.
Consulter les événements DHCP client et serveur
Sur le poste, consultez Microsoft-Windows-DHCP Client Events. Côté serveur, vérifiez journaux DHCP, conflits et erreurs de base de données. Corrélez l’heure du test de renouvellement. Une erreur de policy, de failover ou d’autorisation du serveur doit être traitée au niveau du serveur plutôt que sur les clients.
Get-WinEvent -ListLog *DHCP* | Select-Object LogName,RecordCount,IsEnabled- Les événements confirment ou excluent un problème du service DHCP.
Corriger puis renouveler proprement
Appliquez une correction ciblée : réactiver un scope, corriger le relay, remettre le bon VLAN, libérer des adresses, corriger une réservation ou le client. Puis refaites release/renew et vérifiez passerelle, DNS et suffixe. Supprimez toute IP statique de contournement ajoutée pendant l’incident.
ipconfig /releaseipconfig /renewipconfig /all- Le poste reçoit un bail du bon scope avec les options attendues.
Documenter le motif et prévenir la récidive
Si le scope était presque plein, ajoutez une alerte de capacité. Si le relay était incorrect, mettez à jour le schéma réseau. Si un changement de VLAN a provoqué l’incident, ajoutez le contrôle DHCP aux tests de recette. Une panne DHCP récurrente doit devenir un indicateur supervisé plutôt qu’un diagnostic manuel à répétition.
- La cause est documentée et un contrôle préventif est ajouté lorsque pertinent.
Validation
La procédure est validée lorsque :
- Le client reçoit une adresse du sous-réseau attendu et non une APIPA.
- La passerelle, les DNS et le suffixe DHCP sont corrects.
- Le bail apparaît sur le serveur et le scope conserve une marge suffisante.
- Le relay/VLAN et le cycle DORA fonctionnent après correction.
Retour arrière
- Retirer toute adresse statique temporaire ou modification de VLAN utilisée pour le diagnostic.
- Restaurer le relay/IP helper précédent si la nouvelle configuration n’est pas validée.
- Réactiver une ancienne réservation seulement si elle était correcte et documentée.
Dépannage / erreurs fréquentes
- APIPA sur un seul poste : comparer carte, driver, VLAN, réservation et logs client avant de toucher au serveur.
- Tous les clients d’un VLAN échouent : vérifier relay/IP helper, scope et trunk/VLAN en priorité.
- Discover visible côté client mais absent côté serveur : problème de couche 2/relay/firewall entre les deux.
- Offer reçu mais pas de bail : inspecter Request/ACK, conflits, policy DHCP et éventuel NAC.