Saturation DHCP et BYOD : arbitrer en support niveau 2

1. Capacité du pool Un /24 offre 254 adresses utilisables. On en retire les équipements à adresse fixe : 12 imprimantes, la passerelle et le serveur DHCP, soit 14 adresses indisponibles pour le dynamique. Le pool distribuable tombe à environ 240 adresses.

2. Demande potentielle 150 postes fixes + 70 portables + 55 smartphones = 275 clients susceptibles de demander un bail. 275 > 240 : le pool est structurellement sous-dimensionné, l'écart est de 35 adresses, ce qui correspond à l'ordre de grandeur de la trentaine d'utilisateurs en échec.

3. Effet du bail de 8 jours Un bail n'est rendu qu'à expiration ou sur libération explicite (ipconfig /release). Un portable éteint vendredi, un smartphone d'un visiteur ou un poste déplacé continue de consommer son adresse pendant 8 jours. Sur une semaine, les baux actifs s'accumulent sans être recyclés : le serveur distribue des adresses à des machines absentes.

4. Pourquoi le lundi Le lundi matin, la reconnexion est simultanée : portables rallumés, smartphones de retour au bureau, postes fixes qui renouvellent. La demande instantanée est maximale alors que les baux orphelins du week-end ne sont pas encore expirés. En semaine, les arrivées sont étalées et les machines déjà titulaires d'un bail ne redemandent rien.

5. Pourquoi le symptôme est un 169.254.x.x APIPA signifie que le client n'a reçu aucune réponse DHCP : le serveur a refusé (pool vide) ou n'a pas répondu. C'est bien une preuve d'épuisement, pas un problème de câblage. Le renouvellement manuel du technicien a libéré des baux de machines éteintes, ce qui a masqué la cause.

A. Correction immédiate (48 h, coût 0 €)

• Réduire la durée du bail de 8 jours à 8 heures sur le scope : les baux des machines absentes sont recyclés dans la journée. Effet secondaire à assumer : trafic DHCP plus dense, sans impact sur un réseau local commuté.
• Purger les baux des postes éteints et ajouter des exclusions explicites pour les 12 imprimantes et les équipements réseau.
• Indicateur : Get-DhcpServerv4ScopeStatistics, taux d'utilisation du pool mesuré chaque matin, cible < 80 %.

B. Correction durable (avant le 15 novembre, coût 0 à 400 €)

• Segmenter : VLAN postes / VLAN Wi-Fi interne / VLAN invités, avec un scope DHCP par VLAN. Les 55 smartphones personnels sortent du pool des postes ; c'est la mesure qui traite la cause racine.
• Étendre le plan d'adressage en /23 (10.20.0.0/23, 510 adresses) si la segmentation ne suffit pas : coût nul en matériel, mais modification du masque sur tous les équipements à adresse fixe, donc fenêtre de changement hors heures ouvrées et plan de retour arrière.
• Mettre en place un DHCP failover ou une seconde étendue : aujourd'hui le serveur est un point unique de défaillance.
• Indicateur : zéro ticket « APIPA » sur deux semaines consécutives ; test de coupure du serveur DHCP en recette.

C. Prévention (coût < 400 € : onduleur réseau ou portail captif simple)

• Supervision avec alerte à 80 % d'occupation du pool, remontée dans l'outil de supervision existant.
• Portail captif ou clé Wi-Fi tournante pour les invités, avec bail court dédié.
• Documenter le plan d'adressage et le procédure de renouvellement dans la base de connaissances GLPI.
• Indicateur : fiche de plan d'adressage versionnée, alerte testée en provoquant un seuil.

Le budget est respecté : la segmentation et le /23 sont des changements de configuration, pas des achats. Le vrai coût est le temps d'ingénierie et la fenêtre de changement.

Non, le traitement est incomplet. Le technicien a appliqué un contournement (renouvellement des baux) qui rétablit le service sans identifier la cause, puis a clôturé les tickets. Trois conséquences :

• le ticket est clos alors que l'incident est récurrent et prévisible (trois lundis de suite) ;
• aucun ticket parent ne regroupe les signalements, donc l'ampleur réelle est invisible dans les statistiques ;
• aucune escalade vers le niveau 2 ni ouverture d'un problème : la base de connaissances ne s'enrichit pas, le même incident reviendra.

Qualification

• Impact : majeur - une trentaine d'utilisateurs simultanément bloqués, sur deux sites, en début de semaine, avec perte de travail.
• Urgence : moyenne à haute - le service est dégradé, pas arrêté, mais la récurrence hebdomadaire impose une action rapide.
• Priorité : P2 (haute). Ce n'est pas une P1, le service reste partiellement disponible et il n'y a pas d'arrêt total de production.

Place dans le processus

1. Gestion des incidents : rétablir le service au plus vite, ce qui a été fait, mais en traçant correctement (ticket parent, catégorie, symptôme, workaround documenté).
2. Gestion des problèmes : ouvrir une fiche problème rattachée, analyser la cause racine (dimensionnement du pool DHCP, bail inadapté, absence de segmentation), proposer les changements.
3. Gestion des changements : la réduction du bail et la création de VLAN passent par une demande de changement avec fenêtre, tests et retour arrière.
4. Communication : prévenir les utilisateurs avant l'intervention, pas seulement après.

Un incident clos sans cause racine documentée est une dette qui se paie au ticket suivant.