Proxmox VLAN ne fonctionne pas : configurer correctement un bridge compatible VLAN

Plan de diagnostic rapide

Si les VLAN « ne fonctionnent pas », vous pouvez perdre des heures à vous disputer avec l’équipe switch, l’équipe firewall et la personne qui « n’a que changé une description ». Ne le faites pas. Faites plutôt ceci. Vous recherchez le premier point où le tag est erroné, manquant ou supprimé.

Premier point : prouver la présence du tag sur le câble (côté hyperviseur)

1. Identifiez où la VM se connecte (tapez le port du bridge, pas votre intuition).
2. Capturez le trafic et inspectez les tags VLAN. Si les trames quittant le nœud sont non taguées alors qu’elles devraient l’être, arrêtez de blâmer le switch.
3. Confirmez que le bridge a le filtrage VLAN activé. Une case « VLAN aware » cochée mais non appliquée est un classique.

Second point : prouver que le port du switch est en trunk (et que le VLAN natif ne vous sabote pas)

1. Vérifiez les VLAN autorisés. « Trunk » ne suffit pas ; les trunks peuvent être restreints.
2. Vérifiez le VLAN natif. Si votre environnement suppose « pas de trames non taguées » mais que le port assigne le trafic non tagué au VLAN 1 (ou autre), vous venez de créer un trou noir silencieux.

Troisième point : validez les attentes de marquage du guest

1. Soit Proxmox marque pour le guest (définir le tag VLAN sur la NIC VM), soit le guest se marque lui-même (sous-interface VLAN dans la VM). Faire les deux produit un double-tagging et de la tristesse.
2. Confirmez que le DHCP est sur le bon VLAN. Beaucoup de « problèmes VLAN » sont en réalité des « relais DHCP non configurés là ».

Une citation pour garder la rigueur : L’espoir n’est pas une stratégie. — General Gordon R. Sullivan (souvent cité en exploitation). C’est brutal, mais ça vaut mieux que « je pense que ça devrait marcher ».

Modèle mental : où le marquage VLAN a réellement lieu

Le dépannage VLAN devient plus simple quand vous arrêtez de penser en termes de « VLANs sur un bridge » comme une magie, et que vous commencez à penser en termes de qui ajoute la balise 802.1Q et qui est censé la retirer.

Il n’y a que trois acteurs qui comptent

• Le guest (VM ou container). Il peut envoyer des trames taguées (sous-interfaces VLAN) ou des trames non taguées (NIC normale).
• L’hôte Proxmox. Il peut taguer/détaguer les trames selon la configuration de la NIC VM et les règles de filtrage du bridge, ou laisser passer les tags.
• Le port du switch. Il peut être en access (non tagué, un seul VLAN) ou en trunk (tagué, plusieurs VLANs, plus un VLAN natif/non tagué).

Tout le reste est décoration. Quand « VLAN ne fonctionne pas », un de ces acteurs ajoute un tag alors qu’il ne devrait pas, ne l’ajoute pas alors qu’il devrait, ou bloque le trafic parce qu’il voit un tag inattendu.

Réalité spécifique à Proxmox

Proxmox vous propose deux façons courantes de faire du bridging : le Linux bridge (par défaut) et Open vSwitch. Les deux fonctionnent. Le Linux bridge avec filtrage VLAN est parfaitement adapté pour la plupart des déploiements et a le moins d’éléments mobiles. Préférez-le sauf raison forte de faire autrement.

Bridge compatible VLAN dans Proxmox signifie : le bridge Linux a le filtrage VLAN activé de sorte que le bridge peut gérer l’appartenance VLAN par port, et Proxmox peut programmer ces règles VLAN en fonction des tags de NIC des VM.

Détail clé : un « tag VLAN » défini sur une NIC VM dans Proxmox n’est pas qu’un champ UI. Il transforme la NIC VM en un port access pour ce VLAN, mais sur un lien trunk en amont. L’hôte tague le trafic sortant sur l’uplink physique, et détague le trafic livré à la NIC du guest.

Le désalignement est la maladie. L’alignement est le remède.

Blague n°1 : les VLAN, c’est comme la politique de bureau — tout le monde jure que c’est simple jusqu’à ce qu’on demande qui possède le trunk et quel est le VLAN natif.

Faits intéressants et contexte historique

• Le marquage 802.1Q ajoute 4 octets à une trame Ethernet ; c’est pourquoi les VLAN et le MTU peuvent entrer en conflit de façon surprenante quand on frôle 1500.
• Le VLAN 1 est historiquement le défaut sur beaucoup de switchs ; le « VLAN natif » pointe souvent là, ce qui explique comment du trafic non tagué se retrouve silencieusement là où vous ne l’attendiez pas.
• Le filtrage VLAN du Linux bridge est devenu courant au milieu des années 2010 ; avant cela, beaucoup de configurations Linux utilisaient des sous-interfaces VLAN séparées (comme eth0.100) au lieu de règles VLAN par port.
• Proxmox a déplacé de nombreux utilisateurs de la « configuration réseau Debian manuelle » vers un modèle opinionné où l’UI écrit /etc/network/interfaces. Cela a amélioré la cohérence — et créé de nouvelles façons d’avoir raison avec confiance.
• Les offloads matériels (notamment VLAN offload) peuvent faire mentir les captures de paquets si vous capturez sur la mauvaise interface ; parfois le noyau voit des tags que tcpdump n’affiche pas, ou l’inverse.
• Le Q-in-Q (802.1ad) existe pour le « double-tagging », mais la plupart des environnements SMB/entreprise de virtualisation ne font pas de provider bridging. Un double-tagging accidentel ressemble à du Q-in-Q, mais ce n’est pas volontaire et est généralement rejeté.
• Bridges et bonds ont une relation longue et parfois chaotique dans le réseau Linux ; certains « problèmes VLAN » sont en réalité des problèmes de mode de bond / mismatch LACP qui se manifestent par des pertes de paquets sélectives.
• Spanning Tree a été conçu pour prévenir les boucles dans les réseaux pontés ; un STP mal configuré peut ressembler à une panne VLAN car le trafic est bloqué, pas perdu.

Schémas de configuration corrects (et quand les utiliser)

Schéma A : « Trunk vers l’hôte, Proxmox tague par NIC VM » (recommandé)

C’est le schéma de production propre pour la plupart des clusters Proxmox. Le port switch vers le nœud est en trunk. Le Linux bridge est compatible VLAN. Chaque NIC VM reçoit un tag VLAN dans Proxmox. Les guests croient être sur un réseau Ethernet classique. La vie est belle.

À utiliser quand : vous voulez des guests simples à configurer, un contrôle centralisé des VLAN et moins d’énigmes du type « pourquoi cette VM utilise le VLAN 200 ? ».

Éviter quand : vous avez besoin que le guest voie plusieurs VLANs sur une seule vNIC (par exemple un VM routeur, firewall). Dans ce cas, préférez le passage de tags.

Exemple /etc/network/interfaces

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.10.10.11/24
        gateway 10.10.10.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

La ligne bridge-vlan-aware yes est essentielle. bridge-vids 2-4094 indique au bridge quels IDs VLAN sont autorisés sur ce bridge. Si vous l’omettez, Proxmox fonctionne encore dans de nombreux cas parce qu’il programme dynamiquement l’appartenance VLAN, mais en production je préfère être explicite. C’est une raison de moins de se demander « pourquoi le VLAN 3000 ne passe pas ? ».

Schéma B : « Trunk vers l’hôte, le guest se tague lui-même » (passage de tag)

Ici vous voulez que la VM reçoive des trames taguées et crée des sous-interfaces VLAN à l’intérieur du guest. C’est ainsi que l’on construit une VM routeur, firewall, des nœuds Kubernetes qui font des astuces CNI, ou des appliances qui attendent un trunk.

Configuration Proxmox : vous laissez le tag de la NIC VM sur « sans tag » (vide / 0 selon l’UI). Le bridge doit tout de même être VLAN-aware si vous voulez du filtrage et éviter des fuites accidentelles ; mais vous le configurez pour autoriser les VLANs sur ce port.

Mode d’échec : si vous définissez un tag dans Proxmox et que vous taguez à l’intérieur du guest, vous créez un double-tagging. La plupart des ports switch ne le laisseront pas passer. Votre capture ressemblera à de l’art moderne.

Schéma C : « Port access vers l’hôte, un seul VLAN » (non recommandé mais existant)

C’est ce que font les gens quand ils ne contrôlent pas le switch ou qu’ils « testent juste ». Le port switch est en access sur un VLAN. Le bridge Proxmox n’est pas VLAN-aware (ou peut l’être, mais c’est inutile ici). Chaque VM connectée à ce bridge atterrit dans le même VLAN à moins de commencer à faire des sous-interfaces VLAN sur l’hôte.

À utiliser quand : laboratoires, nœuds à usage unique, ou environnements de fournisseur où le VLAN d’accès est le service.

Éviter quand : vous tenez à l’échelle, à la segmentation multi-tenant, ou à la santé mentale de votre futur vous.

Schéma D : « Bond (LACP) + trunk + bridge compatible VLAN » (courant en clusters)

La plupart des clusters font un bond de deux NICs pour redondance et débit, puis posent un bridge VLAN-aware dessus. C’est correct. Mais cela ajoute des modes de panne supplémentaires : LACP non négocié, hashing provoquant des problèmes asymétriques, ou un port switch configuré en standalone tandis que l’hôte attend LACP.

Bonne pratique : restez simple. Bond en 802.3ad si votre équipe réseau le supporte et le configurera correctement ; sinon utilisez active-backup et dormez tranquille.

Blague n°2 : LACP, c’est génial jusqu’à ce que ça ne le soit plus ; ensuite c’est un système distribué à deux nœuds et trois avis.

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

Vous ne dépannez pas les VLANs avec des intuitions. Vous les dépannez avec des observations. Ci‑dessous des contrôles éprouvés qui répondent à « qu’est-ce qui est vrai maintenant ? » et ce qu’il faut faire ensuite.

Tâche 1 : Confirmer que Proxmox pense que le bridge est VLAN-aware

cr0x@server:~$ grep -A10 -n "iface vmbr0" /etc/network/interfaces
12:iface vmbr0 inet static
13-        address 10.10.10.11/24
14-        gateway 10.10.10.1
15-        bridge-ports eno1
16-        bridge-stp off
17-        bridge-fd 0
18-        bridge-vlan-aware yes
19-        bridge-vids 2-4094

Ce que ça signifie : Si bridge-vlan-aware yes est absent, Proxmox ne peut pas appliquer le filtrage VLAN par port comme vous l’attendez.

Décision : Si manquant, ajoutez-le (et idéalement bridge-vids), puis rechargez le réseau lors d’une fenêtre de maintenance.

Tâche 2 : Vérifier que le filtrage VLAN est réellement activé dans le bridge noyau

cr0x@server:~$ bridge link show
2: eno1 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
3: tap100i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
4: fwpr100p0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0

cr0x@server:~$ bridge vlan show
port              vlan-id
eno1              1 PVID Egress Untagged
eno1              100
tap100i0          100 PVID Egress Untagged
fwpr100p0         100 PVID Egress Untagged

Ce que ça signifie : Vous recherchez l’appartenance VLAN par port. Si bridge vlan show est vide ou n’affiche que VLAN 1 partout, le bridge ne filtre pas comme vous le pensiez.

Décision : Si la VM doit être dans le VLAN 100 et que son port tap n’est pas PVID 100, corrigez le tag de la NIC VM ou la configuration VLAN du bridge.

Tâche 3 : Vérifier la configuration NIC VM dans Proxmox (mode de marquage)

cr0x@server:~$ qm config 100 | egrep "net0|bridge|tag|trunks"
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,tag=100,firewall=1

Ce que ça signifie : Cette NIC VM est un port access pour le VLAN 100. Le guest ne doit pas créer de sous-interfaces VLAN pour cette NIC.

Décision : Si le guest tague aussi, supprimez la config VLAN dans le guest ou supprimez le tag Proxmox et configurez le trunk correctement.

Tâche 4 : Valider que l’uplink physique est up, à la bonne vitesse, et n’a pas de flapping

cr0x@server:~$ ip -br link show eno1
eno1             UP             5c:ba:ef:00:11:22 <BROADCAST,MULTICAST,UP,LOWER_UP>

cr0x@server:~$ ethtool eno1 | egrep "Speed|Duplex|Link detected"
Speed: 10000Mb/s
Duplex: Full
Link detected: yes

Ce que ça signifie : Le lien est up. Si vous voyez des baisses de vitesse ou du flapping, vous pouvez courir après des fantômes VLAN pendant que la couche physique brûle.

Décision : Si le lien est instable, arrêtez-vous et corrigez le câblage/SFP/erreurs du port switch en amont.

Tâche 5 : Vérifier les erreurs côté switch et les drops sur l’hôte

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 5c:ba:ef:00:11:22 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    987654321  1234567      0     124       0  45678
    TX:  bytes packets errors dropped carrier collsns
    876543210  1122334      0       0       0       0

Ce que ça signifie : Des paquets RX dropped peuvent venir de congestion, limites de ring buffer ou policing en amont. Ce n’est pas la preuve d’un problème VLAN, mais c’est un signal d’alerte.

Décision : Si les drops augmentent pendant les tests, investiguez la congestion du port switch, le driver NIC et les mismatches MTU.

Tâche 6 : Confirmer le MTU du bridge et considérer l’overhead VLAN

cr0x@server:~$ ip -d link show vmbr0 | egrep "mtu|vlan|bridge"
2: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    bridge vlan_filtering 1 vlan_default_pvid 1

Ce que ça signifie : Le filtrage VLAN est activé (vlan_filtering 1). MTU est 1500, ce qui convient pour la plupart des réseaux VLAN mais peut vous pénaliser si votre environnement attend des jumbo frames de bout en bout.

Décision : Si vous utilisez MTU 9000 pour des réseaux de stockage/vMotion, imposez un MTU cohérent sur la NIC, le bridge et le trunk du switch.

Tâche 7 : tcpdump sur l’uplink pour voir les tags VLAN (ou leur absence)

cr0x@server:~$ tcpdump -eni eno1 -c 10 vlan
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:01:11.123456 5c:ba:ef:00:11:22 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 100, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: DHCP, Request
10:01:11.223456 00:11:22:33:44:55 > 5c:ba:ef:00:11:22, ethertype 802.1Q (0x8100), length 370: vlan 100, p 0, ethertype IPv4, 10.10.100.1.67 > 10.10.100.50.68: DHCP, Reply

Ce que ça signifie : Vous pouvez littéralement voir le VLAN 100 sur le câble. Cela répond immédiatement à « l’hôte marque-t-il et reçoit-il correctement ? »

Décision : Si vous ne voyez pas de tags VLAN sortir de l’hôte, concentrez-vous sur la configuration du bridge/ de la NIC VM. Si vous voyez des tags sortir mais rien ne revient, concentrez-vous sur le trunk du switch et le L2/L3 en amont.

Tâche 8 : tcpdump sur l’interface tap de la VM pour confirmer la livraison non taguée au guest

cr0x@server:~$ tcpdump -eni tap100i0 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tap100i0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:02:01.100001 de:ad:be:ef:10:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 328: 0.0.0.0.68 > 255.255.255.255.67: DHCP, Request
10:02:01.200002 00:11:22:33:44:55 > de:ad:be:ef:10:00, ethertype IPv4 (0x0800), length 352: 10.10.100.1.67 > 10.10.100.50.68: DHCP, Reply

Ce que ça signifie : Pas d’802.1Q ici. C’est attendu quand Proxmox fait le marquage et que le guest est en « access VLAN ».

Décision : Si vous voyez des tags 802.1Q sur le tap alors que vous ne les attendez pas, vous avez configuré le passage de tag ou le guest marque de façon inattendue.

Tâche 9 : Vérifier que le firewall Proxmox ne bloque pas ce que vous pensez être du « trafic VLAN »

cr0x@server:~$ pve-firewall status
Status: enabled/running

cr0x@server:~$ pve-firewall compile
root@pam: OK

Ce que ça signifie : Le firewall est actif et compile. Le VLAN en soi n’est pas « bloqué par le firewall », mais DHCP, ARP ou ICMP peuvent l’être.

Décision : Désactivez temporairement le firewall sur la NIC VM (pas globalement) pour isoler. Si cela résout le problème, vous avez des règles à revoir — ce n’était pas un problème VLAN.

Tâche 10 : Valider la résolution ARP dans le namespace de l’hôte (vérification L2 rapide)

cr0x@server:~$ ip neigh show dev vmbr0 | head
10.10.10.1 lladdr 00:aa:bb:cc:dd:ee REACHABLE
10.10.10.50 lladdr de:ad:be:ef:10:00 STALE

Ce que ça signifie : L’hôte voit des voisins sur vmbr0 (probablement le VLAN de management). Cela ne prouve pas que le VLAN 100 fonctionne, mais ça prouve que le bridge est vivant et effectue du L2.

Décision : Si la table de voisins est vide et que vous ne pouvez même pas ARP en management, réparez la connectivité de base avant de travailler les VLANs.

Tâche 11 : En mode trunk-vers-guest, confirmer que le guest voit des VLANs tagués (côté hôte)

cr0x@server:~$ qm config 200 | egrep "net0|tag"
net0: virtio=DE:AD:BE:EF:20:00,bridge=vmbr0,firewall=0

cr0x@server:~$ tcpdump -eni tap200i0 -c 5 vlan
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tap200i0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:03:11.010101 de:ad:be:ef:20:00 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 200, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: DHCP, Request

Ce que ça signifie : Le tap voit des tags VLAN, ce qui est attendu quand le guest est en trunking/tagging.

Décision : Si vous attendez le mode trunk mais ne voyez aucun tag VLAN, le guest ne tague pas, ou Proxmox retire les tags à cause d’une config non intentionnelle.

Tâche 12 : Vérifier l’état du bond si vous en utilisez un (sanity LACP/active-backup)

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
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: fast
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 2
        Actor Key: 17
        Partner Key: 42
        Partner Mac Address: 00:25:90:12:34:56

Slave Interface: eno1
MII Status: up
Actor Churn State: none
Partner Churn State: none

Slave Interface: eno2
MII Status: up
Actor Churn State: none
Partner Churn State: none

Ce que ça signifie : LACP a négocié et les deux esclaves sont up. Si Partner Key/MAC manque ou si un seul esclave est actif de façon inattendue, la config du port-channel en amont peut être incorrecte.

Décision : Corrigez l’alignement LACP/port-channel avant de poursuivre le VLAN. Un bond cassé peut faire disparaître certains VLANs « aléatoirement » selon le hashing et le comportement amont.

Tâche 13 : Confirmer que Proxmox a appliqué la configuration (pas d’état runtime obsolète)

cr0x@server:~$ ifreload -a
warning: vmbr0: interface is already configured
warning: eno1: interface is already configured

Ce que ça signifie : Le reload a eu lieu ; les warnings peuvent être normaux. Ce que vous voulez : pas d’erreurs fatales, et l’état runtime qui correspond au fichier.

Décision : Si le reload échoue ou si vous en avez peur, planifiez une fenêtre de maintenance et redémarrez le réseau prudemment. Ne faites pas ça à l’aveugle en distant sauf si vous aimez les sessions console surprises.

Tâche 14 : Vérifier d’éventuels sysctl ou nftables liés aux VLAN (rare mais réel)

cr0x@server:~$ sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.bridge.bridge-nf-call-arptables
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-arptables = 1

Ce que ça signifie : Le trafic ponté passe dans les hooks iptables/nftables. Cela peut être voulu (filtrage) ou désastreux (drops/latence inattendus).

Décision : Si vous ne filtrez pas intentionnellement le trafic ponté, envisagez de désactiver ces options ou auditez les règles de firewall attentivement. « VLAN cassé » signifie parfois « netfilter du bridge a mangé le DHCP ».

Trois mini-récits d’entreprise des tranchées VLAN

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

Une entreprise de taille moyenne consolidait des racks. L’équipe virtualisation a déplacé un nœud Proxmox d’un ancien stack de switches vers un nouveau leaf. L’équipe réseau a dit : « Le port est trunk, vous êtes bon. » Le nœud Proxmox est monté, le management fonctionnait, mais tous les VLANs tenant de ce nœud étaient morts.

L’équipe virtualisation a supposé que « trunked » signifiait « tous les VLANs autorisés ». Sur le nouveau template de switch, les trunks étaient restreints à une petite liste d’autorisation par défaut. Le VLAN management était inclus (parce que tout a besoin de management), mais les VLANs tenants ne l’étaient pas. L’hôte a tagué les trames comme prévu ; le switch les a patiemment rejetées. Les deux côtés ont fait ce qui était raisonnable.

Ça s’est empiré parce que le symptôme était sélectif : certaines VMs du nœud pouvaient parler à des « services partagés » qui se trouvaient accidentellement dans le VLAN management, donc les propriétaires d’apps signalaient des problèmes « intermittents ». Quelqu’un a même suggéré « Proxmox est bogué avec les VLANs. » Ce n’était pas le cas.

La correction fut banale : aligner la liste des VLANs autorisés avec la plage VLAN prévue pour l’hyperviseur, et documenter. L’action post-mortem utile n’était pas « améliorer la supervision ». C’était « arrêter d’employer le mot trunk sans préciser la liste VLAN autorisée et le comportement du VLAN natif ».

Mini-récit 2 : L’optimisation qui a échoué

Une autre organisation voulait réduire la « complexité réseau ». Ils ont décidé que chaque nœud Proxmox aurait un seul bond, et que chaque bridge n’autoriserait qu’une liste restreinte de VLANs : seulement ceux actuellement utilisés. L’idée était de réduire le rayon d’action si une VM était mal taguée.

Ça a fonctionné—jusqu’à ce que ça ne fonctionne plus. Un nouveau projet a démarré sur le VLAN 240, et l’équipe VM a correctement tagué la NIC dans Proxmox. Mais bridge-vids sur vmbr0 n’autorisait que 2–239. Le Linux bridge a filtré le VLAN avant même qu’il n’atteigne le switch. Du point de vue du switch, rien ne se passait. Du point de vue de Proxmox, rien n’était « cassé ». Du point de vue de la VM, l’univers était silencieux.

Le ticket a rebondi entre équipes car chacun vérifiait sa couche : la configuration VM avait tag=240, le trunk switch autorisait VLAN 240, le firewall avait des règles, DHCP était prêt. La pièce manquante était que le bridge de l’hôte avait été « optimisé » pour exclure des VLANs futurs.

Ils ont conservé le filtrage VLAN (bien), mais changé la politique : autoriser une large plage VLAN sur les uplinks des nœuds, et contrôler l’accès VLAN des VM via les permissions et la revue Proxmox. La sécurité par liste d’autorisation obsolète n’est pas de la sécurité. C’est une bombe à retardement.

Mini-récit 3 : La pratique ennuyeuse qui a sauvé la situation

Une équipe de services financiers gérait Proxmox avec un contrôle de changement strict. Chaque nœud avait une configuration réseau standard : bond0 (active-backup), vmbr0 pour management, vmbr1 trunk VLAN-aware pour les guests, et une petite « VM de validation réseau » présente sur chaque nœud. Cette VM pouvait lancer des requêtes DHCP, pinguer des gateways, et émettre des trames taguées à la demande.

Un matin, tout un rack a perdu la connectivité pour le VLAN 310 seulement. Pas le management, pas d’autres VLANs. Les logs du switch étaient bruyants mais non conclusifs. On a commencé à suspecter un changement d’ACL au cœur.

Le SRE de garde a utilisé la VM de validation sur deux nœuds : un dans le rack affecté, un dans un rack sain. Même tag VLAN, même test DHCP, même cible de ping. Les captures sur les uplinks physiques ont montré que le rack affecté ne recevait jamais de réponses — pas d’Offer DHCP, pas de réponse ARP — tandis que le rack sain oui.

Cette preuve a réduit le rayon d’action à « quelque part entre le ToR et l’amont » en quelques minutes. L’équipe switch a trouvé un membre de port-channel avec une config obsolète qui n’autorisait pas le VLAN 310. Comme le bond était en active-backup, basculer vers le lien actif correct a déplacé le trafic vers le membre correctement configuré et restauré le service rapidement.

La pratique ennuyeuse était : configurations standardisées, une petite VM de validation, et l’habitude de capturer les paquets en bordure. Ce n’était pas glamour. C’était efficace, et c’est mieux.

Erreurs courantes : symptôme → cause racine → correction

1) Pas de DHCP sur une VM taguée VLAN, mais le lien est up

Symptôme : La NIC VM est « connectée », mais le DHCP expire. Les pings échouent.

Cause racine : Le port switch est en access VLAN (ou le trunk manque le VLAN) alors que Proxmox tague les VLANs, donc les trames taguées sont rejetées.

Correction : Configurez le port switch en trunk et autorisez le VLAN. Confirmez avec tcpdump -eni eno1 vlan que les réponses arrivent.

2) La VM parle sur le mauvais réseau (connectivité surprise)

Symptôme : Une VM destinée au VLAN 200 obtient une IP du VLAN 1 ou du VLAN management.

Cause racine : Mismatch de VLAN natif / PVID : le trafic non tagué est mappé vers un VLAN inattendu quelque part (hôte ou switch).

Correction : Décidez ce que signifie non tagué. Préférez « pas de non tagué » sur les trunks en production. Assurez-vous que l’uplink vmbr n’utilise pas VLAN 1 comme PVID sauf si c’est intentionnel.

3) Un seul VLAN fonctionne ; les autres sont morts

Symptôme : Le VLAN 100 fonctionne, le VLAN 200 ne fonctionne pas, sur le même hôte/uplink.

Cause racine : Liste de VLANs autorisés sur le trunk restreinte, ou bridge-vids exclut le VLAN.

Correction : Vérifiez bridge vlan show et la liste d’autorisation du trunk switch. Élargissez l’ensemble autorisé et retestez.

4) « Problèmes VLAN intermittents » sur des uplinks bondés

Symptôme : Pertes de paquets aléatoires, certains flux fonctionnent, d’autres non ; pire sous charge.

Cause racine : Mismatch LACP ou membres du port-channel mal configurés avec des VLANs autorisés / VLAN natif / MTU différents.

Correction : Validez l’état du bond dans /proc/net/bonding/* et assurez-vous que les membres du port-channel switch sont identiques. N’acceptez pas « presque identiques ».

5) Les captures montrent aucun tag VLAN alors que vous avez mis tag=100

Symptôme : tcpdump sur eno1 n’affiche pas d’802.1Q.

Cause racine : Confusion liée aux offloads VLAN / point de capture, ou le trafic ne sort jamais parce que le filtrage du bridge le bloque.

Correction : Capturez à la fois sur le tap et sur l’uplink physique ; vérifiez bridge vlan show. Si besoin, désactivez temporairement le VLAN offload (pendant le diagnostic) et retestez.

6) Les guests sur le même VLAN ne peuvent pas se parler

Symptôme : Deux VMs sur le VLAN 300 peuvent atteindre la gateway parfois, mais pas de façon fiable entre elles.

Cause racine : Règles firewall Proxmox, ebtables/nft filtering, ou STP/protection boucle bloquant le switching intra-hôte.

Correction : Désactivez temporairement le firewall VM, confirmez que le L2 fonctionne, puis réintroduisez les règles prudemment. Vérifiez les sysctls bridge netfilter.

7) Les containers (LXC) se comportent différemment des VMs

Symptôme : La VM taguée VLAN fonctionne ; le container tagué VLAN ne fonctionne pas (ou inversement).

Cause racine : Le container utilise un comportement d’interface virtuel différent, et vous pouvez taguer au mauvais niveau (config container vs port du bridge).

Correction : Standardisez : soit taguez côté veth hôte, soit à l’intérieur du container, pas les deux, et confirmez avec bridge vlan show.

8) Migration vers un autre nœud casse le réseau de la VM

Symptôme : La VM fonctionne sur le nœud A, échoue sur le nœud B.

Cause racine : Config réseau incohérente entre nœuds : bridge non VLAN-aware, bond/trunk différent, VLANs manquants dans la liste autorisée.

Correction : Traitez le réseau Proxmox comme une configuration de niveau cluster. Même noms de vmbr, mêmes réglages VLAN-aware, même comportement de trunk physique partout.

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

Étape par étape : Construire un bridge VLAN-aware correct sur un uplink unique

1. Décidez du modèle : l’hôte tague par NIC VM (recommandé) ou le guest se tague lui-même (trunk-to-guest). Écrivez-le. Ça évite le double-tagging.
2. Configurez le port switch : trunk, autorisez les VLANs que vous utiliserez, définissez le VLAN natif explicitement (ou désactivez effectivement le non tagué). Gardez le MTU cohérent.
3. Configurez le bridge Proxmox : Linux bridge avec bridge-vlan-aware yes. Optionnellement définissez bridge-vids sur une plage raisonnable.
4. Attachez les NICs VM : en mode access, mettez tag=VLANID sur chaque NIC VM. En mode trunk-to-guest, laissez le tag vide.
5. Validez avec des captures : confirmez les tags sur l’uplink physique, et la livraison non taguée sur le tap pour les VMs en access.
6. Verrouillez la cohérence : répliquez sur tous les nœuds. L’incohérence est la façon dont les migrations deviennent des pannes.

Checklist : Avant de blâmer les VLANs

• Le lien physique est-il stable ? (ethtool, ip -s link)
• Le bridge filtre-t-il réellement les VLANs ? (bridge vlan show)
• La NIC VM est-elle taguée à un seul endroit exactement ? (Proxmox ou guest)
• Le trunk du switch autorise-t-il le VLAN ? (pas seulement « est-ce trunk ? »)
• Voyez-vous des Offer DHCP / réponses ARP sur la capture uplink ?
• Le MTU est-il cohérent de bout en bout pour le VLAN ?
• Le filtrage firewall ponté n’a-t-il pas mangé le trafic ?

Checklist : Procédure de changement sûre pour les nœuds de production

• Planifiez une fenêtre si vous touchez bridge-ports, des bonds ou rechargez le réseau.
• Ayez un accès console hors bande prêt. Les changements réseau en remote only sont une option de vie.
• Changez une variable à la fois : liste d’autorisation trunk switch, puis bridge hôte, puis tags VM.
• Capturez avant/après sur l’uplink physique. C’est votre sérum de vérité.
• Après changements, testez : DHCP, ping gateway, ping entre VMs, et une petite session TCP.

FAQ

1) Ai-je besoin d’Open vSwitch pour que les VLANs fonctionnent dans Proxmox ?

Non. Le Linux bridge avec VLAN-aware activé suffit pour la plupart des déploiements. OVS est utile si vous avez besoin de ses fonctionnalités ou de son modèle opérationnel, pas comme pansement pour les VLANs.

2) Que change réellement « VLAN aware » ?

Ça active le filtrage VLAN sur le Linux bridge, permettant l’appartenance VLAN par port et laissant Proxmox programmer le comportement access/trunk par NIC VM.

3) Dois-je mettre bridge-vids 2-4094 ?

En production, oui — sauf raison de restreindre. Cela évite des problèmes du type « VLAN ne passe pas parce qu’il est hors de la plage autorisée » quand quelqu’un ajoute un VLAN plus tard.

4) Pourquoi ma VM perd-elle la connectivité après une migration à chaud ?

Le nœud de destination a probablement des paramètres bridge VLAN différents, une liste d’autorisation trunk différente en amont, ou un mapping vmbr différent. Rendre la configuration réseau identique entre nœuds pour les workloads migrés.

5) Où doit avoir lieu le marquage VLAN : dans Proxmox ou dans le guest ?

Choisissez un seul endroit. Pour les VMs normales, marquez dans Proxmox (plus simple, contrôle centralisé). Pour des VMs routeur/firewall/appliance qui ont besoin de plusieurs VLANs, marquez à l’intérieur du guest et laissez passer le trunk.

6) Pourquoi tcpdump n’affiche-t-il parfois pas les tags VLAN alors que je les attends ?

L’offload VLAN peut faire que les tags soient gérés en matériel, rendant les captures confuses selon l’interface et le driver. Capturez à plusieurs points (tap et physique) et corrélez avec bridge vlan show.

7) Le firewall Proxmox peut-il casser le DHCP sur un VLAN ?

Oui. Le DHCP génère beaucoup de broadcasts et est sensible au filtrage. Si le trafic ponté passe par netfilter, une règle peut bloquer DHCP ou ARP et faire croire que « le VLAN est cassé ».

8) Les VLANs nécessitent-ils un MTU plus élevé ?

Pas nécessairement. Le MTU standard 1500 fonctionne avec le marquage VLAN dans la plupart des environnements. Les problèmes apparaissent quand vous utilisez des jumbo frames et qu’un lien du chemin n’a pas le même MTU.

9) Mon switch dit que le port est en trunk, mais le VLAN échoue quand même. Que dois-je demander ?

Demandez : la liste des VLANs autorisés, le VLAN natif, et la confirmation que tous les membres du port-channel ont des réglages VLAN/MTU identiques. « C’est un trunk » n’est pas une réponse.

10) Est‑il sûr de faire circuler le trafic de management sur le même bridge VLAN-aware que les guests ?

Cela peut être fait, mais ce n’est pas ma préférence. Séparez le management (vmbr0) des trunks invités (vmbr1) quand c’est possible. Ça réduit le rayon d’action et rend le dépannage moins cinématique.

Conclusion : prochaines étapes pour éviter la récidive

Corriger un problème VLAN Proxmox n’est que rarement une histoire de « bon réglage magique ». Il s’agit de rendre explicite le contrat de marquage : qui marque, où c’est autorisé, et ce que signifie non tagué. Une fois que vous pouvez montrer une capture et dire « ceci est le VLAN 100 quittant l’hôte », les disputes s’arrêtent et l’ingénierie peut reprendre.

Faites ceci ensuite :

1. Standardisez le réseau des nœuds sur tout le cluster (mêmes noms de vmbr, mêmes réglages VLAN-aware et même comportement de bond).
2. Documentez les attentes des trunks switch en langage opérationnel : VLANs autorisés, VLAN natif, MTU, politique LACP.
3. Ajoutez une routine de validation répétable : une VM connue ou un script capable de DHCP/ping sur un VLAN spécifié, plus une recette de capture.
4. Rendez le double-tagging difficile par politique : soit Proxmox tague les VLANs access, soit le guest fait du trunking — jamais les deux.

Si vous ne faites rien d’autre, retenez ceci : le dépannage VLAN consiste à vérifier si le tag que vous imaginez est bien le tag réellement présent sur le câble.