Interfaces bonding su Debian

Ritornano i nostri how-to prettamente tecnici

Questa volta (come sempre) approfitto dell’esperienza fatta durante il mio lavoro per condividere ciò che imparo; oggi vedremo come configurare il bonding delle interfaccie di rete di una macchina.

Partiamo con la teoria per i non addetti, dicasi bonding (da channel bonding), quel particolare modulo del kernel linux che consente di legare due o più interfaccie di rete fisiche ad un unica interfaccia virtuale, cosi da poterne configurare la modalità active-active al fine di raddoppiarne (o triplicarne in base al numero delle interfaccie) il throughput della larghezza di banda, o in modalità active-passive per crearne la ridondanza.

apt-get install ifenslave-2.6

Installiamo il pacchetto necessario, e poi disabilitiamo i moduli per l’ipv6, questo per evitare di ricevere fastidiosi messaggi del tipo: "ICMPv6 NA: someone advertises our address on bond0!"; creiamo il file /etc/modprobe.d/ipv6-off con dentro:

alias net-pf-10 off
alias ipv6 off

adesso settiamo l’interfaccia virtuale bond0 nell’apposito file /etc/network/interfaces:

auto bond0
iface bond0 inet static
pre-up modprobe bond0
hwaddress ether 00:11:22:33:44:55
address 192.168.0.28
netmask 255.255.255.0
network 192.168.0.0
gateway 192.168.0.5
slaves eth2 eth3

N.B. la direttiva slaves funziona SOLO su Debian, il suo funzionamento è legato al supporto proveniente dai comandi ifup e ifdown; inoltre il mac address può anche essere fittizzio, l’importante è che non ve ne sia uno uguale sullo stesso tronco di rete.

creare il file /etc/modprobe.d/aliases-bond ed editarlo come segue:

alias bond0 bonding
options bond0 mode=0 miimon=100 downdelay=200 updelay=200

La prima opzione che vediamo è mode=0, con questa direttiva decidiamo come deve lavorare il bonding:

mode=0

Questa modalità usa una policy di round-robin. Trasmette i pacchetti in ordine sequenziale dalla prima interfaccia slave disponibile fino all’ultima, per garantire sia load-balancing che ridondanza.

mode=1

Questa modalità usa una policy attivo-passivo: solo una interfaccia del bonding sarà attiva. L’altra interfaccia inattiva comincerà a lavorare se, e solo se, la prima interfaccia slave diviene non disponibile, e per evitare di incasinare gli switch il mac address virtuale esposto sulla rete verrà reso visibile solo sullo switch che ospita l’interfaccia attiva al momento. Modalità usata solo per questioni di ridondanza.

mode=2

Simile alla modalità zero, per la modalità attiva-attiva, ma senza round robin: il traffico verso un determinato mac address verrà inviato sempre e solo dalla stessa interfaccia, anche qui avremo sia load-balancing che ridondanza.

mode=3

Broadcast policy: trasmette tutto su tutte le interfaccie contemporaneamente, fornisce solo ridondanza.

mode=4

IEEE 802.3ad Dynamic link aggregation. Crea gruppi di aggregazione che condividono la stessa velocità e modalità di duplex dell’interfaccia. Tutte le interfaccie sono in modalità attiva-attiva secondo le specifiche 802.3ad

 

          *Pre-requisiti:

1. I driver delle schede di rete devono supportare ethtool..

2. Uno switch che supporta gli standard IEEE 802.3ad Dynamic link aggregation. Molti switch potrebbero richiedere una configurazione particolare per abilitare tale supporto.

mode=5

Adaptive transmit load balancing: Il traffico viene distribuito in base al carico attuale di ogni interfaccia. Il traffico in entrata viene preso dall’interfaccia slave attiva.

*Prerequisiti: Ethtool supportato dai driver delle schede di rete.

mode=6

Adaptive load balancing: simile alla modalità 5 ma funziona in entrambi i sensi, anche il traffico in entrata quindi, viene bilanciato tra le interfaccie slave disponibili.

La seconda opzione che vediamo è miimon, ed indica ogni quanti millisecondi deve essere fatto il monitoring delle risorse. Segue downdelay che indica il tempo, in millisecondi, che deve passare dal link failure per considerare l’interfaccia indisponibile, e quindi disabilitarla. Infine updowndelay, che è lo stesso di downdelay, ma questa volta indica il tempo che deve passare quando l’interfaccia, ritornata up, deve essere considerata disponibile.