Top 10 des causes de dépassements de délai DHCP sur les réseaux WiFi haute densité

Bienvenue dans la série de briefs techniques de Purple. Je suis votre hôte, et aujourd'hui nous plongeons dans l'un des problèmes les plus frustrants - et franchement, les plus mal diagnostiqués - des réseaux sans fil d'entreprise : les expirations de délai DHCP sur les réseaux haute densité. Si vous gérez le WiFi d'un hôtel, d'un centre de conférence, d'une chaîne de magasins ou d'un stade, et que vos clients ou votre personnel restent bloqués sur l'affichage interminable du message « obtention de l'adresse IP », cet épisode est fait pour vous. Nous allons passer en revue les dix causes principales, comment diagnostiquer chacune d'elles et ce que vous devez faire dès maintenant. Plantons d'abord le décor. Le DHCP - Dynamic Host Configuration Protocol - est le mécanisme par lequel chaque appareil se connectant à votre réseau obtient une adresse IP, un masque de sous-réseau, une passerelle par défaut et les informations du serveur DNS. Il s'agit d'une négociation en quatre étapes : Discover, Offer, Request, Acknowledge - ce que les ingénieurs appellent le processus DORA. Cela semble simple, et sur un petit réseau, ça l'est. Mais lorsque vous avez cinq cents appareils qui sollicitent un seul VLAN à la réception d'une conférence, ou dix mille supporters qui ouvrent simultanément l'application d'un stade, le DHCP devient un goulot d'étranglement critique. Et lorsqu'il échoue, les utilisateurs ne peuvent pas se connecter. Point final. Découvrons donc les dix causes. Numéro un : l'épuisement du pool d'adresses IP. C'est la cause la plus fréquente, et elle est tout à fait évitable. Votre étendue DHCP - la plage d'adresses IP que votre serveur est autorisé à attribuer - a une taille limitée. Un sous-réseau slash-24 vous donne 254 adresses utilisables. Cela semble suffisant, jusqu'à ce que vous preniez en compte le fait que les appareils mobiles conservent souvent leurs baux même après s'être déconnectés, que les appareils IoT se multiplient sur votre site et que votre étendue a été dimensionnée pour une occupation normale, pas pour un événement complet. La solution est simple : dimensionnez correctement vos étendues. Pour les environnements haute densité, utilisez des sous-réseaux slash-22 ou slash-21. Cela vous donne plus de mille adresses par VLAN. Surveillez l'utilisation et configurez une alerte à quatre-vingts pour cent de capacité - ne la laissez jamais atteindre quatre-vingt-dix. Numéro deux : les durées de bail excessives. C'est le tueur silencieux. Si la durée de votre bail DHCP est configurée sur vingt-quatre heures - ce qui est la valeur par défaut sur de nombreux systèmes - et que vous gérez un site où les clients vont et viennent tout au long de la journée, ces adresses IP restent réservées par des appareils qui sont partis depuis des heures. Elles ne sont pas disponibles pour de nouvelles connexions. Pour le WiFi invité dans les environnements à fort taux de rotation - hôtels, commerces, événements - configurez la durée de votre bail entre trente et soixante minutes. Pour les réseaux du personnel de l'entreprise où les appareils restent connectés toute la journée, une durée de huit à douze heures est appropriée. N'utilisez jamais le bail par défaut de vingt-quatre heures sur un réseau invité. Numéro trois : mauvaise configuration de l'agent de relais DHCP. Dans tout déploiement d'entreprise avec plusieurs VLANs, votre serveur DHCP se trouve presque certainement sur un sous-réseau différent de celui de vos clients sans fil. L'agent de relais DHCP - généralement configuré sur votre commutateur de couche 3 ou votre routeur - est responsable du transfert des diffusions DHCP des clients vers le serveur. Si le relais est mal configuré - mauvaise adresse helper, mauvaise interface, ou relais simplement manquant sur un nouveau VLAN - les clients ne recevront jamais de réponse à leur DHCPDISCOVER. C'est l'une des causes les plus courantes d'échecs DHCP après un changement de réseau ou le déploiement d'un nouveau SSID. Vérifiez toujours la configuration du relais lors de l'ajout de VLANs, et testez avec une capture de paquets avant la mise en service. Numéro quatre : interférence par tempête de diffusion. Les messages de découverte DHCP sont des diffusions de couche 2. Dans un grand réseau plat avec des centaines de points d'accès tous sur le même VLAN, une tempête de diffusion - causée par une boucle de commutation, un port mal configuré ou un appareil défaillant - peut submerger le réseau de trafic de diffusion au point de perdre ou de retarder les paquets DHCP. Spanning Tree Protocol devrait être votre première ligne de défense, mais dans les déploiements WiFi à haute densité, vous devriez également activer la suppression de diffusion sur vos contrôleurs sans fil. La plupart des plateformes d'entreprise - Cisco, Aruba, Juniper Mist - prennent en charge des fonctionnalités de proxy DHCP ou de filtrage de diffusion qui convertissent les diffusions DHCP en unicast, réduisant ainsi considérablement la charge. Numéro cinq : point de défaillance unique - absence de redondance DHCP. Si votre serveur DHCP est un unique Windows Server ou un seul routeur, il s'agit d'un point de défaillance unique. Lorsqu'il s'arrête pour des mises à jour, tombe en panne ou perd sa connectivité réseau, chaque nouvelle tentative de connexion sur votre réseau échouera. Dans les déploiements d'entreprise, vous devriez exécuter un basculement DHCP - soit le mode de basculement DHCP de Windows Server, soit un boîtier DHCP dédié avec redondance actif-passif ou actif-actif. Pour les réseaux gérés dans le cloud, de nombreuses plateformes proposent désormais un DHCP distribué où le contrôleur gère les baux, mais vous devez tout de même comprendre les modes de défaillance. Numéro six : serveurs DHCP de type rogue. Celui-ci peut être particulièrement insidieux. Un serveur DHCP rogue est tout appareil non autorisé sur votre réseau qui répond aux messages de découverte DHCP. Il peut s'agir d'un point d'accès personnel branché par quelqu'un, d'une machine virtuelle mal configurée ou, dans le pire des scénarios, d'une attaque délibérée. Les serveurs DHCP rogue distribuent des adresses IP incorrectes, de mauvaises informations de passerelle ou des serveurs DNS pointant vers une infrastructure malveillante. Le résultat varie de l'absence de connectivité pour les utilisateurs à une attaque de l'homme du milieu. La parade est le filtrage DHCP (DHCP snooping) - une fonctionnalité disponible sur pratiquement tous les commutateurs gérés qui n'autorise les réponses DHCP que depuis des ports approuvés et désignés. Activez-la. Ce n'est pas optionnel dans un déploiement professionnel. Numéro sept : pare-feu et ACL bloquant les ports UDP soixante-sept et soixante-huit. DHCP fonctionne sur le port UDP soixante-sept pour le trafic serveur-client et sur le port soixante-huit pour le trafic client-serveur. Si des listes de contrôle d'accès ou des règles de pare-feu bloquent ces ports - peut-être dans le cadre d'un renforcement de la sécurité ou d'une politique mal configurée - DHCP échouera silencieusement. Cela se produit fréquemment après une migration de pare-feu ou une mise à jour des politiques. Vérifiez toujours que les ports UDP soixante-sept et soixante-huit sont explicitement autorisés entre vos VLAN sans fil et votre serveur DHCP. Utilisez des captures de paquets au niveau de l'interface du serveur pour confirmer que le trafic arrive bien. Numéro huit : mauvaise configuration de VLAN. Les échecs DHCP sont fréquemment le symptôme d'un problème de VLAN plutôt que d'un problème DHCP. Si un client sans fil est associé à un SSID qui correspond au VLAN trente, mais que le port de liaison montante de l'access point n'achemine pas le VLAN trente en tant que VLAN étiqueté, la découverte DHCP n'atteint jamais la couche de distribution. De même, si l'étendue DHCP est définie pour le mauvais sous-réseau, ou si l'étendue n'est pas activée, les clients ne recevront aucune réponse. Chaque fois que vous dépannez DHCP, vérifiez le marquage VLAN de bout en bout : de la liaison montante de l'AP, en passant par le commutateur d'accès, le commutateur de distribution, jusqu'à l'interface du serveur DHCP. Un seul tag VLAN manquant dans cette chaîne entraînera un échec complet. Numéro neuf : bogues du firmware de l'access point. C'est moins fréquent mais cela mérite d'être souligné, en particulier dans les déploiements à grande échelle exécutant un environnement de firmware mixte. Il y a eu des cas documentés - y compris un bogue UniFi U7 très médiatisé début 2026 - où le firmware de l'access point abandonnait par intermittence le troisième paquet de la liaison à trois voies DHCP : le DHCPREQUEST. Le client envoie la découverte, reçoit une offre, envoie la requête - et l'AP la rejette. Le client ne reçoit jamais d'accusé de réception. La solution est simple : maintenez le firmware de votre AP à jour et, lorsque vous dépannez des échecs DHCP intermittents qui ne correspondent à aucun autre schéma, vérifiez la version du firmware et la liste des problèmes connus du fournisseur. Numéro dix : problèmes d'itinérance des clients. Dans les environnements à haute densité, les clients se déplacent constamment entre les access points. Lorsqu'un client passe d'un AP à un autre - en particulier s'il traverse une limite de VLAN ou passe à un sous-réseau différent - il peut avoir besoin d'obtenir un nouveau bail DHCP. Si l'événement d'itinérance n'est pas géré correctement, le client peut tenter de renouveler son bail existant sur un sous-réseau auquel il n'est plus connecté, ce qui entraîne un dépassement de délai. La norme IEEE 802.11r - transition BSS rapide - est conçue pour accélérer l'itinérance, mais elle présente des problèmes de compatibilité connus avec certains appareils clients. La solution la plus fiable pour l'itinérance de niveau 3 consiste à utiliser les fonctionnalités de tunnelisation de clients ou d'AP d'ancrage de votre contrôleur sans fil, ce qui garantit que le client semble toujours se trouver sur le même sous-réseau, quel que soit l'AP auquel il est associé. Parlons maintenant de la mise en œuvre. Si je devais conseiller un client aujourd'hui sur la sécurisation de son infrastructure DHCP pour un site à haute densité, voici ce que je lui dirais. Premièrement, auditez vos plages immédiatement. Générez un rapport d'utilisation DHCP et examinez les pics d'occupation. Si une plage atteint quatre-vingts pour cent d'utilisation pendant les opérations normales, vous devez l'étendre avant votre prochain événement à fort trafic. Utilisez un masque en slash-22 ou plus grand pour les réseaux invités. Deuxièmement, définissez des durées de bail appropriées pour chaque segment de réseau. WiFi invités : trente à soixante minutes. WiFi du personnel : huit heures. IoT et infrastructure : vingt-quatre heures ou réservations statiques. Troisièmement, implémentez le DHCP snooping sur chaque commutateur d'accès. Il s'agit d'une tâche de configuration unique qui élimine entièrement le risque de serveur DHCP malveillant. Quatrièmement, déployez le basculement DHCP. Si vous êtes sur Windows Server, configurez la fonctionnalité de basculement intégrée. Si vous êtes sur une plateforme gérée dans le cloud, comprenez d'où le DHCP est fourni et ce qui se passe lorsque ce composant tombe en panne. Cinquièmement, activez la suppression des diffusions sur votre contrôleur sans fil. Convertissez les diffusions DHCP en unicast là où cela est pris en charge. Cela réduit considérablement la surcharge dans les environnements denses. Sixièmement, documentez votre cartographie VLAN-to-DHCP-scope. Chaque VLAN doit avoir une plage documentée, une configuration d'agent de relais et un propriétaire désigné. En cas de panne, cette documentation réduit votre temps moyen de résolution de plusieurs heures à quelques minutes. Passons maintenant aux questions rapides. Question : Comment savoir si mon pool DHCP est épuisé ? Réponse : Exécutez "show ip dhcp pool" sur un équipement Cisco, ou vérifiez la console de gestion de votre serveur DHCP. Recherchez "no free leases" dans votre syslog. Configurez des alertes de surveillance à quatre-vingts pour cent d'utilisation. Question : Quel est le moyen le plus rapide de diagnostiquer une panne DHCP ? Réponse : Une capture de paquets sur l'interface côté client. Si vous voyez un DHCPDISCOVER sans DHCPOFFER en réponse, le problème se situe entre le client et le serveur. Si vous voyez un DHCPOFFER mais pas de DHCPACK, le problème réside dans l'échange requête-accusé de réception. Question : Dois-je utiliser des adresses IP statiques plutôt que le DHCP pour les environnements à haute densité ? Réponse : Non. La gestion des adresses IP statiques à grande échelle est impossible à gérer sur le plan opérationnel. La bonne réponse est un DHCP bien architecturé avec un dimensionnement de plage, des durées de bail et une redondance appropriés. Question : Le DHCP snooping affecte-t-il les performances ? Réponse : De façon négligeable. Sur les commutateurs gérés modernes, le DHCP snooping fonctionne au niveau matériel et n'a aucun impact mesurable sur le débit. En résumé : les expirations de délai DHCP sur les réseaux WiFi à haute densité sont presque toujours causées par l'une des dix causes fondamentales suivantes - l'épuisement du pool, des durées de bail excessives, une mauvaise configuration du relais, des tempêtes de diffusion, un manque de redondance, des serveurs malveillants, des blocages de pare-feu, des mauvaises configurations de VLAN, des bogues de firmware ou des problèmes d'itinérance. Chacune d'entre elles dispose d'un parcours de diagnostic clair et d'une solution simple. Aucune ne nécessite de mises à niveau matérielles coûteuses. Elles nécessitent une configuration appropriée, une surveillance adéquate et une documentation rigoureuse. Si vous exploitez une plateforme de WiFi invité comme Purple, vous bénéficiez de l'avantage supplémentaire d'une visibilité optimale sur les événements de connexion, les flux d'authentification et les données de session qui peuvent vous aider à corréler les échecs DHCP avec des appareils, des SSID ou des fenêtres temporelles spécifiques. Cette télémétrie est inestimable pour l'analyse des causes profondes. Vos prochaines étapes : auditez vos plages DHCP dès aujourd'hui, implémentez le DHCP snooping si ce n'est pas déjà fait, et configurez un suivi de l'utilisation avec des alertes. N'attendez pas la prochaine panne pour découvrir que votre pool d'adresses est épuisé. Merci d'avoir écouté la série de fiches techniques Purple. Pour obtenir d'autres guides, des références d'architecture et les meilleures pratiques de déploiement, visitez purple.ai.