Tu connais sûrement la scène. Il est 9 h 02. Tout allait bien. Et d’un coup, les nouveaux postes n’ont plus d’IP, le Wi Fi « marche mais pas Internet », les imprimantes réseau disparaissent, et toi tu vois dans les logs… DHCP scope full. Plage épuisée.
Le piège, c’est que la « solution rapide » (redémarrer le service, vider des baux au hasard, changer le masque en plein milieu) peut provoquer une vraie coupure. Et sur un site en prod, ou même dans un labo un peu sérieux, c’est le genre d’action qui te revient en boomerang.
Dans cet article, on va faire un truc simple et propre : récupérer des adresses et/ou étendre une plage DHCP sans interrompre les clients existants, avec une méthode reproductible. C’est très orienté terrain, un peu comme ce qu’on publie sur BTS SIO2 SISR Tech Lab (si tu veux d’autres labs réseau du même style, garde le site dans tes favoris : https://sio1blog.blogspot.com/).
Symptômes typiques d’une plage épuisée
Avant de toucher quoi que ce soit, valide qu’on est bien sur ce problème là (et pas un VLAN mal tagué, un relais DHCP cassé, un conflit de serveur, etc.).
- Les clients obtiennent une IP en
169.254.x.x(APIPA) ou restent en « identification… » ipconfig /renewoudhclient -r && dhclientéchoue- Sur le serveur DHCP : alertes type « 100 % used » ou événements sur l’étendue
- Des baux très anciens restent « actifs » alors que les machines n’existent plus
- Beaucoup d’appareils temporaires : téléphones, invités, VM, BYOD, IoT
Ajoute un réflexe : compter les IP réellement disponibles.
Ce qu’il ne faut pas faire (même si tu es tenté)
Oui, ça marche parfois. Mais c’est instable.
- Redémarrer le service DHCP « pour voir »
- Réduire la plage en pensant « on n’a pas besoin de tant »
- Changer le masque (passer de /24 à /23) sans plan, sans vérifier les routes, sans vérifier les équipements statiques
- Supprimer des baux au hasard, surtout si tu ne sais pas à qui ils appartiennent
- Laisser deux serveurs DHCP répondre sur le même VLAN
Diagnostic express sans casser l’existant
Côté serveur
Sur Windows Server DHCP, va dans la console DHCP :
- Étendue concernée
- « Address Leases » (baux)
- Trie par « Lease Expiration » et repère les baux qui durent depuis longtemps, ou qui ne devraient pas être là (machines inexistantes, MAC inconnues, etc.)
- Vérifie le pourcentage utilisé et les exclusions
Sur Linux (ISC DHCP ou Kea), tu as les baux dans un fichier ou une DB selon le moteur. Mais l’idée reste la même : identifier si tu es en pénurie réelle ou en pénurie artificielle (baux trop longs, IP réservées, exclusions trop larges, appareils zombies).
Côté réseau
Un check utile : tu as potentiellement plein de périphériques qui consomment une IP sans que tu les voies.
- Contrôleur Wi Fi qui met tout le monde sur le même VLAN
- Téléphones IP avec PC derrière (double consommation)
- Hyperviseur qui a monté 30 VM hier soir
- Switch qui relaie vers un VLAN inattendu (mauvais scope ou mauvais helper)
Objectif : réparer sans coupure, c’est quoi exactement
Dans la vraie vie, « sans coupure » veut dire :
- Les clients qui ont déjà une IP continuent à l’utiliser
- Le DHCP doit à nouveau pouvoir attribuer des adresses aux nouveaux clients
- On évite un renouvellement massif qui provoquerait des conflits ou une tempête réseau
On va donc faire ça en deux temps :
- Récupérer des IP sans forcer tout le monde à renouveler
- Augmenter la capacité proprement si nécessaire
Solution 1 : récupérer des adresses en jouant sur la durée des baux
La cause la plus fréquente en environnement « poste + invités + mobiles », c’est un bail trop long.
Si ton bail est à 8 jours sur un Wi Fi invités, tu es presque certain d’épuiser un /24.
Stratégie
- On baisse la durée du bail, mais pas à 30 minutes direct si on ne maîtrise pas le comportement du réseau.
- On attend le temps que les baux expirent naturellement.
- On évite de casser les baux en cours.
Exemple concret
- Étendue :
[192.168.10.0/24](https://neptunet.fr/intro-dhcp/) - Bail actuel : 8 jours
- Problème : la plage est pleine
Action :
- Passe à 4 h (Wi Fi) ou 1 jour (LAN utilisateurs) selon le contexte
- Laisse tourner
Les anciens baux expireront plus vite lors des prochains renouvellements. Ça ne redonne pas 200 IP en 2 minutes, mais ça évite la brutalité.
Important : modifier la durée du bail n’affecte pas instantanément les baux déjà délivrés. Ça s’applique aux nouveaux baux et aux renouvellements.
Image à insérer
Solution 2 : libérer les baux « zombies » sans couper les bons clients
Là, on veut enlever ce qui ne devrait plus être là.
Méthode douce
- Identifie les baux très anciens ou suspects.
- Vérifie si la MAC apparaît encore sur le réseau en consultant la table ARP du routeur, la table CAM du switch ou les logs Wi-Fi.
- Supprime uniquement les baux dont les appareils ne répondent plus.
Sur Windows DHCP, tu peux filtrer et supprimer des baux. Sur un réseau propre, ça rend souvent 10 à 30 % de la plage.
Le cas des appareils qui changent de MAC
Les mobiles récents font parfois du « MAC randomization ». Résultat : ils consomment une nouvelle IP régulièrement.
Tu peux gérer ce problème de plusieurs façons :
- Adapter la durée de bail (plus courte)
- Segmenter le Wi-Fi invités sur un scope dédié plus large
- Désactiver la randomisation sur SSID entreprise, si ta politique le permet
Solution 3 : étendre la plage DHCP sans changer le plan d'adressage (le plus simple)
Tu es en /24 et tu veux juste plus d'IP, mais tu ne peux pas passer le VLAN en /23 maintenant. Ok. Il y a une astuce propre : ajouter une deuxième étendue sur le même VLAN, en mode split ou en failover, selon ton environnement.
Option A : ajouter une seconde plage dans la même étendue (si possible)
Sur Windows DHCP, tu peux souvent élargir le pool d’adresses si le réseau le permet déjà (donc si le VLAN est déjà plus grand, par exemple /23 côté passerelle). Mais si ton VLAN est réellement en /24, tu ne peux pas inventer des IP hors du sous réseau.
Donc, cette option ne marche que si ton masque réseau est déjà plus large sur la passerelle.
Option B : créer une seconde étendue (superscope) sur le même segment
Le superscope permet de servir plusieurs étendues sur la même interface. Très utile quand tu ne peux pas renuméroter tout de suite.
Tu peux par exemple :
- Garder
192.168.10.0/24(ancienne plage) - Ajouter
192.168.11.0/24(nouvelle plage)
Sur le routeur ou la passerelle, il faudra évidemment router ces deux réseaux sur le VLAN, donc typiquement :
- Soit tu es déjà en /23 et tu n’avais qu’une seule plage DHCP (classique)
- Soit tu ajoutes une IP secondaire (secondary address) sur l’interface VLAN, selon ton équipement
Résultat : les clients existants gardent leur IP. Les nouveaux reçoivent une IP dans le nouveau /24. Pas de coupure.
Image à insérer
Solution 4 : passer de /24 à /23, mais sans douleur (si tu peux)
C’est souvent la vraie correction. Mais elle doit être faite proprement.
Quand c’est faisable sans coupure notable
- Un seul VLAN concerné
- Peu ou pas d’IP statiques
- Équipements réseau compatibles et maîtrisés
- Tu peux modifier la passerelle et les routes sans impact
Plan minimal
- Vérifie que aucun autre VLAN n’utilise le futur bloc (ex : 192.168.10.0/23 couvre 192.168.10.0 et 192.168.11.0)
- Passe l’interface VLAN (SVI) de
255.255.255.0à255.255.254.0 - Ajuste l’étendue DHCP (nouvelle plage)
- Vérifie les ACL, règles firewall, NAT, VPN, tout ce qui dépend du masque
- Laisse les clients renouveler naturellement
Les clients déjà en /24 continueront à communiquer, car le masque plus large côté passerelle permet d’atteindre l’autre moitié. Les seuls clients « gênants » sont ceux qui gardent un masque /24 et qui doivent parler à des IP de l’autre /24. En pratique, ça apparaît si tu commences à distribuer des IP en .11.x alors que certains clients sont encore en .10.x avec masque /24.
Astuce de terrain : pendant une période transitoire, évite de distribuer des IP dans le nouveau /24 tant que tu n’as pas forcé un renouvellement progressif. Ou alors accepte une fenêtre où certains flux inter clients seront bancals (moins grave si tout passe par la passerelle et des services centralisés).
Solution 5 : ajuster les exclusions, réservations, et l’anti gaspillage
C’est bête, mais je l’ai vu souvent : tu as 80 exclusions « historiques » et 40 réservations inutilisées. Et tu te retrouves avec 120 IP « mortes ».
Check-list rapide :
- Exclusions trop larges (anciennes plages statiques)
- Réservations pour des machines qui n’existent plus
- Scope option 003 (gateway) correcte
- DNS correct, sinon tu crées des clients qui « tournent » et renouvellent en boucle
Cas particulier : deux serveurs DHCP, failover, et plage qui se vide mal
Si tu as un cluster DHCP Windows ou un mode failover, vérifie les points suivants :
- Le pourcentage de partage (load balance)
- L'état de synchronisation
- Les conflits de baux (split brain)
- Les adresses en « bad address »
Une plage peut être « pleine » parce que l'autre serveur considère des IP comme mauvaises, ou parce que la réplication est cassée.
Vérifications après correction
Tu as récupéré ou étendu. Maintenant, on valide calmement.
- Un nouveau client obtient une IP en moins de 10 secondes
ipconfig /allmontre la bonne passerelle, DNS, et une durée de bail cohérente- Sur le serveur, le taux d'utilisation redescend
- Pas d'explosion de requêtes DHCP (sinon le bail est trop court)
- Pas de conflits IP signalés
Image à insérer
Petit plan d'action prêt à l'emploi (quand tu es pressé)
- Confirme que le scope est vraiment à 100 % et qu'il ne s'agit pas d'un problème de relais.
- Baisse la durée de bail progressivement.
- Nettoie les baux zombies avec vérification ARP/CAM.
- Si insuffisant, ajoute de la capacité : crée un superscope avec un second /24, ou passe en /23 si possible.
- Surveille pendant 24 h : taux d'utilisation et logs DHCP.
Et pour éviter que ça revienne (le vrai sujet)
Une plage épuisée, ce n'est pas « juste un incident ». C'est souvent un problème de design. Voici les bonnes pratiques par type de réseau :
- Wi-Fi invités : scope dédié, bail court, /23 ou /22 si besoin
- LAN utilisateurs : bail de 1 à 3 jours selon la mobilité
- IoT : idéalement un VLAN dédié avec des réservations propres
- VM lab : scopes séparés ou nettoyage automatique
- Monitoring : alertes dès que tu dépasses 80 % d'utilisation
Si tu es en train de monter ton lab ou de préparer des fiches E4/E5, ce genre de scénario est parfait à documenter. On en publie régulièrement sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), avec des pas à pas et des retours un peu plus concrets que les docs trop propres.
Conclusion
Réparer une plage DHCP épuisée sans coupure, c’est surtout une question de méthode. D’abord récupérer de l’air (baux, nettoyage, exclusions), ensuite augmenter la capacité (superscope, second réseau, ou masque plus large) sans brusquer les clients existants. Et après, tu verrouilles : segmentation, baux adaptés, alertes.
Parce que sinon… tu sais comment ça finit. Même heure, même alerte, la semaine prochaine.
Questions fréquemment posées
Quels sont les symptômes typiques d'une plage DHCP épuisée ?
Les symptômes incluent des clients obtenant une IP en 169.254.x.x (APIPA) ou restant bloqués sur "identification...", des commandes comme ipconfig /renew ou dhclient échouant, des alertes sur le serveur DHCP indiquant une utilisation à 100%, des baux anciens toujours actifs pour des machines inexistantes, et la présence de nombreux appareils temporaires comme téléphones, invités, VM, BYOD ou IoT.
Pourquoi faut-il éviter de redémarrer le service DHCP ou de changer le masque sans plan ?
Ces actions peuvent provoquer une coupure réseau importante et instable. Redémarrer le service DHCP peut interrompre l'attribution d'adresses en cours, et changer le masque sans vérifier les routes ou équipements statiques peut causer des conflits d'adressage et des interruptions de service.
Comment diagnostiquer rapidement une pénurie d'adresses IP sur un serveur DHCP Windows ?
Il faut accéder à la console DHCP, sélectionner l'étendue concernée, consulter la liste des baux (Address Leases), trier par expiration pour repérer les baux anciens ou suspects, vérifier le pourcentage d'adresses utilisées ainsi que les plages d'exclusions afin d'identifier si la pénurie est réelle ou due à des baux zombies.
Quelles sont les causes fréquentes d'épuisement de plage DHCP dans un environnement mixte postes et mobiles ?
Une cause fréquente est une durée de bail trop longue, notamment sur un réseau Wi-Fi invité où un bail de 8 jours peut rapidement saturer un /24. De plus, la présence de nombreux appareils temporaires comme téléphones IP, invités ou VM augmente la consommation d'adresses.
Comment récupérer des adresses IP sans interrompre les clients existants ?
On peut réduire la durée des baux DHCP pour libérer rapidement des adresses non utilisées sans forcer les clients actuels à renouveler leur adresse immédiatement. Cette méthode permet de récupérer des adresses disponibles tout en maintenant la continuité du service.
Quelle stratégie adopter pour étendre proprement une plage DHCP sans causer de coupure réseau ?
Il faut procéder en deux temps : d'abord récupérer des adresses en optimisant la gestion des baux (réduction de leur durée), puis augmenter la capacité de la plage DHCP proprement en ajoutant par exemple un nouveau sous-réseau ou en ajustant l'étendue existante avec un plan clair et vérifications préalables pour éviter conflits et interruptions.
0 Commentaires