Bonding LACP su Linux: configurazione, verifica e risoluzione dei problemi

Il bonding LACP su Linux combina più interfacce Ethernet in un unico collegamento logico, offrendo una maggiore larghezza di banda aggregata e il failover automatico tra le schede di rete fisiche. Utilizza lo standard IEEE 802.3ad, con entrambe le parti (server e switch) che negoziano quali collegamenti sono attivi e come viene distribuito il traffico. Questo post spiega cosa fa effettivamente LACP, quando preferirlo alle altre modalità di bonding di Linux, come configurarlo su un server Linux moderno e come verificare che funzioni.

Che cos'è l'aggregazione di link e il LACP?

L'aggregazione di link combina più connessioni di rete fisiche in un unico canale logico. Ha due scopi: aumentare la larghezza di banda totale disponibile nel gruppo di link e fornire un failover automatico se un singolo link del gruppo si interrompe.

LACP, il Link Aggregation Control Protocol, è la versione dinamica dell'aggregazione di link definita dallo standard IEEE 802.3ad. Invece di basarsi su una configurazione statica su entrambe le estremità, LACP scambia pacchetti di controllo chiamati LACPDU tra il server e lo switch. Le due parti negoziano quali collegamenti unirsi all'aggregazione, monitorano lo stato di salute di ciascun collegamento e inseriscono o rimuovono membri dal gruppo al variare delle condizioni.

In un contesto Linux, LACP funziona come modalità 4 (802.3ad) del driver bonding del kernel. Il driver crea un'interfaccia logica (tipicamente bond0) che possiede l'indirizzo IP, mentre le interfacce fisiche come eth0 e eth1 diventano subordinate al bonding. Dal punto di vista del sistema operativo esiste un'unica interfaccia di rete. Dal punto di vista fisico esistono più collegamenti Ethernet paralleli.

Alcune cose che LACP specificatamente non fa, ma che spesso ci si aspetta:

• Una singola connessione TCP viaggia ancora su un unico collegamento fisico. LACP bilancia i flussi, non i pacchetti all'interno di un flusso. Due collegamenti 1 GbE in bonding non renderanno un singolo download più veloce di 1 Gbps.
• LACP richiede uno switch che supporti lo standard 802.3ad. Non formerà un bond con uno switch non gestito o non LACP.
• Tutti i collegamenti membri devono funzionare alla stessa velocità e con lo stesso duplex. Non è possibile collegare una porta da 1 GbE con una porta da 10 GbE.

Modalità di bonding Linux: quando utilizzare LACP

Il driver di bonding di Linux supporta sette modalità. La maggior parte delle implementazioni in produzione ne utilizza una delle tre.

Modalità 1: active-backup

Un'interfaccia membro è attiva, le altre rimangono inattive. Se quella attiva si guasta, un'altra prende il suo posto entro poche centinaia di millisecondi. Non è necessaria alcuna configurazione dello switch, il che rende questa la scelta giusta quando gli switch sono fuori dal vostro controllo o non supportano lo standard 802.3ad. Si ottiene ridondanza ma nessuna larghezza di banda aggiuntiva.

Modalità 4: 802.3ad (LACP)

Tutti i membri trasportano il traffico. Il driver di bonding e lo switch utilizzano LACP per negoziare il set attivo e rilevare i guasti. Il traffico in uscita viene bilanciato tra i membri utilizzando una politica di hash configurata dall'utente. Questa è la scelta standard per i server dedicati collegati a switch gestiti quando si desidera sia la ridondanza che una larghezza di banda aggiuntiva per carichi di lavoro multi-flusso.

Modalità 6: balance-alb

Bilanciamento del carico adattivo in entrambe le direzioni, senza richiedere il supporto dello switch. Il driver intercetta le risposte ARP per riscrivere gli indirizzi MAC e distribuire il traffico in entrata. Funziona, ma è fragile rispetto a LACP. Utilizzarlo solo quando la configurazione lato switch è realmente impossibile.

Regola decisionale:

• Nessuno switch gestito, oppure è necessario solo il failover: modalità 1 (active-backup).
• Switch gestito, flussi multipli, si desidera sia larghezza di banda che ridondanza: modalità 4 (LACP).
• Switch gestito impossibile ma è necessario il bilanciamento in entrambe le direzioni: modalità 6 (balance-alb).

Le modalità 0 (balance-rr), 2 (balance-xor), 3 (broadcast) e 5 (balance-tlb) esistono, ma raramente sono la scelta giusta sull'hardware moderno. Scegli la modalità 1 o la modalità 4 a meno che tu non abbia un motivo specifico per non farlo.

Configurazione del bonding LACP su Linux

Sui moderni sistemi Ubuntu e Debian, LACP si configura tramite netplan. Su RHEL, CentOS Stream, AlmaLinux e Rocky Linux, utilizzare NetworkManager tramite nmcli o modificando i file di connessione sottostanti.

Netplan (Ubuntu, Debian)

Inserire quanto segue in /etc/netplan/01-lacp.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [10.0.0.5/24]
      gateway4: 10.0.0.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

Quindi applicare con netplan apply. I parametri chiave:

• mode: 802.3ad abilita LACP.
• lacp-rate: fast invia LACPDU ogni secondo invece che ogni 30 secondi (impostazione predefinita). Deve corrispondere all'impostazione dello switch.
• mii-monitor-interval: 100 interroga lo stato del collegamento ogni 100 ms.
• transmit-hash-policy: layer3+4 distribuisce i flussi in base all'IP di origine/destinazione e alla porta TCP/UDP. Ciò produce un bilanciamento migliore rispetto alla layer2 per il traffico web e di database tipico.

NetworkManager (RHEL, AlmaLinux, Rocky)

nmcli con add type bond ifname bond0 con-name bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet ifname eth0 master bond0
nmcli con add type ethernet ifname eth1 master bond0
nmcli con mod bond0 ipv4.addresses 10.0.0.5/24 ipv4.gateway 10.0.0.1 ipv4.method manual
nmcli con up bond0

Lato switch

Lo switch necessita di un gruppo LAG (spesso chiamato port-channel) configurato in modalità LACP attiva, con lo stesso numero di porte membri del bond. La sintassi esatta varia a seconda del fornitore, ma i requisiti no: le porte devono trovarsi nella stessa VLAN, essere impostate sulla stessa velocità e duplex e utilizzare la modalità LACP attiva su almeno un lato. La configurazione più sicura è quella in cui entrambi i lati sono attivi.

Su Cisco IOS:

interface range gigabitethernet0/1 - 2
 channel-group 1 mode active
 channel-protocol lacp

Su Aruba/ProCurve:

trunk 1-2 trk1 lacp

L' lacp_rate impostazione sullo switch deve corrispondere a quella dell'host. Una mancata corrispondenza in questo caso è uno degli errori di configurazione LACP più comuni e causa un flapping intermittente ogni 30 secondi.

Verifica e risoluzione dei problemi LACP

Controllare lo stato in tempo reale del bond sul lato Linux:

cat /proc/net/bonding/bond0

Quattro elementi da cercare nell'output:

1. Bonding Mode: IEEE 802.3ad Dynamic link aggregation conferma che la modalità 4 è caricata.
2. Ogni interfaccia subordinata elencata con MII Status: up e link failure count: 0.
3. un valore diverso da zero Partner Mac Address per ogni subordinato. Se qui ci sono solo zeri, significa che lo switch non sta inviando affatto pacchetti LACP, o perché la porta non è in un LAG attivo per LACP, o perché il cavo è nella porta sbagliata.
4. Aggregator ID è lo stesso su ogni membro. ID diversi significano che i membri non sono effettivamente combinati, ma agiscono in modo indipendente.

Il controllo di integrità più veloce per verificare che la larghezza di banda sia utilizzata consiste nell'eseguire iperf3 con più flussi paralleli (iperf3 -P 8) da un altro host. Se il throughput totale supera la capacità di un singolo collegamento, LACP sta bilanciando correttamente. Un test a flusso singolo che mostra la velocità di un collegamento è un comportamento previsto, non un bug.

I problemi LACP più comuni e le loro cause:

• Il MAC del partner è tutto zeri: la porta dello switch non si trova in un LAG LACP attivo, oppure i cavi sono collegati in modo errato.
• Il bonding si avvia ma la velocità di trasmissione è bloccata su un solo collegamento: la politica di hash è probabilmente impostata di default su layer2, che esegue l'hash solo sul MAC di destinazione. Passare a layer3+4.
• Flapping intermittente ogni 30 secondi: lacp_rate mancata corrispondenza tra host e switch.
• Un dispositivo subordinato funziona ma l'altro non trasporta mai traffico: mancata corrispondenza di velocità/duplex, oppure le porte dello switch non si trovano nello stesso gruppo LAG sul lato switch.

Quando LACP non è la risposta giusta

LACP risolve un problema specifico: aggregare più collegamenti tra un host e uno switch (o uno stack di switch) per ottenere ridondanza e larghezza di banda per flusso. Esistono scenari in cui non è lo strumento giusto.

Se avete solo bisogno di ridondanza e gli switch non supportano lo standard 802.3ad, utilizzate invece la modalità 1 (active-backup). Funziona con qualsiasi cosa.

Se avete bisogno di collegare due switch separati per ottenere ridondanza a livello di chassis, il LACP standard non coprirà due switch non collegati tra loro. È necessario il Multi-Chassis Link Aggregation (MLAG), in cui due switch si presentano come un unico partner LACP logico. La maggior parte dei fornitori di switch aziendali implementa questa funzionalità con un proprio nome: Cisco vPC, Arista MLAG, Juniper MC-LAG.

Se avete bisogno che un singolo flusso superi la larghezza di banda di un collegamento, LACP non può farlo. Le opzioni sono utilizzare un collegamento fisico più veloce (sostituire 2x 10 GbE con 1x 25 GbE o 1x 40 GbE) oppure utilizzare una tecnologia completamente diversa. SR-IOV offre alle macchine virtuali prestazioni a flusso singolo vicine alla velocità di linea, fornendo a ciascuna VM una scheda di rete virtuale con accelerazione hardware, ma risolve un problema diverso e presenta i propri limiti. Questo è un argomento per un post a parte.

Per la maggior parte dei server dedicati e in colocation che gestiscono molte connessioni simultanee, LACP rimane la risposta standard. Due collegamenti 10 GbE in bonding con layer3+4 hashing gestiscono comodamente oltre 18 Gbps di traffico aggregato su molti flussi, resistendo a un guasto della scheda di rete o del cavo senza perdere alcun pacchetto.