Configurer le bonding Linux : modes et active-backup sous CentOS 7.9
EdwardMoon
Le bonding Linux regroupe au moins deux interfaces réseau physiques en une interface logique. Il peut faire basculer les communications en cas de panne ou répartir la charge de plusieurs connexions, mais le résultat dépend du mode choisi et de la configuration des commutateurs. Après une comparaison des modes, ce guide explique comment configurer un bond active-backup avec network-scripts sous CentOS 7.9 et revenir à la configuration initiale.
Périmètre : cet exemple de maintenance concerne des adresses IPv4 statiques déjà gérées par network.service. CentOS Linux 7 n’est plus pris en charge depuis le 30 juin 2024 et ne doit pas servir de référence pour de nouveaux serveurs. Annonce officielle de fin de support de CentOS
Ce que le bonding permet, et ses limites
active-backup utilise une seule carte réseau à la fois et bascule sur une autre en cas de panne. Même avec deux cartes à 1 Gbit/s, la bande passante en fonctionnement normal reste limitée à celle de la carte active. Les modes de répartition de charge, dont LACP, peuvent en revanche distribuer plusieurs flux sur plusieurs cartes. Le débit d’une connexion unique n’est pas systématiquement multiplié par le nombre de cartes.
Le bonding utilise le pilote Linux bonding. Le teaming réseau fondé sur teamd est une autre implémentation répondant à des objectifs similaires : ne mélangez pas leurs méthodes de configuration. La redondance des liens ne protège pas nécessairement d’une panne simultanée du commutateur entier, du routeur amont ou d’une alimentation commune.
Modes de bonding et configuration des commutateurs
Cette comparaison concerne des serveurs reliés à des commutateurs. Les connexions directes et les topologies particulières doivent être validées séparément.
| Mode | Fonctionnement | Exigences côté commutateur | Point d’attention |
|---|---|---|---|
| 0: balance-rr | Répartit les paquets émis successivement entre les cartes. | Agrégation statique des ports généralement nécessaire. | L’ordre des paquets peut changer. |
| 1: active-backup | Une carte active, avec basculement en cas de panne. | Ni LACP ni agrégation statique nécessaires. | Les débits ne s’additionnent pas. |
| 2: balance-xor | Choisit le chemin d’émission selon une politique de hachage. | Agrégation statique des ports généralement nécessaire. | Ce mode ne négocie pas par LACP. |
| 3: broadcast | Envoie le même paquet sur toutes les cartes. | Agrégation des ports généralement nécessaire. | Le trafic est dupliqué ; les débits ne s’additionnent pas. |
| 4: 802.3ad / LACP | Répartit les flux au sein du groupe d’agrégation. | Configuration LACP sur les ports correspondants. | Vérifier la vitesse, le duplex et la politique de hachage du groupe. |
| 5: balance-tlb | Répartit l’émission ; la réception utilise une seule carte. | Aucune agrégation particulière nécessaire. | Vérifier la prise en charge par le pilote. |
| 6: balance-alb | Ajoute au TLB la répartition de réception IPv4. | Aucune agrégation particulière nécessaire. | Dépend de la négociation ARP et de la possibilité de modifier l’adresse MAC. |
Contrairement au mode 5, le mode 6 peut aussi répartir la réception IPv4. Distinguez l’agrégation statique des modes 0, 2 et 3 du LACP du mode 4. Consultez les conditions détaillées dans les sections sur les modes et la configuration des commutateurs de la documentation du noyau Linux.
Environnement et vérifications avant modification
L’exemple rattache eth0 et eth1 à bond0, avec l’adresse serveur 192.168.1.100/24 et la passerelle 192.168.1.1. Remplacez ces noms et adresses par ceux de votre environnement ; vérifiez l’absence de doublon IP et l’appartenance de la passerelle au même sous-réseau. Reliez les ports au même VLAN et au même réseau, sans placer les ports active-backup dans un groupe LACP.
L’application de la configuration interrompt les communications des cartes concernées. Ne procédez pas uniquement par SSH : prévoyez une voie d’administration indépendante, telle qu’IPMI, iDRAC ou la console de virtualisation, ainsi qu’une fenêtre de maintenance. Si vous utilisez des VLAN, bridges, IP virtuelles, plusieurs routes par défaut, du routage par règles ou IPv6, prévoyez séparément leur migration vers le bond. Le générateur ci-dessous ne convertit pas toutes ces configurations.
cat /etc/centos-release
uname -r
ip -br link
ip -br address
ip route show table all
ip rule show
systemctl is-active network
systemctl is-active NetworkManager
modinfo bonding
ethtool eth0
ethtool eth1
Vérifiez que network gère déjà le réseau et que NetworkManager est inactif. Sur un serveur géré par NetworkManager, n’arrêtez pas ce service pour suivre l’exemple : utilisez la procédure de bonding avec nmcli adaptée à cet environnement. Les deux outils ne doivent pas gérer la même carte simultanément.
modinfo bonding affiche les informations du module. Les noyaux habituels des distributions incluent le pilote bonding : n’installez pas un paquet kmod-bonding supplémentaire simplement parce qu’il n’apparaît pas dans lsmod. Si modinfo échoue, vérifiez d’abord la correspondance entre le noyau en cours d’exécution et les paquets de modules installés.
Contenu complet des fichiers ifcfg
Placez l’IP, la passerelle et les options de bonding dans /etc/sysconfig/network-scripts/ifcfg-bond0. miimon=100 surveille l’état du lien toutes les 100 millisecondes ; il ne garantit pas la connectivité de tout le chemin en amont.
DEVICE=bond0
NAME=bond0
TYPE=Bond
BONDING_MASTER=yes
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
IPADDR=192.168.1.100
PREFIX=24
GATEWAY=192.168.1.1
DEFROUTE=yes
PEERDNS=no
IPV6INIT=no
BONDING_OPTS="mode=active-backup miimon=100"
PEERDNS=no empêche ce profil de modifier les paramètres DNS. Après application, vérifiez que la résolution de noms fonctionne toujours. IPV6INIT=no indique que l’exemple est réservé à IPv4 : ne l’appliquez pas tel quel à un serveur utilisant IPv6.
Ne dupliquez pas l’IP ni la passerelle par défaut sur les cartes physiques ; définissez MASTER et SLAVE. Les deux sections suivantes correspondent à deux fichiers distincts.
# /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
NAME=eth0
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
MASTER=bond0
SLAVE=yes
IPV6INIT=no
# /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
NAME=eth1
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
MASTER=bond0
SLAVE=yes
IPV6INIT=no
Il ne doit rester aucun fichier ifcfg en double ni autre profil démarré automatiquement pour la même carte. Définissez les options propres au bond dans BONDING_OPTS. Avec une configuration ifcfg correcte, les scripts réseau chargent les modules nécessaires : il n’est pas utile d’ajouter systématiquement une ligne dans /etc/modules-load.d/bonding.conf. Configuration officielle du bonding avec ifcfg sous RHEL 7
Script Bash de sauvegarde et de préparation de la configuration
Enregistrez le contenu ci-dessous dans prepare-bond.sh et adaptez les variables à votre environnement. Le script sauvegarde les fichiers ifcfg et l’état du réseau dans un répertoire réservé à root, puis génère la nouvelle configuration ailleurs. Le remplacement des véritables fichiers ifcfg et le redémarrage des interfaces interviennent dans la section suivante.
#!/bin/bash
# CentOS 7.9 / network.service uniquement : crée seulement une sauvegarde et la configuration proposée.
set -euo pipefail
umask 077
BOND_DEVICE="bond0"
ETH0_DEVICE="eth0"
ETH1_DEVICE="eth1"
IP_ADDRESS="192.168.1.100"
PREFIX="24"
GATEWAY="192.168.1.1"
CFG_DIR="/etc/sysconfig/network-scripts"
die() { printf '%s\n' "$*" >&2; exit 1; }
valid_ipv4() {
local value="$1" octet a b c d
[[ "$value" =~ ^[0-9]{1,3}(\.[0-9]{1,3}){3}$ ]] || return 1
IFS=. read -r a b c d <<< "$value"
for octet in "$a" "$b" "$c" "$d"; do
(( 10#$octet <= 255 )) || return 1
done
}
[[ "$EUID" -eq 0 ]] || die "root로 실행하세요."
[[ -d "$CFG_DIR" ]] || die "network-scripts 경로가 없습니다."
for nic in "$BOND_DEVICE" "$ETH0_DEVICE" "$ETH1_DEVICE"; do
[[ "$nic" =~ ^[a-zA-Z0-9_-]{1,15}$ ]] || die "인터페이스 이름을 확인하세요."
done
[[ "$ETH0_DEVICE" != "$ETH1_DEVICE" ]] || die "서로 다른 물리 NIC가 필요합니다."
[[ "$BOND_DEVICE" != "$ETH0_DEVICE" && "$BOND_DEVICE" != "$ETH1_DEVICE" ]] ||
die "bond 이름이 물리 NIC와 같습니다."
[[ ! -e "/sys/class/net/$BOND_DEVICE" && ! -e "$CFG_DIR/ifcfg-$BOND_DEVICE" ]] ||
die "기존 bond가 있습니다. 기존 구성 변경은 이 예제 범위 밖입니다."
valid_ipv4 "$IP_ADDRESS" || die "IP 주소 형식이 잘못되었습니다."
valid_ipv4 "$GATEWAY" || die "게이트웨이 주소 형식이 잘못되었습니다."
[[ "$GATEWAY" != "$IP_ADDRESS" ]] || die "게이트웨이는 서버 자신과 달라야 합니다."
[[ "$PREFIX" =~ ^([1-9]|[12][0-9]|3[0-2])$ ]] || die "PREFIX는 1~32여야 합니다."
systemctl is-active --quiet network ||
die "기존 network.service 환경에서만 사용하세요."
if systemctl is-active --quiet NetworkManager; then
die "NetworkManager 환경입니다. 해당 환경의 nmcli 본딩 절차를 사용하세요."
fi
modinfo bonding >/dev/null
for nic in "$ETH0_DEVICE" "$ETH1_DEVICE"; do
[[ -e "/sys/class/net/$nic" ]] || die "NIC가 없습니다: $nic"
[[ -f "$CFG_DIR/ifcfg-$nic" ]] || die "기존 ifcfg 파일이 없습니다: $nic"
[[ ! -L "/sys/class/net/$nic/master" ]] || die "이미 다른 장치에 종속된 NIC입니다: $nic"
[[ ! -e "$CFG_DIR/route-$nic" && ! -e "$CFG_DIR/rule-$nic" &&
! -e "$CFG_DIR/route6-$nic" && ! -e "$CFG_DIR/rule6-$nic" ]] ||
die "별도 경로/정책 설정은 bond에 따로 이전해야 합니다: $nic"
if ip -6 address show dev "$nic" scope global | grep -q 'inet6 '; then
die "IPv6 주소가 있는 NIC입니다. IPv6 이전 계획을 먼저 작성하세요: $nic"
fi
done
PLAN_DIR=$(mktemp -d "/root/bond-plan.XXXXXXXX")
mkdir "$PLAN_DIR/before" "$PLAN_DIR/new"
for nic in "$ETH0_DEVICE" "$ETH1_DEVICE"; do
cp -a "$CFG_DIR/ifcfg-$nic" "$PLAN_DIR/before/"
done
ip address show > "$PLAN_DIR/address-before.txt"
ip route show table all > "$PLAN_DIR/routes-before.txt"
ip rule show > "$PLAN_DIR/rules-before.txt"
printf 'BOND_DEVICE=%q\nETH0_DEVICE=%q\nETH1_DEVICE=%q\n' \
"$BOND_DEVICE" "$ETH0_DEVICE" "$ETH1_DEVICE" > "$PLAN_DIR/names.sh"
cat > "$PLAN_DIR/new/ifcfg-$BOND_DEVICE" <<EOF
DEVICE=$BOND_DEVICE
NAME=$BOND_DEVICE
TYPE=Bond
BONDING_MASTER=yes
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
IPADDR=$IP_ADDRESS
PREFIX=$PREFIX
GATEWAY=$GATEWAY
DEFROUTE=yes
PEERDNS=no
IPV6INIT=no
BONDING_OPTS="mode=active-backup miimon=100"
EOF
for nic in "$ETH0_DEVICE" "$ETH1_DEVICE"; do
cat > "$PLAN_DIR/new/ifcfg-$nic" <<EOF
DEVICE=$nic
NAME=$nic
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
MASTER=$BOND_DEVICE
SLAVE=yes
IPV6INIT=no
EOF
done
printf '백업 및 후보 설정: %s\n' "$PLAN_DIR"
printf '실제 설정과 네트워크 상태는 변경하지 않았습니다.\n'
Vérifiez d’abord la syntaxe avec bash -n prepare-bond.sh, puis préparez les fichiers avec sudo bash prepare-bond.sh. Consignez le chemin affiché et la sauvegarde. Les contrôles du script ne vérifient ni les doublons IP, ni la correspondance des VLAN, ni la politique des commutateurs, ni toutes les dépendances de routage : les vérifications préalables restent nécessaires.
Appliquer depuis la console
Exécutez les commandes ci-dessous une à une et arrêtez-vous en cas d’échec. Le code de retour 1 de diff signifie qu’une différence existe. Vérifiez qu’elle correspond au changement attendu avant de désactiver les cartes. L’utilisation de l’IP de l’exemple peut également modifier l’adresse d’administration.
# Exécuter dans une console root. Remplacer le chemin ci-dessous par celui affiché par le générateur.
PLAN_DIR=/root/bond-plan.XXXXXXXX
test -f "$PLAN_DIR/names.sh" || exit 1
source "$PLAN_DIR/names.sh"
CFG_DIR=/etc/sysconfig/network-scripts
# Vérifier la configuration proposée : les communications ne sont pas encore modifiées.
cat "$PLAN_DIR/new/ifcfg-$BOND_DEVICE"
diff -u "$PLAN_DIR/before/ifcfg-$ETH0_DEVICE" "$PLAN_DIR/new/ifcfg-$ETH0_DEVICE"
diff -u "$PLAN_DIR/before/ifcfg-$ETH1_DEVICE" "$PLAN_DIR/new/ifcfg-$ETH1_DEVICE"
# Exécuter seulement après vérification. Les communications des cartes concernées s’arrêtent à partir d’ici.
# Si ifdown échoue, vérifier la cause et arrêter la procédure.
ifdown "$ETH0_DEVICE"
ifdown "$ETH1_DEVICE"
# Installer les trois fichiers ci-dessous. En cas d’échec, restaurer sans activer les interfaces.
install -o root -g root -m 600 "$PLAN_DIR/new/ifcfg-$BOND_DEVICE" "$CFG_DIR/ifcfg-$BOND_DEVICE"
install -o root -g root -m 600 "$PLAN_DIR/new/ifcfg-$ETH0_DEVICE" "$CFG_DIR/ifcfg-$ETH0_DEVICE"
install -o root -g root -m 600 "$PLAN_DIR/new/ifcfg-$ETH1_DEVICE" "$CFG_DIR/ifcfg-$ETH1_DEVICE"
restorecon "$CFG_DIR/ifcfg-$BOND_DEVICE" "$CFG_DIR/ifcfg-$ETH0_DEVICE" "$CFG_DIR/ifcfg-$ETH1_DEVICE"
ifup "$BOND_DEVICE"
ifup "$ETH0_DEVICE"
ifup "$ETH1_DEVICE"
Vérifier les adresses, le mode et le basculement
ip -br address show bond0
ip -d link show bond0
ip link show master bond0
cat /proc/net/bonding/bond0
ip route
ping -c 4 -I bond0 192.168.1.1
ethtool eth0
ethtool eth1
La présence de bond0 ne suffit pas. Vérifiez que l’adresse n’est affectée qu’au bond, que les deux cartes physiques lui sont rattachées et que la route par défaut est correcte. Dans /proc/net/bonding/bond0, examinez notamment les champs suivants.
# Exemple de format ; il ne s’agit pas de mesures effectuées sur un serveur.
Bonding Mode: fault-tolerance (active-backup)
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
...
Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
...
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Currently Active Slave indique la carte actuellement utilisée pour communiquer. Vérifiez que les deux champs MII Status sont normaux, puis contrôlez la vitesse réelle de chaque lien physique avec ethtool. Ne considérez pas la vitesse cumulée affichée pour le bond comme un débit mesuré.
- Depuis un client indépendant, envoyez en continu des ping et des requêtes réelles au service sur l’IP du serveur.
- En gardant la console de maintenance ouverte, débranchez uniquement le câble de la carte active ou désactivez son port de commutateur.
- Vérifiez le basculement vers l’autre carte et la reprise des communications. Consignez les pertes de paquets et l’impact sur le service.
- Rétablissez le chemin interrompu et vérifiez l’état des deux liens. Testez l’autre chemin de la même manière.
- Vérifiez une nouvelle session d’administration, la résolution DNS et la réponse des services, puis la persistance des paramètres lors d’un redémarrage planifié.
Un test de câble débranché n’équivaut pas à un test de panne du réseau amont. miimon surveille l’état du lien ; il peut ne pas détecter une panne de commutateur ou de routeur amont si le lien reste actif. Testez séparément le périmètre de pannes à couvrir et la configuration des commutateurs.
Restaurer la configuration initiale en cas de problème
Effectuez la procédure suivante depuis la console. Elle concerne une nouvelle configuration, sans bond préexistant, et restaure les fichiers des cartes sauvegardés par le script de préparation. Contrôlez l’état et les erreurs à chaque étape, puis vérifiez les fichiers d’origine avant de les restaurer. Si vous avez aussi modifié le routage, le DNS ou le pare-feu, annulez séparément ces changements.
# Indiquer le chemin réel de sauvegarde affiché lors de l’application. Exécuter dans une console root.
PLAN_DIR=/root/bond-plan.XXXXXXXX
test -f "$PLAN_DIR/names.sh" || exit 1
source "$PLAN_DIR/names.sh"
CFG_DIR=/etc/sysconfig/network-scripts
# Vérifier chaque étape. Si ifdown échoue pour un bond pas encore créé, examiner d’abord l’état.
ifdown "$BOND_DEVICE"
ifdown "$ETH0_DEVICE"
ifdown "$ETH1_DEVICE"
# Cette procédure concerne uniquement une nouvelle configuration sans bond préexistant.
ip link delete "$BOND_DEVICE" type bond
mv "$CFG_DIR/ifcfg-$BOND_DEVICE" "$PLAN_DIR/ifcfg-bond-failed"
cp -a "$PLAN_DIR/before/ifcfg-$ETH0_DEVICE" "$CFG_DIR/ifcfg-$ETH0_DEVICE"
cp -a "$PLAN_DIR/before/ifcfg-$ETH1_DEVICE" "$CFG_DIR/ifcfg-$ETH1_DEVICE"
restorecon "$CFG_DIR/ifcfg-$ETH0_DEVICE" "$CFG_DIR/ifcfg-$ETH1_DEVICE"
ifup "$ETH0_DEVICE"
ifup "$ETH1_DEVICE"
ip -br address
ip route
journalctl -u network --since '-10 minutes' --no-pager
Après restauration, comparez les adresses et routes initiales à address-before.txt et routes-before.txt, puis vérifiez l’accès d’administration et les services depuis un autre client. Si Link Failure Count augmente ou si le mode diffère de celui attendu, vérifiez d’abord les câbles, les VLAN des commutateurs, l’agrégation des ports, les profils en double et BONDING_OPTS.