Configuration correcte du bonding et du teaming réseau : tolérance de panne et LACP en production

Lorsqu’un seul câble réseau, un port de commutateur ou une carte réseau (NIC, Network Interface Card) tombe en panne, c’est au pire tout un hôte — y compris les charges de travail VM ou le nœud Kubernetes — qui s’arrête. C’est précisément là que le sujet intervient : configurer correctement le bonding et le teaming réseau signifie agréger ou redonder plusieurs liaisons physiques de façon à amortir les pannes et — selon le mode — permettre un débit supplémentaire. En pratique, ce ne sont pas tant les bases qui posent problème, mais les détails : mode LACP incorrect sur le switch, paramètres VLAN ou MTU incohérents, politique de hachage inappropriée ou effets secondaires inattendus liés à Spanning Tree et aux architectures multi-châssis (p. ex. MLAG/vPC).

Ce billet s’adresse aux administrateurs, ingénieurs systèmes, opérateurs et prestataires de services informatiques techniques. L’objectif est que vous n’atteigniez pas seulement « ça marche », mais que ce soit robuste en production : avec des prérequis clairs, une mise en œuvre sûre, des étapes de vérification fiables, du troubleshooting et une stratégie de repli.

Configurer correctement le bonding et le teaming réseau en pratique

Dans la pratique, les termes sont souvent confondus. Pour la planification et l’analyse des incidents, il vaut la peine de les distinguer clairement :

• Link Aggregation est le concept générique : plusieurs liaisons Ethernet physiques sont agrégées logiquement en une seule liaison.
• LACP (Link Aggregation Control Protocol, IEEE 802.1AX/802.3ad) est le protocole par lequel le switch et l’hôte négocient quels liens sont actifs dans l’agrégation et comment s’effectue le basculement.
• Linux Bonding est l’implémentation côté hôte (pilote kernel « bonding ») avec des modes tels que active-backup ou 802.3ad.
• Windows NIC Teaming est l’implémentation Windows (LBFO/SET selon la version), également avec des variantes pour le basculement ou l’agrégation.

Important : toutes les formes de « teaming » ne sont pas LACP. Beaucoup d’environnements utilisent délibérément active-backup (un lien actif, un en veille), parce que c’est robuste et nécessite côté switch peu de configuration particulière. LACP vaut la peine si vous avez besoin de tolérance aux pannes plus un mécanisme de répartition de charge prévisible — et si la topologie des switches le permet.

Ce que le bonding/teaming réalise réellement en exploitation — et ce qu’il ne fait pas

Une idée reçue fréquente est « 2×10G en LACP = 20G pour chaque flux ». En pratique, la charge est répartie par hachage : le switch calcule, à partir des attributs d’un flux (p. ex. MAC source/destination, IP, port TCP/UDP), un hash et affecte le flux à un lien physique. Cela entraîne deux conséquences :

• Un seul flux volumineux (p. ex. un flux de sauvegarde) utilise typiquement un seul lien — il n’est pas réparti sur plusieurs liens.
• De nombreux flux parallèles (p. ex. de nombreuses connexions Pod-à-Pod, de nombreux clients) se répartissent bien — selon la politique de hachage.

Pour la tolérance aux pannes : le bonding/teaming protège contre la défaillance d’un lien/port/NIC, pas automatiquement contre la défaillance d’un switch. Pour cela, il faut une architecture multi-châssis (p. ex. MLAG, vPC, Stack) qui permette l’agrégation sur deux switches physiques.

Planification avant la configuration : prérequis et décisions de conception

1) Définir l’objectif de redondance

Répondez d’abord à la question contre quoi vous devez vous prémunir :

• Seulement câble/port/NIC : active-backup ou LACP sur un seul switch suffisent.
• Également défaillance du switch : LACP sur deux switches n’est possible qu’avec MLAG/vPC/Stack ou une technique équivalente.
• Maintenance sans interruption de service : la conception doit supporter la mise hors service d’un port, la mise à jour du firmware et le redémarrage d’un switch.

2) Switch-Fähigkeiten und Betriebsregeln prüfen

Relevante Punkte, die in Change-Reviews häufig fehlen:

• MLAG/vPC/Stack: ist es vorhanden, wie werden Peer-Links abgesichert, was ist das Failover-Verhalten?
• Spanning Tree (STP/RSTP/MST): Aggregation reduziert die Zahl logischer Links, aber Fehlkonfiguration (z. B. Portfast/Edge-Mode falsch) kann trotzdem Loops auslösen.
• LACP Timer: fast/slow – muss zu Host/Anforderungen passen, sonst wirkt Failover «lent».
• VLAN/Trunk-Policy: alle Member-Ports einer LAG müssen identisch konfiguriert sein (VLANs, native VLAN, Allowed VLANs, Storm Control, QoS).

3) MTU und Offloads: kleine Abweichung, große Wirkung

MTU (Maximum Transmission Unit) muss Ende-zu-Ende passen. Jumbo Frames (z. B. MTU 9000) scheitern oft nicht an „dem einen Host“, sondern an einem Zwischenstück: ToR-Switch, Firewall, VXLAN-Overlay, Storage-Netz. Zusätzlich können NIC-Offloads (TSO/GSO/GRO) Messungen verfälschen: „Ping geht“, aber Last bricht ein oder es gibt Fragmentierung/PMTUD-Probleme (Path MTU Discovery).

4) Kubernetes-Kontext: Node-Ports, CNI und Failure Domains

In Kubernetes hängt die Wirkung von Bonding/Teaming davon ab, wie Ihr CNI (Container Network Interface, Netzwerk-Plugin) arbeitet. Bei Overlays (z. B. VXLAN) zählt Stabilität und MTU-Konsistenz, bei Underlay/Layer-2-nahen CNIs (z. B. mit BGP/EVPN oder L2-Announcements) kann Hashing/Link-Design spürbar werden. Zusätzlich relevant: Ein Node mit instabilem Bond führt zu Pod-Evictions, flappenden Endpoints und schwer interpretierbaren Timeouts. Deshalb sind klare Prüfschritte und sauberes Monitoring Pflicht.

Welcher Modus passt? Entscheidungshilfe für die Praxis

Für Admin-Teams sind vier Modi besonders häufig:

• active-backup (Linux bond mode 1): ein aktiver Link, ein Standby. Sehr robust, Switch-seitig meist ohne LACP. Ideal für «sicher und simpel».
• 802.3ad / LACP (Linux bond mode 4, Windows LACP): Bündelung mit Protokoll. Gut für viele parallele Flows und für definierte Betriebslogik.
• balance-xor (Linux bond mode 2): verteilt anhand eines Hash, aber ohne LACP-Aushandlung. Kann funktionieren, ist aber fehleranfälliger (Switch muss statisch passend konfiguriert sein).
• Switch-independent Teaming (Windows): Lastverteilung ohne LACP, Switch sieht einzelne MACs/Flows. Je nach Umgebung nützlich, aber nicht immer vorhersehbar.

Wenn Sie nicht sicher sind, starten Sie mit active-backup. LACP ist dann der nächste Schritt, wenn Sie sowohl Ausfallsicherheit als auch kontrollierbare Aggregation benötigen und die Switch-Seite sauber beherrschen.

LACP richtig aufsetzen: Verständnis, das Troubleshooting spart

LACP organisiert eine LAG (Link Aggregation Group). Beide Seiten schicken LACPDU-Pakete (Control Frames), in denen u. a. System-ID, Key und Port-Prioritäten stehen. Ein Link wird nur dann Member, wenn die Parameter zusammenpassen. Typische operative Konsequenzen:

• Mauvais mode : un hôte en LACP et un commutateur en „statisch“ (ou inversement) entraîne « Up, mais pas de trafic » ou du MAC-flapping.
• Paramètres de port hétérogènes : si un port membre a des paramètres VLAN ou MTU différents, un problème intermittent peut apparaître et ne se révélera qu’au basculement.
• Désynchronisation des timers : Slow (30s) donne l’impression d’un « blocage » lors d’un basculement, Fast (1s) est plus réactif mais peut renégocier plus souvent sur des liens instables.

Règle pratique : LACP n’est pas un substitut à un câblage soigné, il renforce au contraire la nécessité de vérifier systématiquement la qualité du lien et l‘identité du port.

Umsetzung Linux: Bonding (active-backup und 802.3ad) mit Prüfschritten

Linux Bonding kann je nach Distribution über NetworkManager, systemd-networkd oder netplan gemanagt werden. Entscheidend ist nicht das Tool, sondern dass das Ergebnis konsistent ist: ein Bond-Interface mit definierten Slaves, MTU, VLANs und (bei LACP) korrekter LACP-Rate und Hash-Policy.

Analyse de l’existant: Link-Status und Treiberbasis prüfen

Avant la reconfiguration, documentez la base physique : Link-Speed, Duplex, Fehlerzähler, Treiber/firmware.

# Link-Status, Speed, Duplex
ip -br link
ethtool eth0
ethtool eth1

# Fehler/Drop-Zähler (vorher/nachher vergleichen)
ip -s link show dev eth0
ip -s link show dev eth1

# Treiber und Firmware
ethtool -i eth0
ethtool -i eth1

Si vous voyez déjà ici des erreurs CRC, des flaps ou des problèmes d’autonegociation : stabilisez d’abord la physique (Kabel, SFPs, Port-Config), sinon le Bonding/Teaming devient une machine à fumée.

Bond-Status lesen: die wichtigste Datei im Betrieb

Indépendamment de la couche de gestion, l’état côté noyau est généralement visible sous /proc/net/bonding/. C’est votre première source pour le dépannage.

# Bond-Details (Beispiel bond0)
cat /proc/net/bonding/bond0

Portez une attention particulière à „Bonding Mode“, „Currently Active Slave“, „MII Status“ (Link up/down) et bei 802.3ad auf „Aggregator ID“, „Actor/Partner Key“ sowie „LACP rate“.

Exemple: systemd-networkd (concise et bien auditable)

Si vous utilisez systemd-networkd, la configuration est proche du texte et facilement versionnable. L’exemple montre LACP (802.3ad). Adaptez les noms d’interface, la MTU et, le cas échéant, les VLAN.

# /etc/systemd/network/10-bond0.netdev
[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=802.3ad
TransmitHashPolicy=layer3+4
LACPTransmitRate=fast
MIIMonitorSec=1s

# /etc/systemd/network/20-eth0.network
[Match]
Name=eth0

[Network]
Bond=bond0

# /etc/systemd/network/20-eth1.network
[Match]
Name=eth1

[Network]
Bond=bond0

# /etc/systemd/network/30-bond0.network
[Match]
Name=bond0

[Network]
DHCP=no
Address=192.0.2.10/24
Gateway=192.0.2.1
DNS=192.0.2.53

[Link]
MTUBytes=9000

Warum TransmitHashPolicy=layer3+4? Parce que, pour de nombreuses charges modernes (East-West-Traffic, de nombreux ports TCP/UDP), la répartition est meilleure que celle basée uniquement sur le MAC ou l’IP. Quand cela échoue-t-il ? Lorsque le switch ne prend en charge que certaines options de hash ou si vous avez des chemins asymétriques. Dans ce cas, le hashing côté hôte et côté switch doit être cohérent.

Exécution du changement avec risque minimal

• Effectuez la bascule pendant une fenêtre de maintenance si l’hôte ne dispose que d’une seule NIC ou s’il n’existe pas de deuxième route de gestion.
• Si possible : utilisez Out-of-Band (iDRAC/iLO/IPMI/Redfish) afin de pouvoir vous sauver en cas de «Network Lockout».
• Définissez à l’avance une fenêtre de retour : si, après X minutes, il n’y a pas de ping/SSH stable, revenir en arrière.

Mise en œuvre Windows Serveurs : NIC Teaming (LACP) et validation rigoureuse

Sous Windows le NIC Teaming est, selon la version/configuration, pertinent en tant que LBFO (classique) ou via Switch Embedded Teaming (SET, principalement avec Hyper-V). Il est essentiel de savoir si vous utilisez réellement LACP (dépend du switch) ou si vous opérez de façon indépendante du switch. Pour des workloads serveurs purs sans Hyper-V, LBFO RESTe fréquent dans de nombreux environnements ; dans les scénarios Hyper-V, SET est généralement la norme.

Vérifier le statut du team (état des lieux)

Get-NetAdapter
Get-NetLbfoTeam
Get-NetLbfoTeamMember
Get-NetLbfoTeamNic

Vérifiez : tous les membres sont-ils «Up» ? Quel mode de teaming est actif (LACP vs. Static vs. SwitchIndependent) ? Quelle valeur de LoadBalancingAlgorithm est utilisée ? L’algorithme en particulier (p. ex. Dynamic) influence la qualité de la répartition des flows.

Exemple : créer un team avec LACP (LBFO)

# Beispiel: zwei Adapter zu einem LACP-Team zusammenfassen
New-NetLbfoTeam -Name "TEAM0" -TeamMembers "Ethernet0","Ethernet1" -TeamingMode LACP -LoadBalancingAlgorithm Dynamic

# Status und Details
Get-NetLbfoTeam -Name "TEAM0" | Format-List *
Get-NetLbfoTeamMember -Team "TEAM0" | Format-Table -Auto

Pourquoi «Dynamic» ? Dans de nombreux déploiements Windows, cela combine une affectation stable avec une meilleure répartition lorsque de nombreux flows sont présents. Quand cela échoue-t-il ? Si le hashing du switch ou les politiques LACP sont très RESTrictifs, ou si vous passez par deux switches sans vrai MLAG/vPC — vous observerez alors fréquemment du MAC-Flapping ou des pertes de paquets sporadiques.

Contrôle opérationnel après le cutover

# IP-Konfiguration und Routen prüfen
Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4 | Sort-Object -Property RouteMetric | Select-Object -First 15

# Adapter-Statistiken (Drops, Errors)
Get-NetAdapterStatistics -Name "TEAM0"

Si, après le teaming, des décisions de routage «étranges» apparaissent, c’est souvent la métrique ou une interface de gestion supplémentaire qui est en cause. Ce n’est pas un problème de teaming en soi, mais il devient visible lors du même changement.

Côté switch : pièges typiques qui, côté hôte, se manifestent comme des «bugs»

La plupart des problèmes en production ne proviennent pas de l’hôte, mais d’incohérences sur le switch. Schémas fréquents :

• Configuration incohérente des ports membres: un port est Trunk, l’autre Access; ou les VLANs autorisés diffèrent. Résultat: une partie du trafic disparaît, selon le hash/flow.
• Native VLAN / PVID incorrect: le management atteint l’hôte seulement «parfois», ARP semble instable.
• MLAG/vPC incorrect: LACP sur deux commutateurs sans agrégation multi-châssis provoque du MAC-flapping (la même MAC apparaît sur deux commutateurs).
• Interaction STP: si un port du bundle est bloqué par STP (car non reconnu comme Port-Channel), la LAG ne peut pas se stabiliser.
• Rétrogradation LACP/«Suspend individual»: selon le fournisseur, un lien sans information correcte sur le partenaire LACP peut soit continuer à transmettre individuellement, soit être suspendu. Cela modifie considérablement le profil d’erreur.

Opérationnellement important : définissez qui regarde en premier en cas d’incident (switch ou hôte) et quelles preuves sont attendues (p. ex. LACP-Neighbor-Status, Port-Channel-State, Counters). Cela évite le ping-pong entre équipes.

Checklist : Avant la mise en production (hôte, switch, documentation)

Vérification hôte

• Vitesse du lien/Duplex sur toutes les NICs plausible et identique
• MTU identique sur les esclaves, le Bond/Team et les interfaces VLAN
• Mode Bond/Team documenté (active-backup vs. LACP)
• Supervision préparée : drops/erreurs d’interface, état du Bond, flapping de lien

Vérification du switch

• Port-Channel/LAG existe, tous les ports membres sont correctement affectés
• VLAN/Trunk/Native VLAN cohérents sur le Port-Channel (pas seulement sur les membres)
• LACP actif, timer souhaité configuré (fast/slow)
• Pour des switches doubles : MLAG/vPC/Stack correct, Peer-Link sain

Contrôle opérationnel et de changement

• Étapes de rollback écrites, incl. «comment reprendre l’accès» (OOB, Console, Remote Hands)
• Critères de réussite définis (Pings, SSH/RDP, santé des applications, test de débit)
• Fenêtre de maintenance et plan de communication

Dépannage : quand LACP «up» est, mais le trafic manque

Ce profil d’erreur est fréquent et frustrant : le lien est up, LACP semble actif, mais les connexions se coupent ou seuls certains VLAN fonctionnent. Une séquence de vérification pragmatique :

1) Vérifier le statut du Bond/Team et les liens actifs

# Linux: Bond-Details
cat /proc/net/bonding/bond0

# Kernel-Events zu Link-Flaps (letzte Meldungen)
journalctl -k -n 200 --no-pager

# Windows: Team und Member
Get-NetLbfoTeam
Get-NetLbfoTeamMember
Get-NetAdapterStatistics -Name "TEAM0"

Interprétation : si les membres sont «up» mais que l’agrégateur n’est pas stable (IDs d’agrégateur changeantes, Active Slave variable), il s’agit généralement d’un mismatch LACP/Port-Channel ou d’une instabilité physique.

2) Tester isolément le VLAN et la MTU

Ne vous contentez pas de « ping vers la passerelle », testez spécifiquement par VLAN et — pour les jumbo frames — avec une taille de paquet définie. Cela permet de rendre visibles la fragmentation et les problèmes PMTUD.

# Beispiel: MTU-Test (IPv4), DF gesetzt (nicht fragmentieren)
# 8972 Payload + 28 Bytes ICMP/IP = 9000 MTU (Richtwert)
ping -M do -s 8972 192.0.2.1 -c 5

Si cela échoue, alors que les petits pings passent, l’MTU n’est pas cohérente de bout en bout. Dans ce cas, Bonding/Teaming n’est généralement pas la cause, mais ils rendent le problème plus visible car le trafic peut emprunter des chemins/ports différents.

3) Hash-Policy als Ursache für „ein Link voll, der andere leer“

Un déséquilibre n’est souvent pas une erreur mais le résultat de la Hash-Policy. Si vous avez peu de gros flux, c’est normal. Si vous avez beaucoup de flux mais une distribution toujours inégale, vérifiez :

• Switch-Hashing (MAC vs. IP vs. L4 Ports)
• Host-Hashing (bei Linux: TransmitHashPolicy)
• Workload-Pattern (beaucoup de connexions courtes vs. quelques flux longs)

Dans un environnement Kubernetes, on voit fréquemment de nombreux flux East-West ; ici, layer3+4 est souvent pertinent. Pour le stockage (iSCSI/NFS), les règles de conception du setup de stockage sont plus importantes que l’objectif de « distribuer au maximum ».

4) MAC-Flapping und doppelte Pfade erkennen

Si vous exécutez LACP sur deux switches sans vrai MLAG/vPC, l’adresse MAC peut « flapper ». Cela se manifeste par des indisponibilités temporaires, des timeouts ARP, des resets TCP occasionnels. La solution propre est, selon l’infrastructure, soit un design Multi-Chassis réel, soit revenir à active-backup avec des switches séparés et sans LACP sur les deux.

Rollback- und Rückfallstrategie: so vermeiden Sie den „Remote Lockout“

Bonding/Teaming est un changement classique qui peut vous verrouiller hors d’un équipement à distance. Une stratégie de retour pratique combine technique et processus :

• Out-of-Band vorher testen: Zugang, Credentials, Netzwerkpfad, Console-Funktion.
• Konfigurations-Snapshot: aktuelle Netzwerksettings exportieren (Linux: relevante Dateien sichern; Windows: Team-Status dokumentieren).
• Timebox: Wenn nach X Minuten keine stabile Erreichbarkeit, sofort zurückrollen, nicht „noch schnell“ weiter basteln.
• Rollback-Plan: konkret und kurz – welche Dateien zurück, welche Dienste RESTart, welche Teams entfernen.

Linux-seitig sollten Sie vor dem RESTart von Netzwerkdiensten sicher sein, dass Sie über OOB oder lokalen Zugriff verfügen. Windows-seitig gilt: Teaming kann die Interface-GUIDs und Metriken verändern; planen Sie das in der Rückkehr ein.

Best Practices für Kubernetes-Nodes und Cluster-Betrieb

In Kubernetes ist Netzstabilität ein Multiplikator: Un lien de nœud instable génère des symptômes à tous les niveaux de la pile (CNI, kube-proxy, Ingress, endpoints de service). Pratiques éprouvées :

• Node-Standardisierung: mêmes modèles de NIC, mêmes versions de pilotes/firmware, mêmes politiques de Bond/Team. L’hétérogénéité est une cause fréquente.
• MTU-Disziplin: Si le CNI utilise un overlay, définissez une MTU qui RESTe en sécurité en dessous de l’Underlay-MTU. « 9000 partout » semble séduisant mais est difficile à tenir organisationnellement.
• Monitoring: alertes sur les link-flaps, erreurs/discards et état du bond. En complément : latence/perte de paquets au niveau node-to-node, pas seulement « Internet up ».
• Wartungsabläufe: Bei Switch-Firmware-Rollouts prüfen, ob LACP-Fast-Rate zu kurzen Reconvergence-Spikes führt. Gegebenenfalls Timer anpassen.

Une règle opérationnelle utile : si vous configurez correctement le bonding et le teaming réseau, une coupure de port planifiée (un membre down) ne devrait pas provoquer de redémarrages de pods ni d’erreurs applicatives perceptibles. Testez cela consciemment et documentez les effets attendus.

Conclusion : la stabilité résulte d’une conception + de la cohérence + des tests

Le bonding/teaming n’est pas une tâche « à configurer une fois », mais fait partie de la conception de l’infrastructure. Active-backup est souvent le moyen le plus rapide d’obtenir une tolérance de panne robuste. LACP offre des possibilités supplémentaires, mais exige une topologie de commutateurs propre (en particulier avec deux commutateurs), des politiques de ports cohérentes et une compréhension claire du hashing. Si vous combinez planification, listes de contrôle, étapes de vérification et une réelle stratégie de retour arrière, un changement à risque devient une opération de routine contrôlable – y compris dans des environnements Kubernetes, où l’instabilité réseau se propage immédiatement.

Pour ce sujet, Ieee 802.3Ad et Nic Bonding Linux sont également importants. L’article replace ces aspects de manière compréhensible et montre ce qui compte au quotidien.