Agrégation réseau expliquée : les 7 modes, l’architecture et la configuration en conditions réelles

Le bonding réseau — également appelé NIC teaming, agrégation de liens ou bonding Ethernet — est la technique consistant à combiner deux ou plusieurs cartes d’interface réseau (NIC) physiques en une seule interface logique gérée par le noyau du système d’exploitation. Le résultat est un périphérique réseau unifié qui offre une bande passante agrégée accrue, un basculement automatique et une distribution de charge sur tous les liens membres simultanément.

Au niveau du noyau sur les systèmes Linux, le bonding est implémenté via le module noyau `bonding`, qui présente une seule interface virtuelle (généralement nommée `bond0`) à la pile réseau. Cette abstraction signifie que les applications, les tables de routage et les règles de pare-feu interagissent avec une seule interface, quel que soit le nombre de NIC physiques en dessous — un détail architectural critique qui simplifie la gestion tout en offrant une résilience de niveau entreprise.

Pourquoi le bonding réseau est important dans les environnements de production

Avant d’aborder les modes, il est utile de comprendre précisément quel problème le bonding résout — et où il ne le fait pas. Un seul port Gigabit Ethernet a un plafond fixe d’environ 125 MB/s de débit. Pour un serveur de base de données, un nœud de stockage ou une application web à fort trafic, ce plafond est atteint rapidement. Le bonding de deux NIC 1 GbE ne double pas magiquement le débit pour un seul flux TCP (c’est une idée reçue courante), mais il permet à plusieurs flux simultanés de saturer les deux liens, doublant effectivement la capacité agrégée.

Au-delà du débit brut, le bonding élimine le point de défaillance unique que représente un NIC ou un câble isolé. Dans les environnements où la disponibilité se mesure en neuf, cela est d’une importance capitale.

Principaux avantages en un coup d’œil

• Bande passante agrégée : Plusieurs liens physiques contribuent au débit total pour les flux de trafic simultanés
• Basculement automatique : La détection de défaillance de lien (via la surveillance MII ou ARP) déclenche un basculement en moins d’une seconde vers une interface survivante
• Distribution de charge : Le trafic est réparti entre les interfaces membres selon l’algorithme de bonding actif
• Transparent pour les applications : L’interface bond possède une seule adresse MAC et IP, ne nécessitant aucune modification au niveau applicatif
• Efficacité des coûts matériels : Le bonding de NIC standard peut être plus rentable que la mise à niveau vers une seule carte 10 GbE dans certains scénarios

Architecture du bonding réseau : comment ça fonctionne en coulisses

Le pilote de bonding du noyau Linux opère entre la couche 2 (liaison de données) et les pilotes NIC physiques. Lors de la transmission d’une trame, la politique de transmission du pilote de bonding sélectionne l’interface esclave à utiliser. À la réception, toutes les interfaces esclaves transmettent les trames au maître bond, qui les déduplique et les livre à la pile réseau.

La surveillance de lien est le mécanisme qui détecte les défaillances. Deux méthodes existent :

• Surveillance MII (Media Independent Interface) : Interroge l’état du lien physique de chaque NIC à un intervalle configurable (paramètre `miimon`, généralement 100ms). Rapide et fiable pour détecter les débranchements de câbles ou les défaillances de NIC.
• Surveillance ARP : Envoie des requêtes ARP à une IP cible et surveille les réponses. Plus utile lorsque vous devez vérifier la connectivité de bout en bout plutôt que simplement l’état du lien physique, mais introduit une dépendance envers une cible ARP accessible.

Les paramètres `downdelay` et `updelay` ajoutent de l’hystérésis — empêchant les oscillations rapides lorsqu’un lien fluctue. Les régler à 200ms chacun est une base courante en production.

Les 7 modes de bonding Linux : analyse technique approfondie

Le pilote de bonding Linux définit sept modes distincts (0 à 6). Chacun implémente une politique de transmission et un comportement de basculement différents. Choisir le mauvais mode est l’une des erreurs de configuration les plus courantes dans les déploiements de serveurs.

Mode 0 — Round-Robin (balance-rr)

Les paquets sont transmis séquentiellement sur toutes les interfaces esclaves actives de manière rotative : paquet 1 sur eth0, paquet 2 sur eth1, paquet 3 sur eth0, et ainsi de suite.

Ce qui se passe réellement : Le round-robin opère au niveau des paquets, pas au niveau des flux. Cela signifie qu’une seule connexion TCP peut avoir ses paquets livrés dans le désordre si les deux chemins ont des latences différentes. La pile TCP de l’hôte récepteur les réordonnera, mais cela provoque des retransmissions et une dégradation du débit en pratique — particulièrement notable lors de transferts de fichiers volumineux sur une seule connexion.

Exigence du commutateur : Les ports du commutateur doivent être configurés en LAG statique (Link Aggregation Group) sans LACP. Sans cela, le commutateur verra des trames provenant de la même adresse MAC arriver sur plusieurs ports et pourra déclencher un arrêt de protection contre les boucles.

Meilleure utilisation : Charges de travail de transfert en masse avec de nombreuses connexions simultanées de courte durée, où le réordonnancement par paquet est tolérable.

Mode 1 — Active-Backup

Une seule interface esclave est active à tout moment. Toutes les autres sont en état de veille active. Lorsque le lien actif tombe en panne (détecté via la surveillance MII ou ARP), le pilote de bonding promeut un esclave de secours et envoie un ARP gratuit pour mettre à jour les tables d’adresses MAC du réseau.

Nuance critique : En mode active-backup, l’interface bond présente toujours la même adresse MAC au réseau (la MAC de l’esclave actuellement actif). Cela signifie qu’aucune configuration spéciale du commutateur n’est nécessaire — du point de vue du commutateur, il s’agit d’une connexion normale à un seul hôte. C’est le seul mode qui fonctionne correctement sur des commutateurs sans aucune configuration LAG.

Délai de basculement : Avec `miimon=100`, `downdelay=200`, `updelay=200`, vous pouvez vous attendre à un basculement en environ 200–300ms — suffisamment rapide pour éviter les interruptions de sessions TCP dans la plupart des cas.

Meilleure utilisation : Scénarios de haute disponibilité où la simplicité et la compatibilité importent plus que la bande passante — interfaces de gestion, accès hors bande, ou tout environnement où le commutateur n’est pas sous votre contrôle.

Mode 2 — Balance-XOR

Le trafic est distribué à l’aide d’une politique de hachage de transmission appliquée à chaque paquet. Le hachage par défaut est `(source_MAC XOR destination_MAC) modulo slave_count`. Les politiques de niveau supérieur (`layer3+4`) utilisent les adresses IP et les numéros de port pour une meilleure distribution.

La politique layer3+4 : La configuration de `xmit_hash_policy=layer3+4` améliore considérablement la distribution en hachant sur l’IP source, l’IP destination, le port source et le port destination. Cela garantit que différents flux TCP vers le même serveur de destination sont répartis sur les liens, ce que le hachage MAC par défaut ne peut pas réaliser.

Exigence du commutateur : Configuration LAG statique sur le commutateur (identique au Mode 0), mais sans le problème de réordonnancement des paquets puisque tous les paquets d’un même flux traversent la même interface.

Meilleure utilisation : Environnements nécessitant un équilibrage de charge sans support LACP, particulièrement lorsqu’il est combiné avec la politique de hachage `layer3+4`.

Mode 3 — Broadcast

Chaque paquet est transmis simultanément sur toutes les interfaces esclaves. Chaque esclave envoie une copie identique de chaque trame.

Quand c’est réellement utile : Le mode broadcast ne concerne pas la bande passante — il s’agit d’une livraison garantie à plusieurs segments réseau simultanément. Il est utilisé dans des scénarios de clustering haute disponibilité spécialisés où deux commutateurs ou chemins réseau séparés doivent tous deux recevoir chaque paquet (par exemple, certains systèmes de réplication de stockage ou de trading financier avec des structures réseau redondantes). Il est également utilisé dans certaines configurations de surveillance réseau.

Le coût en bande passante : Avec deux NIC en mode broadcast, vous consommez 2x la bande passante sur le câble pour chaque paquet. Avec quatre NIC, 4x. Ce mode ne doit jamais être utilisé pour le trafic général.

Mode 4 — 802.3ad / LACP (agrégation de liens dynamique)

Il s’agit du standard IEEE 802.3ad, implémenté via le Link Aggregation Control Protocol (LACP). Le pilote de bonding et le commutateur échangent des PDU (Protocol Data Units) LACP pour négocier dynamiquement quels liens forment le groupe d’agrégation, leurs paramètres et leur état de santé.

Comment fonctionne la négociation LACP : Chaque côté envoie des LACPDU annonçant sa priorité système, sa priorité de port et sa clé d’agrégation. Les liens avec des clés correspondantes des deux côtés forment un LAG. Si un lien tombe en panne, LACP le détecte et le retire du groupe sans aucune intervention manuelle.

Politique de hachage de transmission : Comme le Mode 2, le Mode 4 utilise une politique de hachage pour la distribution de charge. La politique `layer3+4` est fortement recommandée ici également. Notez que LACP ne garantit pas l’équilibrage de charge par paquet — il distribue les flux sur les liens, donc un seul transfert de fichier volumineux n’utilisera toujours qu’un seul lien physique.

Configuration du commutateur : Le commutateur doit avoir LACP activé sur le canal de port correspondant. Les modes LACP non concordants (actif vs. passif) sont une source fréquente de défaillances de bonding. Les deux côtés peuvent être réglés sur `active` pour s’assurer que la négociation se déroule toujours.

Meilleure utilisation : Centres de données, serveurs haute performance et tout environnement où vous contrôlez la configuration du commutateur. C’est la référence absolue pour le bonding en production lorsque le support du commutateur est disponible.

Mode 5 — Balance-TLB (équilibrage de charge de transmission adaptatif)

Le Mode 5 distribue le trafic sortant sur tous les esclaves en fonction de la charge actuelle de chaque interface (l’esclave le moins chargé reçoit le prochain paquet sortant). Le trafic entrant est reçu uniquement sur un seul esclave désigné.

L’avantage clé : Aucune configuration du commutateur n’est requise. L’interface bond utilise différentes adresses MAC sources par esclave pour le trafic sortant, ce qui est un comportement valide que tout commutateur gère de manière transparente.

La limitation : Le trafic entrant n’est pas équilibré. Si votre serveur reçoit principalement de grands volumes de données (un serveur de téléchargement, un réplica de base de données recevant des flux de réplication), le Mode 5 n’apporte aucun bénéfice dans cette direction. Si votre serveur envoie principalement des données, le Mode 5 est très efficace.

Comportement de basculement : Si l’esclave récepteur tombe en panne, un autre esclave prend le rôle de réception. L’équilibrage de charge sortant continue sur les esclaves restants.

Mode 6 — Balance-ALB (équilibrage de charge adaptatif)

Le Mode 6 étend le Mode 5 en ajoutant l’équilibrage de charge entrant via la négociation ARP. Le pilote de bonding envoie périodiquement des réponses ARP avec différentes adresses MAC sources à différents clients, amenant ces clients à envoyer le trafic de retour vers différentes interfaces esclaves.

Le mécanisme de manipulation ARP : C’est la partie ingénieuse. Le pilote intercepte les réponses ARP et fait tourner l’adresse MAC source parmi les esclaves. Les clients mettent en cache ces entrées ARP et dirigent leur trafic vers l’esclave MAC qu’ils ont appris. Cela permet un équilibrage de charge entrant sans aucune configuration côté commutateur.

Mise en garde pratique : L’équilibrage entrant basé sur ARP ne fonctionne que pour les hôtes qui ont récemment communiqué avec le serveur bondé. Les nouvelles connexions arrivent toujours sur l’esclave principal jusqu’à l’envoi d’une réponse ARP. Dans les scénarios à taux de connexion élevé, la distribution entrante peut être inégale.

Meilleure utilisation : Environnements sans commutateurs compatibles LACP nécessitant un équilibrage de charge bidirectionnel. Un bon choix pour les environnements VPS Hosting où le commutateur virtuel de l’hyperviseur peut ne pas supporter LACP.

Tableau comparatif des modes de bonding

Configuration du bonding réseau sur Linux

Prérequis

“`bash

Verify bonding module is available

modinfo bonding

Load the module if not already loaded

modprobe bonding

“`

Configuration via systemd-networkd (approche moderne)

Créer `/etc/systemd/network/bond0.netdev` :

“`ini

[NetDev]

Name=bond0

Kind=bond

[Bond]

Mode=802.3ad

TransmitHashPolicy=layer3+4

MIIMonitorSec=100ms

LACPTransmitRate=fast

“`

Créer `/etc/systemd/network/bond0.network` :

“`ini

[Match]

Name=bond0

[Network]

Address=192.168.1.10/24

Gateway=192.168.1.1

“`

Créer `/etc/systemd/network/eth0.network` et `eth1.network` :

“`ini

[Match]

Name=eth0

[Network]

Bond=bond0

“`

Configuration via `/etc/network/interfaces` (Debian/Ubuntu)

“`bash

auto bond0

iface bond0 inet static

address 192.168.1.10

netmask 255.255.255.0

gateway 192.168.1.1

bond-slaves eth0 eth1

bond-mode 4

bond-miimon 100

bond-lacp-rate 1

bond-xmit-hash-policy layer3+4

auto eth0

iface eth0 inet manual

bond-master bond0

auto eth1

iface eth1 inet manual

bond-master bond0

“`

Vérification de l’état du bond

“`bash

Check bond status and slave states

cat /proc/net/bonding/bond0

Monitor interface statistics

ip -s link show bond0

Check LACP negotiation state (Mode 4)

cat /proc/net/bonding/bond0 | grep -A5 "LACP"

“`

La sortie `/proc/net/bonding/bond0` est l’outil de diagnostic le plus important. Elle affiche l’esclave actif, l’état du lien de chaque membre, l’état MII et (pour le Mode 4) les informations du partenaire LACP.

Bonding réseau sur les serveurs dédiés et VPS

Sur les Serveurs Dédiés bare-metal, vous avez un contrôle total sur la configuration NIC du serveur et (généralement) sur la configuration des ports du commutateur, faisant du Mode 4 (LACP) le choix naturel pour les charges de travail de production. La plupart des fournisseurs de centres de données peuvent configurer LACP sur vos ports de commutateur sur demande.

Pour les environnements VPS avec cPanel, la couche de réseau virtuel de l’hyperviseur gère le bonding sous-jacent au niveau de l’hôte. La VM invitée voit généralement un seul NIC virtuel, mais l’hôte peut exécuter des interfaces physiques bondées en dessous — offrant une redondance de manière transparente.

Lors du déploiement de charges de travail intensives en GPU sur l’infrastructure GPU Hosting, le bonding réseau devient critique pour alimenter les nœuds GPU suffisamment rapidement afin d’éviter la famine d’E/S. Les pipelines d’entraînement et le service d’inférence bénéficient tous deux de la bande passante agrégée que le bonding LACP fournit.

Pièges courants et cas particuliers

Conflits avec le Spanning Tree Protocol (STP) : Lors de l’ajout de ports bondés à un commutateur, STP peut temporairement bloquer les ports pendant la négociation. Configurez PortFast (ou équivalent) sur les ports du commutateur pour éviter des délais de 30 secondes lors des événements de montée de lien.

Incompatibilités MTU : Toutes les interfaces esclaves d’un bond doivent avoir des paramètres MTU identiques. Une incompatibilité provoque des pertes de paquets intermittentes extrêmement difficiles à diagnostiquer. Vérifiez toujours avec `ip link show` après la configuration.

Modes de timeout LACP : LACP supporte les modes de timeout « lent » (30 secondes) et « rapide » (1 seconde). Utilisez toujours `lacp-rate fast` (`bond-lacp-rate 1`) en production. Le mode lent signifie qu’un lien défaillant peut prendre jusqu’à 90 secondes pour être retiré du LAG.

Migration en direct de machines virtuelles : Si une VM avec une interface bondée est migrée vers un hôte différent, les adresses MAC du bond peuvent changer selon l’hyperviseur. Cela peut provoquer des entrées ARP obsolètes et une brève perte de connectivité. Préparez des ARP gratuits dans vos scripts de migration.

Hachage asymétrique : Avec le Mode 4 et le hachage `layer3+4`, le trafic du serveur A vers le serveur B peut traverser eth0, tandis que le trafic de retour de B vers A traverse eth1 sur le bond de B. C’est normal et attendu — chaque point de terminaison hache indépendamment son trafic sortant.

Interférence de NetworkManager : Sur les systèmes RHEL/CentOS, NetworkManager peut interférer avec les bonds configurés manuellement. Configurez les bonds via l’interface nmcli de NetworkManager ou désactivez NetworkManager pour les interfaces concernées en utilisant `NM_CONTROLLED=no` dans le fichier de configuration de l’interface.

Bonding vs. autres techniques réseau haute disponibilité

Le bonding réseau n’est pas la seule approche pour la redondance NIC. Comprendre quand utiliser des alternatives est tout aussi important.

MLAG (Multi-Chassis Link Aggregation) mérite une mention spéciale : il permet à un serveur exécutant le bonding Mode 4 de connecter ses deux NIC à deux commutateurs physiquement séparés, tous deux participant au même LAG logique. Cela élimine le commutateur lui-même comme point de défaillance unique — un niveau de redondance que le LACP standard à commutateur unique ne peut pas fournir.

Matrice de décision : choisir le bon mode de bonding

Utilisez ce cadre pour sélectionner votre mode de bonding :

Contrôlez-vous la configuration du commutateur ?

• Non → Aller au Mode 1, 5 ou 6
• Besoin d’un équilibrage de charge bidirectionnel ? → Mode 6
• Trafic principalement sortant ? → Mode 5
• Basculement pur, simplicité maximale ? → Mode 1
• Oui → Aller au Mode 0, 2 ou 4
• Besoin d’une négociation dynamique et de la conformité aux meilleures pratiques ? → Mode 4 (LACP)
• LAG statique, configuration plus simple ? → Mode 2 avec hachage layer3+4
• Exigence broadcast spécialisée ? → Mode 3

S’agit-il d’une interface de gestion/IPMI ? Utilisez toujours le Mode 1. Ne risquez jamais une interface de gestion sur un mode qui nécessite une configuration du commutateur.

Êtes-vous sur une plateforme cloud ou virtuelle ? Vérifiez si le commutateur virtuel de l’hyperviseur supporte LACP. Si non, le Mode 6 offre le meilleur équilibre entre distribution de charge et compatibilité.

Pour les équipes gérant plusieurs serveurs via des Panneaux de contrôle VPS, la vérification de l’état du bonding devrait faire partie de la liste de contrôle standard post-déploiement aux côtés de la vérification SSL via les Certificats SSL et des vérifications de propagation DNS après l’Enregistrement de domaine.

Liste de contrôle des points techniques essentiels

• Définissez toujours `miimon=100` et `downdelay=200 updelay=200` comme base pour la surveillance MII en production
• Utilisez `xmit_hash_policy=layer3+4` avec les Modes 2 et 4 pour assurer une distribution au niveau des flux plutôt qu’au niveau MAC
• Vérifiez `/proc/net/bonding/bond0` immédiatement après la configuration — ne supposez pas que ça fonctionne
• Configurez le taux LACP sur `fast` en Mode 4 pour réduire le temps de détection de basculement de 90 secondes à 3 secondes
• Assurez-vous que tous les NIC esclaves ont des paramètres MTU, de vitesse et de duplex identiques avant de les ajouter à un bond
• Sur les Serveurs Dédiés de production, demandez toujours la configuration LACP à votre fournisseur de centre de données plutôt que d’utiliser un LAG statique
• Testez explicitement le basculement en débranchant un câble — ne supposez pas que la configuration est correcte avant de l’avoir vérifiée dans des conditions de défaillance
• Documentez quel NIC physique correspond à quel esclave (eth0, eth1) en utilisant `ethtool -i eth0` pour éviter toute confusion lors de la maintenance physique
• Pour la redondance inter-commutateurs dans les environnements critiques, étudiez MLAG avant de vous contenter du LACP à commutateur unique

FAQ

Le bonding réseau double-t-il la vitesse d’un seul téléchargement de fichier ?

Non. Le bonding distribue le trafic sur les liens au niveau des flux (ou au niveau des paquets en Mode 0). Une seule connexion TCP n’utilise qu’un seul lien physique à la fois dans la plupart des modes. Le bonding augmente le débit agrégé sur plusieurs connexions simultanées, pas la vitesse d’une connexion individuelle.

Quelle est la différence entre le bonding Mode 4 (LACP) et un LAG statique ?

Un LAG statique (utilisé par les Modes 0 et 2) définit manuellement quels ports forment le groupe d’agrégation sans négociation. LACP (Mode 4) négocie dynamiquement le LAG à l’aide de paquets de contrôle, détectant automatiquement les mauvaises configurations, les liens défaillants et l’ajout/suppression de membres. LACP est plus robuste et constitue la norme industrielle pour les déploiements en production.

Puis-je configurer le bonding réseau sur un VPS ?

Cela dépend de l’hyperviseur et du fournisseur d’hébergement. La plupart des instances VPS cloud présentent un seul NIC virtuel à l’invité, avec le bonding géré au niveau de l’hyperviseur. Certains fournisseurs proposant des VPS de type bare-metal ou des instances cloud dédiées supportent le bonding au niveau de l’invité. Vérifiez auprès de votre fournisseur avant de tenter de configurer le bonding dans un invité VPS.

Que se passe-t-il pour les connexions actives lorsqu’un lien bondé tombe en panne ?

En Mode 1 (Active-Backup), le bond envoie un ARP gratuit après le basculement, mettant à jour les tables MAC du commutateur. Les connexions TCP existantes subissent une brève pause (généralement moins de 300ms avec une surveillance MII rapide) mais survivent généralement. En Mode 4, LACP détecte la défaillance et redistribue les flux vers les liens survivants — les flux existants sur le lien défaillant devront être rétablis par l’application.

Pourquoi mon bond Mode 4 n’affiche-t-il qu’un seul esclave actif dans `/proc/net/bonding/bond0` ?

La cause la plus courante est une mauvaise configuration côté commutateur. Vérifiez que les ports du commutateur sont configurés dans le même canal de port avec LACP activé en mode actif. Vérifiez également que `lacp-rate` est défini de manière cohérente des deux côtés. Une clé LACP ou une priorité système non concordante peut empêcher l’agrégation même lorsque les liens physiques sont actifs.