Quand l’adressage automatique échoue

La plupart du temps, DHCP fonctionne sans intervention. Mais lorsqu’aucun serveur DHCP ne répond, un appareil reste sans paramètres appropriés. Reconnaître les symptômes d’une panne DHCP est une compétence essentielle en dépannage. Le signe le plus évident est une adresse étrange commençant par 169.254, appelée adresse APIPA. Cette leçon explique APIPA et les raisons courantes pour lesquelles l’adressage automatique cesse de fonctionner.

APIPA (adressage IP privé automatique) est un mécanisme de secours intégré à Windows et à d’autres systèmes. Si un appareil envoie des Discover DHCP sans recevoir d’Offer, il s’attribue une adresse comprise entre 169.254.0.1 et 169.254.255.254, avec le masque 255.255.0.0. APIPA permet encore aux appareils du même segment de communiquer entre eux, mais ne fournit ni passerelle ni DNS ; l’accès à Internet est donc impossible.

Si vous vérifiez un appareil et voyez une adresse telle que 169.254.45.10, c’est un signal d’alerte majeur : l’appareil n’a jamais atteint de serveur DHCP. Les adresses APIPA sont locales au lien, ce qui signifie qu’elles ne fonctionnent que sur le câble ou le réseau Wi-Fi local et ne sont jamais acheminées ailleurs. La présence d’une adresse 169.254 doit immédiatement vous faire penser : « DHCP a échoué ; où est le serveur ? »

La cause la plus directe est que le serveur DHCP est arrêté ou que son service a cessé de fonctionner. Sans serveur, aucune Offer n’est envoyée et chaque client ayant besoin d’un bail passe à APIPA. Si de nombreux appareils affichent soudainement des adresses 169.254, soupçonnez le serveur lui-même plutôt qu’un appareil isolé. Le redémarrage du service DHCP rétablit souvent l’adressage normal.

Le serveur est peut-être en fonctionnement, mais la requête ne l’atteint jamais. Un câble défectueux, un port de commutateur désactivé ou un relais DHCP défaillant peuvent tous bloquer la diffusion Discover. Comme les routeurs ne transmettent pas les diffusions, l’absence d’un agent relais ou sa mauvaise configuration empêche les clients des sous-réseaux distants de recevoir la moindre réponse d’un serveur, même si celui-ci fonctionne correctement.

Parfois, le serveur répond à tout le monde jusqu’à épuisement de ses ressources. Si le pool d’adresses est entièrement loué, les nouveaux clients ne reçoivent aucune offre et basculent vers APIPA. Ce phénomène est fréquent sur les réseaux invités très sollicités. Pour le résoudre, agrandissez le pool ou réduisez la durée des baux afin que les adresses inutilisées soient recyclées plus rapidement et libèrent de la place pour les nouveaux appareils.

Un serveur DHCP indésirable est un serveur non autorisé, parfois un routeur domestique mal configuré qu’une personne a branché. Il peut répondre plus rapidement que le véritable serveur et distribuer de mauvaises adresses, passerelles ou informations DNS. Les appareils obtiennent alors une adresse apparemment valide, mais qui ne mène nulle part d’utile. Pour résoudre le problème, trouvez et retirez l’appareil indésirable ; les commutateurs peuvent utiliser l’inspection DHCP pour bloquer les serveurs non approuvés.

Un problème DHCP ne produit pas toujours 169.254. Un serveur indésirable ou une étendue mal configurée peut fournir une adresse réelle, mais incorrecte, ainsi qu’une mauvaise passerelle ou de mauvaises informations DNS. L’appareil semble connecté, mais ne peut pas naviguer. Vérifiez donc les quatre valeurs : adresse, masque, passerelle et DNS, et pas seulement la présence d’une adresse. Une configuration plausible, mais incorrecte, est plus difficile à repérer qu’une adresse APIPA évidente.

Lorsque vous dépannez un seul appareil, vous pouvez libérer son adresse actuelle et en demander une nouvelle. Sous Windows, deux commandes rapides suffisent. Si une nouvelle demande réussit, l’échec précédent était peut-être temporaire. Si l’appareil obtient encore 169.254, le problème se situe en amont — au niveau du serveur, du relais ou du chemin — et non au niveau de l’appareil.

Rassemblons tout cela sous forme de procédure. Voyez-vous 169.254 ? DHCP a échoué. Le problème concerne-t-il un seul appareil ou plusieurs ? Un seul appareil suggère un câble ou un port local ; plusieurs appareils orientent vers le serveur, le relais ou le pool. D’autres appareils du même segment obtiennent-ils une adresse ? Si oui, concentrez-vous sur l’appareil défaillant. Si non, concentrez-vous sur l’infrastructure partagée. Cette logique permet de cerner rapidement la cause.

Les échecs DHCP comptent parmi les appels les plus fréquents au service d’assistance, et les utilisateurs les perçoivent souvent comme une panne totale d’Internet. Savoir que 169.254 signifie l’absence de DHCP, et connaître les quelques causes possibles, permet de passer de la confusion à une liste de vérifications claire : serveur, chemin, pool ou serveur indésirable. Cette rapidité est précisément ce que récompensent l’examen Network+ et les emplois réels.

Testez votre analyse des pannes.

Lorsque DHCP échoue, les appareils basculent vers APIPA et s’attribuent automatiquement une adresse locale de liaison 169.254.x.x, sans passerelle ni DNS ; ils ne peuvent donc pas atteindre les autres réseaux. Une adresse 169.254 signifie que DHCP n’a pas répondu. Les causes courantes sont un serveur hors service, un chemin interrompu ou un relais manquant, un pool épuisé ou un serveur DHCP indésirable qui distribue de mauvais paramètres. Vérifiez toujours les quatre valeurs d’adresse et utilisez la libération et le renouvellement pour tester un seul appareil.