Top 10 des causes de timeouts DHCP sur les réseaux sans fil à haute densité

Bienvenue dans la série de briefings techniques Purple. Je suis votre hôte et aujourd'hui, nous plongeons au cœur de 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 (DHCP timeouts) sur les réseaux à haute densité. Si vous gérez le WiFi dans un hôtel, un centre de conférence, une chaîne de magasins ou un stade, et que vos clients ou votre personnel sont confrontés à ce redoutable indicateur de chargement "obtention de l'adresse IP", cet épisode est pour vous. Nous allons passer en revue les dix principales causes profondes, comment diagnostiquer chacune d'elles et ce que vous devriez faire dès maintenant. Plantons d'abord le décor. Le DHCP — Dynamic Host Configuration Protocol — est le mécanisme par lequel chaque appareil qui se connecte à votre réseau obtient une adresse IP, un masque de sous-réseau, une passerelle par défaut et les informations du serveur DNS. C'est 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 simultanément un seul VLAN à un bureau d'inscription de conférence, ou dix mille supporters qui ouvrent en même temps l'application du stade, le DHCP devient un goulot d'étranglement critique. Et quand il échoue, les utilisateurs ne peuvent pas se connecter. Point final. Entrons donc dans le vif du sujet avec les dix causes. Numéro un : l'épuisement de la plage 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é à distribuer — a une taille limitée. Un sous-réseau en /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 prolifèrent dans votre établissement et que votre étendue a été dimensionnée pour une occupation normale, et non pour un événement à guichets fermés. La solution est simple : dimensionnez correctement vos étendues. Pour les environnements à haute densité, utilisez des sous-réseaux en /22 ou /21. Cela vous donne plus de mille adresses par VLAN. Surveillez l'utilisation et configurez des alertes à quatre-vingts pour cent de capacité — ne la laissez jamais atteindre quatre-vingt-dix. Numéro deux : des 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 visiteurs vont et viennent tout au long de la journée, ces adresses IP sont conservé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 votre durée de 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 VLAN, 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 ou routeur de couche 3 — est responsable de la transmission des diffusions (broadcasts) DHCP des clients vers le serveur. Si le relais est mal configuré — mauvaise adresse d'assistance (helper address), mauvaise interface, ou si le relais est tout 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 une modification du réseau ou le déploiement d'un nouveau SSID. Vérifiez toujours la configuration du relais lors de l'ajout de VLAN et testez avec une capture de paquets avant la mise en production. Numéro quatre : interférences dues aux tempêtes de diffusion (broadcast storms). Les messages de découverte DHCP sont des diffusions de couche 2. Dans un grand réseau plat comprenant 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 équipement défectueux — peut submerger le réseau de trafic de diffusion au point d'égarer ou de retarder les paquets DHCP. Le protocole Spanning Tree doit être votre première ligne de défense, mais dans les déploiements sans fil à haute densité, vous devez également activer la suppression des diffusions sur vos contrôleurs sans fil. La plupart des plateformes d'entreprise — Cisco, Aruba, Juniper Mist — prennent en charge les fonctionnalités de proxy DHCP ou de filtrage des diffusions qui convertissent les diffusions DHCP en unicast, réduisant ainsi considérablement la surcharge. Numéro cinq : point de défaillance unique — absence de redondance DHCP. Si votre serveur DHCP est un simple serveur Windows Server ou un routeur unique, il constitue un point de défaillance unique. Lorsqu'il s'arrête pour une mise à 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 (DHCP failover) — soit le mode de basculement DHCP de Windows Server, soit un équipement DHCP dédié avec une 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 (serveurs DHCP pirates). 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 un utilisateur, d'une machine virtuelle mal configurée ou, dans le pire des cas, 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 va d'une absence totale de connectivité pour les utilisateurs à une attaque de type homme du milieu (man-in-the-middle). La solution est le filtrage DHCP (DHCP snooping) — une fonctionnalité disponible sur la quasi-totalité des commutateurs managés qui n'autorise les réponses DHCP que provenant de ports approuvés et désignés. Activez-le. Ce n'est pas une option 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-vers-client et sur le port soixante-huit pour le trafic client-vers-serveur. Si vous avez des listes de contrôle d'accès ou des règles de pare-feu qui bloquent ces ports — peut-être dans le cadre d'un exercice de renforcement de la sécurité ou d'une politique mal configurée — DHCP échouera silencieusement. C'est particulièrement fréquent après une migration de pare-feu ou une mise à jour de politique. 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. 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'accès point ne transporte pas le VLAN trente en tant que VLAN taggué, 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 taggage des 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 n'importe où dans cette chaîne entraînera un échec complet. Numéro neuf : bogues de firmware des points d'accès. C'est moins fréquent mais cela vaut la peine d'être souligné, en particulier dans les déploiements à grande échelle où vous exécutez un environnement de firmware mixte. Il y a eu des cas documentés — y compris un bogue UniFi U7 très médiatisé au début de 2026 — où le firmware du point d'accès abandonnait par intermittence le troisième paquet de la liaison DHCP : le DHCPREQUEST. Le client envoie la découverte, obtient une offre, envoie la demande — et l'AP l'abandonne. 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 modèle, 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 sont constamment en itinérance entre les points d'accès. 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élai d'attente dépassé. 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 couche 3 consiste à utiliser les fonctionnalités de tunnelisation client ou d'AP d'ancrage de votre contrôleur sans fil, qui garantissent que le client semble toujours être 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 analysez les pics d'occupation. Si une plage atteint quatre-vingts pour cent d'utilisation en fonctionnement normal, vous devez l'étendre avant votre prochain événement à fort trafic. Utilisez un /22 ou plus grand pour les réseaux WiFi 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 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 non autorisé. Quatrièmement, déployez le failover DHCP. Si vous utilisez Windows Server, configurez la fonctionnalité de failover intégrée. Si vous utilisez une plateforme gérée dans le cloud, comprenez d'où le DHCP est fourni et ce qui se passe en cas de défaillance de ce composant. Cinquièmement, activez la suppression du broadcast sur votre contrôleur sans fil. Convertissez les broadcasts DHCP en unicast là où cela est pris en charge. Cela réduit considérablement la surcharge dans les environnements d'utilisateurs denses. Sixièmement, documentez votre mappage VLAN vers plage DHCP. 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 d'heures en 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 d'administration 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 : Capturez les 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 de demande-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 conçu 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 manière négligeable. Sur les commutateurs managé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 sans fil à haute densité sont presque toujours causées par l'une des dix causes profondes suivantes — épuisement du pool, durées de bail excessives, mauvaise configuration du relais, tempêtes de broadcast, manque de redondance, serveurs non autorisés, blocages de pare-feu, mauvaises configurations de VLAN, bogues de firmware ou problèmes d'itinérance. Chacune dispose d'un parcours de diagnostic clair et d'une résolution précise. Aucune d'entre elles ne nécessite de mises à niveau matérielles coûteuses. Elles nécessitent une configuration adéquate, une surveillance appropriée et une documentation rigoureuse. Si vous exploitez une plateforme WiFi invités comme Purple, vous bénéficiez de l'avantage supplémentaire d'une visibilité sur les événements de connexion, les flux d'authentification et les données de session pour vous aider à corréler les échecs DHCP avec des appareils, des SSIDs ou des fenêtres temporelles spécifiques. Cette télémétrie est précieuse 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 le prochain incident pour découvrir que votre pool d'adresses est épuisé. Merci d'avoir suivi la série Purple Technical Briefing. Pour plus de guides, de références d'architecture et de bonnes pratiques de déploiement, visitez purple.ai.