VLAN Proxmox ne fonctionne pas : trunks, étiquetage du bridge Linux et corrections du « pas de réseau »

Le modèle mental qui évite les suppositions

Quand les VLAN « ne fonctionnent pas » dans Proxmox, ce n’est rarement mystérieux. Il s’agit généralement d’un de ces cas :

• Les trames ne sont pas taguées quand vous le pensez. La VM envoie sans tag, le bridge attend des tags, ou l’inverse.
• Les trames sont taguées, mais rejetées. La table VLAN du bridge, la liste des VLAN autorisés du switch, ou une ACL montante les abandonne.
• Les trames passent, mais L2/L3 se casse. L’ARP ne reçoit pas de réponse, la passerelle est sur un VLAN différent, ou vous subissez un routage asymétrique.
• Tout fonctionne… jusqu’à ce que ça ne fonctionne plus. Un reboot change l’ordre des interfaces, le filtrage VLAN se bascule, LACP renégocie, ou le template du port switch « remet en place » la config.

Pensez en couches, pas en impressions :

1. L1 : lien, vitesse/duplex, optiques, état du bonding.
2. L2 : tags VLAN, table VLAN du bridge, apprentissage MAC, état STP.
3. L3 : adressage IP, passerelle, ARP/ND, routage, firewall.

Proxmox complique cela car il mêle le réseau de l’hôte (management, stockage) et le commutateur des guests (interfaces VM). Les bridges Linux sont de vrais commutateurs avec de vraies tables de forwarding. Traitez‑les comme tels.

Une citation à garder : « L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan. Le réseau ne récompense pas l’optimisme.

Playbook de diagnostic rapide (premier/deuxième/tiers)

Premier : prouver si les tags existent sur le câble

Votre premier travail est d’arrêter de théoriser et d’observer la réalité.

• Sur l’hôte Proxmox, lancez tcpdump sur la NIC physique ou le bond et cherchez vlan dans les trames.
• Si les tags manquent : c’est un problème de config Proxmox/bridge/VM.
• Si les tags sont présents : c’est un problème de trunk/allowed VLAN/PVID sur le switch, ou une politique montante.

Deuxième : confirmer le filtrage VLAN du bridge et l’appartenance

Les bridges Linux peuvent ignorer les tables VLAN (mode classique) ou les appliquer (VLAN-aware). Mélanger les attentes provoque un « pas de réseau » malgré des configs propres en apparence.

• Vérifiez vlan_filtering sur le bridge et l’appartenance VLAN par port.
• Vérifiez quel port est l’uplink, quel est le tap VM, et quels IDs VLAN sont autorisés.

Troisième : valider les bases L3 et les éléments ennuyeux

Une fois L2 correct, les échecs restants sont généralement :

• Mauvaise passerelle ou masque dans le guest.
• Échec ARP dû au firewall, adresse IP dupliquée, ou appareil upstream répondant sur le mauvais VLAN.
• Incompatibilité MTU — particulièrement avec VLAN + bond + réseaux de stockage.

Si vous ne retenez qu’une chose : le chemin le plus rapide est « le tag est‑il présent ? » → « est‑il autorisé ? » → « l’ARP obtient‑il une réponse ? »

Faits et contexte intéressants (oui, ça compte)

Ce ne sont pas des anecdotes pour le plaisir. Chacun correspond à un mode de défaillance réel que j’ai vu en production.

1. Le tag 802.1Q ajoute 4 octets à une trame Ethernet. Ce petit en‑tête explique pourquoi les problèmes MTU surviennent « seulement sur les VLANs ».
2. Le bridging Linux existe depuis des décennies et précède beaucoup d’enveloppes modernes « SDN ». Sous Proxmox, c’est toujours le noyau Linux qui commute.
3. Le mode bridge VLAN-aware est relativement récent par rapport au bridging classique et se comporte comme un switch géré : si un VLAN n’est pas dans la table, il peut être silencieusement rejeté.
4. Le concept de « native VLAN » est une convention de switch, pas une fonctionnalité VLAN. Des native VLANs mal alignés font atterrir le trafic non tagué au mauvais endroit sans erreur.
5. Les premières implémentations VLAN visaient souvent à contenir les broadcasts, pas la sécurité. Aujourd’hui, on traite les VLANs comme des zones de sécurité ; ce n’est vrai que si vous appliquez une politique L3/L4.
6. LACP ne fait pas du « load balance » par paquet par défaut sur beaucoup de systèmes ; il hash les flux. D’où le « une VM lente, une autre OK » sur des trunks bondés.
7. STP et VLANs sont liés : selon le mode du switch (PVST/RPVST/MST), un VLAN peut être bloqué pendant que d’autres sont en forwarding, créant des cas « seul le VLAN 30 est mort ».
8. ARP est bavard et fragile. Beaucoup d’incidents « VLAN cassé » sont en réalité des réponses ARP filtrées par un firewall hôte, une sécurité switch ou des IP dupliquées.
9. Proxmox utilisait historiquement une config de style ifupdown ; les systèmes récents utilisent ifupdown2 et peuvent appliquer des changements à chaud, mais tous les changements ne sont pas sûrs sans fenêtre de maintenance.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les tâches que j’exécute, approximativement dans cet ordre, quand une VM affiche « pas de réseau » sur un VLAN. Chaque entrée inclut : commande, ce que signifie une sortie typique, et la décision suivante.

Task 1: Confirm the host sees link and which NIC is which

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp3s0           UP             3c:ec:ef:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>
enp4s0           DOWN           3c:ec:ef:11:22:34 <BROADCAST,MULTICAST>
bond0            UP             3c:ec:ef:aa:bb:cc <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP>
vmbr0            UP             3c:ec:ef:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP>

Sens : bond0 et vmbr0 sont up ; une NIC physique est down. Si vous pensiez avoir deux liens actifs, non.

Décision : Réparez l’état du lien/bond avant de toucher la config VLAN. Déboguer VLAN sur un uplink instable est de l’auto‑dommage.

Task 2: Check bonding health (LACP vs active-backup and which slave is active)

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

Slave Interface: enp3s0
MII Status: up
Actor Churn State: churned
Partner Churn State: churned

Slave Interface: enp4s0
MII Status: down

Sens : LACP est configuré, mais un esclave est down et les états churn indiquent des renégociations.

Décision : Vérifiez la config LACP côté switch et le câblage. Si le switch attend un trunk statique mais l’hôte fait du LACP, vous aurez des bizarreries VLAN intermittentes.

Task 3: Inspect Proxmox network config (source of truth)

cr0x@server:~$ sed -n '1,200p' /etc/network/interfaces
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
        bond-slaves enp3s0 enp4s0
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4

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

Sens : bridge VLAN-aware activé ; l’uplink est bond0 ; l’IP de management est non taguée sur vmbr0 (donc sur le VLAN natif du trunk).

Décision : Si votre réseau de management doit être tagué, déplacez‑le sur une sous‑interface (par ex. vmbr0.10) ou ajustez les attentes de PVID. Un management non tagué sur un trunk cause des surprises ultérieures.

Task 4: Confirm bridge VLAN filtering is actually on

cr0x@server:~$ ip -d link show vmbr0
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:aa:bb:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
    bridge forward_delay 0 hello_time 2 max_age 20 ageing_time 300 stp_state 0 priority 32768 vlan_filtering 1 vlan_protocol 802.1Q

Sens : vlan_filtering 1 signifie que le bridge appliquera les règles d’appartenance VLAN.

Décision : Vous devez vérifier la table VLAN ensuite. En mode VLAN‑aware, « connecté à vmbr0 » ne suffit pas.

Task 5: Dump VLAN membership per bridge port

cr0x@server:~$ bridge vlan show
port              vlan-id
bond0             1 PVID Egress Untagged
bond0             10
bond0             20
tap100i0          10 PVID Egress Untagged
tap101i0          20 PVID Egress Untagged

Sens : L’uplink bond0 a les VLANs 10 et 20 tagués, et le VLAN 1 non tagué (natif). Les ports tap VM sont membres non tagués avec un PVID par VM.

Décision : Si la VM doit taguer elle‑même (guest VLAN tagging), son tap doit généralement transporter des VLANs tagués, pas être PVID non tagué. Décidez qui tague : l’hôte ou le guest. Ne faites pas les deux.

Task 6: Identify which tap device maps to which VM

cr0x@server:~$ qm list
      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID
       100 app-01               running    4096              32.00 2101
       101 db-01                running    8192             128.00 2255

Sens : Les VMID 100/101 correspondent probablement à tap100i0 et tap101i0.

Décision : Si la mauvaise VM est dans le mauvais VLAN, vérifiez la config hardware Proxmox : tag sur la NIC, bridge sélectionné, flag firewall.

Task 7: Confirm the VM NIC is tagged as expected in Proxmox

cr0x@server:~$ qm config 100 | sed -n '1,120p'
boot: order=scsi0;net0
memory: 4096
name: app-01
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,tag=10,firewall=0
scsi0: local-lvm:vm-100-disk-0,size=32G

Sens : Proxmox effectue le tagging pour la VM 100 (VLAN 10). Le guest doit être configuré avec une NIC non taguée.

Décision : Si le guest tague aussi VLAN 10 en interne, vous venez de doubler le tagging. Corrigez un côté.

Task 8: Capture traffic on the uplink and verify VLAN tags

cr0x@server:~$ sudo tcpdump -eni bond0 -c 8 '(arp or icmp) and (vlan 10)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:10.112233 DE:AD:BE:EF:10:00 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), vlan 10, ethertype ARP (0x0806), Request who-has 10.10.10.1 tell 10.10.10.50, length 46
12:01:10.113005 00:11:22:33:44:55 > DE:AD:BE:EF:10:00, ethertype 802.1Q (0x8100), vlan 10, ethertype ARP (0x0806), Reply 10.10.10.1 is-at 00:11:22:33:44:55, length 46

Sens : Les tags VLAN 10 sont présents sur le câble. L’ARP répond. L2 est probablement correct pour ce VLAN.

Décision : Si la VM ne peut toujours rien atteindre, regardez la config IP du guest, le firewall de l’hôte, ou le routage en amont. Si vous voyez des ARP requests sans réponses, vérifiez l’appartenance VLAN du switch ou la présence de la passerelle.

Task 9: Capture on the VM tap to see what the guest “sees”

cr0x@server:~$ sudo tcpdump -eni tap100i0 -c 6 arp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tap100i0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:02:44.000111 DE:AD:BE:EF:10:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), Request who-has 10.10.10.1 tell 10.10.10.50, length 46
12:02:44.000890 00:11:22:33:44:55 > DE:AD:BE:EF:10:00, ethertype ARP (0x0806), Reply 10.10.10.1 is-at 00:11:22:33:44:55, length 46

Sens : Le tap côté guest est non tagué (attendu, car Proxmox tague en sortie vers l’uplink). L’ARP fonctionne.

Décision : Si l’ARP fonctionne ici mais pas sur bond0, les règles de tagging/bridge VLAN sont erronées. Si l’ARP fonctionne aux deux endroits, concentrez‑vous sur L3.

Task 10: Verify MAC learning and forwarding database (FDB) per VLAN

cr0x@server:~$ bridge fdb show br vmbr0 | head -n 12
00:11:22:33:44:55 dev bond0 vlan 10 master vmbr0 permanent
de:ad:be:ef:10:00 dev tap100i0 master vmbr0
de:ad:be:ef:20:00 dev tap101i0 master vmbr0

Sens : Le MAC de la passerelle est appris/forcé sur VLAN 10 via bond0. Le MAC VM est appris sur le tap.

Décision : Si le MAC de la passerelle manque, le switch/la passerelle peut être injoignable sur ce VLAN. Si le MAC VM n’apparaît pas, la VM n’émet pas ou est connectée au mauvais bridge.

Task 11: Check for host firewall or bridge netfilter surprises

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 = 0

Sens : Le trafic bridgé peut traverser les règles iptables. Parfois souhaitable, parfois destructeur silencieux de paquets.

Décision : Si vous ne filtrez pas intentionnellement le trafic bridgé, envisagez de désactiver bridge-nf ou d’auditer les règles. Si vous filtrez, confirmez que les règles incluent correctement les interfaces VLAN/taps.

Task 12: Validate MTU end-to-end (host, bridge, VM path)

cr0x@server:~$ ip -br link show bond0 vmbr0
bond0            UP             3c:ec:ef:aa:bb:cc <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500
vmbr0            UP             3c:ec:ef:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

Sens : MTU à 1500. Si votre upstream est en 9000 (jumbo) ou si la VM attend 1500 alors que quelque part c’est 1496 à cause de réglages, vous aurez des problèmes de fragmentation/PMTUD.

Décision : Choisissez une MTU par domaine. Pour des trunks VLAN portant du trafic jumbo/stockage, appliquez la même MTU sur NIC physiques, bonds, bridges et ports switch. Sinon, restez à 1500 pour éviter les ennuis.

Task 13: Check routing and neighbor table on the host (for tagged host IPs)

Si l’hôte Proxmox a lui‑même une sous‑interface VLAN (fréquent pour le management), vérifiez la résolution des voisins.

cr0x@server:~$ ip neigh show dev vmbr0
10.10.10.1 lladdr 00:11:22:33:44:55 REACHABLE
10.10.10.50 lladdr de:ad:be:ef:10:00 STALE

Sens : La résolution ARP fonctionne sur vmbr0. Si vous voyez des entrées FAILED, L2 est brisé ou filtré.

Décision : Si les voisins échouent seulement sur un VLAN, revoyez la table VLAN du bridge et les VLANs autorisés sur le switch. S’ils échouent globalement, vérifiez lien/bond et état du port switch.

Task 14: Verify the guest path isn’t blocked by Proxmox firewall flags

cr0x@server:~$ pvesh get /nodes/server/qemu/100/config | sed -n '1,40p'
boot: order=scsi0;net0
memory: 4096
name: app-01
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,firewall=0,tag=10

Sens : Le firewall est désactivé pour la NIC VM. S’il est activé, des règles peuvent bloquer DHCP/ARP/ICMP.

Décision : Si vous activez le firewall, autorisez explicitement DHCP (67/68), ARP (L2) et les protocoles nécessaires, sinon vous déboguerez des « problèmes VLAN » qui ne seront que des politiques.

Modèles de configuration Proxmox qui fonctionnent vraiment

Il y a deux façons sensées de gérer les VLANs pour les VM dans Proxmox. Choisissez‑en une. Les mélanger crée un sanctuaire de perte de paquets.

Pattern A: Proxmox tague la NIC par VM (recommandé pour la plupart)

C’est le champ « VLAN tag » dans la config NIC de la VM. Le guest voit une NIC non taguée. Proxmox place la VM dans un VLAN en taguant les trames sur l’uplink du bridge.

Pourquoi ça marche : Vous centralisez l’attribution VLAN dans l’hyperviseur. Les guests restent simples. La migration entre hôtes est prévisible.

Exigences pour le bridge :

• bridge-vlan-aware yes sur le bridge
• bridge-vids inclut les VLAN IDs nécessaires (ou configuré via la table VLAN du bridge)
• Le port switch est en trunk et transporte ces VLANs

Pattern B: Le guest tague les VLANs (seulement si nécessaire)

Parfois une VM est un routeur, firewall, ou appliance qui a besoin de plusieurs VLANs sur une seule NIC. Dans ce cas, le guest tague lui‑même (par ex. eth0.10, eth0.20).

Config hôte : La NIC VM ne doit pas être configurée avec un tag. Le port tap doit laisser passer des VLANs tagués, et vous gérez les VLAN autorisés sur le bridge et le trunk du switch.

Règle pratique : Si vous ne construisez pas une VM routeur/firewall, n’utilisez pas le tagging côté guest. Ça ajoute une complexité inutile et rend les incidents « pas de réseau » plus créatifs qu’il ne faut.

IP de management de l’hôte sur un VLAN : faites‑le proprement

Si votre réseau de management Proxmox est tagué (fréquent en entreprise), ne comptez pas sur « trunk non tagué = le bon VLAN ». Faites‑le explicitement avec une interface VLAN sur le bridge. Exemple :

cr0x@server:~$ sed -n '1,120p' /etc/network/interfaces
auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
        bond-slaves enp3s0 enp4s0
        bond-miimon 100
        bond-mode 802.3ad

auto vmbr0
iface vmbr0 inet manual
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 10 20 30

auto vmbr0.10
iface vmbr0.10 inet static
        address 10.10.10.11/24
        gateway 10.10.10.1

Payoff opérationnel : Quand quelqu’un change le « native VLAN » sur le switch, votre hôte ne se téléporte pas dans un autre réseau. Il reste sur VLAN 10 parce qu’il tague.

Blague courte #1 : Un native VLAN, c’est comme des « règles firewall temporaires » — personne ne se souvient que ça existe jusqu’à ce que ça gâche votre journée.

Ne compliquez pas inutilement : un bridge par uplink suffit généralement

Des gens créent plusieurs bridges (vmbr0, vmbr1, vmbr2) pour chaque VLAN parce que c’est propre sur le papier. Ça multiplie aussi les points de défaillance, rend les trunks plus difficiles à raisonner, et fragilise les migrations.

Utilisez un bridge VLAN-aware par uplink et taguez côté VM. Ajoutez des bridges seulement si vous avez vraiment des domaines physiques séparés ou besoin de MTU/sécurité différentes.

Contrôles de sanity côté switch

Soyons clairs : la moitié des tickets VLAN Proxmox sont en réalité des tickets switch déguisés en problème Linux. Vous pouvez tout faire correctement sur l’hôte et perdre la connectivité parce que le trunk n’est pas réellement trunk.

Ce dont vous avez besoin sur le port switch

• Mode trunk (ou équivalent) : le port doit accepter les trames taguées.
• Liste des VLAN autorisés : incluez les VLANs nécessaires. « Tous les VLANs » est simple mais parfois interdit par la politique.
• Alignement du native VLAN : si vous utilisez du trafic non tagué, définissez explicitement à quel VLAN il appartient. Mieux : évitez le non tagué sauf pour des raisons explicites.
• Consistance LACP : si vous faites du bonding, les deux côtés doivent être d’accord sur LACP vs agrégation statique.
• Comportement STP : des ports trunk peuvent être bloqués si STP détecte des boucles. Sur certaines familles de switch, le blocage peut être par VLAN.

Les deux mismatches de trunk qui font perdre du temps

Mismatch 1 : Les VLANs autorisés n’incluent pas votre VLAN. Votre hôte tague VLAN 20 ; le switch abandonne VLAN 20. Sur l’hôte, vous verrez des tags partir sans réponses. Classique.

Mismatch 2 : Native VLAN mal aligné. Votre hôte envoie du management non tagué en attendant VLAN 10 ; le switch mappe le non tagué sur VLAN 1. Votre hôte a toujours du lien, mais il est sur une planète différente.

Blague courte #2 : Les mismatches VLAN sont le seul endroit où « ça marche sur ma machine » se traduit par « c’est cassé sur le switch ».

Erreurs fréquentes : symptôme → cause → correction

1) Symptom: VM gets no DHCP lease on VLAN, but static IP also doesn’t ping gateway

Root cause : VLAN non autorisé sur le trunk du switch ou absence d’appartenance VLAN dans la table du bridge.

Fix : Ajoutez le VLAN à la liste autorisée du switch et assurez‑vous de bridge-vlan-aware yes ainsi que de la présence du VLAN dans bridge vlan show. Validez avec tcpdump -eni bond0 vlan X.

2) Symptom: VM can ping gateway but not other subnets

Root cause : Mauvaise passerelle dans le guest, route manquante en amont, ou routage asymétrique dû à des gateways/firewalls multi‑homés.

Fix : Vérifiez la route par défaut du guest, puis tracez depuis la passerelle. Si vous avez des interfaces VLAN multiples sur un firewall, vérifiez politique et tables de routage par VLAN.

3) Symptom: Only one Proxmox node has working VLANs; others don’t

Root cause : Ports switch différents (VLANs autorisés, native VLAN, mode LACP), ou dérive de config hôte (filtrage VLAN activé sur l’un mais pas sur les autres).

Fix : Comparez /etc/network/interfaces, ip -d link, et bridge vlan show entre les nœuds. Les ports switch doivent utiliser le même profil.

4) Symptom: VLAN works until VM live-migrates, then dies

Root cause : La table VLAN du bridge de destination n’inclut pas le VLAN, ou le trunk uplink est différent.

Fix : Traitez l’appartenance VLAN comme une intention de cluster : standardisez la config de bridge et la config switch par nœud. Testez les migrations avec une VM canari sur chaque VLAN.

5) Symptom: Management access to host disappears after enabling VLAN-aware bridge

Root cause : L’IP de management de l’hôte reposait sur le comportement native VLAN non tagué ; l’activation du filtrage a changé le traitement, ou le PVID/untagged n’était pas celui attendu.

Fix : Déplacez le management sur une sous‑interface taguée explicite (vmbr0.10) et assurez‑vous que le trunk switch autorise VLAN 10. Planifiez une fenêtre de maintenance et utilisez un accès hors bande.

6) Symptom: Some traffic works (small pings), but large transfers stall or hang

Root cause : Incompatibilité MTU avec overhead VLAN, ou PMTUD bloqué par un firewall.

Fix : Standardisez la MTU ; autorisez les messages ICMP fragmentation‑needed si le routage est impliqué. Testez avec ping -M do -s depuis le guest.

7) Symptom: VLAN 1 works, VLAN 10/20 don’t

Root cause : Le trunk du switch est en réalité en access port, ou la liste des VLAN autorisés est erronée.

Fix : Reconfigurez le switch en trunk et autorisez les VLANs. Vérifiez les tags sur le câble avec tcpdump ; si vous ne voyez jamais de tags VLAN partir, le tagging côté hôte/bridge est incorrect.

8) Symptom: ARP requests go out, but ARP replies never come back

Root cause : VLAN bloqué sur le trunk, passerelle absente sur ce VLAN, ou fonction de sécurité montante (dynamic ARP inspection, port security) qui filtre les réponses.

Fix : Confirmez l’interface de la passerelle et son VLAN ; vérifiez les fonctions de sécurité du switch ; validez l’apprentissage MAC. Sur l’hôte, utilisez tcpdump pour voir si les réponses arrivent sur bond0.

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

Étape par étape : faire fonctionner un VLAN de bout en bout (méthode répétable)

1. Choisir un VLAN de test (par ex. VLAN 20) et une VM de test avec IP/passerelle connues et correctes.
2. Vérifier le trunk du switch : mode trunk, VLAN 20 autorisé, native VLAN correct (ou éviter le non tagué).
3. Vérifier l’uplink hôte : lien up, bond correct, pas de flapping.
4. Vérifier le mode du bridge : VLAN‑aware activé si vous comptez sur les tags Proxmox.
5. Vérifier la config NIC VM : tag=20 si l’hôte tague ; sinon pas de tag si le guest tague.
6. Vérifier la table VLAN du bridge inclut VLAN 20 sur l’uplink et le comportement des taps VM.
7. Observer l’ARP à trois points : tap, bridge/uplink, et (si possible) côté switch/passerelle.
8. Prouver L3 avec un ping de la passerelle ; puis tester au‑delà de la passerelle.
9. Tester le MTU si des performances ou gros paquets sont concernés.
10. Une fois que ça marche, étendre aux autres VLANs et automatiser.

Checklist avant changement (avant de toucher des VLANs en prod)

• Accès console hors bande fonctionnel (IPMI/iDRAC/iLO) et identifiants à jour.
• Config du port switch sauvegardée ou capturée (même un extrait collé suffit).
• Fenêtre de maintenance ou plan de rollback : restaurer /etc/network/interfaces et redémarrer le réseau peut vous couper l’accès.
• Savoir si vous utilisez le tagging Proxmox ou le tagging guest. Notez‑le.
• Confirmer si le firewall Proxmox est activé au niveau datacenter/node/VM et si bridge netfilter est activé.

Checklist après changement (prouver que c’est vraiment corrigé)

• La VM obtient un bail DHCP (si applicable) et peut renouveler le lease.
• La VM peut pinguer la passerelle et au moins une IP au‑delà de la passerelle.
• Test migration : live‑migrer la VM vers un autre nœud et retester la connectivité.
• Test reboot (si permis) : confirmer que le VLAN survit au redémarrage du nœud.
• Capturer une preuve : un extrait tcpdump montrant le tag VLAN présent et les réponses ARP reçues.

Trois mini‑histoires d’entreprise issues du terrain

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Ils migraient quelques VM « à faible risque » vers un nouveau cluster Proxmox. L’équipe réseau avait fourni deux ports switch par hôte, agrégés en LACP, et a prononcé les mots magiques : « C’est un trunk. » L’équipe virtualisation a hoché la tête, activé des bridges VLAN‑aware, assigné des tags par VM, et est passée à autre chose.

Deux heures plus tard, la première vague de migrations a commencé. La moitié des VMs revenait correctement. Le reste affichait « pas de réseau » dans le guest. L’équipe, sous pression, a fait ce que font les équipes : elle a changé trois choses à la fois — reboot des VMs, reload des services réseau, basculement des flags firewall — et a rendu la situation plus confuse.

La mauvaise hypothèse était subtile : « trunk » signifiait « tous les VLANs » pour l’équipe virtualisation, mais le switch autorisait seulement un sous‑ensemble. Les VMs fonctionnelles vivaient fortuitement sur les VLANs autorisés ; les autres non. Rien sur l’hôte n’avait l’air « down ». Le lien était up, les bonds up, les bridges up. C’était l’échec le plus propre qu’un réseau puisse offrir : rejet silencieux des tags VLAN non autorisés.

La correction a été ennuyeuse et immédiate : aligner les listes de VLAN autorisés sur chaque port channel d’hôte, puis standardiser une checklist : quand un VLAN est ajouté, mettre à jour la permission VLAN du bridge Proxmox et le trunk du switch en une seule opération.

Ils ont aussi ajouté une VM canari par VLAN qui teste en continu l’ARP et la reachabilité de la passerelle. Ce n’est pas glamour, mais ça rend la prochaine mauvaise hypothèse bruyante plutôt que coûteuse.

Mini‑histoire 2 : L’optimisation qui s’est retournée

Un ingénieur orienté performance a décidé de « simplifier et accélérer » en créant des bridges Linux séparés par VLAN, chacun lié au même bond uplink, puis en attachant les VMs au bridge spécifique. La logique semblait propre : moins de règles VLAN, moins de complexité, diagrammes plus nets. Ça a aussi rendu le système plus difficile à exploiter.

Le premier problème est apparu pendant une maintenance. Un changement switch a brièvement altéré le native VLAN sur le trunk. Un de ces bridges transportait le management non tagué — parce que « le management n’a pas besoin de tags, il est sur le native VLAN ». L’IP management de l’hôte s’est retrouvée dans un autre VLAN, et le nœud a disparu du monitoring. Pas down. Juste… déplacé.

Le deuxième problème est arrivé avec les migrations. Certains nœuds avaient des définitions de bridge légèrement différentes, et une VM migrée de l’hôte A vers l’hôte B s’est retrouvée attachée à un bridge existant mais mal câblé. La connectivité est devenue une caractéristique par‑nœud.

Dans le nettoyage post‑incident, ils ont fusionné en un seul bridge VLAN‑aware par uplink et utilisé les tags par VM de Proxmox. Ils ont aussi déplacé le management de l’hôte sur une sous‑interface taguée explicite. Les performances n’ont pas diminué. La clarté opérationnelle a beaucoup augmenté.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une autre organisation avait une habitude presque old‑school : chaque nœud Proxmox avait une strophe réseau identique, stockée dans le gestionnaire de configuration, et les ports switch étaient provisionnés via un template standard. Ils avaient encore des incidents — tout le monde en a — mais l’impact était réduit.

Un après‑midi, un nouveau VLAN pour une application métier a été introduit. Le VLAN a été ajouté au firewall et au core switching, mais pas aux ports d’accès alimentant deux des quatre hyperviseurs. Les VMs sur ces deux nœuds ne pouvaient pas atteindre leur passerelle ; celles des autres nœuds pouvaient.

Voici où la pratique ennuyeuse a payé : l’astreinte a appliqué le playbook rapide, comparé les VLANs autorisés entre ports, et trouvé le mismatch en minutes. Pas de débat prolongé sur si Proxmox « supporte ce VLAN » ou si le driver guest « agit bizarrement ». Les preuves étaient propres car la baseline était cohérente.

La correction a été une seule mise à jour du template switch et réapplication. Puis ils ont ajouté à leur checklist de changement : « Ajouter le VLAN aux trunks hyperviseur » comme point explicite. Ce n’est pas brillant, mais c’est le genre d’ennuyeux qui protège vos nuits.

FAQ

1) Dois‑je utiliser des bridges VLAN‑aware dans Proxmox ?

Oui, si vous utilisez Proxmox pour taguer le trafic VM (cas courant). Les bridges VLAN‑aware font que le bridge Linux se comporte comme un vrai switch avec appartenance VLAN, ce qui évite les fuites accidentelles et rend le tagging déterministe.

2) Ma VM est taguée dans Proxmox. Le NIC invité doit‑il aussi créer des sous‑interfaces VLAN ?

Non. Si Proxmox applique tag=10 sur la NIC VM, le guest doit traiter cette NIC comme non taguée. Les sous‑interfaces VLAN côté guest servent uniquement si la VM doit transporter plusieurs VLANs ou jouer le rôle de routeur/firewall.

3) Pourquoi l’activation du filtrage VLAN a‑t‑elle cassé le réseau de management de l’hôte ?

Parce que votre IP de management reposait probablement sur le comportement native VLAN non tagué. Quand le filtrage est activé, le bridge peut appliquer différemment l’appartenance VLAN, ou la gestion du PVID/untagged change. Corrigez en mettant le management sur une interface taguée explicite comme vmbr0.10.

4) Comment savoir si le switch abandonne mon VLAN ?

Lancez tcpdump -eni bond0 vlan X. Si vous voyez des ARP tagués sortir mais aucune réponse revenir, le VLAN n’est probablement pas autorisé sur le trunk ou la passerelle n’est pas présente sur ce VLAN.

5) Dois‑je configurer manuellement les tables VLAN du bridge ?

Souvent Proxmox gère une grande partie lorsque vous définissez des tags sur les NIC VM et activez le mode VLAN‑aware. Mais vous devez quand même valider avec bridge vlan show, surtout en mélangeant trunks guest‑tagged, bonds ou designs d’uplink inhabituels.

6) Quelle est la différence entre « bridge-vids » et « VLANs autorisés » sur le switch ?

bridge-vids définit les IDs VLAN que le bridge Linux considère valides/autorisés (selon la config). Les « VLANs autorisés » du switch définissent quels VLANs le switch forwarde sur ce trunk. Les deux doivent inclure le VLAN, sinon le trafic meurt.

7) Mon VLAN fonctionne sur un nœud mais pas après migration. Que standardiser ?

Standardisez : config trunk switch par nœud, mode bonding, réglage bridge VLAN‑aware, et la liste des VLANs autorisés. Testez les migrations comme partie de l’acceptation. Les échecs de migration sont presque toujours une dérive de configuration.

8) Les fonctions SDN de Proxmox peuvent‑elles créer de la confusion VLAN ?

Oui, surtout en masquant le comportement du bridge Linux sous des abstractions. Si quelque chose casse, redescendez aux fondamentaux : inspectez bridge vlan show, ip -d link, et confirmez les tags avec tcpdump. Le noyau fait toujours la commutation.

9) Pourquoi l’ARP fonctionne mais TCP échoue ?

Parce que l’ARP prouve seulement la découverte L2 du voisin. TCP peut échouer à cause d’un MTU/PMTUD, règles firewall, routage asymétrique, ou ACLs en amont. Après un ARP réussi, testez MTU et tracez le routage/politiques.

10) Est‑il acceptable de trunker « tous les VLANs » vers Proxmox ?

Techniquement oui. Opérationnellement, cela dépend de votre modèle de sécurité. Dans beaucoup d’environnements, limiter les VLANs autorisés réduit le rayon d’impact. Si vous limitez, considérez‑le comme un contrat : tout nouveau VLAN nécessite des mises à jour switch + Proxmox ensemble.

Conclusion : étapes suivantes pour éviter les répétitions

Si votre VLAN Proxmox ne fonctionne pas, arrêtez de cliquer dans l’UI en espérant que l’univers vous pardonne. Suivez des étapes mesurables :

1. Prouvez le tagging avec tcpdump sur l’uplink.
2. Prouvez l’autorisation avec bridge vlan show et les VLANs autorisés sur le switch.
3. Prouvez L3 avec ARP/voisins et la reachabilité de la passerelle.
4. Standardisez les configs entre nœuds pour que la migration ne devienne pas une roulette.
5. Rendez le management explicite (sous‑interface taguée), et cessez de compter sur les native VLANs sauf si vous le souhaitez vraiment.

Ensuite, notez votre modèle choisi (tag côté hôte vs tag côté guest), templatez les ports switch, et gardez une VM canari par VLAN. Ce n’est pas sophistiqué. Ça marche. Et en production, « ça marche » est la fonctionnalité.