Linux bridge, VLAN-aware, bonding LACP¶

Day 0 · ConcevoirNiveau 2 · OpérerCoursRédigé · à valider en lab

Sur Proxmox VE, le réseau d'un nœud tient en trois briques empilées : des cartes physiques, regroupées en bond (LACP de préférence), sur lequel repose un Linux bridge VLAN-aware qui joue le rôle du vSwitch. Tout est décrit dans /etc/network/interfaces et appliqué à chaud par ifupdown2. Objectif : lire et concevoir cette configuration sans risque de couper le nœud.

Notions clés¶

Correspondances avec vSphere¶

vSphere	Proxmox VE	Remarque
vSwitch standard	Linux bridge `vmbr0`	Un bridge par nœud, même nom sur tous les nœuds
Port group VLAN 30	Tag VLAN `30` sur la carte réseau de la VM	Avec un bridge VLAN-aware, aucun objet à créer
Uplinks + teaming	Bond `bond0`	Le bridge utilise le bond comme port
VMkernel de management	Adresse IP sur `vmbr0` ou sur `vmbr0.10`	Un VLAN de management dédié est recommandé
Distributed vSwitch	SDN (zones, VNets) au niveau Datacenter	Voir SDN

ifupdown2 et l'application des changements¶

ifupdown2 est l'outil par défaut depuis PVE 7.0 : il applique les changements sans redémarrage.
La GUI n'écrit pas directement dans /etc/network/interfaces : elle prépare /etc/network/interfaces.new. Le bouton Apply Configuration (nœud → System → Network) bascule le fichier et applique.
Après une modification manuelle du fichier : ifreload -a.
Un redémarrage applique aussi le fichier .new en attente (service pvenetcommit) : attention aux modifications oubliées.

Modes de bond¶

Mode	Switch requis	Usage
`802.3ad` (LACP)	Agrégat LACP configuré (MLAG/stack si deux switchs)	Recommandé : redondance et répartition
`active-backup`	Aucun	Switchs sans LACP ; une seule carte active
`balance-rr`, `balance-xor`, `broadcast`	Spécifique	À éviter
`balance-tlb`, `balance-alb`	Aucun	Interdits sous un bridge qui porte des VM (documentation officielle)

La politique de hachage choisit la carte utilisée par flux. layer2+3 (exemple de la documentation officielle) hache sur MAC et IP. layer3+4 ajoute les ports TCP/UDP : meilleure répartition quand peu d'hôtes échangent beaucoup de flux (migration, sauvegarde, Ceph). Le noyau la signale comme non strictement conforme 802.3ad (paquets fragmentés), sans conséquence pratique dans la plupart des cas. Le switch doit utiliser une politique équivalente pour le trafic retour. Un flux unique ne dépasse jamais la vitesse d'une carte.

Configuration de référence¶

auto lo
iface lo inet loopback

iface eno1 inet manual
iface eno2 inet manual

auto bond0
iface bond0 inet manual
        bond-slaves eno1 eno2
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4
        bond-lacp-rate fast

auto vmbr0
iface vmbr0 inet manual
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

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

bridge-vlan-aware yes : le bridge transporte tous les VLAN listés dans bridge-vids. Une VM reçoit son VLAN via le champ VLAN Tag de sa carte (net0: virtio=...,bridge=vmbr0,tag=30).
Le port du switch en face est un trunk qui autorise ces VLAN.
bond-lacp-rate fast : LACPDU toutes les secondes ; recommandé par Proxmox dès que Corosync passe sur un bond LACP, sur le nœud et sur le switch.

flowchart BT
    E1[eno1] --> B[bond0 802.3ad]
    E2[eno2] --> B
    B --> V[vmbr0 VLAN-aware]
    V --> M[vmbr0.10 management]
    V --> VM1[VM 101 tag 30]
    V --> VM2[VM 102 tag 40]

Noms d'interface stables¶

PVE 9 fournit pve-network-interface-pinning generate pour figer les noms des cartes (préfixe nic par défaut) et éviter qu'une mise à jour du noyau ou du firmware renomme eno1. L'outil prépare des fichiers .new à comparer, et un redémarrage est nécessaire. Opération à planifier avec le MSP.

Recommandations MSP¶

Même nom de bridge et mêmes VLAN sur tous les nœuds : sinon la migration à chaud échoue.
Corosync ne passe pas uniquement par le bond des VM : un lien dédié reste nécessaire. Voir Plan réseau type.
Toute modification réseau sur un nœud de production se fait avec un accès console hors bande (IPMI, iDRAC, iLO) ouvert.
Ajouter un VLAN pour une VM : le client le fait seul (tag sur la carte de la VM, VLAN autorisé sur le trunk). Modifier un bond ou l'IP de management : MSP.

Pièges vus en support

Bond LACP côté Proxmox, ports du switch non agrégés : liens qui oscillent, perte de paquets aléatoire.
Deux switchs non empilés (sans MLAG/vPC) avec un bond LACP sur les deux : l'agrégat ne monte que d'un côté.
balance-alb sous un bridge : pertes de connectivité des VM liées à la réécriture des adresses MAC.
Modification préparée dans la GUI, jamais appliquée, puis appliquée par surprise au redémarrage suivant.
IP de management déplacée sur un autre VLAN sans accès console : nœud injoignable.

Testez-vous¶

Que fait le bouton Apply Configuration ?

Réponse

Il remplace /etc/network/interfaces par /etc/network/interfaces.new préparé par la GUI et applique la configuration à chaud avec ifupdown2.
Quel mode de bond choisir avec deux switchs empilés compatibles LACP ?

Réponse

802.3ad, avec un agrégat LACP multi-châssis côté switch et bond-lacp-rate fast.
Comment une VM accède-t-elle au VLAN 30 sur un bridge VLAN-aware ?

Réponse

On renseigne VLAN Tag = 30 sur sa carte réseau. Le VLAN doit être autorisé sur le trunk du switch et dans bridge-vids.
Pourquoi un transfert unique de 10 Go ne va-t-il pas plus vite avec un bond de deux cartes 10 Gb/s ?

Réponse

Le hachage affecte chaque flux à une seule carte. Seul l'ensemble des flux bénéficie de l'agrégat.