Bonding et teaming réseau avec NetworkManager : modes, exigences côté switch et vérification

Ce que c'est

Le bonding Linux (le pilote noyau bonding) présente plusieurs cartes réseau physiques comme une seule interface logique (bondX). NetworkManager peut créer et gérer une connexion de bonding : une connexion de type bond, plus une connexion ethernet par esclave, déclarée comme port du bond. Les options du pilote noyau sont stockées dans la propriété bond.options (par exemple mode=802.3ad,miimon=100). Le teaming (teamd, type de connexion team) est l'ancienne alternative ; il est obsolète dans RHEL 9 et supprimé dans RHEL 10, c'est pourquoi les nouvelles installations devraient utiliser le bonding.

Pourquoi c'est important

Les modes de bonding ne sont pas interchangeables : un mauvais choix reste sans effet utile ou casse la connectivité.

• active-backup : un seul esclave est actif à la fois, les autres restent en attente ; la bascule s'effectue en cas de perte de lien. Aucune configuration du switch n'est nécessaire : chaque carte peut même être reliée à un switch différent, ce qui constitue aussi le principal avantage de ce mode en matière de résilience.
• 802.3ad (LACP) : les esclaves négocient avec le switch un groupe d'agrégation de liens dynamique grâce au protocole LACP ; tous les esclaves sont normalement connectés au même switch, dont les ports doivent être explicitement configurés en un groupe LACP correspondant. Sans cette configuration côté switch, le trafic est perdu ou un seul esclave est utilisé en pratique.
• Les autres modes arbitrent différemment entre répartition de charge et exigences côté switch : balance-rr, balance-xor et broadcast demandent que les ports du switch soient regroupés en EtherChannel/trunk statique (sans LACP), faute de quoi le switch voit la même adresse MAC passer d'un port à l'autre en permanence ; balance-tlb et balance-alb ne nécessitent aucune configuration du switch.

Comment l'appliquer

• Choisir le mode en fonction de ce que l'équipe en charge du switch peut configurer : active-backup lorsqu'aucune configuration coordonnée du switch n'est possible ou disponible ; 802.3ad lorsqu'un port-channel/EtherChannel LACP en bonne et due forme peut être mis en place.
• Créer la configuration avec nmcli : une connexion bond portant bond.options, puis au moins deux connexions ethernet avec connection.master pointant vers le bond et connection.slave-type bond.
• Vérifier l'état négocié, et pas seulement la configuration : cat /proc/net/bonding/bond0 affiche le mode actif, l'état MII de chaque esclave et, pour 802.3ad, le partenaire LACP et les identifiants d'agrégateur effectivement convenus avec le switch.
• Confirmer le comportement de la bascule en désactivant un esclave (ip link set eth0 down, en root), puis en vérifiant que /proc/net/bonding/bond0 montre la bascule et que la connectivité est maintenue ; le rétablir avec ip link set eth0 up. Effectuer ce test depuis une console, et non via le bond lui-même : si la bascule ne fonctionne pas, la session est perdue.

Pièges

• Configurer 802.3ad sur l'hôte alors que les ports du switch restent en mode autonome (non agrégé) : le lien peut quand même monter, mais le trafic est perdu ou dupliqué.
• Supposer que /proc/net/bonding reflète l'intention d'un fichier de configuration : il ne reflète que ce que le pilote a négocié à l'instant présent ; il faut donc le revérifier après toute modification côté switch.