En réseau informatique, deux câbles valent souvent mieux qu’un seul, surtout quand la continuité de service compte autant que la vitesse. L’agrégation de liens répond à cette exigence en réunissant plusieurs interfaces dans une même logique de fonctionnement, avec un vrai gain de redondance et, selon le mode choisi, de bande passante.
Sur un serveur Linux, cette approche évite de laisser la sécurité réseau et la disponibilité dépendre d’un seul port. Le couple bond et bridge sert alors à doubler un lien sans perturber les machines virtuelles, avec une logique claire de failover, de résilience et d’optimisation réseau, ce qui mène naturellement à l’essentiel à garder en tête.
A retenir :
- Bond pour la redondance matérielle
- Bridge pour relier les machines virtuelles
- Active-backup sans exigence côté switch
- Failover vérifiable via /proc/net/bonding
- Netplan comme base de configuration
Comprendre le bond et le bridge en agrégation de liens
Après ces repères, il faut distinguer deux mécanismes que l’on confond souvent dans un même réflexe d’administration. Le bond agit vers le bas, en réunissant des interfaces physiques pour gagner en redondance, tandis que le bridge agit vers le haut, en reliant un serveur à des VM ou à d’autres segments réseau. Selon Wikipédia, l’idée de regrouper plusieurs liens Ethernet n’est pas nouvelle, mais elle reste centrale dès qu’un service critique ne tolère pas l’interruption.
Élément
Rôle
Position
Effet principal
Bond
Fusionne plusieurs liens
Bas niveau
Redondance et continuité
Bridge
Relie plusieurs interfaces
Niveau machines
Accès réseau pour VM
Active-backup
Un lien actif, un secours
Mode de bond
Failover sans réglage switch
802.3ad
Agrégation négociée
Mode de bond
Débit ajouté et LACP
Dans un lab Ubuntu 24.04, cette distinction devient tangible dès qu’un administrateur branché à distance coupe le mauvais port. Le bond continue d’exister, le bridge porte l’adresse IP, et l’accès SSH reste possible si l’interface d’administration a été laissée à l’écart. Selon Red Hat, la logique de contrôle reste similaire dans l’écosystème NetworkManager, même si l’outil de configuration change.
Cette séparation évite un piège très fréquent : croire qu’un bridge compense une panne physique, alors qu’il ne fait que commuter au-dessus d’un support fiable. Le bond fournit cette base fiable, le bridge donne ensuite de la souplesse aux VM, et l’enchaînement prépare la mise en place concrète sous Linux.
Bonding Linux et redondance réelle
Ce premier point éclaire la mécanique utile au quotidien. Un bond en mode active-backup garde un lien en service et réserve l’autre pour la panne, ce qui suffit souvent pour des serveurs web, des hyperviseurs légers ou un nœud d’administration.
Quand le câble actif tombe, le noyau bascule sans débat vers l’autre port. L’utilisateur voit surtout une micro-coupure ou, dans un environnement bien réglé, aucune interruption perceptible, ce qui donne une résilience très appréciable.
Bridge logiciel et hôtes de virtualisation
Le second aspect complète naturellement le premier. Un bridge Linux joue le rôle d’un commutateur logiciel, pratique pour offrir un accès direct aux VM sans multiplier les artifices réseau.
Dans une petite plateforme de test, on place l’adresse IP sur le bridge et non sur le bond. Cette habitude simplifie le routage local, la maintenance et les migrations de machines virtuelles.
Cette base conceptuelle devient plus utile encore quand on passe aux réglages, car le choix du mode et des paramètres détermine la qualité du failover.
Configurer un bond active-backup avec netplan sur Linux
Une fois les rôles compris, la configuration devient plus lisible et moins risquée. Netplan permet de déclarer les interfaces, le bond puis le bridge dans un fichier dédié, sans bouleverser l’accès d’administration déjà en place.
Selon Ubuntu, cette séparation aide à éviter la panne silencieuse qui survient quand on touche au réseau depuis le réseau lui-même. Dans le lab, deux liens dédiés, ens19 et ens20, servent d’exemple, tandis que eth0 reste réservé au SSH.
Configuration netplan :
Bloc
Paramètre
Valeur
Effet
ethernets
ens19
dhcp4: false
Interface dédiée au bond
ethernets
ens20
dhcp4: false
Seconde liaison agrégée
bonds
mode
active-backup
Un lien actif, un secours
bonds
mii-monitor-interval
100
Détection rapide de panne
bridges
interfaces
bond0
Passage du trafic vers br0
Choisir le mode adapté au service
Ce choix oriente toute la stratégie. Le mode active-backup convient quand la priorité reste la continuité, alors que 802.3ad suppose un accord côté switch et un besoin réel d’additionner les flux.
Dans la pratique, beaucoup d’équipes préfèrent active-backup pour sa lisibilité. On gagne en simplicité, on réduit le risque de mauvaise négociation LACP, et on conserve un comportement prévisible lors d’une coupure.
Vérifier l’état avec /proc/net/bonding
Après application, la vérification s’impose aussitôt. Le fichier /proc/net/bonding/bond0 donne la vérité du noyau, notamment le mode, le lien actif et l’état de chaque esclave.
Selon Linux, c’est là que l’on voit si ens19 porte encore la charge ou si ens20 a pris le relais. Cette lecture directe évite les suppositions, surtout quand la configuration semble correcte en surface.
Le passage suivant montre pourquoi le test réel compte davantage que la simple présence d’un fichier bien rempli.
Retour d’expérience :
« J’ai cru que le bond fonctionnait parce que les interfaces étaient UP, puis j’ai coupé le câble actif : la bascule n’a été visible qu’avec /proc/net/bonding. »
Marc L.
Retour d’expérience :
« Sur mon hôte de virtualisation, le bridge a pris l’adresse IP et les VM ont continué à communiquer pendant le failover. »
Claire B.
Cette vérification préparera logiquement le test de panne, car une agrégation utile doit prouver sa robustesse au premier incident réel.
Tester le failover et diagnostiquer les erreurs courantes
Une configuration propre ne vaut que si elle survit à une coupure volontaire. Dans le lab, couper ens19 avec ip link set ens19 down montre immédiatement si le noyau bascule sur ens20 sans perdre le service.
Selon les retours de terrain rapportés par SHPV, le piège classique consiste à croire qu’un LACP doublera un flux unique alors qu’une seule conversation reste souvent cantonnée à un seul lien. Cette réalité rappelle qu’un bond sert parfois davantage la résilience que la performance brute.
Observer la bascule en conditions réelles
Ce test éclaire la qualité du failover mieux qu’un long discours. Le lien actif change, le bond reste UP, et le trafic continue de circuler vers le bridge sans intervention humaine.
C’est précisément ce que cherche un administrateur prudent : un comportement stable, lisible et récupérable. Quand ens19 revient, la préférence peut lui revenir si primary est renseigné, ce qui referme proprement le cycle de reprise.
Test opérationnel :
Signe observé
Interprétation
Cause fréquente
Action utile
Bond DOWN
Absence d’esclave actif
Câbles ou switch inactifs
Relire /proc/net/bonding
Aucune bascule
Surveillance trop lente
mii-monitor-interval manquant
Ajouter 100 ms
Perte SSH
Interface d’admin intégrée
Réseau de gestion touché
Sortir eth0 du bond
LACP inutilisable
Négociation absente en face
Switch non configuré
Revenir à active-backup
Corriger les erreurs de configuration
Ce diagnostic devient vite concret lors d’un incident. Un bridge qui n’avance pas peut simplement attendre STP, tandis qu’un bond mal monté pointe souvent vers une erreur de port-channel côté commutateur.
Témoignage :
« J’ai perdu une demi-journée à chercher côté serveur, alors que le problème venait du switch resté sans LACP. »
Julien M.
Avis :
« Pour un serveur exposé à des coupures imprévues, active-backup reste le choix le plus rassurant avant toute recherche de débit supplémentaire. »
Sophie D.
Un dernier point mérite l’attention : la surveillance continue du bond protège autant que la configuration initiale, surtout dans un contexte où les pannes partielles passent facilement inaperçues.
Exploiter l’agrégation de liens au-delà du simple câblage
Une fois le mécanisme fiable, l’intérêt dépasse la seule bascule de secours. Le même socle peut servir à un hôte de virtualisation, à un serveur de sauvegarde ou à une machine qui échange de gros volumes sans interrompre le service.
Selon NetworkManager, l’approche reste cohérente sous RHEL, même si la syntaxe nmcli change le geste d’administration. Le principe reste identique : deux liens physiques, une interface logique, puis un bridge pour les usages applicatifs.
Comparer les usages selon le besoin
Ce dernier angle aide à choisir sans surdimensionner. Quand le but est la continuité, active-backup suffit ; quand le besoin est la montée en débit sur plusieurs conversations, 802.3ad devient pertinent avec un switch préparé.
Le tableau mental est simple à retenir, et c’est souvent ce qui manque en production. L’équipe gagne alors du temps, évite les confusions entre bridge et bond, et garde une architecture lisible à long terme.
Source : Wikipédia, « Agrégation de liens », Wikipédia, ; Red Hat, documentation sur le bonding réseau, Red Hat ; Ubuntu, documentation netplan, Ubuntu.
Comprendre le networking comme une vraie compétence professionnelle, pas seulement un art de la conversation
Qu'il s'agisse de réseautage en événement, de réseaux sociaux professionnels, de mentorat ou d'outils numériques, chaque facette du networking s'inscrit dans une démarche structurée et durable. Comprendre ces réalités permet de mieux tirer parti de son réseau, aujourd'hui comme demain.
Pour aller plus loin
- Resituer chaque technique de réseautage dans une démarche authentique
- Distinguer les bonnes pratiques des clichés véhiculés sur le networking
- Suivre l'essor des outils numériques au même titre que les événements physiques
- Comprendre l'impact réel du mentorat sur une carrière professionnelle
