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