Réseau sur Proxmox vs ESXi : trunk VLAN, bridges/vSwitches, bonding/LACP expliqués

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

Cet article vous a aidé ?

Si vous avez déjà migré un cluster et vu un « réseau simple » se transformer en une panne de quatre heures, vous connaissez déjà la vérité :
le réseau des hyperviseurs est l’endroit où les suppositions meurent. Les VLAN se comportent bien. Les trunks se comportent bien. Jusqu’au jour
où ils ne le font pas — parce que la machine fait exactement ce que vous lui avez dit, pas ce que vous vouliez.

Voici une carte pratique entre le réseau Proxmox et ESXi : comment le trunk VLAN se matérialise réellement sur un bridge Linux vs un vSwitch,
comment fonctionne (et échoue) le bonding/LACP, et quoi vérifier quand les paquets disparaissent dans le vide.

1) Modèle mental : bridges vs vSwitches

Le réseau ESXi est une pile de commutation virtuelle conçue pour cet usage. Vous créez des vSwitches (standard ou distributed), définissez des port groups,
attachez des vmnics (uplinks), et vous obtenez l’application de politiques dans un système piloté par une interface avec des abstractions cohérentes.

Le réseau Proxmox, c’est le réseau Linux avec une interface graphique. Sous le capot, vous utilisez des bridges Linux (souvent nommés vmbr0),
des sous-interfaces VLAN et du bonding Linux. Le « switch » est le noyau. L’avantage : vous pouvez le dépanner comme n’importe quel hôte Linux,
avec des outils standards. L’inconvénient : vous pouvez aussi vous tirer une balle dans le pied comme sur n’importe quel hôte Linux, avec ces mêmes outils.

Ce qui correspond à quoi

ESXi vSwitch / vDS ≈ bridge Linux (Proxmox vmbrX)
Uplinks ESXi (vmnicX) ≈ NICs Linux (eno1, ens3f0, etc.) ou bond (bond0)
Port Group ESXi ≈ VLAN sur un port de bridge (bridge VLAN-aware + tag VM) ou un bridge dédié/sous-interface VLAN
VLAN ID 4095 ESXi (trunk invité) ≈ NIC Proxmox sans tag VLAN + le guest gère le tagging

La grande différence conceptuelle : ESXi a tendance à pousser l’identité VLAN dans les port groups, tandis que Proxmox a tendance à la placer dans la configuration
de la NIC de la VM lorsque vous utilisez des bridges VLAN-aware. Les deux peuvent faire l’une ou l’autre approche. Mais les humains sont des créatures d’habitude,
et les migrations échouent dans les interstices entre ces habitudes.

La citation fiabilité que vous devriez tatouer sur vos runbooks

« L’espoir n’est pas une stratégie. » — idée paraphrasée souvent citée dans les cercles opérations et fiabilité.
Traitez les configs VLAN et LACP comme du code : relisez, testez et prévoyez une restauration.

2) Trunk VLAN : Proxmox vs ESXi en termes simples

Un trunk VLAN, c’est simplement « transporter plusieurs VLAN sur un seul lien physique ». Les problèmes commencent quand on se demande : « Où a lieu le marquage ? »

Trunk VLAN sur ESXi

Sur ESXi, le trunking s’exprime surtout via les port groups :

VLAN ID = N : ESXi marque les trames sortantes de ce port group avec le VLAN N et accepte le VLAN N en entrée.
VLAN ID = 0 : comportement de priority-tagging ; utilisé rarement en virtualisation serveur classique.
VLAN ID = 4095 : cas spécial signifiant « trunk VLAN vers le guest ». ESXi laisse passer les tags VLAN et la VM gère le tagging.

Lorsque vous attachez un vmnic uplink à un vSwitch ou vDS, vous dites en substance : « Cet uplink est connecté à un port de switch configuré correctement
pour le comportement VLAN attendu par ces port groups. » ESXi ne configurera pas votre switch physique, et votre switch physique ne lira pas vos pensées.
C’est pour ça que les tickets existent.

Trunk VLAN sur Proxmox

Sur Proxmox, le modèle « moderne » le plus courant est :

Rendre vmbr0 un bridge VLAN-aware.
Attacher votre uplink trunk (une NIC physique ou un bond) comme port du bridge.
Pour chaque NIC de VM, définir le tag VLAN dans la configuration matérielle de la VM.

C’est conceptuellement similaire aux port groups d’ESXi avec des VLAN IDs, sauf que Proxmox met le tag sur la NIC de la VM plutôt que sur un objet port group.
Opérationnellement, ça marche — jusqu’à devoir auditer 200 VMs pour « qui est sur le VLAN 132 ? » et en rater une parce qu’elle a été configurée différemment
dans ce cas spécial de 2019.

Pattern alternatif sur Proxmox : créer des sous-interfaces VLAN sur l’hôte (par ex. bond0.100) et construire un bridge séparé par VLAN (par ex. vmbr100).
C’est plus verbeux, mais aussi brutalement clair. La clarté est une fonction de performance quand l’horloge d’incident tourne.

Définition de trunk : ne confondez pas « VLAN autorisés » avec « VLAN natif »

Les trunks de switch physiques ont typiquement :

Liste des VLAN autorisés : quels tags VLAN sont permis sur le trunk.
VLAN natif (ou VLAN non taggé) : que deviennent les trames non taggées (elles sont mappées vers un VLAN).

Si votre uplink hyperviseur envoie des trames non taggées (gestion, cluster, stockage, peu importe) et que vous supposez « non taggé = VLAN 1 »
alors que le switch a un VLAN natif 20, vous aurez de la connectivité — simplement au mauvais endroit. C’est comme ça que des pannes deviennent des incidents
avec des implications de sécurité.

Blague n°1 : Les VLAN sont comme les plans de seating au bureau — tout le monde convient qu’ils sont nécessaires, et personne n’est d’accord sur qui s’assoit où.

3) Port groups ESXi vs bridges VLAN-aware Proxmox

Le port group d’ESXi est un objet de politique : VLAN ID, paramètres de sécurité, shaping, règles de NIC teaming, et en vDS même des choses
comme NetFlow et le port mirroring. C’est une abstraction propre pour des environnements avec de nombreux consommateurs et contrôle des changements.

Le modèle de bridge VLAN-aware de Proxmox est plus proche du « switching dans le noyau » : le bridge voit les tags et commutent en fonction du MAC+VLAN.
L’interface tap de la VM reçoit un réglage de tag VLAN, et Linux gère le marquage/démarquage.

Ce qu’il faut privilégier

Si vous avez un petit à moyen environnement, les bridges VLAN-aware sont le pattern le plus simple et le moins fragile sur Proxmox.
Un bridge, un trunk uplink, tags sur les NICs VM. Cela s’échelonne opérationnellement jusqu’à ce que vous ayez besoin de politiques par réseau et de garde-fous stricts.

Si vous avez besoin d’une séparation des rôles (netops définit les réseaux, l’équipe virt attache les VMs), l’approche port group d’ESXi tend à mieux coller
à la réalité corporate. Sur Proxmox, vous pouvez toujours faire la séparation — acceptez simplement que vous la construirez avec des conventions, de l’automatisation
et de la revue, pas avec des objets magiques.

Guest VLAN trunking (le guest fait le tagging)

ESXi rend cela explicite avec VLAN 4095. Proxmox peut le faire en ne définissant pas de tag VLAN sur la NIC VM et en s’assurant que le bridge/uplink laisse passer
les trames taggées. Ensuite, le guest crée des sous-interfaces 802.1Q à l’intérieur de la VM.

Utile pour des routeurs virtuels, firewalls ou appliances qui attendent des liens trunk. C’est aussi le moyen le plus rapide de créer un terrier de diagnostic
où personne ne sait si le tagging est dans le guest, l’hyperviseur ou le switch physique. Choisissez un emplacement et documentez-le.

4) Bonding et LACP : ce qui marche et ce qui fait mal

On bond des NICs pour obtenir de la redondance et/ou de la bande passante. Il y a deux grandes catégories :

Modes statiques/team (sans négociation avec le switch) : active-backup, balance-xor (selon), etc.
LACP (802.3ad) : agrégation négociée avec le switch, avec des politiques de hashing qui décident quel flux utilise quel lien.

Bonding sur Proxmox

Proxmox utilise typiquement le bonding Linux (bond0) avec des modes comme :

active-backup : un lien actif, un lien de secours. Ennuyeux. Fiable. Mon choix par défaut pour les réseaux de gestion.
802.3ad (LACP) : tous les liens actifs, meilleure utilisation, mais nécessite une config de switch correcte et un hashing cohérent.
balance-xor : style d’agrégation statique ; peut fonctionner mais est plus facile à mal configurer entre switches.

NIC teaming et LACP sur ESXi

Le NIC teaming du vSwitch standard ESXi n’est pas LACP. C’est du « teaming » avec différentes politiques d’équilibrage. Pour faire du vrai LACP, il faut généralement
un vDS (distributed switch) selon la version/licence, puis définir un LACP LAG et y attacher les uplinks.

Traduction : si vous aviez l’habitude de « juste activer LACP sur l’hôte », ESXi peut vous forcer à aller en vDS. Si vous aviez l’habitude de « juste teamer des NICs »,
Proxmox peut vous tenter avec des modes statiques qui fonctionnent jusqu’à ce qu’un remplacement de switch change le comportement.

Le hashing, là où les rêves meurent

LACP ne donne pas magiquement le double de bande passante à un flux TCP unique. Il répartit les flux sur les liens selon un hash (MAC/IP/port).
Si vous voulez « une VM obtient 20 Gbps », il faudra probablement autre chose (plusieurs flux, SMB multichannel, sessions NVMe/TCP multiples,
ou simplement un tuyau plus large).

Aussi : le trafic stockage (iSCSI, NFS) et vMotion peut devenir très sensible aux livraisons hors ordre et aux micro-bursts si vous « optimisez » sans mesurer.
LACP n’est pas un repas gratuit. C’est un accord négocié pour se disputer avec la physique.

Blague n°2 : LACP, c’est une relation — si un côté pense que vous êtes « active-backup » et l’autre que vous êtes « tout en jeu », quelqu’un va disparaître des paquets.

5) MTU, offloads et le « coût » des jumbo frames

Les désaccords MTU sont ennuyeux et catastrophiques. ESXi tend à pousser les réglages MTU via vSwitches/vDS et interfaces VMkernel.
Proxmox les pousse via les interfaces Linux, bonds, sous-interfaces VLAN et bridges. Vous pouvez le faire correctement — ou « presque correctement »,
ce qui conduit à un réseau de stockage qui fonctionne jusqu’à l’activation de la réplication.

Si vous utilisez des jumbo frames (MTU 9000), faites-le bout en bout : switchports physiques, uplinks, bond, bridge, interfaces VLAN et NICs invités
là où c’est pertinent. Si vous ne pouvez pas garantir le bout en bout, ne le faites pas à moitié. Restez en 1500 et concentrez-vous plutôt sur le pinning CPU
ou l’agencement du stockage.

6) Les réglages de sécurité du vSwitch vs les valeurs par défaut Linux

Les port groups ESXi ont des bascules de sécurité classiques : Promiscuous Mode, MAC Address Changes, Forged Transmits. Elles existent parce que
la commutation virtuelle est un medium partagé, et certains workloads (IDS, appliances) ont besoin d’un comportement spécial. Beaucoup des pires
« pannes mystères » en environnement ESXi viennent justement d’un de ces réglages trop stricts pour une VM spécifique.

Le bridging Proxmox/Linux ne présente pas ces mêmes boutons de la même façon, mais des contraintes similaires existent : ebtables/nftables,
filtrage sur le bridge, et comportement des guests. Si vous exécutez des firewalls virtuels, vous devez valider que l’hyperviseur laisse passer
les trames attendues, y compris les tags VLAN et le comportement MAC.

7) Faits intéressants & contexte historique (8 points rapides)

802.1Q VLAN tagging a été standardisé en 1998, et on se dispute encore sur les native VLAN comme si c’était nouveau.
Le bridging Linux est en production depuis des décennies ; il précède beaucoup d’UIs modernes des stacks de virtualisation enterprise.
LACP (802.3ad / 802.1AX) visait à standardiser l’agrégation de liens entre fournisseurs ; il a aussi standardisé les disputes.
Le vSwitch standard ESXi ne gérait historiquement pas LACP comme un vDS peut le faire ; les gens ont construit des policies « assez bonnes » à la place.
VLAN 4095 sur ESXi n’est pas « un VLAN », c’est un signal de passthrough de trunk pour le port group vers le guest.
Les réseaux overlay/VXLAN sont devenus courants en partie parce que l’échelle VLAN (4094 IDs utilisables) est un plafond réel en grand environnement.
Les offloads NIC (TSO/GSO/GRO/LRO) peuvent modifier le comportement des paquets assez pour embrouiller les captures et certains appliances de sécurité.
STP et les bridges comptent toujours : les boucles accidentelles peuvent fondre un réseau rapidement, qu’il soit physique ou virtuel.

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

Voici les vérifications que je lance réellement quand quelque chose sent le roussi. Chaque tâche inclut : commande, sortie d’exemple, ce que ça signifie, et la
décision que vous prenez.

Task 1: Identifier les NICs physiques et l’état des liens (Proxmox)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:fd:fe:aa:bb:01
eno2             DOWN           3c:fd:fe:aa:bb:02
ens3f0           UP             0c:42:a1:11:22:33
ens3f1           UP             0c:42:a1:11:22:34
bond0            UP             0c:42:a1:11:22:33
vmbr0            UP             0c:42:a1:11:22:33

Sens : Vous voyez immédiatement ce qui est up/down et si des bonds/bridges existent.
Décision : Si une NIC membre est down de façon inattendue, cessez d’accuser les VLANs et regardez d’abord le câblage/les erreurs du switch.

Task 2: Vérifier le mode du bond et l’état LACP (Proxmox)

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
Transmit Hash Policy: layer3+4 (1)
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: 2
        Number of ports: 2
        Actor Key: 17
        Partner Key: 42
        Partner Mac Address: 00:11:22:33:44:55

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

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

Sens : Confirme 802.3ad, la politique de hash et que les deux esclaves sont effectivement agrégés avec une MAC partenaire.
Décision : Si vous voyez « Number of ports: 1 » ou des états de churn, soupçonnez une incompatibilité de config LACP sur le switch ou des liens instables.

Task 3: Confirmer la VLAN-awareness du bridge et l’appartenance des ports (Proxmox)

cr0x@server:~$ bridge link
2: bond0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
5: tap100i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0
6: tap101i0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> master vmbr0

Sens : Montre ce qui est attaché au bridge : uplink et périphériques tap VM.
Décision : Si l’uplink n’est pas dans le bridge, votre « trunk » est un concept philosophique, pas un réseau.

Task 4: Inspecter le filtrage VLAN sur un bridge Linux (Proxmox)

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

Sens : Le bridge filtre les VLANs ; bond0 autorise VLANs 20 et 30 et a PVID 1 non taggé.
Décision : Si le VLAN requis n’est pas listé, soit autorisez-le (si le filtrage est activé), soit corrigez la configuration du tag NIC de la VM.

Task 5: Vérifier l’adressage IP de l’hôte et quelle interface le possède (Proxmox)

cr0x@server:~$ ip -br addr
eno1             UP             192.0.2.10/24
bond0            UP
vmbr0            UP             198.51.100.10/24
vmbr0.20         UP             10.20.0.10/24

Sens : Montre si l’IP de gestion est sur un bridge, une sous-interface VLAN ou une NIC physique.
Décision : Si l’IP de l’hôte est sur une NIC physique qui est aussi dans un bridge, attendez des comportements bizarres. Mettez les IPs sur le bridge
(ou sur les interfaces VLAN au-dessus du bridge), pas sur les ports esclaves.

Task 6: Valider la cohérence MTU sur uplink, bond, bridge (Proxmox)

cr0x@server:~$ ip -d link show bond0
3: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 0c:42:a1:11:22:33 brd ff:ff:ff:ff:ff:ff promiscuity 0
    bond mode 802.3ad miimon 100 updelay 0 downdelay 0 lacp_rate 1 xmit_hash_policy 1

Sens : MTU est 9000 sur le bond ; il faut encore vérifier les NICs esclaves, le bridge et les switchports.
Décision : Si MTU diffère sur un saut, corrigez bout en bout ou revenez à 1500 et arrêtez de payer le coût des jumbo frames.

Task 7: Test rapide de reachabilité VLAN avec ping + bit DF (Proxmox)

cr0x@server:~$ ping -c 2 -M do -s 8972 10.20.0.1
PING 10.20.0.1 (10.20.0.1) 8972(9000) bytes of data.
8972 bytes from 10.20.0.1: icmp_seq=1 ttl=64 time=0.421 ms
8972 bytes from 10.20.0.1: icmp_seq=2 ttl=64 time=0.398 ms

--- 10.20.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Sens : Confirme que le jumbo MTU fonctionne jusqu’à la passerelle sur ce VLAN (au moins pour ICMP).
Décision : Si ceci échoue mais que le ping normal fonctionne, vous avez de la fragmentation/blackhole MTU. Corrigez le MTU ou le comportement PMTUD.

Task 8: Voir l’apprentissage MAC sur le bridge (Proxmox)

cr0x@server:~$ bridge fdb show br vmbr0 | head
0c:42:a1:11:22:33 dev bond0 master vmbr0 permanent
52:54:00:aa:bb:01 dev tap100i0 master vmbr0 vlan 20
52:54:00:aa:bb:02 dev tap101i0 master vmbr0 vlan 30

Sens : Confirme que le bridge apprend les MACs des VMs par VLAN et où elles sont.
Décision : Si une MAC de VM n’apparaît pas alors que la VM est up et génère du trafic, suspectez l’attachement NIC VM, les règles firewall, ou que le guest est sur le mauvais VLAN.

Task 9: Capturer le trafic taggé sur l’uplink (Proxmox)

cr0x@server:~$ sudo tcpdump -eni bond0 -c 5 vlan
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:11.123456 0c:42:a1:11:22:33 > 01:00:5e:00:00:fb, ethertype 802.1Q (0x8100), length 86: vlan 20, p 0, ethertype IPv4, 10.20.0.10.5353 > 224.0.0.251.5353: UDP, length 44
12:01:11.223456 52:54:00:aa:bb:01 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 20, p 0, ethertype ARP, Request who-has 10.20.0.1 tell 10.20.0.50, length 28

Sens : Vous voyez les tags VLAN sur le fil et confirmez l’ID VLAN.
Décision : Si les tags manquent sur un trunk qui devrait les transporter, le tagging a lieu ailleurs — ou pas du tout.

Task 10: ESXi — confirmer le lien vmnic et les infos driver (shell ESXi)

cr0x@server:~$ esxcli network nic list
Name    PCI Device    Driver  Link  Speed  Duplex  MAC Address         MTU  Description
vmnic0  0000:3b:00.0  ixgbe   Up    10000  Full    3c:fd:fe:aa:bb:01  9000 Intel Corporation 82599ES
vmnic1  0000:3b:00.1  ixgbe   Up    10000  Full    3c:fd:fe:aa:bb:02  9000 Intel Corporation 82599ES

Sens : Les uplinks physiques sont up, à la vitesse/MTU attendue. Cela élimine toute une classe d’excuses « c’est le réseau ».
Décision : Si la vitesse est 1000 alors que vous attendiez 10000, arrêtez tout. Corrigez l’optique/le câblage/la config du switch d’abord.

Task 11: ESXi — inspecter vSwitches et port groups

cr0x@server:~$ esxcli network vswitch standard list
vSwitch0
   Name: vSwitch0
   Class: etherswitch
   Num Ports: 128
   Used Ports: 12
   Configured Ports: 128
   MTU: 9000
   Uplinks: vmnic0, vmnic1
   Portgroups: Management Network, VM Network, Storage-20

Sens : Montre MTU, uplinks et quels port groups existent sur le vSwitch standard.
Décision : Si le port group pertinent n’est pas sur le vSwitch que vous pensez, vous avez trouvé votre mauvais câblage — logique, pas physique.

Task 12: ESXi — vérifier les VLAN IDs configurés sur les port groups

cr0x@server:~$ esxcli network vswitch standard portgroup list
Name               Virtual Switch  VLAN ID
Management Network vSwitch0        10
VM Network         vSwitch0        0
Storage-20         vSwitch0        20
Trunk-to-FW        vSwitch0        4095

Sens : Vous dit si ESXi marque les trames (VLAN 10/20) ou les passe au guest (4095).
Décision : Si une VM qui attend du trafic non taggé est sur VLAN 20, elle sera « up » mais isolée. Corrigez le VLAN ID du port group, pas la VM.

Task 13: Proxmox — valider que le fichier de config est bien ce que vous pensez

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

auto bond0
iface bond0 inet manual
        bond-slaves ens3f0 ens3f1
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4
        bond-lacp-rate 1

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

Sens : Confirme le mode du bond, le réglage bridge VLAN-aware et la plage de VLANs autorisée.
Décision : Si bridge-vlan-aware est off mais que vous comptez sur les tags NIC VM, les tags ne se comporteront pas comme attendu. Activez-le ou changez le design.

Task 14: Proxmox — vérifier les règles firewall qui interfèrent avec L2/L3

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

Sens : Le firewall est activé ; il faut maintenant tenir compte des règles host et VM dans votre modèle mental.
Décision : Si vous déboguez « ARP marche mais TCP non », isoler temporairement l’influence du firewall (dans une fenêtre contrôlée) est souvent plus rapide que de deviner.

9) Playbook de diagnostic rapide

Quand le réseau casse sur des hyperviseurs, le chemin le plus rapide est de trouver la couche où la réalité diverge de votre schéma. Vérifiez dans cet ordre.

Premier : vérité physique (lien, vitesse, erreurs)

Le lien NIC est-il up ? À la vitesse attendue ?
Sur Proxmox : ip -br link, ethtool eno1 (si disponible), compteurs switchport.
Sur ESXi : esxcli network nic list.

Indicateur de goulot : mismatch de vitesse (1G au lieu de 10G), erreurs/paquets drop en hausse, liens qui flottent.

Deuxième : topologie L2 (bonding/LACP, attachement bridge/vSwitch)

L’uplink est-il vraiment attaché au bridge/vSwitch que vous croyez ?
LACP est-il négocié et stable ?
Proxmox : cat /proc/net/bonding/bond0, bridge link.
ESXi : uplinks du vSwitch, et si vDS, confirmer l’appartenance au LAG.

Indicateur de goulot : un seul esclave actif dans un bond, churn, ou uplink absent là où il devrait être.

Troisième : justesse VLAN (emplacement du tag, VLANs autorisés, VLAN natif)

Le tag VLAN est-il appliqué sur le bon objet (NIC VM vs port group vs OS invité) ?
Le trunk physique autorise-t-il le VLAN ?
Proxmox : bridge vlan show, tcpdump -eni bond0 vlan.
ESXi : esxcli network vswitch standard portgroup list.

Indicateur de goulot : requêtes ARP visibles mais pas de réponses sur le VLAN attendu, ou réponses arrivant sur un VLAN différent.

Quatrième : MTU et blackholes de fragmentation

Testez avec ping DF à la MTU prévue.
Vérifiez la MTU sur chaque saut : switch physique, NIC uplink, bond, bridge/vSwitch, VMkernel (ESXi), NIC invité.

Indicateur de goulot : petits pings fonctionnent, gros pings échouent ; le stockage se bloque sous charge ; les migrations gèlent par intermittence.

Cinquième : politiques et filtrage (firewalls, réglages de sécurité, comportement MAC)

Les réglages de sécurité des port groups ESXi bloquent les forged transmits ou les changements MAC pour des appliances.
Le firewall Proxmox/nftables bloque du trafic que vous supposiez « juste L2 ».

Indicateur de goulot : un seul type de VM échoue (ex. VM firewall) alors que des serveurs normaux fonctionnent.

10) Trois mini-récits du monde d’entreprise

Incident causé par une mauvaise supposition : « non taggé signifie VLAN 1 »

Une entreprise de taille moyenne a déplacé des workloads d’ESXi vers Proxmox lors d’un renouvellement matériel. L’équipe virtualisation a conservé les mêmes
top-of-rack physiques et réutilisé les ports trunk existants. Sur ESXi, la plupart des port groups VM étaient taggés, mais la gestion était non taggée sur les uplinks
parce que « c’est comme ça que ça a toujours été ».

Sur Proxmox, ils ont construit un vmbr0 VLAN-aware et ont mis l’IP de gestion directement sur vmbr0 sans tag VLAN.
L’hôte est monté, mais le réseau de gestion se comportait de manière incohérente : certains hôtes joignables, d’autres non, et les tables ARP avaient l’air d’avoir été brassées.

La mauvaise supposition : l’équipe croyait que le VLAN natif sur ces trunks était VLAN 1. Il ne l’était pas. Une normalisation réseau antérieure avait déplacé
le VLAN natif vers un VLAN « infra » dédié, et VLAN 1 avait été explicitement élagué à certains endroits. Les trames non taggées atterrissaient dans le VLAN infra,
pas dans le VLAN de gestion. Les hôtes parlaient — simplement au mauvais voisinage.

La correction n’a pas été héroïque. Ils ont taggé la gestion correctement (sous-interface VLAN ou tag NIC VM) et rendu le trunk explicite :
liste de VLAN autorisés, définition du VLAN natif, et documentation. Le rapport d’incident a été court et légèrement embarrassant, ce qui est exactement ce qu’on veut.
Plus le rapport est long, plus vous admettez que le système était inintelligible.

Optimisation qui s’est retournée contre eux : « mettons LACP partout et MTU à 9000 »

Une autre organisation faisait tourner ESXi avec des réseaux séparés : gestion, stockage, vMotion. Ils ont migré vers Proxmox et décidé de « simplifier »
en convergeant tout sur un seul bond LACP et un seul trunk VLAN. L’argument était propre : moins de câbles, moins de switchports, meilleure utilisation.

Ils ont aussi activé les jumbo frames bout en bout — ou du moins c’est ce qu’ils pensaient. MTU hôte 9000, switchports configurés, bond sain.
En production, pendant les fenêtres de sauvegarde, la latence du stockage a grimpé et les migrations ont échoué par intermittence. Les pannes n’étaient pas totales.
Elles étaient pires : partielles, imprévisibles, et faciles à écarter comme « le réseau étant le réseau ».

Le coupable était double. Premièrement, un switch sur le chemin avait le MTU appliqué sur le mauvais profile de port, laissant un seul saut à 1500.
Certains trafics se fragmentaient, d’autres étaient blackholés selon le protocole et le comportement DF. Deuxièmement, la politique de hashing LACP sur le bond Linux
était layer3+4, tandis que le côté switch distribuait effectivement les flux différemment pour certaines classes. Sous charge microburst, un lien saturait alors que l’autre semblait au repos.

Le rollback a été pragmatique : garder LACP pour les VLAN VM/données, mais mettre le stockage sur une paire de NICs dédiée en active-backup et un VLAN dédié,
avec MTU validé saut par saut. Les performances se sont stabilisées. La « simplification » avait été réelle, mais elle avait aussi supprimé de l’isolation et rendu le dépannage plus difficile.
La convergence est un outil, pas une personnalité.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « un bridge, un usage, configs testées »

Une société financière exploitait un parc mixte : des clusters ESXi, des clusters Proxmox pour des workloads spécifiques. Leur équipe réseau imposait
une règle qui semblait bureaucratique : chaque hôte hyperviseur doit avoir un petit design « mgmt-only » testable indépendamment des réseaux VM.

Sur Proxmox, cela signifiait un bridge de gestion dédié mappé à un VLAN dédié avec bonding active-backup, sans fantaisie. Les VLANs VM/données vivaient
sur un trunk bridge séparé, souvent sur un bond différent. Oui, cela consommait plus de ports. Oui, les diagrammes de câblage étaient plus longs.
Cela signifiait aussi que vous pouviez redémarrer, patcher et récupérer des hôtes sans dépendre d’un trunk LACP convergé qui pourrait mal se comporter.

Lors d’une mise à jour de firmware de switch, le comportement LACP d’un rack a dégradé d’une façon qui ne faisait pas complètement tomber les liens mais provoquait churn et rééquilibrage.
Les réseaux VM ont subi de la perte de paquets. La gestion est restée propre. L’équipe ops a pu joindre chaque hôte, évacuer les VMs et garder le rayon d’impact maîtrisé.

Le post-mortem n’était pas glamour. Il rappelait surtout que la segmentation est une stratégie de fiabilité. Quand les choses cassent, vous voulez un domaine de panne étroit.
Les designs ennuyeux produisent une disponibilité excitante.

11) Erreurs fréquentes : symptôme → cause racine → correction

1) Les VMs ne joignent pas la passerelle sur un VLAN, mais d’autres VLANs fonctionnent

Symptôme : Seul le VLAN 30 est mort ; le VLAN 20 fonctionne.
Cause racine : VLAN non autorisé sur le trunk physique, ou filtrage VLAN sur le bridge qui ne l’inclut pas.
Correction : Assurez-vous que le VLAN est dans la liste des VLAN autorisés du switch ; sur Proxmox, confirmez bridge-vlan-aware yes et bridge vlan show inclut le VLAN ; sur ESXi, vérifiez le VLAN ID du port group.

2) La connectivité de gestion meurt quand vous ajoutez un port au bridge

Symptôme : Ajout d’une NIC au bridge ; l’hôte disparaît du réseau.
Cause racine : L’IP de l’hôte est configurée sur la NIC physique esclavagée au lieu du bridge ; ARP/MAC bougent et causent de la confusion.
Correction : Mettez l’IP sur vmbrX (ou sur vmbrX.Y interface VLAN), pas sur la NIC/bond sous-jacent.

3) Le bond LACP est présent, mais un seul lien transporte le trafic

Symptôme : Les deux liens « up », mais l’utilisation colle un lien.
Cause racine : Politique de hashing inadaptée au pattern de trafic (flux unique dominant), ou mismatch de hashing côté switch.
Correction : Alignez les politiques de hashing ; acceptez qu’un flux TCP unique ne se stripe pas ; envisagez plusieurs sessions ou réseaux séparés pour les gros consommateurs.

4) Le stockage fonctionne jusqu’à la charge, puis timeouts

Symptôme : NFS/iSCSI OK à l’état idle, échoue sous backup/réplication.
Cause racine : Mismatch MTU ou micro-bursts sur liens convergés ; QoS absent ; offloads mal combinés.
Correction : Validez MTU avec pings DF bout en bout ; séparez le trafic stockage ou implémentez buffering/QoS ; testez soigneusement les changements d’offload.

5) VM firewall/router voit le trafic que dans un sens

Symptôme : Paquets entrants visibles, sortants manquants (ou l’inverse).
Cause racine : Réglages de sécurité du port group ESXi bloquent forged transmits/changement MAC ; ou trunking guest mal configuré.
Correction : Sur ESXi, ajustez la sécurité du port group pour cette appliance ; sur Proxmox, assurez-vous que les tags VLAN sont passés/traités au bon niveau et que les règles firewall ne les bloquent pas.

6) Avertissements d’IP dupliquée ou ARP qui flotte

Symptôme : Logs indiquent IP dupliquée ; connectivité oscille.
Cause racine : Mismatch de VLAN natif causant l’atterrissage des trames non taggées dans le mauvais VLAN ; ou boucle L2 accidentelle.
Correction : Rendre le VLAN natif explicite et cohérent ; activer STP si approprié ; valider les ports de bridge et la config switchport.

12) Checklists / plan étape par étape

Checklist A : Concevoir le trunk VLAN sur Proxmox (faites ceci, pas des intuitions)

Décidez où vit le tagging VLAN : tags sur NIC VM (bridge VLAN-aware) ou sous-interfaces hôte (un bridge par VLAN). Choisissez un défaut.
Faites de l’uplink un bond si vous avez besoin de redondance. Choisissez active-backup pour la gestion par défaut ; n’utilisez LACP que si vous pouvez valider la config switch et le hashing.
Mettre bridge-vlan-aware yes sur les bridges trunk et définir les VLANs autorisés (bridge-vids) intentionnellement.
Définissez le comportement natif/non taggé : idéalement, ne comptez pas sur le non taggé pour quelque chose d’important. Taguez aussi la gestion sauf raison solide.
Validez la MTU bout en bout avec des pings DF par VLAN.
Capturez le trafic sur l’uplink avec tcpdump -eni pour confirmer la présence des tags VLAN.
Documentez : quel bridge porte quels VLANs, et si une VM est un « guest trunk ».

Checklist B : Migrer des port groups ESXi vers des tags VLAN Proxmox

Exportez ou listez les port groups ESXi et leurs VLAN IDs (inclure les trunks 4095).
Créez les bridge(s) trunk Proxmox et confirmez la VLAN-awareness.
Pour chaque VM, mappez : VLAN ID port group ESXi → tag VLAN NIC VM Proxmox.
Pour les VMs en 4095 : assurez-vous que la NIC VM Proxmox n’a pas de tag et que le guest est configuré pour 802.1Q ; validez par capture.
Avant basculement, testez une VM par VLAN : ARP, ping, ping jumbo (si utilisé), et validation applicative.
Gardez le chemin de gestion suffisamment isolé pour pouvoir revenir en arrière sans vous rendre en datacenter.

Checklist C : Déploiement LACP sans douleur auto-infligée

Confirmez que vos switches supportent LACP tel que configuré (MLAG si vous spannez deux switches).
Définissez le LACP rate (fast/slow) volontairement et faites correspondre des deux côtés.
Alignez la politique de hashing. Si vous ne savez pas ce que votre switch utilise, renseignez-vous. Ne devinez pas.
Testez les modes de panne : débranchez un lien ; redémarrez un switch ; confirmez que le trafic survit et se rééquilibre sans flapping.
Surveillez drops et erreurs sous charge. Si vous ne pouvez pas mesurer, vous ne pouvez pas déclarer le succès.

13) FAQ

Q1: Un bridge Linux Proxmox est-il essentiellement la même chose qu’un vSwitch ESXi ?

Fonctionnellement, oui : les deux acheminent des trames entre interfaces VM et uplinks. Opérationnellement, non : ESXi est une abstraction appliance ;
Proxmox est le réseau Linux avec tout le pouvoir et les bords tranchants que cela implique.

Q2: Dois-je utiliser un seul grand bridge trunk pour tout sur Proxmox ?

Pour beaucoup d’environnements, un bridge trunk pour les VLANs VM/données suffit. Mais gardez la gestion ennuyeuse et récupérable.
Si vous le pouvez, séparez la gestion du grand trunk convergé.

Q3: Qu’est-ce que le VLAN 4095 ESXi et quelle est l’équivalence Proxmox ?

Le VLAN 4095 ESXi signifie « passer les tags VLAN au guest » (guest trunk). Sur Proxmox, vous le faites typiquement en ne mettant pas de tag VLAN sur la NIC VM
et en laissant le guest créer des sous-interfaces 802.1Q — en vous assurant que le bridge/uplink laisse passer les trames taggées.

Q4: LACP double-t-il la bande passante pour une VM unique ?

Pas pour un flux TCP unique. LACP répartit les flux selon un hashing. Un gros flux reste généralement sur un lien. Plusieurs flux peuvent utiliser plusieurs liens.

Q5: Le bonding active-backup « gaspille » de la bande passante ?

Il « gaspille » le débit agrégé potentiel, oui. Il vous achète aussi des modes de panne plus simples. Pour la gestion, ce compromis est généralement correct.
Pour un fort trafic est-ouest, envisagez LACP si vous pouvez le supporter opérationnellement.

Q6: Pourquoi des problèmes VLAN ressemblent parfois à des bugs DNS ou applicatifs ?

Parce que la connectivité partielle est la pire. L’ARP peut fonctionner, les petits paquets peuvent passer, mais la MTU ou le filtrage peut casser des protocoles spécifiques.
Votre appli échoue alors de façon créative qui fait rejeter la faute partout.

Q7: Dois-je activer les jumbo frames pour les réseaux de stockage ?

Seulement si vous pouvez prouver la cohérence MTU bout en bout et que vous avez mesuré un bénéfice. Si vous ne pouvez pas garantir cela, restez en 1500 et optimisez autrement.

Q8: Comment prouver rapidement si le tagging a lieu au bon endroit ?

Capturez sur l’uplink : sur Proxmox utilisez tcpdump -eni bond0 vlan ; sur ESXi utilisez les outils de capture appropriés ou observez la config du port group.
Si vous voyez des tags 802.1Q avec le VLAN attendu, le tagging est réel. Sinon, votre config est du wishful thinking.

Q9: Quelle conception VLAN Proxmox est la plus favorable à la migration ?

Bridge VLAN-aware avec tags sur les NICs VM, plus un réseau de gestion clairement taggé. Cela se mappe proprement aux port groups ESXi et évite la prolifération de bridges.

Q10: Quand préfèreriez-vous un bridge par VLAN sur Proxmox ?

Quand vous voulez une clarté extrême, une séparation stricte, ou que vous vous intégrez à des processus legacy où « ce réseau a sa propre interface »
est la façon dont les gens pensent et auditent.

14) Prochaines étapes pratiques

Si vous exécutez ESXi, traitez les port groups comme source de vérité : VLAN IDs, réglages de sécurité et règles de teaming. Auditez-les, exportez-les,
et évitez que des trunks 4095 « temporaires » ne deviennent une architecture permanente.

Si vous exécutez Proxmox, embrassez la réalité Linux : utilisez des bridges VLAN-aware intentionnellement, placez les IPs sur les bonnes interfaces, et faites du bonding
un choix délibéré (active-backup pour les réseaux ennuyeux, LACP là où vous pouvez valider le comportement switch et le hashing).

Prochaines étapes qui rapportent immédiatement :

Choisissez et documentez une stratégie VLAN par défaut par plateforme (tag sur port group vs tag sur NIC VM) et une stratégie d’exception (guest trunk) avec règles strictes.
Exécutez le playbook de diagnostic rapide sur un hôte sain et sauvegardez les sorties. Les baselines raccourcissent les incidents.
Pour tout plan LACP ou jumbo-frames : testez les modes de panne et la MTU bout en bout avant de vous déclarer victorieux.