Comment dépanner un réseau VLAN VLAN VLAN qui ne route plus correctement ?

Le routage inter-VLAN repose sur un principe simple : chaque VLAN constitue un domaine de broadcast isolé, et seule une interface de couche 3 (routeur ou switch multicouche) permet aux trames de passer d’un VLAN à un autre. Quand un réseau VLAN ne route plus correctement, la panne provient presque toujours d’une rupture dans cette chaîne logique, pas d’une défaillance matérielle. Ce guide parcourt les causes les plus fréquentes, dans l’ordre où il faut les vérifier.

Vérifier la configuration des ports trunk sur le switch

Le port trunk est le premier endroit à inspecter. Un trunk mal configuré silencieusement bloque certains VLAN sans générer d’erreur visible dans les journaux.

Sur un switch Cisco, la commande show interfaces trunk affiche trois colonnes critiques : les VLAN autorisés sur le trunk, les VLAN actifs dans le domaine de spanning tree, et les VLAN qui acheminent effectivement du trafic. Un VLAN peut figurer dans la liste des autorisés sans apparaître dans la colonne de transfert actif.

• Vérifier que le VLAN est bien déclaré dans la liste des VLAN autorisés sur le trunk (switchport trunk allowed vlan add <id> si absent).
• Confirmer que le VLAN existe dans la base de données du switch (show vlan brief). Un VLAN référencé sur un trunk mais absent de la base locale ne transmet rien.
• Contrôler le mode du port : un port en mode access au lieu de trunk interrompt le passage des tags 802.1Q sans message d’erreur explicite.

Le VLAN natif mérite une attention particulière. Si les deux extrémités d’un trunk n’ont pas le même VLAN natif configuré, le trafic non taggé arrive dans le mauvais VLAN de l’autre côté. Cisco génère une alerte CDP dans ce cas, mais tous les équipements ne le font pas.

Diagnostiquer les interfaces SVI et les routes inter-VLAN

Une fois le trunk validé, l’attention se déplace vers les interfaces VLAN (SVI) du switch de couche 3 ou du routeur. Une SVI peut être configurée avec une adresse IP correcte et rester inactive.

La commande show interfaces vlan <id> indique l’état de la ligne et du protocole. Si l’état affiche « up/down », l’interface est administrativement active mais aucun port du VLAN n’est en état « up » sur ce switch. Si l’état est « administratively down », la SVI a été désactivée manuellement (no shutdown résout ce cas).

Après avoir confirmé que les SVI sont actives, vérifier la table de routage avec show ip route. Chaque réseau associé à un VLAN doit y figurer comme route connectée. L’absence d’une entrée révèle soit une SVI inactive, soit un adressage incorrect.

Un point moins évident : une route visible ne garantit pas que le trafic passe. Une liste de contrôle d’accès (ACL) appliquée sur l’interface VLAN ou une règle de pare-feu en amont peut bloquer les flux malgré un routage correct. Tester avec un ping depuis l’équipement de routage lui-même (source d’interface forcée) aide à distinguer un problème de routage d’un problème de filtrage.

Router-on-a-stick : vérifier les sous-interfaces Ethernet

Dans une architecture router-on-a-stick, le routeur porte une sous-interface par VLAN sur un unique port physique. Ce modèle est fréquent dans les petits déploiements et concentre plusieurs points de défaillance sur une seule configuration.

Chaque sous-interface doit avoir trois éléments cohérents : l’encapsulation 802.1Q avec l’identifiant VLAN correct (encapsulation dot1Q <id>), une adresse IP dans le réseau du VLAN, et un état « up/up ». Un décalage entre l’ID VLAN déclaré sur la sous-interface et l’ID réellement utilisé sur le trunk est une erreur fréquente lors des modifications de configuration.

Vérifier aussi que le port du switch connecté au routeur est bien configuré en mode trunk et autorise tous les VLAN concernés. Un port laissé en mode access ne transmet qu’un seul VLAN et brise immédiatement le routage pour tous les autres.

Problèmes de routage asymétrique et de retour de trafic

Un symptôme trompeur : la connectivité fonctionne dans un sens mais pas dans l’autre. Ce comportement indique un routage asymétrique ou une route de retour absente.

Quand un hôte du VLAN 10 envoie un paquet vers le VLAN 20, le routeur l’achemine correctement. Mais si l’hôte du VLAN 20 n’a pas de route vers le VLAN 10 dans sa passerelle par défaut, ou si sa passerelle est différente de celle qui gère le retour, les réponses ne reviennent pas. Le ping échoue, mais la cause n’est pas le routage aller.

Vérifier séparément le trajet aller et le trajet retour en utilisant des traceroutes depuis les deux extrémités. Les passerelles par défaut des hôtes sont souvent oubliées lors de la reconfiguration d’un plan d’adressage VLAN.

DHCP inter-VLAN : quand les hôtes n’obtiennent pas d’adresse

L’absence d’adresse IP sur les hôtes masque parfois un problème de routage sous une apparence de panne DHCP. Sans adresse, les hôtes ne peuvent pas tester la connectivité et l’erreur semble remonter à la couche réseau.

Si le serveur DHCP est dans un VLAN différent de celui des clients, les requêtes broadcast DHCP ne traversent pas les frontières de VLAN sans un relais DHCP (ip helper-address) configuré sur la SVI du VLAN client. L’adresse helper pointe vers l’IP du serveur DHCP.

Trois vérifications rapides dans ce scénario :

• La commande ip helper-address est présente sur la bonne SVI et pointe vers l’adresse IP correcte du serveur DHCP.
• Le serveur DHCP dispose d’un pool pour le réseau du VLAN concerné et que ce pool n’est pas épuisé.
• Le trafic UDP sur le port 67 n’est pas bloqué par une ACL entre la SVI et le serveur DHCP.

VRF et contexte de routage : une cause avancée à ne pas négliger

Dans les réseaux segmentés par VRF (Virtual Routing and Forwarding), une SVI peut avoir une adresse IP valide et un état « up/up » tout en étant rattachée au mauvais contexte de routage. Le trafic arrive sur l’interface mais disparaît dans une table de routage qui ne contient pas la destination.

Vérifier l’association VRF d’une SVI avec show interfaces vlan <id> et croiser avec la table de routage du bon VRF (show ip route vrf <nom>). Le relais DHCP doit aussi pointer vers le bon VRF si le serveur DHCP est accessible depuis un contexte différent.

Ce cas se présente surtout après une migration ou une restructuration du plan de segmentation réseau, quand des interfaces sont réaffectées sans que toutes leurs dépendances soient mises à jour.

La démarche de dépannage d’un réseau VLAN suit donc un ordre logique : trunk et base de données VLAN en premier, SVI et table de routage ensuite, filtrage et asymétrie si le routage semble correct mais le trafic ne passe toujours pas. Chaque couche peut masquer la suivante, ce qui justifie de valider chaque étape avant de passer à la suivante plutôt que de modifier plusieurs paramètres simultanément.