Ubuntu 24.04 : les VLAN ne fonctionnent pas — le paramètre bridge que la plupart oublient

novembre 9, 2025 • février 3, 2026 • Lecture : 28 min • Views: 9

Cet article vous a aidé ?

Tout a l’air correct. Le port du switch est en trunk. La VM a une interface taggée. Le VLAN existe. Vous voyez même des paquets sur le lien. Et pourtant : pas de trafic. Pas « lent ». Pas « instable ». Juste mort, comme votre fenêtre de changement.

Sur Ubuntu 24.04, les VLAN « qui ne fonctionnent pas » sur un bridge Linux tiennent souvent à un élément manquant : le filtrage VLAN du bridge. Si vlan_filtering n’est pas activé sur le bridge, votre trunk soigneusement configuré se transforme en une suggestion polie que le noyau ignore. La correction est simple ; le diagnostic est là où les gens passent des heures.

Le paramètre oublié : `vlan_filtering` et pourquoi il compte

Les bridges Linux peuvent traiter les VLAN de deux façons très différentes :

Bridge non conscient des VLAN : le bridge achemine les trames selon l’apprentissage des adresses MAC et ne maintient pas d’appartenance VLAN par port. Les tags peuvent parfois passer, mais vous ne configurez pas les VLAN sur le bridge lui‑même.
Bridge conscient des VLAN : le bridge se comporte comme un petit switch géré. Les ports ont une appartenance VLAN, un PVID (Port VLAN ID), un comportement non taggé optionnel et du filtrage. Ce mode est contrôlé par vlan_filtering.

Sur Ubuntu 24.04, en particulier avec Netplan + systemd-networkd, les gens construisent souvent un bridge en s’attendant à un « trunking » de type switch. Ils définissent des VLANs, créent une interface VM, la taggent, et supposent que le bridge transmettra le trafic taggué. Mais le bridge ne se comportera pas comme un switch VLAN-aware à moins que vous n’activiez le filtrage VLAN. Vous pouvez avoir des définitions VLAN parfaitement valides et ne rien filtrer — parce que le noyau n’a pas été invité à le faire.

Voici le comportement central à retenir :

Si vlan_filtering=0, la configuration bridge vlan est effectivement ignorée pour les décisions de forwarding.
Si vlan_filtering=1, le bridge utilise sa table VLAN pour décider quels VLANs sont permis sur quels ports et comment les trames non taggées sont classifiées (PVID).

Une petite blague, parce que vous l’avez mérité : le filtrage VLAN, c’est comme la ceinture de sécurité — personne ne la remarque jusqu’au moment où il est projeté à travers le pare‑brise.

À quoi ressemble un « les VLAN ne fonctionnent pas »

Schémas courants :

Les VM sur un VLAN taggé peuvent ARP mais ne reçoivent pas de réponses.
VM‑to‑VM sur le même hôte fonctionne, mais VM‑to‑gateway ne fonctionne pas.
Le trafic non taggé fonctionne sur le bridge, mais le trafic taggé disparaît.
tcpdump montre des tags VLAN sur une interface VM, mais pas sur la NIC physique (ou inversement).

Comment les bridges Linux gèrent réellement les VLAN (pas comme on le souhaiterait)

Un bridge Linux est un datapath noyau (pas seulement un concept en espace utilisateur), avec des réglages qui déterminent comment les trames sont classées et acheminees. Le bridging VLAN-aware est implémenté dans la couche bridge : le bridge maintient l’appartenance VLAN par port et par VLAN, plus des flags comme « untagged » et « PVID ».

Les éléments mobiles à garder droits

Dispositif bridge (par ex. br0) : là où le filtrage VLAN est activé et où la table VLAN vit.
Ports du bridge (par ex. eno1, vnet12) : chaque port peut être membre trunk de plusieurs VLANs et peut avoir un PVID.
PVID : le VLAN assigné aux trames d’entrée non taggées sur un port. C’est votre concept de « native VLAN » (mais n’abusez pas de ce terme devant les ingénieurs réseau si vous aimez les soupirs).
Flag d’ejection non taggée : si les trames pour ce VLAN sortent du port sans tag.
Sous‑interfaces VLAN (par ex. br0.20 ou eno1.20) : une autre façon de faire des VLANs, souvent utilisée quand on veut du L3 sur un VLAN. Cela peut coexister avec le bridging VLAN-aware, mais mélanger les modèles sans précaution crée des problèmes fantômes.

Pourquoi Ubuntu 24.04 embrouille les gens

Ubuntu 24.04 configure beaucoup de serveurs avec Netplan et systemd-networkd par défaut. C’est bien. C’est déterministe. C’est aussi intransigeant : si vous ne demandez pas explicitement le comportement VLAN-aware, vous ne l’obtiendrez pas. Les anciens how‑to de l’ère « ifupdown » supposent souvent des valeurs par défaut différentes, et de nombreuses piles de virtualisation « cachent » la complexité jusqu’à ce que vous quittiez le chemin heureux.

Aussi : Linux vous donne au moins trois façons de construire la même topologie réseau. Choisissez‑en une et tenez‑vous‑y :

Bridge Linux VLAN‑aware (recommandé pour le bridging KVM et l’hébergement VM multi‑VLAN).
Interfaces VLAN séparées + bridges séparés par VLAN (ennuyeux et efficace ; se débogue facilement mais scale mal).
OVS (Open vSwitch) (puissant ; plus de composants ; utile si vous avez besoin des fonctionnalités OVS).

Plan de diagnostic rapide (vérifiez 1, 2, 3)

Si les VLAN « ne fonctionnent pas », vous voulez trouver le goulot rapidement. N’allez pas éditer du YAML Netplan immédiatement. D’abord, prouvez ce que le noyau pense être vrai.

1) Le bridge est‑il VLAN‑aware ?

Vérifiez vlan_filtering et la table VLAN. Si le filtrage est désactivé, arrêtez et corrigez cela d’abord.

2) Le bridge autorise‑t‑il le VLAN sur les bons ports ?

Le VLAN doit être présent sur les deux :

le port uplink physique (le trunk vers votre switch), et
le port vnet de la VM (ou le veth du conteneur), ou un bond/bridge en aval.

3) Le comportement non taggé vs taggé est‑il correct ?

La plupart des pannes ici sont « mismatch PVID » ou « hypothèse native VLAN ». Confirmez :

Quel VLAN reçoit les trames d’entrée non taggées ?
Est‑on en train d’enlever les tags à la sortie par erreur ?

4) Ensuite, vérifiez le switch externe

Ce n’est qu’après avoir prouvé que Linux est correctement configuré que vous devez discuter avec l’équipe réseau (ou avec votre ancien vous). Validez les VLAN autorisés sur le trunk et l’attente de native VLAN.

Tâches pratiques : commandes, sortie attendue, et décisions

Voici les tâches que j’exécute en production quand quelqu’un dit « les VLAN ne fonctionnent pas ». Chaque tâche inclut une commande, une sortie exemple, ce que cela signifie et la décision à prendre.

Task 1: Identifier le bridge et ses ports

cr0x@server:~$ bridge link
2: eno1 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master br0
5: vnet12 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master br0
6: vnet13 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master br0

Ce que cela signifie : Les ports eno1, vnet12, vnet13 sont esclavagés par br0.

Décision : Si la NIC physique que vous attendez n’est pas listée, votre bridge n’est pas connecté à l’extérieur. Corrigez cela avant de chasser les VLANs.

Task 2: Vérifier si le filtrage VLAN est activé (le but entier)

cr0x@server:~$ ip -d link show br0
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:ab:cd:ef brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
    bridge forward_delay 1500 hello_time 200 max_age 2000 stp_state 0 priority 32768 vlan_filtering 0 vlan_protocol 802.1Q

Ce que cela signifie : vlan_filtering 0 indique que le bridge n’est pas VLAN-aware. Votre table bridge vlan ne sera pas appliquée.

Décision : Si vous essayez de trunker des VLANs via br0, vous voulez presque certainement vlan_filtering 1. Activez‑le (temporairement avec ip, de façon permanente via Netplan/systemd-networkd).

Task 3: Montrer la table d’appartenance VLAN actuelle

cr0x@server:~$ bridge vlan show
port              vlan-id  
eno1              1 PVID Egress Untagged
vnet12            1 PVID Egress Untagged
vnet13            1 PVID Egress Untagged

Ce que cela signifie : Seul le VLAN 1 existe partout, il est le PVID et sort non taggé. Pas de VLAN 20/30 présent.

Décision : Ajoutez les VLANs aux ports concernés, ou revérifiez que votre configuration s’est appliquée. Si le filtrage VLAN est désactivé, corrigez‑le d’abord — cette table peut être sans signification pour le forwarding.

Task 4: Confirmer que l’interface VM voit les tags VLAN

cr0x@server:~$ tcpdump -eni vnet12 -c 5 vlan
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vnet12, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:00:01.100000 52:54:00:11:22:33 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), vlan 20, p 0, ethertype ARP (0x0806), Request who-has 10.20.0.1 tell 10.20.0.50, length 46
12:00:01.200000 52:54:00:11:22:33 > 33:33:00:00:00:02, ethertype 802.1Q (0x8100), vlan 20, p 0, ethertype IPv6 (0x86dd), length 86

Ce que cela signifie : La VM envoie des trames taggées (VLAN 20) vers l’hôte.

Décision : Si des tags existent sur le vnet, la VM est probablement configurée correctement. Assurez‑vous maintenant que le bridge achemine le VLAN 20 et que l’uplink l’autorise.

Task 5: Confirmer que l’uplink physique voit les mêmes tags VLAN

cr0x@server:~$ tcpdump -eni eno1 -c 5 vlan 20
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:00:01.300000 52:54:00:ab:cd:ef > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), vlan 20, p 0, ethertype ARP (0x0806), Request who-has 10.20.0.1 tell 10.20.0.50, length 46

Ce que cela signifie : Les tags sortent de la NIC. Cela oriente le diagnostic hors de Linux vers le switch, le filtrage en amont ou des problèmes de chemin retour.

Décision : Si vous voyez des tags sur vnet mais pas sur eno1, Linux les supprime/strippe (table VLAN du bridge / PVID / flags untagged). Corrigez d’abord la configuration du bridge Linux.

Task 6: Activer temporairement le filtrage VLAN pour prouver l’hypothèse

cr0x@server:~$ sudo ip link set dev br0 type bridge vlan_filtering 1
cr0x@server:~$ ip -d link show br0 | sed -n '1,3p'
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:ab:cd:ef brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
    bridge forward_delay 1500 hello_time 200 max_age 2000 stp_state 0 priority 32768 vlan_filtering 1 vlan_protocol 802.1Q

Ce que cela signifie : Le bridge est maintenant VLAN-aware.

Décision : Si les VLANs se mettent soudainement à fonctionner, vous avez trouvé le paramètre manquant. Maintenant rendez‑le persistant dans Netplan/systemd-networkd. Ne le laissez pas comme correctif ponctuel en runtime.

Task 7: Ajouter VLAN 20 à l’uplink et au port VM (runtime)

cr0x@server:~$ sudo bridge vlan add dev eno1 vid 20
cr0x@server:~$ sudo bridge vlan add dev vnet12 vid 20
cr0x@server:~$ bridge vlan show | egrep 'eno1|vnet12'
eno1              1 PVID Egress Untagged
eno1              20
vnet12            1 PVID Egress Untagged
vnet12            20

Ce que cela signifie : Le VLAN 20 est maintenant permis sur les deux ports.

Décision : Si le trafic fonctionne maintenant, traduisez ces réglages dans votre configuration déclarative. Les commandes runtime servent au diagnostic, pas à dormir tranquille.

Task 8: Vérifier le PVID et le comportement non taggé sur l’uplink

cr0x@server:~$ bridge vlan show dev eno1
port              vlan-id  
eno1              1 PVID Egress Untagged
eno1              20

Ce que cela signifie : Les trames non taggées entrant sur eno1 seront traitées comme VLAN 1, et VLAN 1 sortira non taggé. VLAN 20 sortira taggé.

Décision : Si votre port de switch attend un native VLAN différent, ajustez le PVID (et éventuellement retirez VLAN 1). Les PVIDs mal alignés créent des mystères « ça marche pour certains hôtes ».

Task 9: Rechercher des sous‑interfaces VLAN inattendues qui compliquent le bridging

cr0x@server:~$ ip -o link show | grep -E '\.([0-9]+):'
10: eno1.20@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
11: br0.30@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Ce que cela signifie : Vous avez des sous‑interfaces VLAN sur la NIC et/ou le bridge. Ce n’est pas faux, mais c’est un signe que vous pourriez mélanger les modèles de conception.

Décision : Décidez si vous faites du bridging VLAN‑aware (préféré pour des trunks VM) ou des sous‑interfaces VLAN + bridges par VLAN. Mélanger sans diagramme transforme le débogage en folklore.

Task 10: Confirmer quel renderer et backend sont utilisés

cr0x@server:~$ networkctl status -a | sed -n '1,14p'
● State: routable
  Online state: online
  Address state: routable
  IPv4 address state: routable
  IPv6 address state: degraded
  Carrier bound to: config
  DNS: 10.0.0.53
  Network:
       Link 2 (eno1)
       Link 7 (br0)

Ce que cela signifie : systemd-networkd gère les liens (commun sur les serveurs Ubuntu). Si vous attendiez NetworkManager, vous êtes en train de déboguer la mauvaise pile.

Décision : Tenez‑vous à un seul plan de contrôle. Si Netplan rend vers networkd, utilisez Netplan (ou des fichiers networkd natifs) de façon cohérente.

Task 11: Valider le rendu netplan et capter les erreurs YAML

cr0x@server:~$ sudo netplan generate
cr0x@server:~$ sudo netplan try
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 120 seconds

Ce que cela signifie : generate a réussi (pas d’erreur de syntaxe). try applique temporairement et vous donne une porte de sortie.

Décision : Utilisez netplan try dans les sessions à distance. Si une erreur VLAN coupe votre connectivité, vous récupérez votre serveur sans aller à la torche et à la console.

Task 12: Inspecter l’état bridge du noyau et la base de forwarding

cr0x@server:~$ bridge fdb show br br0 | head
52:54:00:11:22:33 dev vnet12 master br0 permanent
0a:1b:2c:3d:4e:5f dev eno1 master br0
33:33:00:00:00:16 dev vnet12 master br0 permanent

Ce que cela signifie : Le bridge apprend des MACs et a des entrées permanentes. Cela prouve que le forwarding L2 est vivant au moins à un niveau basique.

Décision : Si la FDB est vide alors que les interfaces sont up et qu’il y a du trafic, vous pourriez avoir des bizarreries d’offload, un mauvais attachement (la VM n’est pas sur ce bridge), ou le trafic n’atteint tout simplement pas le bridge.

Task 13: Chercher des drops liés aux VLAN dans les compteurs

cr0x@server:~$ ip -s link show eno1 | sed -n '1,12p'
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast           
     987654321  1234567      0     120       0    45678
    TX:  bytes packets errors dropped carrier collsns         
     876543210  1122334      0       0       0       0

Ce que cela signifie : Un dropped RX non nul peut venir de la mise en file, du pilote, d’un offload ou d’une politique. C’est un indice, pas un verdict.

Décision : Si les drops montent pendant vos tests VLAN, envisagez les réglages d’offload ou un mismatch MTU (surtout avec VLAN + overlay). Mesurez avant d’« optimiser ».

Task 14: Vérifier l’MTU de bout en bout (le VLAN ajoute un overhead)

cr0x@server:~$ ip link show br0 | head -n 2
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:ab:cd:ef brd ff:ff:ff:ff:ff:ff

Ce que cela signifie : Le MTU du bridge est 1500. Si votre réseau physique est 1500 et que vous exécutez aussi VXLAN/Geneve par‑dessus, vous fragmenterez ou perdrez des paquets.

Décision : Si vous utilisez des overlays, augmentez le MTU de l’underlay de façon cohérente, ou acceptez un MTU inférieur pour l’overlay et configurez‑le volontairement.

Task 15: Confirmer les attentes VLAN côté switch en testant non taggé vs taggé

cr0x@server:~$ sudo arping -I br0 -c 3 10.0.0.1
ARPING 10.0.0.1 from 10.0.0.10 br0
Unicast reply from 10.0.0.1 [00:11:22:33:44:55]  1.233ms
Unicast reply from 10.0.0.1 [00:11:22:33:44:55]  1.104ms
Unicast reply from 10.0.0.1 [00:11:22:33:44:55]  1.098ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)

Ce que cela signifie : La connectivité non taggée/native fonctionne sur br0.

Décision : Si le non taggé fonctionne mais que VLAN 20 ne fonctionne pas, concentrez‑vous sur l’appartenance VLAN / PVID / tagging entre les ports du bridge et la liste d’autorisation du trunk du switch.

Netplan sur Ubuntu 24.04 : le modèle de bridge qui gère les VLAN et qui marche

Il existe deux modèles raisonnables pour des hôtes VM multi‑VLAN. Choisissez selon vos priorités opérationnelles.

Modèle A (recommandé) : bridge VLAN‑aware en trunk vers les VM

Vous créez un bridge (br0) avec l’uplink physique comme port. Vous activez le filtrage VLAN. Vous définissez quels VLANs sont autorisés sur quels ports. Les VM peuvent être connectées et soit taggées à l’intérieur de la VM, soit vous configurez le comportement VLAN par VM via l’outil d’hyperviseur (libvirt/virt-manager/etc.).

Un exemple Netplan représentatif (conceptuel ; vos clés exactes peuvent varier selon l’environnement) :

cr0x@server:~$ sudo cat /etc/netplan/01-br0.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: false
  bridges:
    br0:
      interfaces: [eno1]
      dhcp4: false
      addresses: [10.0.0.10/24]
      routes:
        - to: default
          via: 10.0.0.1
      nameservers:
        addresses: [10.0.0.53]
      parameters:
        stp: false
      # The critical part: VLAN-aware bridge behavior is not magic.
      # Netplan renders this into the appropriate backend config.
      # If your environment doesn't apply it, validate with `ip -d link show br0`.

Véracité : L’abstraction de Netplan est utile jusqu’à ce qu’elle ne le soit plus. La seule vérité est ce que rapporte le noyau (ip -d link, bridge vlan show).

Si vous ne parvenez pas à faire en sorte que Netplan configure de façon fiable le filtrage VLAN dans votre environnement, il est acceptable de revenir à une configuration systemd-networkd native. Les systèmes de production récompensent la justesse ennuyeuse.

Modèle B : sous‑interfaces par VLAN et bridges par VLAN

Cela ressemble à :

eno1.20 attaché à br20
eno1.30 attaché à br30

C’est verbeux, mais facile à déboguer : si VLAN 20 est cassé, vous regardez eno1.20 et br20 et vous vous arrêtez là. C’est ce que vous faites quand vous voulez le modèle mental le plus simple et que la prolifération de configuration ne vous dérange pas.

Les réglages systemd-networkd dont vous avez réellement besoin

Le réseau serveur Ubuntu 24.04 finit fréquemment géré par systemd-networkd. Dans ce contexte, un bridging VLAN-aware revient typiquement à :

Bridge créé et ports attachés
VLANFiltering=yes (ou équivalent) appliqué au bridge
Appartenance VLAN configurée par port (parfois via des entrées bridge VLAN)

Au lieu de deviner, validez ce qui est appliqué :

cr0x@server:~$ networkctl status br0 | sed -n '1,40p'
● 7: br0
             Link File: /run/systemd/network/10-netplan-br0.network
          Network File: /run/systemd/network/10-netplan-br0.network
                  Type: bridge
                 State: routable (configured)
          Online state: online

Ce que cela signifie : Netplan a généré des unités networkd d’exécution. Vous savez maintenant où regarder si vous devez inspecter la configuration rendue.

cr0x@server:~$ sudo sed -n '1,120p' /run/systemd/network/10-netplan-br0.netdev
[NetDev]
Name=br0
Kind=bridge

[Bridge]
STP=false

Ce que cela signifie : Ce fichier rendu peut ne pas inclure le filtrage VLAN, selon la façon dont Netplan l’a exprimé (ou pas).

Décision : Si la configuration d’exécution ne définit pas le filtrage VLAN, vous pouvez corriger votre YAML Netplan ou passer à des fichiers networkd natifs où vous le contrôlez explicitement.

Deuxième petite blague (et dernière) : Un bridge sans filtrage VLAN est comme une demande de changement sans plan de rollback — techniquement autorisé, émotionnellement irresponsable.

Erreurs courantes : symptôme → cause racine → correction

Cette section est celle que vous voudrez à 02:00 quand vous plisserez les yeux sur tcpdump.

1) Le trafic VLAN taggé ne quitte jamais l’hôte

Symptôme : Des tags VLAN apparaissent sur vnetX, mais pas sur eno1.

Cause racine : Filtrage VLAN du bridge activé mais VLAN non autorisé sur le port uplink ; ou filtrage VLAN désactivé donc votre config VLAN n’est pas appliquée comme vous le pensez ; ou egress untagged mal configuré.

Correction : Activez le filtrage VLAN sur le bridge et ajoutez l’appartenance VLAN sur les deux ports :

cr0x@server:~$ sudo ip link set dev br0 type bridge vlan_filtering 1
cr0x@server:~$ sudo bridge vlan add dev eno1 vid 20
cr0x@server:~$ sudo bridge vlan add dev vnet12 vid 20

2) Le trafic non taggé fonctionne, les VLANs taggés échouent

Symptôme : La gestion de l’hôte sur le VLAN natif fonctionne. La VM sur VLAN 20 ne peut pas atteindre la gateway.

Cause racine : La liste d’autorisation du trunk sur le switch ne contient pas le VLAN ; ou le bridge Linux n’autorise pas VLAN 20 sur l’uplink ; ou l’hyperviseur retire les tags alors que la VM attend des tags.

Correction : Validez d’abord l’appartenance VLAN sur les ports Linux avec bridge vlan show, puis validez le trunk sur le switch.

3) Certaines VMs parlent sur VLAN 20, d’autres non

Symptôme : VM‑A fonctionne sur VLAN 20, VM‑B non, même hôte.

Cause racine : Le port vnet de la VM cassée n’a pas l’appartenance VLAN ; ou il a un mode de tagging différent (taggé dans l’invité vs non taggé dans l’invité et taggé par l’outil d’hyperviseur).

Correction : Comparez bridge vlan show dev vnetX pour les deux et standardisez une approche.

4) ARP fonctionne mais le trafic IP ne passe pas

Symptôme : Vous voyez des réponses ARP mais les pings échouent.

Cause racine : Problèmes MTU/fragmentation (surtout avec des overlays), politique de sécurité en amont, ou routage asymétrique. La config VLAN peut être correcte.

Correction : Vérifiez la cohérence MTU, puis le routage et le pare‑feu. Les VLANs ne sont pas les seuls qui peuvent gâcher votre soirée.

5) Le trafic fonctionne jusqu’au reboot

Symptôme : bridge vlan add en runtime a corrigé le problème, mais un redémarrage le recrée.

Cause racine : Vous n’avez pas rendu persistant le filtrage VLAN et la table VLAN ; la config Netplan/networkd manque des lignes critiques.

Correction : Encodez les réglages dans Netplan ou des fichiers networkd natifs. Confirmez après reboot avec ip -d link show br0 et bridge vlan show.

6) « Mais le bridge est UP » (tromperie classique)

Symptôme : Tous les liens sont UP, mais le forwarding VLAN n’a pas lieu.

Cause racine : Filtrage VLAN désactivé ou appartenance VLAN manquante. L’état du lien n’est pas l’état de la politique.

Correction : Arrêtez de faire confiance au « UP ». Commencez à faire confiance à la table VLAN et aux captures.

Trois mini-histoires d’entreprise issues du terrain

Incident causé par une fausse hypothèse : « Un bridge Linux, c’est un switch, non ? »

Une entreprise de taille moyenne exécutait un cluster de virtualisation sur Ubuntu. Elle a migré depuis une image hôte plus ancienne où le réseau était configuré par des scripts faits à la main. La nouvelle image standardisait sur Ubuntu 24.04 et Netplan. Le plan était sain : un bridge par hôte, trunk de plusieurs VLANs, et réseau VM flexible.

La première fenêtre de maintenance s’est déroulée sans problème — jusqu’à ce que de nouvelles VMs sur un « app VLAN » taggé ne puissent pas atteindre leur gateway. L’équipe a fait la danse habituelle : revérifier le trunk du switch, recharger le port ToR, rattacher les NICs de la VM, essayer différents modèles virtio. Quelqu’un a même basculé STP parce que ça donnait l’impression de faire quelque chose.

L’hypothèse erronée était simple : ils pensaient que définir l’appartenance VLAN quelque part dans leur chaîne d’outils ferait automatiquement se comporter le bridge Linux comme un switch VLAN-aware. Ce n’était pas le cas. Le bridge forwardait bien les trames non taggées, donc tout le monde regarda ailleurs que l’hôte vers le réseau. Pendant ce temps, l’hôte ignorait calmement leurs intentions VLAN parce que vlan_filtering était désactivé.

La correction prit quelques minutes : activer le filtrage VLAN et ajouter l’appartenance VLAN pour l’uplink et les ports VM. Le vrai travail fut social : mettre à jour la documentation de build et les tests d’acceptation pour éviter que cela ne se reproduise.

Ensuite, ils écrivirent un petit préflight qui s’exécute sur chaque hôte : dumper ip -d link show br0, échouer la build si vlan_filtering 0, et exiger une liste VLAN connue dans bridge vlan show. Personne n’aime les garde‑fous jusqu’à ce qu’ils évitent une panne.

Optimisation qui s’est retournée contre eux : « On décharge tout »

Une autre organisation voulait un meilleur débit sur le réseau VM. Ils avaient plusieurs VLANs bridgés vers une NIC 25G, et ils voyaient des drops occasionnels lors de rafales. La solution, pensaient‑ils, fut d’activer toutes les fonctions d’offload disponibles et d’ajuster agressivement les queues.

Au début, ça semblait mieux : le CPU baissait, le débit montait dans les tests synthétiques, les graphiques s’amélioraient. Puis les ennuis commencèrent : pertes sporadiques de paquets seulement sur un VLAN, et seulement pour certains motifs de trafic. ARP semblait OK. TCP piquait et récupérait. Le monitoring UDP ratait des intervalles. C’était le pire type de bug : intermittent et plausiblement « en amont ».

Le retour de bâton venait d’un mélange de comportement du pilote et de la manière dont les captures étaient interprétées. Avec certains offloads activés, la visibilité des paquets changea : tcpdump ne racontait pas toujours toute la vérité sur ce qui était taggé où, et l’équipe poursuivit des problèmes VLAN fantômes pendant des jours. Ils découvrirent aussi que les rafales venaient d’un pattern de déploiement applicatif, pas du réseau, ils avaient donc d’abord mal ajusté la cible.

La résolution fut moins spectaculaire : créer un test de trafic répétable, ajuster un réglage à la fois, valider avec des compteurs hardware, et garder le diagnostic VLAN séparé de l’optimisation de performance. Quand ils réintroduisirent les offloads sélectivement et vérifièrent MTU et tagging de bout en bout, la stabilité revint.

Leçon : le travail de performance change l’observabilité. Si vous ne pouvez pas le mesurer, vous ne pouvez pas y faire confiance. Surtout autour du tagging VLAN et du bridging.

La pratique ennuyeuse mais correcte qui a sauvé la mise : « Faites de l’état noyau votre test d’acceptation »

Une entreprise du secteur financier appliquait un contrôle des changements strict et leur réseau était notoirement conservateur. Leurs hôtes VM étaient basés sur Ubuntu, et ils avançaient lentement pour de bonnes raisons. Ils avaient aussi une habitude que j’aimerais voir plus répandue : valider l’état vivant du noyau après chaque application de configuration réseau, à chaque fois, avec une checklist.

Pendant un refresh, un nouveau template introduisit un changement Netplan subtil. Le YAML semblait « équivalent » à l’ancien, mais il ne définissait plus le bridge en comportement VLAN-aware. Le premier hôte a démarré et a immédiatement échoué les checks d’acceptation post‑config.

Parce qu’ils avaient décrit ce à quoi ressemblait un état « correct » — vlan_filtering 1, VLANs attendus présents sur les ports attendus, et un test ping taggé rapide — ils l’ont détecté avant que la charge de production ne bouge. Pas d’incident. Pas d’appels de minuit. Juste une étape de déploiement échouée et un ticket pour corriger le template.

Ils n’ont pas gagné de points pour la créativité. Ils ont gagné parce qu’ils ont été ennuyeux et justes.

Faits et contexte (pourquoi c’est déroutant en 2025)

Quelques faits courts et concrets et un peu d’histoire qui expliquent pourquoi les gens continuent de marcher sur ce râteau :

Le tagging 802.1Q VLAN ajoute un en‑tête de 4 octets aux trames Ethernet, insérant un ID VLAN et des bits de priorité.
Le bridging Linux est dans le noyau depuis des décennies, et il est plus proche d’un datapath de switch que la plupart le réalisent — jusqu’à ce que la politique VLAN entre en jeu.
Le support des bridges VLAN‑aware a mûri au fil du temps ; les anciennes configurations utilisaient souvent des sous‑interfaces VLAN parce que c’était plus facile à raisonner.
Le concept de « native VLAN » est principalement un comportement de port de switch ; dans les bridges Linux, le mécanisme analogue est le PVID et les flags d’ejection non taggée.
Netplan est un renderer, pas une pile réseau. Il génère des configs pour systemd-networkd ou NetworkManager, ce qui signifie que « j’ai changé le YAML » n’est pas la même chose que « le noyau a changé de comportement ».
systemd-networkd est strict et déterministe, ce qui est bon pour les serveurs. Cela signifie aussi qu’un booléen manquant peut silencieusement désactiver un ensemble de fonctionnalités.
La visibilité tcpdump peut être déformée par les offloads (TSO/GSO/GRO et offloads VLAN), donc les captures doivent être corroborées avec l’état du bridge et les compteurs.
Les tables VLAN du bridge sont par‑port ; il ne suffit pas « d’activer le VLAN 20 sur le bridge ». L’uplink et le port VM doivent tous deux l’autoriser.
Les bridges par VLAN sont un modèle ancien qui gagne encore en simplicité opérationnelle ; c’est verbeux, mais difficile à mal interpréter pendant un incident.

Listes de contrôle / plan pas à pas

Pas à pas : réparer un trunk VLAN cassé sur Ubuntu 24.04

Confirmer la topologie : identifier le nom du bridge (br0) et l’uplink physique (eno1).
Vérifier le filtrage VLAN : ip -d link show br0 ; si vlan_filtering 0, c’est votre première correction.
Lancer temporairement : ip link set dev br0 type bridge vlan_filtering 1.
Inspecter la table VLAN : bridge vlan show. Confirmer que les VLANs attendus existent.
Autoriser les VLANs sur l’uplink et les ports VM : bridge vlan add dev eno1 vid 20 et bridge vlan add dev vnet12 vid 20.
Vérifier PVID et réglages non taggés : assurez‑vous que le comportement « native » correspond à la configuration du switch.
Valider par capture : les tags doivent apparaître sur vnet et sur la NIC physique là où c’est approprié.
Rendre persistant : encoder dans Netplan ou networkd natif ; éviter les correctifs runtime uniquement.
Test de reboot : validez à nouveau après reboot ; ne faites pas confiance à une configuration tant qu’elle n’y survit pas.
Documenter l’état attendu : sauvegardez les sorties de ip -d link show br0 et bridge vlan show comme « known‑good ».

Checklist opérationnelle : à quoi ressemble un état « bon »

ip -d link show br0 affiche vlan_filtering 1.
bridge vlan show liste les VLANs attendus sur eno1 et sur chaque port VM concerné.
Le PVID est intentionnel, pas par défaut par accident.
L’ejection non taggée est définie uniquement là où vous le souhaitez.
tcpdump confirme que les tags traversent correctement l’hôte.
Un reboot ne change pas le comportement.

FAQ

1) Quel est le « paramètre bridge que la plupart oublient » ?

vlan_filtering sur le device bridge. Sans lui, les règles de forwarding VLAN‑aware ne sont pas appliquées comme on s’y attend quand on construit des trunks via un bridge Linux.

2) Comment vérifier si le filtrage VLAN est activé ?

Exécutez :

cr0x@server:~$ ip -d link show br0 | grep -o 'vlan_filtering [01]'
vlan_filtering 0

Si cela affiche vlan_filtering 0, votre bridge n’est pas VLAN-aware.

3) Si le filtrage VLAN est désactivé, les tags VLAN sont‑ils toujours supprimés ?

Pas toujours ; c’est pourquoi c’est déroutant. Les tags peuvent parfois sembler passer, selon la topologie et les attentes. Mais si vous comptez sur une appartenance VLAN par port et une politique de type trunk, vous voulez le mode VLAN‑aware. Sinon, vous déboguez un comportement qui n’est pas piloté par une politique.

4) Dois‑je configurer les VLANs à la fois sur l’uplink et sur le port VM ?

Oui, pour le bridging VLAN‑aware. Le VLAN doit être autorisé sur les ports d’ingress/egress qui le portent. Le trunk physique et le port vnet de la VM ont tous deux besoin d’appartenance pour ce VLAN.

5) Quelle est la différence entre PVID et « untagged » ?

Le PVID classe les trames entrantes non taggées dans un VLAN. « Egress untagged » décide si les trames pour ce VLAN sortent du port sans tag 802.1Q. Vous pouvez avoir un VLAN présent sans qu’il soit le PVID.

6) Dois‑je trunker les VLANs dans la VM, ou tagger à l’hôte ?

Choisissez une méthode par environnement et standardisez :

Tagguer à l’intérieur de la VM si la VM est un routeur/pare‑feu ou a besoin de plusieurs VLANs.
Tagger à l’hôte/hyperviseur si la VM doit être « une seule VLAN, NIC simple ».

Mélanger les deux approches aléatoirement est une excellente façon de créer des pannes « ça dépend ».

7) Pourquoi mon tcpdump n’affiche pas les tags VLAN dont je suis sûr ?

Les offloads peuvent changer ce que vous voyez dans les captures. Le traitement des tags VLAN peut être déchargé vers le matériel, et GRO/GSO peut coalescer des paquets. Utilisez l’état du bridge (bridge vlan show) et corroborez depuis plusieurs points de capture.

8) Open vSwitch est‑il une meilleure réponse ?

Parfois. Si vous avez besoin de fonctionnalités comme une politique avancée, une intégration tunneling, ou une observabilité plus riche au niveau du switch virtuel, OVS peut valoir le coût. Si votre besoin est « trunker des VLANs vers des VMs de façon fiable », le bridge Linux in‑kernel avec filtrage VLAN est généralement plus simple et plus rapide à déboguer.

9) Puis‑je corriger cela par un reboot ou un redémarrage des services réseau ?

Les reboots ne corrigent pas une configuration manquante ; ils ne font que rejouer ce que vous avez oublié. Utilisez les reboots pour vérifier la persistance, pas comme outil de réparation.

10) Quel est un bon test d’acceptation après des changements ?

Au minimum :

ip -d link show br0 et vérifier vlan_filtering 1
bridge vlan show et vérifier la présence des VLANs sur les ports pertinents
Capture ou test de connectivité taggé depuis une VM
Reboot et répéter les vérifications

Conclusion : prochaines étapes pratiques

Quand les VLANs « ne fonctionnent pas » sur des bridges Ubuntu 24.04, le chemin le plus rapide est d’arrêter les hypothèses et d’interroger le noyau. Vérifiez vlan_filtering. Vérifiez la table VLAN du bridge. Confirmez que le VLAN existe sur l’uplink et le port VM. Ce n’est qu’ensuite que vous devez commencer à débattre la configuration du switch.

Voici votre plan pour une fenêtre de changement :

Exécutez ip -d link show br0 et corrigez vlan_filtering en premier.
Exécutez bridge vlan show et assurez‑vous que l’appartenance VLAN est correcte par port.
Prouvez le forwarding avec un tcpdump à deux points (vnet + NIC physique).
Rendez‑le persistant dans le plan de contrôle choisi (Netplan ou networkd natif) et validez après reboot.

Une idée paraphrasée de Werner Vogels (ingénierie axée sur la fiabilité) : tout échoue éventuellement ; concevez de sorte que les défaillances soient prévues et récupérables (idée paraphrasée).