Cet article explore un problème réseau lié à une mauvaise configuration d’adresses IP dans un VLAN dédié au Wi-Fi. Nous détaillons les impacts de cette situation sur les bornes Wi-Fi, les symptômes observés, les diagnostics réalisés, et les solutions mises en œuvre pour restaurer la stabilité du réseau.
Table of Contents
Résumé du problème
Dans le VLAN Wi-Fi (VLAN 300), deux routeurs étaient configurés pour gérer les communications. Une mauvaise configuration d’adresses IP a provoqué un conflit, affectant principalement les bornes Wi-Fi :
- Les bornes Wi-Fi diffusaient un SSID temporaire « Recover.Me » et ne pouvaient plus communiquer avec le contrôleur Wi-Fi.
- Les bornes ne recevaient pas d’adresse IP en raison d’échecs dans le relais DHCP.
- Le routage était instable dans le VLAN Wi-Fi.
La source du problème était l’utilisation de la même adresse IP (192.168.10.1) sur les deux routeurs :
- Configurée comme secondaire sur le premier routeur (RT1).
- Configurée comme principale sur le second routeur (RT2).
Contexte technique
Voici les configurations initiales des deux routeurs :
Configuration de RT1 (Routeur principal) :
interface Vlan300
description Gestion du Wi-Fi
ip address 192.168.10.1 255.255.255.224 secondary
ip address 192.168.20.1 255.255.255.224
ip helper-address 10.0.0.1
Configuration de RT2 (Routeur secondaire) :
interface Vlan300
description Gestion du Wi-Fi
ip address 192.168.10.1 255.255.255.224
ip helper-address 10.0.0.1
La présence de 192.168.10.1 sur les deux routeurs a généré des conflits ARP et des dysfonctionnements dans le relais DHCP.
Symptômes observés
Les problèmes étaient limités au VLAN Wi-Fi (SVI associé au VLAN 300) et impactaient uniquement les bornes Wi-Fi et les clients qui en dépendaient.
Symptôme 1 : Bornes Wi-Fi en mode « Recover.Me »
- Les bornes Wi-Fi perdaient leur connectivité avec le contrôleur central et diffusaient un SSID temporaire nommé « Recover.Me-XXXX ».
- Cela reflétait une incapacité à rejoindre le réseau.
Symptôme 2 : Échecs DHCP
- Les bornes Wi-Fi ne recevaient pas d’adresse IP via DHCP, rendant impossible leur intégration au réseau.
- Le conflit d’adresses IP et les réponses contradictoires des deux routeurs empêchaient un traitement correct des requêtes DHCP.
Symptôme 3 : Instabilité ARP
- Les requêtes ARP pour 192.168.10.1 renvoyaient deux adresses MAC différentes, provenant des deux routeurs.
- Cela causait une instabilité dans la communication entre les bornes et leur passerelle.
Symptôme 4 : Logs DHCP incohérents
Les logs des relais DHCP montraient des requêtes et réponses inconsistantes, indiquant un traitement fragmenté des demandes des bornes.
Diagnostic du problème
Pour identifier la source du problème, les étapes suivantes ont été suivies :
Étape 1 : Vérification des adresses IP configurées
Commandes utilisées :
show ip interface brief
Résultat : 192.168.10.1 était configurée sur les deux routeurs.
Étape 2 : Analyse des conflits ARP
Commandes utilisées :
show ip arp | include 192.168.10.1
Résultat : Deux adresses MAC répondaient pour 192.168.10.1, confirmant un conflit ARP.
Étape 3 : Observation des logs DHCP
Les logs DHCP ont été analysés avec les commandes suivantes :
debug ip dhcp server packet
debug ip dhcp server eventsRésultats :
debug ip dhcp server packetmontrait que les requêtes des bornes Wi-Fi étaient transmises mais souvent perdues ou mal redirigées.debug ip dhcp server eventsrévélait des anomalies dans le traitement des événements DHCP, avec des réponses venant parfois de RT1 et d’autres fois de RT2, causant des échecs DHCP.
Résolution du problème
Étape 1 : Suppression de l’adresse secondaire sur RT1
L’adresse IP secondaire configurée sur RT1 a été supprimée avec la commande suivante :
interface Vlan300
no ip address 192.168.10.1 255.255.255.224 secondaryÉtape 2 : Vérification des configurations
Après correction, les adresses IP des interfaces ont été revérifiées :
show ip interface briefCela a confirmé que seule RT2 gérait l’adresse 192.168.10.1.
Étape 3 : Tests ARP
Les requêtes ARP ont été surveillées pour confirmer qu’une seule adresse MAC répondait pour 192.168.10.1 :
show ip arp | include 192.168.10.1Étape 4 : Validation du relais DHCP
Les logs DHCP ont été surveillés après correction avec la commande :
debug ip dhcp server eventsRésultat : Les requêtes DHCP des bornes étaient désormais traitées correctement par RT2.
Résultats après correction
- Les bornes Wi-Fi ont rejoint le contrôleur Wi-Fi :
- Elles ont cessé de diffuser le SSID « Recover.Me ».
- La connectivité a été restaurée.
- Les requêtes DHCP étaient traitées correctement :
- Les bornes recevaient des adresses IP cohérentes.
- Stabilité ARP rétablie :
- Une seule adresse MAC répondait pour 192.168.10.1, éliminant tout conflit.
- Routage stable :
- Les bornes pouvaient atteindre la passerelle sans interruptions.
Bonnes pratiques pour éviter ce problème
1. Ne pas utiliser d’adresses secondaires sans justification claire
- Les adresses secondaires peuvent provoquer des conflits lorsqu’elles se chevauchent avec des adresses principales sur d’autres équipements.
- Utilisez des sous-réseaux distincts ou des VLAN supplémentaires.
2. Documentation et coordination des configurations
- Chaque routeur doit avoir des rôles bien définis avec une documentation claire des adresses IP utilisées.
3. Surveillance proactive
- Configurez des outils SNMP pour surveiller les conflits d’adresses IP ou les anomalies ARP.
- Implémentez des scripts automatisés pour détecter les adresses dupliquées.
4. Tests approfondis avant le déploiement
- Validez les configurations réseau dans un environnement de test (comme GNS3) avant de les appliquer en production.
Conclusion
Ce cas illustre les conséquences d’un conflit d’adresses IP dans un VLAN Wi-Fi et l’impact direct sur les équipements réseau comme les bornes Wi-Fi. La suppression de l’adresse IP secondaire et la clarification des rôles des routeurs ont permis de restaurer la connectivité et la stabilité du réseau.
Pour éviter de tels problèmes, appliquez les bonnes pratiques mentionnées et surveillez régulièrement votre infrastructure réseau.
