Network Bonding su Linux: guida completa a ridondanza e throughput aggregato
Perché il bonding delle interfacce di rete è ancora rilevante
Una singola scheda di rete è un punto singolo di fallimento. Su un server di produzione, un cavo che si stacca, una porta dello switch che si guasta o un driver che va in crash possono bastare per portare giù un servizio. Il network bonding su Linux (noto anche come NIC teaming o link aggregation) risolve il problema aggregando due o più interfacce fisiche in un’unica interfaccia logica gestita dal kernel: bond0. A seconda della modalità scelta, si ottiene ridondanza, throughput aggregato maggiore, oppure entrambi.
Non è una tecnologia nuova, il driver bonding è nel kernel Linux da anni, ma resta uno degli strumenti più sottoutilizzati nella cassetta degli attrezzi di chi amministra server fisici, hypervisor o anche semplici home lab. Vediamo come funziona davvero, quali modalità scegliere e come configurarlo con gli strumenti che si trovano oggi sulle distribuzioni più diffuse.
Bonding non è bridging
Prima di entrare nella configurazione, vale la pena chiarire un equivoco comune: il bonding non è la stessa cosa del bridging. Un bridge collega segmenti di rete distinti, permettendo al traffico di attraversare due reti separate. Il bonding, invece, aggrega più interfacce fisiche facendole apparire al sistema operativo e alle applicazioni come un unico dispositivo di rete. Sono strumenti diversi, per scopi diversi, e vanno configurati in modo diverso.
Un altro equivoco frequente riguarda la banda: il bonding non raddoppia automaticamente il throughput di una singola connessione TCP. La maggior parte delle modalità distribuisce connessioni multiple su interfacce diverse, non spezzetta un singolo trasferimento su tutti i link contemporaneamente. Il guadagno di banda aggregata si ottiene quando più flussi sono attivi in parallelo, non con un singolo trasferimento di file.
Va inoltre notato che le interfacce WiFi generalmente non sono compatibili con il bonding: la maggior parte dei driver wireless non supporta la modalità promiscua e la manipolazione dell’indirizzo MAC richieste dal driver bonding. Il bonding va quindi limitato a interfacce Ethernet cablate.
Le modalità di bonding: quale scegliere
Il driver bonding del kernel Linux supporta sette modalità. Per la maggior parte degli scenari operativi ne bastano tre o quattro:
- Mode 0 (balance-rr): round-robin, trasmette i pacchetti in sequenza su tutte le interfacce. Offre load balancing e fault tolerance, ma richiede un gruppo di aggregazione statico configurato correttamente sullo switch. Senza questo, si ottengono pacchetti fuori ordine e prestazioni scadenti.
- Mode 1 (active-backup): una sola interfaccia attiva alla volta; se quella attiva si guasta, subentra la backup. Non richiede alcuna configurazione sullo switch. È la modalità più sicura e compatibile, ideale quando l’obiettivo è puramente la ridondanza.
- Mode 2 (balance-xor): selezione dell’interfaccia basata su un hash degli indirizzi MAC sorgente e destinazione. Load balancing per connessione e fault tolerance, richiede supporto dello switch.
- Mode 3 (broadcast): trasmette ogni pacchetto su tutte le interfacce contemporaneamente. Usata raramente, solo in scenari di fault tolerance molto specifici.
- Mode 4 (802.3ad / LACP): link aggregation dinamica secondo lo standard IEEE 802.3ad. Richiede uno switch gestito con LACP abilitato. È la modalità più usata in ambito enterprise: se lo switch la supporta, è la scelta corretta per la produzione.
- Mode 5 (balance-tlb): load balancing adattivo del traffico in uscita in base al carico corrente su ciascuna interfaccia; il traffico in ingresso arriva sull’interfaccia attiva corrente. Non richiede configurazione dello switch.
- Mode 6 (balance-alb): come mode 5, ma bilancia anche il traffico in ingresso tramite negoziazione ARP. Non richiede switch gestito e offre buoni guadagni di throughput, anche se alcuni switch e ambienti virtualizzati gestiscono il bilanciamento basato su ARP in modo incoerente: va testato prima di affidarcisi in produzione.
Per un homelab o un setup semplice senza switch gestito, Mode 1 (failover puro) o Mode 6 (bilanciamento senza configurazione switch) sono le scelte pratiche. Per server di produzione con switch gestito, Mode 4 (LACP) è la strada corretta.
Prerequisiti
Servono almeno due interfacce di rete fisiche (o virtuali, in una VM), accesso root o sudo, il modulo kernel bonding e uno strumento di gestione della rete (NetworkManager, systemd-networkd o Netplan, a seconda della distribuzione).
Verificare che il modulo bonding sia disponibile:
modinfo bonding
Se restituisce le informazioni del modulo, si può procedere caricandolo:
sudo modprobe bonding
Prima di modificare qualsiasi configurazione, è indispensabile identificare le interfacce disponibili:
ip link show
Sui sistemi moderni i nomi saranno del tipo enp3s0, enp4s0, oppure i più tradizionali eth0, eth1. Annotarli, perché verranno referenziati per tutta la configurazione.
Metodo 1: NetworkManager (desktop e la maggior parte dei server moderni)
Su Ubuntu, Fedora, Debian con NetworkManager, o qualunque distribuzione desktop, questo è l’approccio più semplice, grazie al supporto per il bonding consolidato da anni tramite nmcli.
Creare l’interfaccia bond:
sudo nmcli con add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100"
Aggiungere le interfacce fisiche come slave del bond:
sudo nmcli con add type ethernet slave-type bond con-name bond0-slave1 ifname enp3s0 master bond0
sudo nmcli con add type ethernet slave-type bond con-name bond0-slave2 ifname enp4s0 master bond0
Assegnare un indirizzo IP statico al bond:
sudo nmcli con modify bond0 ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns 1.1.1.1 ipv4.method manual
Oppure, per usare il DHCP:
sudo nmcli con modify bond0 ipv4.method auto
Attivare il bond:
sudo nmcli con up bond0
Le interfacce slave dovrebbero attivarsi automaticamente. In caso contrario, portarle su manualmente:
sudo nmcli con up bond0-slave1
sudo nmcli con up bond0-slave2
Verificare lo stato del bond:
cat /proc/net/bonding/bond0
Il file /proc/net/bonding/bond0 è lo strumento diagnostico principale: va consultato ogni volta che qualcosa non sembra funzionare come previsto.
Metodo 2: systemd-networkd (server e installazioni minimali)
Su server senza NetworkManager, systemd-networkd gestisce il bonding in modo pulito. Creare il file netdev del bond:
sudo nano /etc/systemd/network/10-bond0.netdev
[NetDev]
Name=bond0
Kind=bond
[Bond]
Mode=active-backup
MIIMonitorSec=100ms
UpDelaySec=200ms
DownDelaySec=200ms
Creare la configurazione di rete per l’interfaccia bond (esempio DHCP):
sudo nano /etc/systemd/network/20-bond0.network
[Match]
Name=bond0
[Network]
DHCP=yes
Vincolare le interfacce fisiche al bond, un file per ciascuno slave:
sudo nano /etc/systemd/network/30-bond0-slave1.network
[Match]
Name=enp3s0
[Network]
Bond=bond0
Riavviare systemd-networkd e verificare:
sudo systemctl restart systemd-networkd
cat /proc/net/bonding/bond0
Metodo 3: Netplan (Ubuntu Server)
Ubuntu Server 18.04 e successivi usano Netplan come layer di configurazione di rete predefinito. Editare il file (di solito /etc/netplan/01-netcfg.yaml):
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
dhcp4: no
enp4s0:
dhcp4: no
bonds:
bond0:
interfaces:
- enp3s0
- enp4s0
addresses:
- 192.168.1.100/24
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses:
- 1.1.1.1
parameters:
mode: active-backup
mii-monitor-interval: 100
primary: enp3s0
Applicare la configurazione:
sudo netplan apply
Se si sta lavorando da remoto, Netplan offre una modalità di test sicura che ripristina automaticamente la configurazione precedente dopo 120 secondi se non viene confermata:
sudo netplan try
Per usare LACP, basta modificare il blocco parameters:
parameters:
mode: 802.3ad
lacp-rate: fast
mii-monitor-interval: 100
transmit-hash-policy: layer2+3
Metodo 4: LACP (Mode 4) con switch gestito
Con uno switch gestito che supporta LACP, Mode 4 vale la configurazione aggiuntiva: si ottiene link aggregation reale con negoziazione dinamica. Sul lato switch, le porte interessate vanno configurate come LAG (Link Aggregation Group) con LACP abilitato: su Cisco il comando è channel-group X mode active; sulla maggior parte degli switch gestiti consumer c’è una sezione LAG o Trunk nell’interfaccia web.
Sul lato Linux, l’unica differenza rispetto al Metodo 1 sono le opzioni del bond:
sudo nmcli con add type bond con-name bond0 ifname bond0 bond.options "mode=802.3ad,miimon=100,lacp_rate=fast"
La policy transmit-hash-policy: layer2+3 distribuisce il traffico basandosi sia sull’indirizzo MAC sia sull’IP, offrendo una distribuzione del carico migliore rispetto alla policy predefinita solo layer2.Attenzione: se si abilita LACP sul lato Linux ma lo switch non è configurato di conseguenza, il bond torna a usare un solo link attivo. Non va in errore, ma non si ottiene alcuna aggregazione: va sempre configurato prima lo switch.
Testare il failover
Con il bonding in active-backup configurato, si può simulare un guasto e osservare il recupero. In un terminale, avviare un ping continuo verso il gateway:
ping 192.168.1.1
In un altro terminale, disattivare l’interfaccia attiva:
sudo ip link set enp3s0 down
Si osserveranno al massimo uno o due pacchetti persi, poi il traffico continuerà a fluire attraverso l’interfaccia di backup. Verificare lo stato del bond:
cat /proc/net/bonding/bond0
La riga Currently Active Slave mostrerà il passaggio alla seconda interfaccia. Per impostare un’interfaccia primaria preferita:
sudo nmcli con modify bond0 bond.options "mode=active-backup,miimon=100,primary=enp3s0"
Comandi utili per il monitoraggio
# Stato del bond in tempo reale
watch -n 1 cat /proc/net/bonding/bond0
# Traffico sull'interfaccia bond
sudo iftop -i bond0
# Stato IP e link
ip addr show bond0
ip link show bond0
# Conteggio dei fallimenti di link (utile per individuare cavi difettosi)
grep "Link Failure Count" /proc/net/bonding/bond0
Se il contatore dei fallimenti su una sola interfaccia cresce mentre il sistema funziona normalmente, probabilmente c’è un cavo o una porta dello switch difettosa: conviene sostituirli prima che il guasto si presenti nel momento peggiore.
Problemi comuni e soluzioni
Il bond non ha IP dopo il riavvio
Probabilmente le interfacce slave vengono attivate prima che il bond sia inizializzato. Con systemd-networkd, i numeri più bassi vengono processati per primi: assicurarsi che il file netdev (10-bond0.netdev) abbia un numero inferiore rispetto ai file network degli slave. Verificare anche che il modulo si carichi al boot:
echo "bonding" | sudo tee /etc/modules-load.d/bonding.conf
Solo uno slave risulta attivo anche in round-robin o LACP
Lo switch non è configurato per il LAG. Configurarlo correttamente, oppure passare a Mode 1 o Mode 6, che non richiedono configurazione dello switch.
I drop di ping durante il failover durano più del previsto
Abbassare il valore di miimon (l’intervallo di polling predefinito è 100ms):
bond.options "mode=active-backup,miimon=50,updelay=100,downdelay=100"
updelay e downdelay prevengono il flapping su link instabili: impostarli ad almeno il doppio del valore di miimon.
Conclusione
Il network bonding è una di quelle funzionalità che sembrano complicate finché non si mettono effettivamente in pratica. Il modulo kernel è già presente nella maggior parte delle distribuzioni, la configurazione è lineare, e il risultato è concreto: failover a downtime quasi zero, throughput aggregato maggiore, o entrambi, a seconda della modalità scelta.
Per chi non ha certezze su quale modalità scegliere, Mode 1 è il punto di partenza più sicuro: non richiede configurazione dello switch, funziona ovunque e il failover è quasi istantaneo. Si può poi passare a Mode 4 con LACP quando si dispone di uno switch gestito e si desidera una vera link aggregation. In entrambi i casi, /proc/net/bonding/bond0 resta lo strumento diagnostico di riferimento: va controllato dopo il setup, dopo ogni modifica, e ogni volta che qualcosa sembra non funzionare come dovrebbe.
Fonte: LinuxBlog.io
Two network interfaces are better than one. With Linux network bonding (also known as NIC bonding or link aggregation), you can combine multiple NICs into
Hayden James (LinuxBlog.io)
Marcel Geveler
in reply to netzpolitik.org • • •ʙwɑnɑ нoɴoʟʊʟʊ reshared this.
Holger
in reply to netzpolitik.org • • •ʙwɑnɑ нoɴoʟʊʟʊ reshared this.
jesterchen42
in reply to netzpolitik.org • • •Danke, das brauchte ich gerade.
Es wird echt Zeit, sich zu organisieren. Massiv. Was auch immer das bedeutet und erfordert...
reshared this
ʙwɑnɑ нoɴoʟʊʟʊ e Lord Caramac the Clueless, KSC reshared this.
Liz
in reply to netzpolitik.org • • •Es wird Jahrzehnte brauchen, um den Schaden, den diese Merz Regierung angerichtet hat und weiter anrichten wird, überhaupt halbwegs wieder beheben zu können.
@netzpolitik_feed @markusreuter
reshared this
ʙwɑnɑ нoɴoʟʊʟʊ e Lord Caramac the Clueless, KSC reshared this.
punIssuer
in reply to netzpolitik.org • • •Es könnte so einfach sein – Gesetzespakete ("Omnibusse"), die auch nur eine fragliche Änderung enthalten, dürfen einfach nicht mehr akzeptiert werden. Effizienz darf niemals zu Lasten von Richtigkeit gehen!
Bonus Idee: In jeden Omnibus ein Gesetz schmuggeln (oder in manche mehrere), das das Einbringen fachfremder Gesetze in einen Themen-Omnibus mit Haftstrafe belegt.
reshared this
Lord Caramac the Clueless, KSC reshared this.