Un serveur, une carte réseau, un câble, un port de switch. Quatre points de panne en série pour atteindre le réseau. Le câble se débranche, la carte grille, le port du switch tombe : le serveur est isolé. Sur une base de données qui sert mille clients, ça veut dire incident majeur sur une cause à deux euros. L'agrégation de liens supprime cette fragilité, à condition de la monter correctement, jusqu'au switch.
On agrège pour deux raisons, et l'ordre compte. La bande passante cumulée d'abord : deux liens 10G donnent jusqu'à 20G de capacité agrégée. La redondance ensuite, et c'est elle qui justifie vraiment l'effort : la panne d'un lien, d'une carte ou d'un switch ne doit pas couper le serveur. Beaucoup montent un bond pour le débit et découvrent en panne qu'ils n'ont rien protégé du tout. On va voir pourquoi.
Le bonding Linux et ses modes
Le noyau Linux agrège plusieurs interfaces physiques en une interface logique, bond0, qui porte l'IP. Les cartes physiques deviennent esclaves du bond. Le driver bonding existe depuis vingt ans, il est stable et documenté en détail sur kernel.org. Tout se joue dans le mode choisi.
active-backup (mode 1) garde un seul lien actif, l'autre en réserve. Bascule en cas de panne du lien actif. Zéro gain de bande passante, redondance simple, et surtout aucune exigence côté switch : les deux ports peuvent être sur des switches différents sans configuration spéciale. Le mode du pauvre, mais robuste et sans dépendance.
balance-xor (mode 2) répartit le trafic sur tous les liens selon un hash, statiquement, sans négociation avec le switch. Actif sur tous les liens à la fois. Gain de débit et tolérance de panne, mais le switch doit être configuré en static link aggregation côté face.
802.3ad (mode 4), le LACP, négocie l'agrégation avec le switch via le protocole LACP. Tous les liens actifs, répartition par hash, et détection mutuelle des pannes par échange de PDU. C'est le mode standard pour un serveur sérieux relié à un switch managé.
balance-alb (mode 6) équilibre émission et réception au niveau ARP, sans rien exiger du switch. Pratique quand on n'a pas la main sur l'infra réseau, mais plus fragile et moins propre que LACP. À éviter si on contrôle le switch.
Le bon réflexe : si on maîtrise le switch et qu'il est managé, LACP. Sinon, active-backup pour de la pure redondance. balance-alb seulement en dernier recours.
LACP : négociation et hash de répartition
LACP (802.3ad) ne se contente pas d'empiler des liens. Les deux extrémités, serveur et switch, échangent des LACPDU pour confirmer en continu que chaque lien est sain et membre du même groupe. Si un lien tombe ou cesse de répondre, il sort de l'agrégat sans attendre un timer côté carte. Cette négociation bidirectionnelle, c'est ce qui sépare LACP du mode statique : le lien doit être bon des deux côtés pour rester dans le bond.
Le point que tout le monde sous-estime : LACP ne fait pas du round-robin paquet par paquet. Il choisit le lien de sortie par un hash. Une conversation donnée part toujours sur le même lien, pour ne pas désordonner les paquets. La politique de hash décide de la granularité.
layer2 hashe sur les MAC source et destination. Si tout le trafic passe par une seule passerelle, une seule MAC de destination, donc un seul lien utilisé. Débit plafonné à un lien malgré l'agrégat.
layer2+3 ajoute les IP. Mieux réparti dès qu'il y a plusieurs IP en jeu. Le défaut raisonnable.
layer3+4 hashe en plus sur les ports TCP/UDP. Répartition fine, deux connexions entre les deux mêmes machines peuvent emprunter deux liens. Le meilleur étalement, à réserver aux cas où les deux côtés le supportent.
Le piège classique : monter un LACP entre deux machines pour doubler le débit d'un transfert, rester en hash layer2, et voir tout passer sur un seul lien. Une seule conversation ne dépassera jamais la vitesse d'un lien, quel que soit le hash. LACP additionne des conversations, pas des paquets.
La limite que personne ne voit venir : la panne d'un switch
Un bond LACP classique relie un serveur à un seul switch. Les deux câbles partent vers le même équipement. Le switch entier tombe, alimentation, crash logiciel, reboot firmware, et les deux liens tombent ensemble. Le bond ne protège de rien. On a doublé les câbles et les cartes, mais on a gardé un point de panne unique : le switch.
C'est l'erreur qu'on voit le plus souvent en audit. Un beau bond LACP 2x10G, fier sur le papier, raccordé à un switch unique. Redondance de carte et de câble, oui. Redondance réseau réelle, non. Le jour où le switch reboot pour une mise à jour, le serveur dit prétendument redondant tombe avec.
La réponse vient du switch : le MLAG. Multi-Chassis Link Aggregation. Deux switches s'interconnectent par un lien dédié et se présentent au serveur comme un seul partenaire LACP. Un câble vers chaque switch, un seul bond côté serveur, et la panne d'un switch entier laisse le second porter le trafic. Chaque constructeur a son nom : vPC chez Cisco, MLAG chez Arista, MC-LAG chez Juniper, et les implémentations Linux côté switch sur base Cumulus ou SONiC. Le serveur, lui, ne voit qu'un LACP normal, c'est le réseau qui fait l'illusion du switch unique.
La règle qu'on applique en production : redondance réelle = LACP côté serveur ET MLAG côté réseau. Un câble vers chaque switch d'une paire MLAG. Tout le reste est une demi-mesure qui tombera sur la première panne de switch. Pour la couche au-dessus, quand c'est une passerelle ou une VIP qu'on veut rendre redondante, c'est l'affaire de VRRP avec Keepalived, un autre étage du même combat.
Configuration sous Linux
Trois écoles selon la distribution et l'outillage. Le principe reste identique : un bond en mode 802.3ad, des esclaves, une politique de hash, un monitoring de lien.
Avec systemd-networkd, un fichier .netdev crée le bond et fixe le mode, un .network par carte la rattache. Les options utiles : Mode=802.3ad, LACPTransmitRate=fast pour un PDU par seconde au lieu d'un toutes les 30 secondes, TransmitHashPolicy=layer2+3 ou layer3+4, MIIMonitorSec=100ms.
Avec NetworkManager, nmcli crée une connexion bond maître puis des connexions esclaves. Les options passent en chaîne : mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4. Attention, certaines versions de systemd derrière NetworkManager ont eu des régressions LACP sur les bonds, à vérifier selon la distribution.
Avec le vieux /etc/network/interfaces sur Debian, on déclare le bond0 avec ses bond-slaves, bond-mode 802.3ad, bond-miimon 100, bond-xmit-hash-policy. Format historique, toujours valable. Pour le reste de la pile réseau Linux, on couvre le terrain dans le réseau sous Linux en 2026.
Pièges en production
Mode désaccordé avec le switch. Si le serveur est en 802.3ad et le switch en static aggregation, ou l'inverse, le lien part en vrille : flapping, paquets perdus, comportement erratique. Les deux côtés doivent parler le même langage. LACP avec LACP, statique avec statique. Jamais de mélange.
MTU incohérent. Les jumbo frames sur un bond exigent le même MTU sur les esclaves, le bond, le port du switch et tout le chemin. Un maillon à 1500 quand le reste est à 9000, et tu récoltes des fragmentations ou des drops silencieux qui se diagnostiquent mal. Pour cette chasse-là, voir déboguer un problème réseau.
Monitoring de lien mal réglé. miimon surveille l'état physique du lien (carrier) à intervalle donné. À 0, le bonding ne détecte pas une carte morte qui garde le carrier électrique mais ne transmet plus. La valeur saine : miimon=100, soit 100 ms. Pour détecter une panne plus subtile en bout de chemin, le mode ARP monitoring teste une vraie joignabilité L3, plus coûteux mais plus honnête sur la santé réelle du lien.
Sur un routeur logiciel, ces bonds deviennent les uplinks de la machine, et la logique se combine avec le routage : on en parle côté routeur datacenter avec VyOS, et le filtrage du trafic agrégé relève de nftables avancé.
Le verdict est sans nuance. Pour de la vraie haute disponibilité réseau, LACP côté serveur plus MLAG côté switch, un câble vers chaque switch d'une paire. Un bond LACP vers un switch unique protège du câble et de la carte, pas de la panne qui arrive vraiment : le switch. Tenir ce niveau de redondance jusqu'au switch, c'est ce qu'on conçoit sur les infras qu'on opère ; si votre HA s'arrête au câble, on peut auditer le raccordement et le remettre au niveau.
Sources
- Linux Ethernet Bonding Driver HOWTO, kernel.org : référence des modes, paramètres miimon, xmit_hash_policy, LACP rate.
- Configuring a network bond, Red Hat Enterprise Linux : configuration NetworkManager et nmcli, exemples 802.3ad.
- Multi-Chassis Link Aggregation MLAG, NVIDIA Cumulus Linux : principe et configuration du MLAG côté switch.
- Bonding, Debian Wiki : configuration via /etc/network/interfaces.
- LACP no longer works on NetworkManager bond interfaces, systemd issue 15208 : régression LACP à connaître selon la version de systemd.
