VLAN : 7 pièges qui cassent l’inter-VLAN

Tu configures des VLAN, tout est propre, les ports sont taggés comme il faut… et pourtant, impossible de faire parler deux réseaux entre eux. Ou alors ça marche un peu, puis plus rien. Le genre de truc qui te fait douter de ta vie, puis tu te rends compte que c’était juste… un détail.

Dans les labs que je vois passer (et ceux qu’on fait au BTS SIO2 SISR Tech Lab, sur https://sio1blog.blogspot.com/), l’inter-VLAN plante presque toujours pour les mêmes raisons. Pas parce que « le VLAN c’est dur », mais parce que c’est rempli de petites cases à cocher, sur plusieurs équipements, parfois sur plusieurs couches. Et une seule case oubliée suffit.

On va faire simple : 7 pièges très fréquents, comment les reconnaître, et quoi vérifier. Avec des exemples Cisco-like, mais les idées sont valables partout.

1. Mélanger access, trunk… et croire que « ça va passer »

Le classique. Un port côté switch en access VLAN 10, et de l’autre côté tu penses être en trunk. Ou l’inverse. Et tu te dis « pourtant j’ai mis le VLAN ». Ce genre de mélange entre access et trunk peut causer beaucoup de confusion.

Symptômes

• Les machines dans le même VLAN communiquent, mais pas entre VLAN.
• Ou pire : rien ne marche sur ce lien.
• show interfaces trunk ne montre pas ton port.
• Des MAC apparaissent dans « le mauvais VLAN ».

Vérifications rapides

Sur le switch, vérifie le mode du port :

bash show interfaces gi0/1 switchport show interfaces trunk

Ce que tu veux en général pour un lien vers un routeur (router-on-a-stick) ou vers un autre switch :

bash interface gi0/1 switchport mode trunk switchport trunk allowed vlan 10,20,30 switchport trunk native vlan 999

Et si c’est un port vers un PC :

bash interface gi0/10 switchport mode access switchport access vlan 10 spanning-tree portfast

Petit détail qui pique : certains équipements négocient le trunk (DTP), d’autres pas. Donc « des deux côtés trunk » reste la règle la plus sûre.

2. Oublier le VLAN dans la liste « allowed » du trunk

Tu as bien mis le trunk. Tout a l’air OK. Mais… le VLAN 20 ne passe jamais. Parce que tu as filtré sans t’en rendre compte.

Symptômes

• VLAN 10 OK, VLAN 20 KO.
• show interfaces trunk montre une liste « allowed » sans le VLAN attendu.
• Les pings marchent dans un sens (selon où tu testes), puis tu changes de poste et c’est mort.

Vérification

bash show interfaces trunk

Tu dois voir ton VLAN dans « Vlans allowed on trunk » et dans « Vlans in spanning tree forwarding state ».

Correction :

bash interface gi0/1 switchport trunk allowed vlan add 20

Oui, c’est bête. Mais en prod, c’est un vrai piège quand quelqu’un a « sécurisé » le trunk en limitant les VLAN autorisés, puis tu ajoutes un nouveau VLAN et tu oublies de l’autoriser.

3. Native VLAN incohérente : le bug silencieux

La native VLAN sur un trunk, c’est le VLAN qui transporte le trafic non taggé. Si tu as un mismatch, tu peux te retrouver avec des comportements chelous, parfois intermittents. Et parfois tu ne vois rien, sauf que « ça marche pas ».

Symptômes

• Messages du type « Native VLAN mismatch » (selon modèles).
• Certains protocoles passent, d’autres pas.
• Tu récupères du trafic de management dans un VLAN inattendu.

Bonne pratique

Choisir une native VLAN « poubelle » (ex. 999) et ne jamais y mettre de machines.

bash interface gi0/1 switchport trunk native vlan 999

Puis vérifier que c’est identique de l’autre côté du trunk.

Et si tu fais de la sécu : tu peux aussi forcer le tag sur la native VLAN (selon équipement), mais déjà… cohérence et VLAN inutilisé, ça évite beaucoup de drames.

4. Inter-VLAN sans passerelle : la gateway est fausse, absente, ou mal placée

L'Inter-VLAN = routage donc chaque machine doit avoir une passerelle par défaut dans son VLAN, et cette passerelle doit exister, et être joignable.

Ça semble évident, mais en TP ça arrive tout le temps : IP correcte, masque correct, VLAN correct… mais la gateway pointe sur une IP qui n’existe pas. Ou pointe sur l’IP d’un autre VLAN. Ou le routeur n’a pas l’interface virtuelle attendue.

Symptômes

• Ping dans le même VLAN OK.
• Ping vers la gateway KO, ou OK mais inter-VLAN KO.
• Traceroute qui s’arrête au premier saut.

En ce qui concerne les bridging and VLANs, il est crucial de comprendre comment ces concepts interagissent pour éviter des problèmes similaires à ceux mentionnés ci-dessus.

Check côté client

• IP : 192.168.10.50/24
• Gateway : 192.168.10.254 (par exemple)

Check côté L3 (routeur ou switch L3)

Router-on-a-stick (sous-interfaces) :

bash interface g0/0.10 encapsulation dot1Q 10 ip address 192.168.10.254 255.255.255.0

interface g0/0.20 encapsulation dot1Q 20 ip address 192.168.20.254 255.255.255.0

Switch L3 (SVI) :

bash interface vlan 10 ip address 192.168.10.254 255.255.255.0 no shutdown

interface vlan 20 ip address 192.168.20.254 255.255.255.0 no shutdown

Et là on arrive au piège suivant, qui tue tout.

5. Switch L3 : oublier ip routing (ou laisser les SVI down)

Sur un switch de niveau 3, tu peux créer des interfaces VLAN (SVI) et te dire « ok, c’est bon, ça route ». Sauf que non. Par défaut, certains switches ne routent pas tant que tu n’as pas activé le routage IP.

Et même si tu l’as activé, tes SVI peuvent être down/down si le VLAN n’existe pas, ou si aucun port n’est actif dans ce VLAN. C’est un autre piège bien vicieux.

Symptômes

• Les SVI ont une IP, mais l’inter-VLAN ne marche pas.
• show ip route est vide ou ne montre que des routes connectées partielles.
• show interfaces vlan 10 indique « administratively up, line protocol down ».

Corrections

Activer le routage :

bash conf t ip routing

Vérifier l’état des SVI :

bash show ip interface brief show interfaces vlan 10

Créer le VLAN (oui, parfois on oublie) :

bash vlan 10 name USERS

Et s’assurer qu’au moins un port dans le VLAN est up :

bash interface gi0/10 switchport mode access switchport access vlan 10 no shutdown

Sinon ton SVI reste down et tu peux ping la lune tant que tu veux.

6. ACL ou firewall qui bloque : « ça route », mais ça drop

Celui-là fait perdre du temps parce que tu vois des routes, tu ping la gateway, tu vois les ARP… et pourtant le ping inter-VLAN ne passe pas. La raison : une ACL sur une SVI, une policy sur un firewall, un filtre implicite, ou juste une règle « deny any » posée trop tôt.

Symptômes

• Ping vers la gateway OK, mais ping vers un autre VLAN KO.
• Traceroute qui s’arrête au switch L3.
• Sur un firewall : session non créée, ou refusée.
• En Cisco : compteur d’ACL qui augmente sur un deny.

Vérifications

Sur switch/routeur :

bash show access-lists show run interface vlan 10 show run interface vlan 20

Tu cherches un truc du genre :

bash interface vlan 10 ip access-group VLAN10-IN in

Ensuite tu lis l’ACL. Et tu vérifies l’ordre. Parce que oui, l’ordre des lignes… ça compte. Beaucoup.

Exemple minimal pour autoriser inter-VLAN entre 10 et 20, puis bloquer le reste :

bash ip access-list extended VLAN10-IN permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 deny ip any any log

En lab, c’est bien pour comprendre. En vrai, tu feras plus fin, et tu feras attention aux flux retour, aux services, au DNS, à l’ICMP si tu veux du diagnostic, etc.

7. Le problème n’est pas le VLAN : c’est le DNS, la route retour, ou l’asymétrie

Un dernier piège, plus sournois. Tu crois que l’inter-VLAN est cassé parce que « je n’accède pas au serveur ». Mais en fait :

• le ping IP marche, mais le nom ne résout pas (DNS).
• l’aller passe, le retour non (route retour manquante).
• tu as deux routeurs, et le trafic prend un chemin différent au retour (asymétrie), et un firewall stateful bloque.

Symptômes

• ping 192.168.20.10 OK, mais ping serveur.fqdn.local KO.
• Accès web KO, mais ping OK.
• Depuis VLAN 10 vers VLAN 20 OK, mais depuis VLAN 20 vers VLAN 10 KO.
• Sur firewall : paquets SYN sortent, SYN-ACK ne revient jamais, ou revient par un autre chemin.

Check-list rapide

DNS :

• Sur le client : quel serveur DNS est configuré ?
• Est-ce que ce DNS est joignable inter-VLAN ?
• Est-ce qu’il a les bonnes zones ?

Routes :

• Sur chaque réseau, qui est la passerelle ?
• Sur les équipements L3, est-ce que toutes les routes existent ?
• Si tu as un routeur en amont, a-t-il une route vers tes VLAN, et surtout une route de retour ?

Asymétrie :

• Un seul point de routage si possible en lab.
• Si firewall, s’assurer que les deux sens passent par lui.

Commandes utiles : bash traceroute 192.168.20.10 nslookup serveur.fqdn.local show ip route show arp

Et parfois, juste parfois, tu as un MTU ou un PMTUD cassé. Mais pour un article « pièges inter-VLAN », on va rester focus.

---

Mini méthodo : comment diagnostiquer sans partir dans tous les sens

Quand ça ne marche pas, fais simple, toujours dans le même ordre. Sinon tu changes trois trucs à la fois et tu ne sais plus ce qui a corrigé.

1. Même VLAN : ping entre deux machines du même VLAN.
2. Gateway : ping la passerelle de ce VLAN.
3. Inter-VLAN IP : ping une IP de l’autre VLAN (pas un nom).
4. Trunk : vérifier VLAN allowed, native VLAN, état du trunk.
5. L3 : vérifier SVI up, ip routing, routes.
6. Sécurité : ACL, firewall, policies.
7. Services : DNS, applicatif, ports, NAT éventuel.

Si tu veux, on peut en faire un TP complet sur le blog, genre « inter-VLAN qui ne marche pas : check-list + commandes ». D’ailleurs, si tu révises E4 ou E5, garde BTS SIO2 SISR Tech Lab dans tes favoris, on publie régulièrement des labs réseau et des retours terrain : https://sio1blog.blogspot.com/

---

Conclusion : l’inter-VLAN casse rarement « au hasard »

Ce qui est frustrant avec l’inter-VLAN, c’est que tu as l’impression que c’est fragile. Mais en vrai, c’est très logique. Juste… distribué. Un bout sur le switch, un bout sur le routeur, un bout sur le client, un bout sur le firewall.

Retient ça : si un VLAN ne traverse pas le trunk, tu auras beau faire du routage, ça ne passera jamais. Et si le routage est bon mais que les règles bloquent, tu verras des symptômes qui ressemblent à une panne réseau alors que c’est une panne de politique.

Et oui, on s’est tous fait avoir par un VLAN non autorisé ou une SVI down. Plus d’une fois.

Questions fréquemment posées

Pourquoi mes VLANs ne communiquent-ils pas entre eux malgré une configuration apparemment correcte ?

Même si les ports sont bien taggés et configurés, l'inter-VLAN peut échouer à cause de petits détails comme un mélange entre ports en mode access et trunk, un VLAN non autorisé sur le trunk, ou une incohérence dans la native VLAN. Ces petites erreurs courantes empêchent la communication entre réseaux.

Quelle est la différence entre un port en mode access et un port en mode trunk, et pourquoi est-ce important ?

Un port en mode access transporte un seul VLAN non taggé, généralement vers un PC, tandis qu'un port en mode trunk transporte plusieurs VLANs tagués entre équipements réseau. Mélanger ces modes incorrectement provoque des problèmes de communication inter-VLAN.

Comment vérifier que le VLAN est bien autorisé sur un lien trunk ?

Il faut utiliser la commande 'show interfaces trunk' pour voir la liste des VLANs autorisés. Si un VLAN manque dans 'Vlans allowed on trunk', il ne passera pas. Pour corriger, on ajoute le VLAN avec 'switchport trunk allowed vlan add X' sur le port concerné.

Qu'est-ce que la native VLAN et quels problèmes peuvent survenir si elle est mal configurée ?

La native VLAN transporte le trafic non taggé sur un trunk. Si elle est différente d'un côté à l'autre (mismatch), cela peut causer des comportements intermittents, du trafic qui passe mal ou des messages d'erreur. Il est conseillé d'utiliser une native VLAN dédiée inutilisée (ex : 999) pour éviter ces soucis.

Pourquoi est-il important d'avoir une passerelle (gateway) correctement configurée pour l'inter-VLAN ?

L'inter-VLAN nécessite une passerelle pour router le trafic entre différents VLANs. Si la gateway est absente, fausse ou mal placée, les machines ne pourront pas communiquer hors de leur VLAN local, rendant l'interconnexion impossible.

Quels sont les symptômes courants indiquant un problème d'inter-VLAN ?

Parmi les signes fréquents : machines dans un même VLAN communiquent mais pas entre VLANs ; aucun trafic ne passe sur certains liens ; affichage incorrect des MAC dans des VLANs inattendus ; messages d'erreur liés à la native VLAN ; pings fonctionnant partiellement selon le poste testé.