Réseau : VLAN mal configurés — L’erreur qui crée des pannes fantômes

L’erreur unique : balisage incohérent sur un chemin

Voici l’erreur qui crée des pannes fantômes : un VLAN est tagué d’un côté d’un lien et traité comme non tagué de l’autre.
Ou le VLAN natif diffère entre les extrémités d’un trunk. Ou la liste des VLAN autorisés ne correspond pas le long de la chaîne de trunks.
Différentes variantes, même maladie : vous n’avez pas une vérité unique pour « dans quel VLAN est cette trame ? » de bout en bout.

En pratique, cela se manifeste ainsi :

• Un serveur envoie des trames taguées sur eth0.120, mais le port du switch est configuré en port d’accès dans le VLAN 120 (attend des trames non taguées).
• Un trunk a le VLAN natif 1 d’un côté et le VLAN natif 120 de l’autre. Les trames non taguées deviennent VLAN 1 d’un côté, VLAN 120 de l’autre.
• Un changement « utile » réduit les VLAN autorisés sur un trunk d’agrégation, supprimant accidentellement un VLAN encore utilisé par un hôte legacy.
• Un portgroup de vSwitch d’hyperviseur attend le VLAN 120, mais la carte NIC physique en amont est réglée sur « untagged » et compte sur le switch pour taguer.

La mauvaise nouvelle : cela ne coupe pas toujours tout. Les cas vraiment dangereux laissent fuiter suffisamment de connectivité pour garder les systèmes à moitié vivants.
L’ARP et l’apprentissage des MAC peuvent osciller. Certains flux hachent d’un côté, d’autres d’un autre. Les tentatives masquent le problème jusqu’à ce que vous atteigniez un pic de trafic et que le système admette enfin qu’il est blessé.

La leçon opérationnelle est franche : les VLAN ne sont pas « configurés et oubliés ». Ils sont un contrat de bout en bout. Si vous ne pouvez pas décrire le contrat à chaque saut,
vous n’avez pas un VLAN — vous avez une rumeur.

Pourquoi cela crée des pannes « fantômes » (et pas des pannes nettes)

1) Confusion du domaine de broadcast : ARP et ND se comportent comme des narrateurs peu fiables

Lorsque le balisage est incohérent, les requêtes ARP peuvent sortir dans un VLAN tandis que les réponses ARP reviennent dans un autre — ou arrivent sur un port différent à cause du churn de la table MAC.
L’hôte met en cache les correspondances « IP → MAC ». Le switch met en cache « MAC → port ». Vous avez maintenant deux caches indépendants qui essaient de modéliser une réalité que vous venez de briser.

Vous verrez des symptômes comme :

• Entrées ARP basculant entre deux MAC pour la même IP (ou le même MAC rebondissant entre ports).
• Anomalies de Neighbor Discovery en IPv6 : reachable, stale, reachable, stale, sans raison évidente.
• La connectivité fonctionne une minute après un rafraîchissement ARP, puis se dégrade jusqu’au prochain rafraîchissement.

2) « Presque fonctionne » est pire que « en panne »

Les pannes nettes vous alertent, poussent à l’action et se terminent rapidement. Les pannes fantômes s’étirent sur des jours parce que :

• Les retransmissions TCP cachent la perte de paquets jusqu’à ce que la latence de queue devienne visible pour le business.
• Les checks de santé sondent un chemin heureux tandis que le trafic réel frappe le chemin cassé.
• Les load balancers gardent une jambe active et drainent silencieusement l’autre, donc vous ne remarquez qu’en charge.
• La surveillance agrège le motif : 0,5% de perte ressemble à du bruit jusqu’à ce que ce soit votre base de données.

3) Le balisage incohérent crée des chemins asymétriques

Un fantôme classique : le trafic sortant quitte le serveur correctement, mais le trafic de retour atterrit dans le mauvais VLAN ou le mauvais port parce que le réseau a appris le MAC ailleurs.
Ou l’inverse. Vous pouvez pinguer dans un sens, échouer dans l’autre, et passer des heures à blâmer les pare-feux. Les logs du pare-feu paraîtront innocents parce que les paquets ne sont jamais arrivés.

4) MTU et surcharge du tag VLAN peuvent transformer « ok » en « instable »

Le tag 802.1Q ajoute 4 octets. Si vous fonctionnez avec des MTU serrés (surtout dans les overlays ou réseaux de stockage), un décalage peut faire que certains périphériques jettent les trames « géantes »
tandis que d’autres fragmentent ou clampent. Le résultat est une douleur sélective : de petits pings fonctionnent, les gros transferts stagnent.

Blague n°1 : les VLAN sont comme des badges nominatifs à une conférence — si la moitié de la salle les porte et l’autre moitié non, vous rencontrerez toujours des gens, juste pas les bons.

Faits intéressants et contexte historique

• IEEE 802.1Q (balisage VLAN) est devenu la norme interopérable parce que les vendeurs avaient des méthodes de trunk incompatibles dans les années 1990.
• La balise 802.1Q fait 4 octets : ID VLAN sur 12 bits (1–4094 utilisables), plus bits de priorité et indicateur de drop-eligible.
• VLAN 0 est réservé pour le marquage de priorité ; il est « tagué » mais pas assigné à un VLAN au sens habituel.
• VLAN 1 a un bagage historique : de nombreux équipements l’utilisent par défaut pour les protocoles de management/plan de contrôle, d’où le « native VLAN 1 partout » devenu courant (et risqué).
• Le VLAN natif existe surtout pour la compatibilité avec l’Ethernet non tagué ; c’est aussi une source récurrente de mauvais mappages silencieux.
• Les attaques de double-tagging (VLAN hopping) exploitaient le comportement du VLAN natif ; la bonne pratique moderne est d’éviter VLAN 1 comme natif et d’éviter les trunks non tagués.
• Les premiers datacenters utilisaient souvent des VLAN pour créer des « zones de sécurité », mais les VLAN sont de la segmentation, pas de la sécurité ; votre application d’ACL/pare-feu reste nécessaire.
• Les grands environnements sont passés de « VLAN par application » à des overlays EVPN/VXLAN parce que l’échelle L2 et la complexité du spanning tree devenaient coûteuses en exploitation.
• La « liste des VLAN autorisés » sur un trunk est à la fois un mécanisme de sécurité et un piège : elle limite le rayon d’action, mais peut isoler du trafic quand il y a dérive.

Signatures de panne : à quoi ça ressemble en production

Les pannes fantômes ont une ambiance. Une fois brûlé, vous pouvez les sentir dans les graphiques.

Symptômes que vous pouvez grapher

• Courtes rafales de pertes répétées toutes les quelques minutes (souvent alignées avec les timers de rafraîchissement ARP/ND ou l’expiration MAC).
• Pics de latence sans saturation de bande passante, surtout sur le trafic est-ouest.
• Une AZ/rack « paraît lente » mais rien n’est complètement hors service ; déplacer des charges corrige le problème.
• Instabilité du stockage : timeouts iSCSI/NFS, flaps Ceph OSD, retard de réplication. Le stockage est impitoyable et sera votre signal d’alerte précoce.

Symptômes dans les logs

• Flux ARP (tempêtes ARP gratuites, churn du cache neighbor).
• Alertes de MAC flapping sur les switches (« MAC moved from port X to port Y »).
• Compteurs d’erreurs d’interface qui ne collent pas à l’histoire (CRC ok, mais les drops augmentent ; ou les erreurs en entrée flambent sur un uplink).
• Retentatives applicatives et timeouts sans pression CPU/mémoire corrélée.

Pourquoi votre première hypothèse est généralement fausse

Vous accuserez DNS. Puis le load balancer. Puis Kubernetes. Puis « l’équipe pare-feu ». Pendant ce temps le réseau rebaptise silencieusement les trames.
Les équipes rapides apprennent à tester le contrat VLAN avant d’inventer de nouvelles théories.

Mode opératoire de diagnostic rapide

Voici la boucle de triage que j’utilise quand quelqu’un dit « c’est intermittent » et que mon café n’a pas encore fait effet.
Le but est de trouver rapidement le goulet, pas de faire un voyage spirituel à travers chaque switch.

Première étape : prouver s’il s’agit d’un problème L2/VLAN ou non

1. Choisissez un hôte affecté et une cible (l’IP de la passerelle est parfaite). Lancez un ping continu et un ping MTU élevé (là où c’est autorisé).
2. Surveillez ARP/ND pendant que le problème se produit. Si les entrées ARP changent ou deviennent incomplètes, suspectez immédiatement un mauvais balisage VLAN.
3. Vérifiez la stabilité de l’adresse MAC sur le switch : si le même MAC bouge entre ports/VLANs, vous êtes en territoire L2.

Deuxième étape : valider le contrat de balisage de bout en bout

1. Sur l’hôte : confirmez si la NIC envoie des trames taguées (sous-interface VLAN) ou non taguées (interface simple).
2. Sur le switch adjacent : confirmez mode access vs trunk, VLAN natif et liste de VLAN autorisés.
3. Parcourez les uplinks : sur chaque trunk du chemin, vérifiez que le VLAN est autorisé et tagué de manière cohérente (et que les VLAN natifs correspondent si utilisés).

Troisième étape : vérifier que ce n’est pas « ce sont les MTU »

1. Confirmez le MTU sur l’hôte, le port du switch et toute frontière overlay/underlay.
2. Recherchez des drops de trames géantes, des compteurs de fragmentation ou des mismatches de TCP MSS clamping.
3. N’oubliez pas les hyperviseurs et les bonds — la dérive MTU adore la virtualisation.

Quatrième étape : confirmez que vous n’avez pas construit une boucle ou un hairpin

1. Vérifiez les changements spanning-tree, les ports bloqués ou des états de forwarding inattendus.
2. Vérifiez les mis-bundles LACP où un côté croit être en port-channel et l’autre croit avoir deux liens indépendants.
3. Recherchez des IP dupliquées ou une confusion VRRP/HSRP qui peut imiter des problèmes VLAN.

Si vous faites ces quatre étapes, vous trouverez soit le mismatch VLAN soit vous l’exclurez assez vite pour avancer sans perdre une journée.

Tâches pratiques : commandes, sorties et décisions

Le travail pratique bat la théorie. Ci-dessous se trouvent des tâches réelles que vous pouvez exécuter sur des hôtes Linux et des environnements de commutation courants. Chaque tâche inclut :
la commande, ce que signifie la sortie et la décision à en tirer.

Task 1: Check whether the host is using VLAN subinterfaces

cr0x@server:~$ ip -d link show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
3: eth0.120@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    vlan protocol 802.1Q id 120 <REORDER_HDR>

Signification : eth0.120 existe et transmettra des trames taguées VLAN 120. Le parent eth0 n’est que le transporteur.

Décision : Le port du switch face à cet hôte doit être en trunk (ou un port hybride configuré pour accepter le VLAN 120 tagué). S’il est en access VLAN 120, vous avez un mismatch.

Task 2: Confirm IP addressing is bound to the VLAN interface you think

cr0x@server:~$ ip addr show dev eth0.120
3: eth0.120@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.20.120.17/24 brd 10.20.120.255 scope global eth0.120
       valid_lft forever preferred_lft forever

Signification : L’IP de l’hôte est sur l’interface taguée, pas sur eth0.

Décision : Si le port du switch est en accès (non tagué), l’hôte crie dans le vide tagué. Corrigez le mode du port ou déplacez l’IP vers l’interface correcte.

Task 3: Verify default route uses the expected interface

cr0x@server:~$ ip route show default
default via 10.20.120.1 dev eth0.120 proto static

Signification : La route par défaut sort via la sous-interface VLAN 120.

Décision : Si la gateway est atteignable de façon intermittente, concentrez-vous sur la couche L2 (VLAN/ARP) avant de poursuivre sur le routage en amont.

Task 4: Watch ARP behavior during the problem window

cr0x@server:~$ ip -s neigh show dev eth0.120
10.20.120.1 lladdr 00:25:90:aa:bb:cc REACHABLE used 42/0/38 probes 0
10.20.120.50 lladdr 00:25:90:11:22:33 STALE used 9/9/0 probes 0

Signification : Si les entrées basculent entre REACHABLE, STALE et INCOMPLETE pendant les pannes, quelque chose perturbe la portée L2 ou des réponses arrivent sur un segment différent.

Décision : L’instabilité ARP/ND est un indice fort : vérifiez la cohérence du balisage et les mouvements de MAC sur les switches.

Task 5: Capture VLAN tags on the wire (prove the host is tagging)

cr0x@server:~$ sudo tcpdump -eni eth0 -c 5 vlan 120
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:01.123456 52:54:00:12:34:56 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 120, p 0, ethertype ARP, Request who-has 10.20.120.1 tell 10.20.120.17, length 46
12:10:02.123457 52:54:00:12:34:56 > 00:25:90:aa:bb:cc, ethertype 802.1Q (0x8100), length 74: vlan 120, p 0, ethertype IPv4, 10.20.120.17 > 10.20.120.1: ICMP echo request, id 123, seq 1, length 32

Signification : Les trames quittant eth0 sont taguées (ethertype 0x8100, VLAN 120).

Décision : Si le port du switch est en access/non tagué, il n’acceptera pas ces trames (ou pourra les supprimer). Configurez le port en trunk ou retirez le tag côté hôte.

Task 6: Check MTU and look for a “works for ping, fails for transfers” trap

cr0x@server:~$ ip link show dev eth0.120
3: eth0.120@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

Signification : Le MTU est 1500 sur l’interface VLAN. Si votre réseau attend des jumbo frames (9000) ou que vous utilisez des overlays, vous pouvez fragmenter ou perdre des paquets.

Décision : Si vous voyez des échecs sélectifs pour de gros payloads, lancez un test de MTU chemin et alignez le MTU de bout en bout.

Task 7: Test path MTU without fragmentation

cr0x@server:~$ ping -M do -s 1472 -c 3 10.20.120.1
PING 10.20.120.1 (10.20.120.1) 1472(1500) bytes of data.
1472 bytes from 10.20.120.1: icmp_seq=1 ttl=64 time=0.402 ms
1472 bytes from 10.20.120.1: icmp_seq=2 ttl=64 time=0.398 ms
1472 bytes from 10.20.120.1: icmp_seq=3 ttl=64 time=0.401 ms

--- 10.20.120.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms

Signification : Un chemin MTU 1500 fonctionne vers la passerelle. Si cela échoue, vous avez un problème MTU ou filtrage.

Décision : Si 1472 échoue mais que les petits pings passent, n’appelez pas ça « perte aléatoire ». Corrigez le MTU ou le MSS clamping ; la surcharge du tag VLAN peut faire partie du problème.

Task 8: Check Linux VLAN filtering and bridge membership (common on hypervisors)

cr0x@server:~$ bridge vlan show
port              vlan-id  
eth0              1 PVID Egress Untagged
br0               1 PVID Egress Untagged
vnet0             120

Signification : Cette configuration host/bridge n’est pas symétrique : eth0 est effectivement en VLAN 1 non tagué, tandis qu’une NIC VM (vnet0) attend VLAN 120.

Décision : C’est ainsi que vous obtenez « la VM marche parfois » selon l’interface qui reçoit le trafic. Corrigez le filtrage VLAN du bridge : taguez le VLAN 120 sur l’uplink ou déplacez la VM dans le bon portgroup.

Task 9: Confirm bond/LACP state (L2 issues often hide in “half a bond”)

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: up
Active Aggregator Info:
        Aggregator ID: 2
        Number of ports: 2
Slave Interface: eth1
MII Status: up
Actor Churn State: churned
Partner Churn State: churned
Slave Interface: eth2
MII Status: up
Actor Churn State: stable
Partner Churn State: stable

Signification : Un slave montre du churn. Cela peut corréler avec du réordonnancement de paquets intermittent ou des drops, surtout si LACP côté switch est mal configuré ou si les VLAN diffèrent par lien membre.

Décision : Vérifiez que le port-channel côté switch est correctement formé et que la configuration VLAN cohérente est appliquée au bundle, pas aux ports membres individuellement.

Task 10: Look for MAC address flapping evidence on the host (as a hint)

cr0x@server:~$ sudo journalctl -k --since "1 hour ago" | tail -n 8
Feb 04 09:12:11 server kernel: IPv6: eth0.120: neighbor 10.20.120.1 is using my MAC address 52:54:00:12:34:56
Feb 04 09:12:12 server kernel: arp: 10.20.120.1 moved from 00:25:90:aa:bb:cc to 00:25:90:dd:ee:ff on eth0.120
Feb 04 09:12:40 server kernel: arp: 10.20.120.1 moved from 00:25:90:dd:ee:ff to 00:25:90:aa:bb:cc on eth0.120

Signification : Le MAC de la passerelle semble changer. Cela peut arriver avec des gateways HA, mais le motif plus les pannes pointe souvent vers une fuite VLAN ou une boucle.

Décision : Confirmez si la gateway est réellement redondante (VRRP/HSRP) et si ces appareils partagent un VLAN de manière cohérente. Sinon, suspectez un mismatch de balisage ou une boucle L2.

Task 11: On a Linux router/firewall, verify VLAN interfaces are present and correctly named

cr0x@server:~$ ip -d link show | grep -E "vlan|eth1\."
5: eth1.120@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    vlan protocol 802.1Q id 120 <REORDER_HDR>
6: eth1.220@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    vlan protocol 802.1Q id 220 <REORDER_HDR>

Signification : Le routeur attend les VLANs tagués 120 et 220 sur eth1.

Décision : Le port adjacent du switch doit trunker ces VLANs vers le routeur. Si quelqu’un a « simplifié » en port d’accès VLAN 120, le VLAN 220 tombera de façon étrange et partielle.

Task 12: Verify firewall rules aren’t lying to you (because the packets never arrive)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,40p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iifname "eth1.120" ip saddr 10.20.120.0/24 tcp dport { 22, 443 } accept
    iifname "eth1.220" ip saddr 10.20.220.0/24 tcp dport 443 accept
  }
}

Signification : Les règles sont spécifiques à l’interface. Si les paquets VLAN 120 arrivent accidentellement non tagués sur eth1, ils manqueront ces règles et seront dropés par la politique par défaut.

Décision : Si les drops augmentent tandis que les compteurs de règles restent à plat, ce n’est probablement pas la règle ; c’est la classification interface/VLAN. Corrigez le balisage avant de « réparer » le pare-feu.

Task 13: Validate switch-side VLAN membership from a host using LLDP hints (when available)

cr0x@server:~$ sudo lldpctl | sed -n '1,40p'
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    eth0, via: LLDP, RID: 1, Time: 0 day, 00:00:22
  Chassis:
    ChassisID:    mac 00:1c:73:aa:bb:cc
    SysName:      tor-sw-07
  Port:
    PortID:       ifname Ethernet1/7
    PortDescr:    server-rack12-u14
  VLAN:           120

Signification : Le switch annonce le VLAN 120 sur ce port. LLDP peut être faux ou incomplet, mais c’est un indice utile.

Décision : Si LLDP montre VLAN 120 mais que l’hôte tague et que le port est en réalité access VLAN 120, vous avez toujours un mismatch. Utilisez LLDP comme orientation, pas comme vérité absolue.

Task 14: Verify actual packet path classification with conntrack (for intermittent flows)

cr0x@server:~$ sudo conntrack -L | head
tcp      6 431999 ESTABLISHED src=10.20.120.17 dst=10.20.120.80 sport=52344 dport=5432 src=10.20.120.80 dst=10.20.120.17 sport=5432 dport=52344 [ASSURED] mark=0 use=1
tcp      6 431998 ESTABLISHED src=10.20.120.17 dst=10.20.120.90 sport=49712 dport=443 src=10.20.120.90 dst=10.20.120.17 sport=443 dport=49712 [ASSURED] mark=0 use=1

Signification : Des flux existent et sont établis ; si l’application se plaint encore, vous observez probablement des drops sporadiques, du réordonnancement ou des chemins de retour asymétriques plutôt qu’un blocage net.

Décision : Descendez la pile : compteurs d’interface, stabilité ARP, stabilité de la table MAC, et cohérence des trunks VLAN.

Voilà plus d’une douzaine de tâches. Utilisez-les comme un entonnoir : commencez large, puis réduisez jusqu’au lien qui ment sur les tags.

Trois mini-histoires d’entreprise (anonymisées, plausibles, douloureuses)

Mini-histoire 1 : La panne causée par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne avait un réseau « simple » : deux switches top-of-rack par rangée, uplinks vers une paire de spines, et une poignée de VLANs.
Le réseau de stockage était VLAN 220, le réseau serveur VLAN 120, et un VLAN de management dont personne ne voulait parler.

Un nouveau rack a été mis en service. Une équipe serveur a provisionné des hôtes avec des sous-interfaces VLAN sur Linux parce que « c’était comme le rack précédent ».
Ils ont tagué eth0.120 et eth0.220, mis des IP, et sont passés à autre chose.

L’équipe réseau, pendant ce temps, avait standardisé les ports face serveur en ports d’accès dans le VLAN 120 et gardait le stockage sur une NIC séparée.
Ils ont supposé que les nouveaux serveurs étaient non tagués. Personne n’a parlé parce que « ce ne sont que des VLANs ».

Le résultat n’a pas été une panne nette. Une partie du trafic fonctionnait parce qu’un hyperviseur en amont avait une ancienne config qui trunkait les ports,
et certains serveurs étaient raccordés accidentellement à ces ports. D’autres serveurs étaient patchés sur des ports stricts d’accès et criaient en envoyant des trames taguées dans le vide.

Ce qui a fait de l’incident un fantôme : l’hôte de supervision se trouvait sur un port « fonctionnel ». Les erreurs côté client étaient sur les ports « cassés ».
L’incident a duré suffisamment longtemps pour énerver tout le monde mais assez peu pour que personne ne veuille faire un postmortem. Jusqu’à ce que ça arrive de nouveau.

La correction a été humiliant de simplicité : aligner le contrat. Soit rendre les ports serveurs en trunks avec seulement les VLANs nécessaires autorisés, soit arrêter le tagging côté hôtes.
Ils ont choisi des trunks avec des listes de VLAN explicitement autorisées, documentées par rack. Le déploiement suivant n’a pas nécessité de télépathie.

Mini-histoire 2 : L’optimisation qui a échoué

Une grande entreprise avait l’habitude de « nettoyer la prolifération de VLAN ». Objectif raisonnable. Les VLAN ont tendance à s’accumuler comme des buckets S3 oubliés.
Un ingénieur senior a décidé de resserrer les listes de VLAN autorisés sur les trunks pour réduire le bruit de broadcast et limiter l’impact des pannes.

Il a mis à jour les VLAN autorisés sur plusieurs trunks spine-to-leaf, supprimant quelques VLANs « non utilisés ».
La vérification d’usage s’est basée sur un export CMDB et un coup d’œil rapide sur les configs des switches. C’était propre, rapide, et faux.

L’un des VLANs supprimés était utilisé par un cluster de traitement batch legacy qui ne lançait de gros jobs que le week-end.
En semaine, il semblait inactif. Le samedi matin, le cluster batch s’est réveillé, n’a pas pu joindre sa base de données, et a commencé à retenter.
Les retentatives sont devenues des hordes. La base de données a subi des tempêtes de connexions. Le CPU a monté. La latence a augmenté. Tout le monde a blâmé la base.

Quand ils ont découvert que le VLAN n’était autorisé sur aucun trunk, l’incident avait déjà muté : le cluster batch avait déclenché des logiques de basculement ailleurs, générant une pile d’alertes secondaires qui ont obscurci la cause racine.

La leçon n’était pas « ne jamais élaguer les VLAN ». C’était : on n’élague pas sur la base de la documentation seule. Élaguer après observation du trafic et décommissionnement délibéré.
Rendre le changement réversible, le réaliser par étapes et mesurer. L’optimisation est une taxe que vous payez plus tard si vous n’y prêtez pas attention maintenant.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une fintech gérait plusieurs datacenters avec un contrôle de changement strict. Pas un contrôle lent. Strict : chaque VLAN avait un propriétaire, un objectif,
et un chemin défini à travers le fabric. Ils gardaient un document « contrat VLAN » vivant qui décrivait, pour chaque VLAN, où il était tagué,
où il était non tagué (idéalement nulle part), et quels trunks le transportaient.

Pendant une actualisation matérielle, un nouveau modèle de top-of-rack a été introduit. Un des templates par défaut de la nouvelle gamme de switches utilisait un VLAN natif différent
du template ancien. Même vendor, defaults différents. Classique.

L’ingénieur de déploiement a suivi la checklist quand même : après application du template, il a lancé un script de validation qui comparait VLAN natif des trunks
et listes de VLAN autorisés par rapport au contrat. Il a échoué immédiatement. Pas en production, mais en staging.

La correction a pris dix minutes : mettre à jour le template pour désactiver l’usage du VLAN natif sur les trunks (tagger tout), définir explicitement les mêmes VLANs autorisés,
et relancer la validation. Aucun impact client. Aucun fantôme.

C’est ça la chose avec les pratiques ennuyeuses : elles ne font pas de belles histoires de guerre, mais elles vous évitent d’en jouer la star.

Erreurs courantes : symptôme → cause racine → correction

1) « Certains hôtes du rack ne peuvent pas atteindre la passerelle, d’autres oui »

Cause racine : Configurations mixtes access et trunk sur les ports face serveur ; hôtes qui taguent de façon inconsistante.

Correction : Standardiser : soit les hôtes sont non tagués (ports access), soit les hôtes taguent (ports trunk). Choisir une approche par environnement et l’appliquer via des templates.

2) « Échecs ARP intermittents, entrées neighbor passent à INCOMPLETE »

Cause racine : Mismatch VLAN provoquant des requêtes/réponses ARP dans des VLANs différents, ou instabilité de la table MAC due à fuite/boucle.

Correction : Valider le contrat de balisage hop par hop ; vérifier les MAC flaps sur les switches ; éliminer les trunks non tagués ou les VLAN natifs mismatched.

3) « Seuls les gros transferts échouent ; les petits pings passent »

Cause racine : Mismatch MTU amplifié par la surcharge du tag VLAN ou l’encapsulation overlay ; PMTUD bloqué ; jumbo non uniforme.

Correction : Aligner le MTU sur l’hôte, les switchports, les port-channels et les frontières d’overlay. Autoriser ICMP « fragmentation needed » quand approprié ou clamp MSS.

4) « Alerte MAC address flapping sur le switch »

Cause racine : Boucle L2, liens redondants mal câblés sans LACP correct, ou fuite VLAN où le même MAC apparaît à plusieurs endroits.

Correction : Vérifier l’état du spanning tree, les bundles LACP, et s’assurer que les VLANs ne sont pas accidentellement pontés entre segments. Corriger câblage et configs de port-channel.

5) « Le pare-feu ne voit rien ; les applis timeoutent quand même »

Cause racine : Les paquets n’atteignent jamais l’interface/ VLAN du pare-feu que vous pensez ; ils arrivent non tagués ou sur un VLAN différent et sont dropés ailleurs.

Correction : Capturez le trafic sur les interfaces du pare-feu avec conscience VLAN ; vérifiez le balisage du switch vers le pare-feu ; évitez de compter sur le VLAN natif pour des zones critiques.

6) « Après un changement, un VLAN est mort mais seulement dans une direction »

Cause racine : Mismatch de la liste de VLAN autorisés sur un trunk multi-sauts ; VLAN autorisés asymétriquement ou élagage incohérent.

Correction : Comparez les listes de VLAN autorisés aux deux extrémités de chaque trunk ; utilisez l’automatisation pour détecter la dérive ; mettez en place l’élagage par étapes avec vérification du trafic observé.

7) « Les VMs sur le même hôte se parlent, mais pas hors hôte »

Cause racine : Le vSwitch/bridge de l’hyperviseur tague en interne, mais l’uplink physique est configuré en access (ou mauvais VLAN de trunk).

Correction : Faire de l’uplink physique un trunk transportant les VLANs des VMs ; vérifier le filtrage VLAN sur les bridges Linux ou les VLAN IDs des portgroups hyperviseur.

8) « La redondance aggrave la situation »

Cause racine : Les membres d’un bundle LACP n’ont pas les mêmes paramètres VLAN ; ou un côté est en LACP et l’autre en ports individuels.

Correction : Configurer les VLANs sur le port-channel, pas sur les membres ; vérifier l’état LACP ; s’assurer que les deux côtés sont d’accord sur le mode et le hashing.

Blague n°2 : le VLAN natif est comme un tiroir « divers » — parfait jusqu’au moment où il faut trouver quelque chose, puis c’est une scène de crime.

Listes de contrôle / plan étape par étape

Étape par étape : corriger l’incident actuel en toute sécurité

1. Choisir un flux qui échoue (hôte source, hôte/ gateway destination, protocole/port). Notez-le.
2. Prouver le balisage sur la source avec ip -d link et tcpdump vlan.
3. Vérifier le mode du switch adjacent (access vs trunk) et les paramètres VLAN (VLAN natif, VLANs autorisés).
4. Parcourir le chemin : pour chaque saut trunk, vérifier que le VLAN est autorisé et tagué de manière cohérente.
5. Vérifier la stabilité MAC : rechercher MAC flapping ; si présent, arrêtez et traquez les boucles/mis-bundles avant de modifier les VLANs.
6. Corriger le contrat à une frontière : choisissez « l’hôte tague » ou « le réseau tague », pas les deux. Implémentez le plus petit changement qui restaure la cohérence.
7. Valider avec une capture : voir les trames taguées là où vous les attendez, et non taguées uniquement là où vous les destinez explicitement.
8. Verrouiller le changement : mettre à jour templates et gestion de configuration pour éviter la dérive la semaine suivante.
9. Vérification post-incident : exécuter des tests MTU et surveiller la stabilité ARP/ND pendant au moins un intervalle d’expiration MAC.

Checklist : concevoir des VLAN qui ne vous hanteront pas

• Taggez tout sur les trunks. Si vous devez utiliser un VLAN natif, gardez-le inutilisé pour le trafic utilisateur et cohérent partout.
• Minimisez le L2 quand vous pouvez. Routez au ToR si votre design le permet ; gardez les VLANs petits et intentionnels.
• Listes de VLAN autorisés explicites sur les trunks — associées à l’automatisation pour détecter la dérive. L’élagage manuel est l’endroit où les bonnes intentions se perdent.
• Une source de vérité pour la propriété et le but des VLANs. Si personne ne possède le VLAN 317, il finira par vous posséder.
• Standardiser la connectivité serveur. Décidez host-tagging vs ports access ; documentez les exceptions comme des cas soumis à approbation.
• Surveillez les signaux L2 : MAC flaps, changements STP, anomalies de taux ARP. Ce sont les alarmes incendie pour les problèmes VLAN.

Checklist : validation pré-changement (avant de toucher la prod)

• Confirmer que les deux bouts de chaque trunk s’accordent sur : mode de trunking, VLAN natif (si présent), liste VLAN autorisés.
• Confirmer la cohérence LACP : même mode, mêmes ports membres, mêmes paramètres VLAN sur le bundle.
• Confirmer le MTU : NICs hôtes, switchports, port-channels, et frontières d’overlay.
• Faire un smoke test : ARP vers la gateway, ping avec DF, et une petite transaction applicative si possible.
• Avoir un plan de rollback qui restaure rapidement la liste VLAN autorisée ou le mode du port précédent.

Principe opérationnel à piquer

Voici une idée paraphrasée attribuée à Richard Cook (résilience des systèmes) : les systèmes complexes réussissent parce que les personnes s’adaptent continuellement pour les maintenir.
La dérive VLAN prospère quand votre système dépend d’adaptations héroïques plutôt que de contrats explicites.

FAQ

1) Qu’est-ce qu’une « panne fantôme » en termes de VLAN ?

Une panne où la connectivité échoue de manière intermittente ou partielle parce que les trames sont parfois classifiées dans le mauvais VLAN le long du chemin.
Ce n’est pas net ; c’est une douleur probabiliste.

2) Le VLAN natif est-il intrinsèquement mauvais ?

Le VLAN natif est une fonctionnalité de compatibilité. Il n’est pas mauvais, il est juste facile à mal utiliser. Si vous l’utilisez, gardez-le cohérent aux deux extrémités et évitez de transporter du trafic utilisateur non tagué.
Beaucoup d’équipes de production choisissent « tagger tout » sur les trunks et considèrent le non tagué comme une mauvaise configuration.

3) Un mismatch VLAN peut-il causer une connectivité unidirectionnelle ?

Oui. Si les trames sortantes sont correctement taguées mais que les trames de retour sont apprises/forwards dans un VLAN différent (ou arrivent non taguées et mappées à un autre VLAN),
vous obtenez une reachabilité asymétrique : le SYN part, le SYN-ACK ne revient jamais.

4) Pourquoi les problèmes ARP apparaissent-ils en premier ?

ARP (et ND IPv6) est broadcast/multicast et dépend d’être dans le bon domaine L2. Si la classification VLAN est fausse, la résolution d’adresse casse d’une manière que TCP ne peut pas cacher longtemps.
Vous verrez les entrées neighbor devenir incomplètes, ou les MAC de la gateway « changer ».

5) Le balisage VLAN affecte-t-il le MTU ?

Le tag VLAN ajoute 4 octets. Sur du matériel correctement configuré, le MTU physique l’accommode. Dans la réalité, les équipements divergent.
Si votre design est serré (jumbos, overlays), ces 4 octets peuvent vous pousser vers des drops ou de la fragmentation à moins d’aligner le MTU de bout en bout.

6) Comment choisir entre host tagging et ports d’accès switch ?

Si vous exploitez des hyperviseurs ou avez besoin de plusieurs VLANs sur une NIC, le host tagging (ou tagging hyperviseur) est souvent pratique — accompagné de ports trunk.
Si vous voulez de la simplicité et moins d’éléments mouvants, les ports access par NIC par VLAN peuvent être plus sûrs. Le mauvais choix est de mélanger les deux sans documentation.

7) Quel est le moyen le plus rapide de prouver qu’un VLAN est autorisé à travers le fabric ?

Depuis l’hôte : capturez les trames taguées sortant de la NIC, puis capturez sur le switch adjacent (SPAN/mirror) pour voir si ces trames taguées arrivent inchangées.
Si elles disparaissent ou deviennent non taguées, vous avez trouvé une frontière qui rompt le contrat.

8) L’élagage des VLAN autorisés peut-il causer des problèmes même si « personne n’utilise ce VLAN » ?

Oui, parce que « personne ne l’utilise » signifie souvent « personne ne l’utilise maintenant ». Jobs planifiés, tests DR, appliances anciennes, ou basculements HA peuvent activer un usage dormant.
Élaguer seulement après décommission vérifié et observation, pas uniquement sur la documentation.

9) Comment cela se rapporte-t-il aux pannes de stockage ?

Les protocoles de stockage sont sensibles à la perte et à la latence. Une petite quantité de perte intermittente liée au VLAN peut déclencher des timeouts, des basculements ou une réplication dégradée.
Le stockage devient votre système d’alerte précoce pour « le réseau vous ment ».

10) Si j’utilise VXLAN/EVPN, les erreurs VLAN ont-elles encore de l’importance ?

Moins à certains endroits, plus à d’autres. Les overlays réduisent la prolifération L2, mais vous avez toujours des VLANs à la périphérie (ports serveur, uplinks VTEP, segments de handoff).
Le mauvais balisage à la périphérie peut toujours créer des pannes fantômes — maintenant avec l’encapsulation qui rend les symptômes plus difficiles à lire.

Conclusion : étapes pratiques suivantes

Les pannes fantômes ne sont pas surnaturelles. Elles apparaissent quand votre réseau ne peut pas répondre de façon cohérente à une question basique : « Dans quel VLAN est cette trame ? »
Des balisages incohérents, des VLANs natifs mismatched et des listes de VLAN autorisés qui dérivent transforment l’Ethernet en un livre dont vous êtes le héros,
sauf que la fin est toujours un canal d’incident rempli de captures d’écran.

Étapes suivantes qui font vraiment avancer :

1. Choisir une politique : taggez tout sur les trunks, et considérez le non tagué comme une exception délibérée.
2. Rédiger le contrat VLAN : pour chaque VLAN, définir où il existe, où il est tagué, et qui en est propriétaire.
3. Automatiser la détection de dérive : les mismatches de VLAN natif et de VLANs autorisés doivent être détectés avant les utilisateurs.
4. Ajouter des signaux L2 à la supervision : MAC flaps, événements STP, anomalies ARP/ND, et drops d’interface.
5. S’exercer au playbook : exécuter les étapes de diagnostic rapide pendant les périodes calmes pour pouvoir les appliquer sous pression.

Faites cela, et la prochaine fois que quelqu’un dira « c’est intermittent », vous aurez une courte liste de preuves — pas une longue liste de suppositions.