Link Aggregation/Bonding: Unterschied zwischen den Versionen
K Textersetzung - „== Syntax ==“ durch „== Aufruf ==“ |
|||
(40 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
'''topic''' | '''topic''' - Beschreibung | ||
== Beschreibung == | == Beschreibung == | ||
; Failover und Hochverfügbarkeit | |||
; Netzwerkbindung auf einem Linux-Server konfigurieren | ; Netzwerkbindung auf einem Linux-Server konfigurieren | ||
* In einer Windows-Umgebung wird Network Bonding als Network Teaming bezeichnet | * In einer Windows-Umgebung wird Network Bonding als Network Teaming bezeichnet | ||
Zeile 32: | Zeile 32: | ||
== Installation == | == Installation == | ||
# | # ''apt install ifenslave'' | ||
; Gegebenenfalls werden noch die folgenden Programme benötigt | |||
; net-tools | |||
* Beinhaltet das Programm mii-tool, das unabhängig vom Medium den Status der Schnittstelle sowie die Geschwindigkeits- und Duplex-Einstellungen abfragen bzw. einstellen kann. | |||
* Mii-Tool wird für den Modus 4 (802.3ad) und das Abfragen der verfügbaren Schnittstellen benötigt. | |||
; ethtool | |||
* Programm zum Setzen der Geschwindigkeits- und Duplex-Einstellungen bei Ethernet-Schnittstellen. | |||
* Ethtool wird für die Modi 4 (802.3ad), 5 (balance-tlb) und 6 (balance-alb) benötigt. | |||
* Siehe auch [https://wiki.ubuntuusers.de/ethtool/ ethtool] | |||
# '''apt install net-tools ethtool''' | |||
; bmon | |||
* Optional ist das folgende Programm | |||
* Bandwith Monitor, ein Programm, das die Datenübertragungsraten pro Gerät in Echtzeit anzeigen kann | |||
# '''apt install bmon''' | |||
== Anwendungen == | == Anwendungen == | ||
=== | === Problembehebung === | ||
== | == Aufruf == | ||
=== Optionen === | === Optionen === | ||
=== Parameter === | === Parameter === | ||
=== | === Umgebung === | ||
=== | === Rückgabewert === | ||
== Konfiguration == | == Konfiguration == | ||
* Bevor wir mit der Konfiguration beginnen, müssen wir zunächst sicherstellen, dass wir mindestens 2 Ethernet-Schnittstellen in unserem Server konfiguriert haben. | * Bevor wir mit der Konfiguration beginnen, müssen wir zunächst sicherstellen, dass wir mindestens 2 Ethernet-Schnittstellen in unserem Server konfiguriert haben. | ||
Zeile 187: | Zeile 204: | ||
64 bytes from 172.20.43.110: icmp_seq=3 ttl=64 time=0.415 ms | 64 bytes from 172.20.43.110: icmp_seq=3 ttl=64 time=0.415 ms | ||
64 bytes from 172.20.43.110: icmp_seq=4 ttl=64 time=0.427 ms | 64 bytes from 172.20.43.110: icmp_seq=4 ttl=64 time=0.427 ms | ||
In dieser Zeit gehen wir zurück zu unserem Bonding-Server und schalten die Ethernet-Schnittstelle ETH0 aus. | In dieser Zeit gehen wir zurück zu unserem Bonding-Server und schalten die Ethernet-Schnittstelle ETH0 aus. | ||
ifconfig eth0 | Zuerst führen Sie [https://www.howtoforge.de/anleitung/linux-ifconfig-befehl/ ifconfig] eth0 aus: | ||
# ifconfig eth0 | |||
eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88 | eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88 | ||
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 | UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 | ||
Zeile 208: | Zeile 217: | ||
ifdown eth0 | ifdown eth0 | ||
Nun haben wir die Dienste für die Netzwerkschnittstelle ETH0 abgeschaltet | Nun haben wir die Dienste für die Netzwerkschnittstelle ETH0 abgeschaltet. | ||
; Bindungsstatus überprüfen | |||
cat /proc/net/bonding/bond0 | cat /proc/net/bonding/bond0 | ||
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) | Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) | ||
Zeile 227: | Zeile 237: | ||
Slave queue ID: 0 | Slave queue ID: 0 | ||
Sie werden feststellen, dass die ETH0-Schnittstelle nun nicht mehr im Bindungsstatus existiert | Sie werden feststellen, dass die ETH0-Schnittstelle nun nicht mehr im Bindungsstatus existiert. | ||
Während dieser Zeit gehen wir zurück zum vorherigen Testserver und überprüfen den kontinuierlichen Ping zu unserem Bonding-Server. | |||
64 bytes from 172.20.43.110: icmp_seq=22 ttl=64 time=0.408 ms | 64 bytes from 172.20.43.110: icmp_seq=22 ttl=64 time=0.408 ms | ||
64 bytes from 172.20.43.110: icmp_seq=23 ttl=64 time=0.402 ms | 64 bytes from 172.20.43.110: icmp_seq=23 ttl=64 time=0.402 ms | ||
Zeile 243: | Zeile 254: | ||
64 bytes from 172.20.43.110: icmp_seq=34 ttl=64 time=0.491 ms | 64 bytes from 172.20.43.110: icmp_seq=34 ttl=64 time=0.491 ms | ||
Obwohl die Schnittstelle heruntergefahren wurde, ist haben, immer noch in der Lage sind, unseren Bonding-Server zu pingen und darauf zuzugreifen. | |||
; Weiteren Test | |||
Schalten Sie die ETH0-Schnittstelle wieder ein und die ETH1-Schnittstelle aus. | |||
ifup eth0 | ifup eth0 | ||
Zeile 271: | Zeile 285: | ||
Da die ETH0-Schnittstelle bereits hochgefahren war, schalten wir die ETH1-Schnittstelle aus. | Da die ETH0-Schnittstelle bereits hochgefahren war, schalten wir die ETH1-Schnittstelle aus. | ||
ifdown eth1 | ifdown eth1 | ||
cat /proc/net/bonding/bond0 | cat /proc/net/bonding/bond0 | ||
Zeile 291: | Zeile 304: | ||
Nun gehen wir zurück zum Testserver und überprüfen, was auf dem kontinuierlichen Ping zu unserem Bonding-Server passiert. | Nun gehen wir zurück zum Testserver und überprüfen, was auf dem kontinuierlichen Ping zu unserem Bonding-Server passiert. | ||
64 bytes from 172.20.43.110: icmp_seq=84 ttl=64 time=0.437 ms | 64 bytes from 172.20.43.110: icmp_seq=84 ttl=64 time=0.437 ms | ||
64 bytes from 172.20.43.110: icmp_seq=85 ttl=64 time=0.504 ms | 64 bytes from 172.20.43.110: icmp_seq=85 ttl=64 time=0.504 ms | ||
Zeile 305: | Zeile 317: | ||
64 bytes from 172.20.43.110: icmp_seq=95 ttl=64 time=0.479 ms | 64 bytes from 172.20.43.110: icmp_seq=95 ttl=64 time=0.479 ms | ||
Wir haben erfolgreich konfiguriert und bewiesen, dass unser Bonding-Server es schafft, das Disaster-Recovery-Szenario bei einem Netzwerkausfall zu erfüllen. | |||
== Sicherheit == | == Sicherheit == | ||
Zeile 312: | Zeile 323: | ||
== Dokumentation == | == Dokumentation == | ||
=== RFC === | === RFC === | ||
=== Man- | === Man-Page === | ||
=== Info-Pages === | === Info-Pages === | ||
== Siehe auch == | == Siehe auch == | ||
== Links == | == Links == | ||
=== Projekt | === Projekt === | ||
=== Weblinks === | === Weblinks === | ||
# http://wiki.debian.org/Bonding | # http://wiki.debian.org/Bonding | ||
Zeile 322: | Zeile 333: | ||
# [http://www.linuxfoundation.org/en/Net:Bonding Ausführliche Anleitung zum Bonding auf www.linuxfoundation.org] | # [http://www.linuxfoundation.org/en/Net:Bonding Ausführliche Anleitung zum Bonding auf www.linuxfoundation.org] | ||
# https://www.thomas-krenn.com/de/wiki/NIC_Bonding_unter_Debian | # https://www.thomas-krenn.com/de/wiki/NIC_Bonding_unter_Debian | ||
# [https://help.ubuntu.com/community/UbuntuBonding Bonding] - Ubuntu Community Documentation | |||
# [https://wiki.debian.org/Bonding Bonding] im Debian Wiki | |||
# [http://web.archive.org/web/20111105062131/http://www.5dollarwhitebox.org/wiki/index.php/Howtos_NIC_Bonding_Debian NIC Bonding Debian] | |||
# [http://www.nwlab.net/art/teaming/nic-teaming.html Lastverteilung und Ausfallsicherheit mit mehreren Netzwerkkarten] | |||
# [http://www.linux-magazin.de/heft_abo/ausgaben/2004/07/doppelt_reissfest Doppelt reissfest] - Linux-Magazin, 07/2004 | |||
# [http://www.linuxhorizon.ro/bonding.html Erläuterung der verschieden Modi auf LINUX Horizon] | |||
# [http://blog.brightbox.co.uk/posts/howto-do-ethernet-bonding-on-ubuntu-properly http://blog.brightbox.co.uk/posts/howto-do-ethernet-bonding-on-ubuntu-properly] | |||
# [https://www.kernel.org/doc/Documentation/networking/bonding.txt bonding.txt (Kernel.org Documentation)] | |||
# [http://blog.netways.de/2012/11/21/bonding-unter-ubuntu-12-04-1 Bonding unter Ubuntu 12.04.1] | |||
= TMP = | = TMP = | ||
Zeile 354: | Zeile 352: | ||
* The following example shows my previous bonding mode 1 configuration within the /etc/network/interfaces file, I will leave interfaces with their names for easier understanding: | * The following example shows my previous bonding mode 1 configuration within the /etc/network/interfaces file, I will leave interfaces with their names for easier understanding: | ||
auto enp2s0iface enp2s0 inet manualbond-master bond0bond-primary enp2s0 wlp3s0 auto wlp3s0iface wlp3s0 inet manualbond-master bond0bond-primary enp2s0 wlp3s0wpa-ssid 'LinuxHint'wpa-bssid '14:CF:E2:2A:EF:00'wpa-psk '972537288765'auto bond0iface bond0 inet dhcpbond-slaves nonebond-mode active-backupbond-miimon 100bond-downdelay 200bond-updelay 200 | auto enp2s0iface enp2s0 inet manualbond-master bond0bond-primary enp2s0 wlp3s0 auto wlp3s0iface wlp3s0 inet manualbond-master bond0bond-primary enp2s0 wlp3s0wpa-ssid 'LinuxHint'wpa-bssid '14:CF:E2:2A:EF:00'wpa-psk '972537288765'auto bond0iface bond0 inet dhcpbond-slaves nonebond-mode active-backupbond-miimon 100bond-downdelay 200bond-updelay 200 | ||
[[Image:Bild17.png|top]]A network bonding configuration with static IP instead of DHCP would have the last block like: | [[Image:Bild17.png|top]]A network bonding configuration with static IP instead of DHCP would have the last block like: | ||
Zeile 368: | Zeile 366: | ||
= Netzwerkkarten bündeln = | = Netzwerkkarten bündeln = | ||
Manchmal ist es notwendig, zwei Netzwerkkarten zu bündeln, z.B. für eine höhere Ausfallsicherheit oder um einfach den Durchsatz zu erhöhen. Man spricht auch vom NIC-Teaming oder Bonding, wenn man zwei Netzwerkschnittstellen zu einer virtuellen Einheit zusammenfasst. So wird erreicht, dass das System beide Karten als ein Gerät anspricht. Das bedeutet, dass beide Karten dieselbe Hardware-(MAC-)Adresse haben. | Manchmal ist es notwendig, zwei Netzwerkkarten zu bündeln, z. B. für eine höhere Ausfallsicherheit oder um einfach den Durchsatz zu erhöhen. Man spricht auch vom NIC-Teaming oder Bonding, wenn man zwei Netzwerkschnittstellen zu einer virtuellen Einheit zusammenfasst. So wird erreicht, dass das System beide Karten als ein Gerät anspricht. Das bedeutet, dass beide Karten dieselbe Hardware-(MAC-)Adresse haben. | ||
Die Bündelung der Netzwerkkarten wird durch das Dienstprogramm '''ifenslave''' bewerkstelligt, das dem Kernel ermöglicht, nur ein Gerät zu sehen und zu verwenden, während es die Datenpakete tatsächlich über die zwei Karten sendet. Hiermit kann sowohl Ausfallsicherheit als auch die Nutzung einer größeren Bandbreite erreicht werden. | Die Bündelung der Netzwerkkarten wird durch das Dienstprogramm '''ifenslave''' bewerkstelligt, das dem Kernel ermöglicht, nur ein Gerät zu sehen und zu verwenden, während es die Datenpakete tatsächlich über die zwei Karten sendet. Hiermit kann sowohl Ausfallsicherheit als auch die Nutzung einer größeren Bandbreite erreicht werden. | ||
== Vorbereitung == | == Vorbereitung == | ||
Zeile 434: | Zeile 414: | ||
* bond-downdelay: Gibt es einen Übertragungsfehler oder Aussetzer, so betrachtet das bonding-Modul die Schnittstelle erst nach 200ms als verloren und entfernt diese aus dem bond, ansonsten sofort. | * bond-downdelay: Gibt es einen Übertragungsfehler oder Aussetzer, so betrachtet das bonding-Modul die Schnittstelle erst nach 200ms als verloren und entfernt diese aus dem bond, ansonsten sofort. | ||
Die Konfiguration für alle anderen Interfaces bis auf das <tt>loopback</tt>-Interface können entfernt bzw. deaktiviert werden. | Die Konfiguration für alle anderen Interfaces bis auf das <tt>loopback</tt>-Interface können entfernt bzw. deaktiviert werden. | ||
* Wer ungeduldig ist, kann nun mit folgenden Befehlen den Treiber laden und die Netzwerke neu starten: | * Wer ungeduldig ist, kann nun mit folgenden Befehlen den Treiber laden und die Netzwerke neu starten: | ||
Zeile 501: | Zeile 481: | ||
== Bonding Modi == | == Bonding Modi == | ||
Bei der Konfiguration muss ein Bonding-Modus ( | Bei der Konfiguration muss ein Bonding-Modus (bond-mode) angegeben werden, der den Zweck und die Art der Bündelung der Netzwerkschnittstellen angibt. | ||
{| | {| class="wikitable sortable options" | ||
|- | |- | ||
! Modus !! Bezeichnung !! Zweck !! Beschreibung | |||
|- | |||
|- | |||
|| 0 | || 0 | ||
|| balance-rr | || balance-rr | ||
|| Lastverteilung & Ausfallsicherheit | || Lastverteilung & Ausfallsicherheit | ||
|| Die genutzte Netzwerkschnittstelle wird im [https://de.wikipedia.org/wiki/Round_Robin_(Informatik) Round-Robin]-Verfahren festgelegt, das heißt die verfügbaren Schnittstellen werden in Senderichtung wechselweise genutzt. In Empfangsrichtung kann max. die Geschwindigkeit einer einzelnen Schnittstelle erreicht werden - je mehr Teilnehmer, umso mehr Upload-Gesamtbandbreite, denn diese werden auf die übrigen freien Schnittstellen aufgeteilt. | || Die genutzte Netzwerkschnittstelle wird im [https://de.wikipedia.org/wiki/Round_Robin_(Informatik) Round-Robin]-Verfahren festgelegt, das heißt die verfügbaren Schnittstellen werden in Senderichtung wechselweise genutzt. In Empfangsrichtung kann max. die Geschwindigkeit einer einzelnen Schnittstelle erreicht werden - je mehr Teilnehmer, umso mehr Upload-Gesamtbandbreite, denn diese werden auf die übrigen freien Schnittstellen aufgeteilt. | ||
|- | |- | ||
|| 1 | || 1 | ||
|| active-backup | || active-backup | ||
|| Ausfallsicherheit | || Ausfallsicherheit | ||
|| Nur eine Schnittstelle ist aktiv, im Fehlerfalle wird eine der anderen im Verbund genutzt. die Netzwerkkarten können über verschiedene [https://de.wikipedia.org/wiki/Switch_(Computertechnik) Switches] angebunden werden. | || Nur eine Schnittstelle ist aktiv, im Fehlerfalle wird eine der anderen im Verbund genutzt. die Netzwerkkarten können über verschiedene [https://de.wikipedia.org/wiki/Switch_(Computertechnik) Switches] angebunden werden. | ||
|- | |- | ||
|| 2 | || 2 | ||
|| balance-xor | || balance-xor | ||
|| Lastverteilung & Ausfallsicherheit | || Lastverteilung & Ausfallsicherheit | ||
|| Es wird für jede Gegenstelle im Netzwerk eine zu nutzende Netzwerkschnittstelle zugewiesen, die Zuordnung geschieht über den Modulo der Division zwischen der Formel (Quell-MAC-Adresse XOR Ziel-MAC-Adresse) und der Anzahl der Slave-Schnittstellen. | || Es wird für jede Gegenstelle im Netzwerk eine zu nutzende Netzwerkschnittstelle zugewiesen, die Zuordnung geschieht über den Modulo der Division zwischen der Formel (Quell-MAC-Adresse XOR Ziel-MAC-Adresse) und der Anzahl der Slave-Schnittstellen. | ||
|- | |- | ||
|| 3 | || 3 | ||
|| broadcast | || broadcast | ||
|| Ausfallsicherheit | || Ausfallsicherheit | ||
|| Daten werden auf allen Netzwerkschnittstellen gesendet. Die Nutzung mehrerer Switches ist möglich. | || Daten werden auf allen Netzwerkschnittstellen gesendet. Die Nutzung mehrerer Switches ist möglich. | ||
|- | |- | ||
|| 4 | || 4 | ||
|| 802.3ad | || 802.3ad | ||
|| Lastverteilung & Ausfallsicherheit | || Lastverteilung & Ausfallsicherheit | ||
|| 802.3ad ist ein Standard der IEEE, der die Bündelung mehrerer Schnittstellen mit gleichen Übertragungseinstellungen (Geschwindigkeit und Duplex-Einstellungen) erlaubt, um eine höhere Bandbreite zu erhalten. Es kann nur ein Switch verwendet werden, dieser muss 802.3ad unterstützen. | || 802.3ad ist ein Standard der IEEE, der die Bündelung mehrerer Schnittstellen mit gleichen Übertragungseinstellungen (Geschwindigkeit und Duplex-Einstellungen) erlaubt, um eine höhere Bandbreite zu erhalten. Es kann nur ein Switch verwendet werden, dieser muss 802.3ad unterstützen. ethtool oder mii-tool wird benötigt. | ||
|- | |- | ||
|| 5 | || 5 | ||
|| balance-tlb | || balance-tlb | ||
|| Lastverteilung | || Lastverteilung | ||
|| Es wird für jede Gegenstelle im Netzwerk eine zu nutzende Netzwerkschnittstelle zugewiesen. Das Verfahren hierzu ist jedoch komplexer und effizienter als bei | || Es wird für jede Gegenstelle im Netzwerk eine zu nutzende Netzwerkschnittstelle zugewiesen. Das Verfahren hierzu ist jedoch komplexer und effizienter als bei balance-xor. Das Programm ethtool wird benötigt. | ||
|- | |- | ||
|| 6 | || 6 | ||
|| balance-alb | || balance-alb | ||
|| Lastverteilung | || Lastverteilung | ||
|| Erweitertes | || Erweitertes balance-tlb, zusätzlich zur MAC-basierten Zuordnung der Schnittstellen für ausgehende Verbindungen werden eingehende Verbindungen auf die Schnittstellen verteilt. Das Programm ethtool wird benötigt. | ||
|} | |} | ||
Zeile 552: | Zeile 526: | ||
* Bei Unsicherheiten oder scheinbaren Zufälligkeiten der Funktionalität der Konfiguration kann die folgende Variante gewählt werden. | * Bei Unsicherheiten oder scheinbaren Zufälligkeiten der Funktionalität der Konfiguration kann die folgende Variante gewählt werden. | ||
* Diese geht davon aus, dass ein Interface per DHCP, das andere direkt adressiert wird. | * Diese geht davon aus, dass ein Interface per DHCP, das andere direkt adressiert wird. | ||
Voraussetzung ist das folgende Paket: | |||
# apt-get install moreutils | # apt-get install moreutils | ||
Zeile 563: | Zeile 538: | ||
bonding | bonding | ||
Danach wird die Netzwerkkonfiguration erstellt. Diese enthält folgende Nebenbedingungen:* Über | Danach wird die Netzwerkkonfiguration erstellt. | ||
* Die Interfaces | |||
* Mittels | Diese enthält folgende Nebenbedingungen: | ||
* Über ''eth0'' wird eine DHCP-Adresse vermittelt | |||
* Die Interfaces ''eth0'' und ''eth1'' bilden ''bond0'' | |||
* Mittels ''eth2'' und ''eth3'' wird statisch eine Adresse an ''bond1'' gebunden | |||
=== | === Schnittstellendefinition === | ||
; /etc/network/interfaces | |||
auto lo | auto lo | ||
iface lo inet loopback | iface lo inet loopback | ||
Zeile 592: | Zeile 571: | ||
dns-search … | dns-search … | ||
Nun muss noch | Nun muss noch ''bond0'' entsprechend konfiguriert werden. Das geschieht in '''/etc/rc.local''' | ||
set -x | set -x | ||
/sbin/ifconfig eth1 $(/usr/bin/ifdata -pa eth0) \ | /sbin/ifconfig eth1 $(/usr/bin/ifdata -pa eth0) \ | ||
Zeile 603: | Zeile 582: | ||
=== Variante, die auch funktionierte === | === Variante, die auch funktionierte === | ||
* Gewisse Unsicherheiten ergeben sich aus der im Paket | * Gewisse Unsicherheiten ergeben sich aus der im Paket ''linux-doc'' beschriebenen Dokumentation ''/usr/share/doc/linux-doc/networking/bonding.txt.gz''. | ||
* Folgende Variante im obrigen Beispiel von | * Folgende Variante im obrigen Beispiel von ''bond1'' funktionierte: | ||
; /etc/network/interfaces | ; /etc/network/interfaces | ||
Zeile 645: | Zeile 624: | ||
bond-primary eth0 eth1 | bond-primary eth0 eth1 | ||
Diese Variante funktionierte nicht immer. Für die MAC-Adresse von | Diese Variante funktionierte nicht immer. Für die MAC-Adresse von ''eth0'' wird dabei eine IP Adresse bereit gestellt. Die Mac-Adresse von ''eth1'' wird nicht mit einer IP-Adresse versorgt. | ||
auto bond0 | auto bond0 | ||
iface bond0 inet dhcp | iface bond0 inet dhcp | ||
Zeile 662: | Zeile 641: | ||
bond-primary eth0 eth1 | bond-primary eth0 eth1 | ||
Die letzte Variante, die genau der Beschreibung aus | Die letzte Variante, die genau der Beschreibung aus ''linux-doc'' entspricht, funktionierte leider gar nicht bei mir. | ||
== Hardwareunabhängiges Image == | == Hardwareunabhängiges Image == | ||
Zeile 672: | Zeile 651: | ||
for I in {0,1,2,3,4,5,6,7} | for I in {0,1,2,3,4,5,6,7} | ||
do echo eth$I | do echo eth$I | ||
udevadm info -a -p /sys/class/net/eth$I | grep KERNELS | |||
udevadm info -a -p /sys/class/net/eth$I | grep 'ATTR{dev_id}' | |||
udevadm info -a -p /sys/class/net/eth$I | grep 'ATTR{type}' | |||
done | done | ||
Zeile 681: | Zeile 660: | ||
Im obrigen Beispiel kommt es zu folgender Ausgabe: | Im obrigen Beispiel kommt es zu folgender Ausgabe: | ||
eth0 | eth0 | ||
KERNELS=="0000:04:00.0" | |||
KERNELS=="0000:00:02.2" | |||
KERNELS=="pci0000:00" | |||
ATTR{dev_id}=="0x0" | |||
ATTR{type}=="1" | |||
eth1 | eth1 | ||
KERNELS=="0000:04:00.1" | |||
KERNELS=="0000:00:02.2" | |||
KERNELS=="pci0000:00" | |||
ATTR{dev_id}=="0x0" | |||
ATTR{type}=="1" | |||
… | … | ||
Zeile 707: | Zeile 686: | ||
sudo service udev restart | sudo service udev restart | ||
wird die Änderung getestet bzw. wirksam. | wird die Änderung getestet bzw. wirksam. | ||
== | == Problembehebung == | ||
=== Problembeschreibung === | === Problembeschreibung === | ||
Wenn man mehrere Netzwerkkarten des gleichen Typs einsetzt, kann es passieren, dass die Netzwerkkarten neu benannt werden. Ein | Wenn man mehrere Netzwerkkarten des gleichen Typs einsetzt, kann es passieren, dass die Netzwerkkarten neu benannt werden. Ein | ||
# '''ifconfig -a''' | |||
liefert dann z.B. einen Eintrag wie: | liefert dann z. B. einen Eintrag wie: | ||
[...] | [...] | ||
eth?_rename | eth?_rename | ||
[...] | [...] | ||
Um dies zu vermeiden muss die Datei [https://wiki.ubuntuusers.de/interfaces/ /etc/network/interfaces] editiert werden. Im Abschnitt | Um dies zu vermeiden, muss die Datei [https://wiki.ubuntuusers.de/interfaces/ /etc/network/interfaces] editiert werden. | ||
Im Abschnitt ''bonding'' muss die Angabe für eine MAC eingefügt werden: | |||
auto bond0 | auto bond0 | ||
iface bond0 inet static | iface bond0 inet static | ||
Zeile 728: | Zeile 709: | ||
Bitte keine MAC von einer vorhandenen Karte benutzen, sondern selber eine setzen. | Bitte keine MAC von einer vorhandenen Karte benutzen, sondern selber eine setzen. | ||
= TMP = | = TMP = | ||
Zeile 772: | Zeile 742: | ||
Als Gegenstelle verwenden wir den Switch eines Intel Modular Servers. Eth0 und eth1 des Servers sind mit den LAN-Ports 1 und 2 am Modular Server Switch verbunden. Diese beide LAN-Ports sind für die Link Aggregation konfiguriert. Details dazu siehe [[Link Aggregation beim Modular Server]] und [[Link Aggregation Lastverteilung Test Modular Server Switch]]. | Als Gegenstelle verwenden wir den Switch eines Intel Modular Servers. Eth0 und eth1 des Servers sind mit den LAN-Ports 1 und 2 am Modular Server Switch verbunden. Diese beide LAN-Ports sind für die Link Aggregation konfiguriert. Details dazu siehe [[Link Aggregation beim Modular Server]] und [[Link Aggregation Lastverteilung Test Modular Server Switch]]. | ||
= Linux Network Bonding = | |||
If you have a few years of experience in the Linux ecosystem, and you’re interested in sharing that experience with the community, have a look at our Contribution Guidelines. | |||
=== Overview === | |||
Modern hardware offers multiple network interfaces. However, we need appropriate means to use them effectively. An available way is to bind together existing connections, so the system recognizes them as one. In this way, we increase redundancy or throughput. | |||
In this tutorial, we’ll learn how to use popular network services to create network bonding. | |||
=== Prerequisites === | |||
Let’s notice that we can bind connections in many ways. Here, we’ll use the active-backup mode with two slave connections. With this setup, we increase redundancy, as the backup connection is activated when the primary fails. | |||
Further, we need the Linux kernel to manage network bonding. So, let’s check if the bonding kernel module is available with lsmod: | |||
$ lsmod | grep bond | |||
bonding 196608 0 | |||
If it isn’t the case, we need to load it with modprobe: | |||
$ sudo modprobe bonding | |||
Next, we need at least two network interfaces. So, we’re going to use a virtual Linux system in the Oracle VM VirtualBox Manager. Subsequently, we’ll provide two NAT interfaces to simulate hardware ethernet cards. | |||
Throughout this article, we’ll be working with Lubuntu 22.04 LTS with the kernel version 5.15.0-46-generic inside VirtualBox 6.1 on Windows 10. | |||
Now, let’s check network interfaces with lshw: | |||
$ sudo lshw -short -c network | |||
[sudo] password for joe: | |||
H/W path Device Class Description | |||
======================================================= | |||
/0/100/3 enp0s3 network 82540EM Gigabit Ethernet Controller | |||
/0/100/8 enp0s8 network 82540EM Gigabit Ethernet Controller | |||
So, we have two virtual ethernet cards – enp0s3 and enp0s8. | |||
=== Bonding With NetworkManager === | |||
Let’s use the NetworkManager service to manage network connections. Usually, this tool is available out of the box in most Linux distributions. First, let’s check if it’s running with systemctl: | |||
$ systemctl status NetworkManager | |||
● NetworkManager.service - Network Manager | |||
Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; ve> | |||
Active: active (running) since Sat 2022-09-03 14:57:17 CEST; 14min ago | |||
# ... | |||
If necessary, we should install NetworkManager from the network-manager package. | |||
=== Using nmtui === | |||
nmtui is a text user interface to configure NetworkManager. So, let’s start it and go to Edit a connection menu. Then we’re going to create a new connection with Add. Finally, let’s select Bond: | |||
screen | |||
Then, let’s set the profile name and the device’s name – nm-bond: | |||
screen01 | |||
Now, let’s provide a slave connection with Add and create an Ethernet connection: | |||
screen02 | |||
Subsequently, in the next panel, we should use one of enp0s3 or enp0s8 devices: | |||
screen03 | |||
Finally, let’s choose Active-backup as Mode. Then we’ll be asked to specify the primary slave interface – enp0s3: | |||
screen06 | |||
=== Checking Configuration === | |||
Let’s reboot the system and check the links: | |||
$ ip link | |||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 | |||
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 | |||
2: enp0s3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master nm-bond state UP mode DEFAULT group default qlen 1000 | |||
link/ether 6a:23:45:28:ac:0f brd ff:ff:ff:ff:ff:ff permaddr 08:00:27:42:6c:e3 | |||
3: enp0s8: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master nm-bond state UP mode DEFAULT group default qlen 1000 | |||
link/ether 6a:23:45:28:ac:0f brd ff:ff:ff:ff:ff:ff permaddr 08:00:27:fa:13:16 | |||
4: nm-bond: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 | |||
link/ether 6a:23:45:28:ac:0f brd ff:ff:ff:ff:ff:ff | |||
So we can find out that the bonding is working with two slaves. Moreover, let’s notice that the MAC address of all three interfaces is the same. | |||
Now let’s check the bonding configuration in the /proc/net/bonding/nm-bond file: | |||
$ cat /proc/net/bonding/nm-bond | |||
Ethernet Channel Bonding Driver: v5.15.0-47-generic | |||
Bonding Mode: fault-tolerance (active-backup) | |||
Primary Slave: enp0s3 (primary_reselect always) | |||
Currently Active Slave: enp0s3 | |||
MII Status: up | |||
MII Polling Interval (ms): 100 | |||
Up Delay (ms): 0 | |||
Down Delay (ms): 0 | |||
Peer Notification Delay (ms): 0 | |||
Slave Interface: enp0s3 | |||
MII Status: up | |||
Speed: 1000 Mbps | |||
Duplex: full | |||
Link Failure Count: 0 | |||
Permanent HW addr: 08:00:27:42:6c:e3 | |||
Slave queue ID: 0 | |||
Slave Interface: enp0s8 | |||
MII Status: up | |||
Speed: 1000 Mbps | |||
Duplex: full | |||
Link Failure Count: 0 | |||
Permanent HW addr: 08:00:27:fa:13:16 | |||
Slave queue ID: 0 | |||
We can find that the currently used slave link is enp0s3. In addition, the Permanent HW addr contains the MAC address of each slave interface before bonding. | |||
=== Bonding Connection in Action === | |||
Let’s check how the redundancy bonding works. First, let’s ping through nm-bond: | |||
$ ping -c 10 -I nm-bond www.baeldung.com | |||
PING www.baeldung.com (172.66.40.248) from 10.0.2.15 nm-bond: 56(84) bytes of data. | |||
# ... | |||
--- www.baeldung.com ping statistics --- | |||
10 packets transmitted, 10 received, 0% packet loss, time 9014ms | |||
rtt min/avg/max/mdev = 14.011/14.650/15.156/0.453 ms | |||
In addition, let’s check the active interface: | |||
$ cat /sys/class/net/nm-bond/bonding/active_slave | |||
enp0s3 | |||
Next, let’s just turn down the active slave enp0s3: | |||
$ sudo ip link set enp0s3 down | |||
Then, let’s ping again: | |||
$ ping -c 10 -I nm-bond www.baeldung.com | |||
PING www.baeldung.com (172.66.40.248) from 10.0.2.15 nm-bond: 56(84) bytes of data. | |||
# ... | |||
--- www.baeldung.com ping statistics --- | |||
10 packets transmitted, 9 received, 10% packet loss, time 9014ms | |||
rtt min/avg/max/mdev = 13.863/14.618/15.177/0.414 ms | |||
So we see that the connection works. Finally, let’s make sure that the bond interface has switched to enp0s8: | |||
$ cat /sys/class/net/nm-bond/bonding/active_slave | |||
enp0s8 | |||
=== Bonding With systemd-networkd === | |||
Instead of NetworkManager, we can use the systemd-networkd service. Assuming that we have NetworkManager working, we need to disable it: | |||
$ systemctl disable NetworkManager | |||
Subsequently, let’s enable systemd-networkd: | |||
$ systemctl enable systemd-networkd | |||
In addition, we should check if the NetworkManager-wait-online service is in use: | |||
$ systemctl status NetworkManager-wait-online | |||
If so, let’s disable it: | |||
$ systemctl disable NetworkManager-wait-online | |||
and enable its networkd counterpart: | |||
$ systemctl enable systemd-networkd-wait-online | |||
=== Configure systemd-networkd === | |||
We can provide configuration files in the /etc/systemd/network folder. Therein, files with the network extension describe the connections, while the file with netdev extension contains the bonding configuration. | |||
Let’s notice that the files are parsed in alphabetic order. So per convention, we should start their names with numbers. | |||
Now, let’s review the setup: | |||
$ ls -1 /etc/systemd/network | |||
10-nd-bond.network | |||
20-enp0s3.network | |||
20-nd-bond.netdev | |||
30-enp0s8.network | |||
99-dhcp.network | |||
First, let’s look into the bond device: | |||
$ cat 20-nd-bond.netdev | |||
[NetDev] | |||
Name=nd-bond | |||
Kind=bond | |||
[Bond] | |||
Mode=active-backup | |||
PrimaryReselectPolicy=always | |||
MIIMonitorSec=1s | |||
So in the NetDev section, we define the type and name of the device. Next, we add the device’s details in the Bond section. | |||
Now let’s examine the bond connection: | |||
$ cat 10-nd-bond.network | |||
[Match] | |||
Name=nd-bond | |||
[Network] | |||
DHCP=yes | |||
Let’s notice that the Name field in the Match section indicates that this configuration applies to the bonding device. Subsequently, the Network section says that we use DHCP. | |||
Further, let’s move to the enslaved connections enp0s3 and enp0s8: | |||
$ cat 20-enp0s3.network | |||
[Match] | |||
Name=enp0s3 | |||
[Network] | |||
Bond=nd-bond | |||
PrimarySlave=true | |||
As before, the Match section says which interface this file refers to. Next, we provide the bonding device name in the Network section. Finally, we make enp0s3 the primary slave. | |||
Similarly, for enp0s8, we have: | |||
$ cat 30-enp0s8.network | |||
[Match] | |||
Name=enp0s8 | |||
[Network] | |||
Bond=nd-bond | |||
Finally, the 99-dhcp.network contains the fallback setup for any connection whose name matches the enp0* pattern: | |||
$ cat 99-dhcp.network | |||
[Match] | |||
Name=enp0* | |||
[Network] | |||
DHCP=yes | |||
=== Checking the networkd Service === | |||
Now let’s reboot the computer and check the service status with networkctl: | |||
$ networkctl | |||
IDX LINK TYPE OPERATIONAL SETUP | |||
1 lo loopback carrier unmanaged | |||
2 enp0s3 ether enslaved configured | |||
3 enp0s8 ether enslaved configured | |||
4 nd-bond bond routable configured | |||
4 links listed | |||
So we see that enp0s3 and enp0s8 are enslaved, and the nd-bond link is routable. | |||
Further, let’s disable one slave link, e.g., enp0s8: | |||
$ sudo ip link set enp0s8 down | |||
and check the status again: | |||
$ networkctl | |||
IDX LINK TYPE OPERATIONAL SETUP | |||
1 lo loopback carrier unmanaged | |||
2 enp0s3 ether enslaved configured | |||
3 enp0s8 ether off configured | |||
4 nd-bond bond degraded-carrier configured | |||
4 links listed. | |||
Let’s notice the degraded-carrier operational status, which indicates that one of the bonded links is out of use. | |||
=== netplan === | |||
With the netplan command, we can write down the network configuration in a YAML file. netplan doesn’t manage interfaces on its own. Instead, it supplies a renderer with an appropriate configuration. Furthermore, as a renderer, we can use NetworkManager or systemd-networkd. | |||
=== Configuration === | |||
Let’s create the networkd-bond.yaml file and copy it to the /etc/netplan folder: | |||
$ cat /etc/netplan/networkd-bond.yaml | |||
# Let network manage bond connection on this system | |||
network: | |||
version: 2 | |||
renderer: networkd | |||
ethernets: | |||
enp0s3: {} | |||
enp0s8: {} | |||
bonds: | |||
np-bond: | |||
dhcp4: yes | |||
interfaces: | |||
- enp0s3 | |||
- enp0s8 | |||
parameters: | |||
mode: active-backup | |||
primary: enp0s3 | |||
Let’s notice the ethernets section, which contains empty YAML maps enp0s3 and enp0s8, just to inform netplan about these interfaces. | |||
=== Application and Validation === | |||
Now let’s apply the new bonding configuration: | |||
$ sudo netplan apply | |||
Then, let’s check connections with networkctl: | |||
$ networkctl | |||
IDX LINK TYPE OPERATIONAL SETUP | |||
1 lo loopback carrier unmanaged | |||
2 enp0s3 ether enslaved configured | |||
3 enp0s8 ether enslaved configured | |||
4 nd-bond bond no-carrier configuring | |||
5 np-bond bond routable configured | |||
5 links listed. | |||
Let’s notice that the previous link, nd-bond is down. Instead, the new np-bond is up and working. So, let’s check its details: | |||
$ cat /proc/net/bonding/np-bond | |||
Ethernet Channel Bonding Driver: v5.15.0-46-generic | |||
Bonding Mode: fault-tolerance (active-backup) | |||
Primary Slave: enp0s3 (primary_reselect always) | |||
# ... | |||
Slave Interface: enp0s8 | |||
# ... | |||
Slave Interface: enp0s3 | |||
# ... | |||
=== Conclusion === | |||
In this article, we learned how to bind together internet interfaces. First, we shortly presented the network bonding. Then, we created a bonding interface with NetworkManager and networkd services. Next, we learned how to check the bonding setup and activity. | |||
Finally, we introduced netplan, which translated the YAML configuration into configurations applicable to both of these services. | |||
# https://www.baeldung.com/linux/network-bonding | |||
= TMP = | |||
== Bonding == | |||
This article will show how to "bond" two Ethernet connections together to create an auto failover interface. | |||
== Installation == | |||
First install the [https://packages.debian.org/ifenslave ifenslave] package, necessary to enable bonding: | |||
# apt-get install ifenslave | |||
=== Shutdown / Unconfigure Existing Interfaces === | |||
# ifdown eth0 (Repeat for all interfaces included in the bond) | |||
# /etc/init.d/networking stop | |||
[[Image:Bild1.png|top|alt="{i}"]]Sometimes, <tt>ifdown</tt> doesn't work, in that case use <tt>ifconfig eth0 down</tt>. | |||
== Configuration - Example 1 == | |||
Modify the <tt>/etc/network/interfaces</tt> file: | |||
auto bond0 | |||
iface bond0 inet static | |||
address 10.31.1.5 | |||
netmask 255.255.255.0 | |||
network 10.31.1.0 | |||
gateway 10.31.1.254 | |||
bond-slaves eth0 eth1 | |||
bond-mode active-backup | |||
bond-miimon 100 | |||
bond-downdelay 200 | |||
bond-updelay 200 | |||
For more detail, see <tt>/usr/share/doc/ifenslave/README.Debian</tt> and [http://www.kernel.org/doc/Documentation/networking/bonding.txt /usr/src/linux/Documentation/networking/bonding.txt]. | |||
== Configuration - Example 2 ("Laptop-Mode") == | |||
Tie cable and wireless network interfaces (RJ45/WLAN) together to define a single, virtual (i.e. bonding) network interface (e.g. bond0). | |||
As long as the network cable is connected, its interface (e.g. eth0) is used for the network traffic. If you pull the RJ45-plug, ''ifenslave'' switches over to the wireless interface (e.g. wlan0) transparently, without any loss of network packages. | |||
After reconnecting the network cable, ''ifenslave'' switches back to eth0 ("failover mode"). | |||
From the outside (=network) view it doesn't matter which interface is active. The bonding device presents its own software-defined (i.e. virtual) MAC address, different from the hardware defined MACs of eth0 or wlan0. | |||
The dhcp server will use this MAC to assign an ip address to the bond0 device. So the computer has one unique ip address under which it can be identified. Without bonding each interface would have its own ip address. | |||
Modify the <tt>/etc/network/interfaces</tt> file: | |||
# Define slaves | |||
auto eth0 | |||
iface eth0 inet manual | |||
bond-master bond0 | |||
bond-primary eth0 | |||
bond-mode active-backup | |||
auto wlan0 | |||
iface wlan0 inet manual | |||
wpa-conf /etc/network/wpa.conf | |||
bond-master bond0 | |||
bond-primary eth0 | |||
bond-mode active-backup | |||
# Define master | |||
auto bond0 | |||
iface bond0 inet dhcp | |||
bond-slaves none | |||
bond-primary eth0 | |||
bond-mode active-backup | |||
bond-miimon 100 | |||
Note: The configuration above has been found working on Debian 6 and later versions. The last verified version is Debian 9.8 (*). The configuration is somewhat contrary to the documentation of ''interfaces'', ''ifup'' and ''ifenslave'' and the examples under /usr/share/doc/ifenslave/examples/. | |||
Theoretically only the bond0 interface should have the ''auto'' attribute. '''ifup bond0''' will bring up the slaves automatically (as documentation says). This is partially true but obviously the configuration options of the slaves are ignored. E.g. wlan0 is brought up without starting ''wpa_supplicant'' and the ''bond-primary'' setting of eth0 is ignored. (TODO: Is this a bug in ''ifenslave''?) | |||
It seems the slaves must be brought up before bond0 to include their configuration options. To do so via the ''/etc/init.d/networking'' script, their definitions must be before the bond0 definition and the ''auto'' attributes have to be set. | |||
Of course, they must not be started again when bond0 starts. The option ''bond-slaves none'' disables this. | |||
The options ''bond-master'', ''bond-primary'' and ''bond-mode'' have to be repeated consistently for each slave. | |||
There will be warnings "ifup: interface xyz already configured", but at least it works. | |||
(*) With newer Debian versions the names of the network devices (may) have changed, depending on the upgrade path. Installations from scratch now use "predictable network interface names" ([https://wiki.debian.org/NetworkConfiguration#Predictable_Network_Interface_Names https://wiki.debian.org/NetworkConfiguration#Predictable_Network_Interface_Names]). To find the names of your interfaces you will want to look here: <tt>$ ls /sys/class/net/ </tt> | |||
This document still uses the traditional names. | |||
== Configuration - Example 3 ("Laptop mode", mostly as per documentation - Debian 9 "stretch") == | |||
This is a way to bring up a laptop mode with automatic failover between wired and wireless, with wired preferred if both are available, based on the documentation. However, the documentation example is not complete and not fully correct. Specificly, the changes to the example (usr/share/doc/ifenslave/examples/ethernet+wifi) are: * the eth0 stanza ''is'' required, otherwise it will work initially, but bond0 will remove eth0 for good if the eth0 link goes back down after coming up once (like when going from wireless to wired and then back to wireless), instead of just disabling it until it's link comes back up. | |||
* "bond-give-a-chance 10" resulted in the interface wlan0 trying to come up thrice, with the third attempt failing and then being unusable. Removing it entirely fixed that. Instead of deleting it I just commented it out FYI since YMMV. | |||
* the enslavement order seems to matter: if "bond-slaves" is specified the expected way (eth0 wlan0), then wlan0 will initially be the primary interface, only to be changed to eth0 upon the "bond-primary" directive. | |||
* "bond-mode" was changed from "1" to "active-backup" to be at least more readable. | |||
* it would be good practice to have the configuration for the wlan in a separate file so that "interfaces" does not require special protection, so that was changed as well. The contents of "wpa_supplicant.conf" are not specific to bonding and just entered as normal. | |||
So here is the <tt>/etc/network/interfaces</tt> marvel: | |||
auto bond0 | |||
iface bond0 inet static | |||
bond-slaves wlan0 eth0 | |||
bond-mode active-backup | |||
bond-primary eth0 | |||
bond-miimon 100 | |||
address <ipv4address>/<maskbits> | |||
gateway <ipv4address> | |||
allow-bond0 eth0 | |||
iface eth0 inet manual | |||
allow-bond0 wlan0 | |||
iface wlan0 inet manual | |||
# bond-give-a-chance 10 | |||
wpa-bridge bond0 | |||
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf | |||
If you use DHCP or some other service, you need to change the "bond0" stanza accordingly, but the other interfaces must remain "manual", as they aren't supposed to get an IP address. | |||
== Configuration - Example 4 - (very complex server setup) with LACP Bonded trunk and VLANs split out of the trunk, different MTU's on the VLANs == | |||
Example is Debian 11 with lots of hard-to-derive-from-man-pages syntax. You are NOT going to want this config on a desktop computer, this is likely only going to be used in a datacenter with a properly configured (802.3ad or LACP bonding) upstream network switch Example <tt>/etc/network/interfaces</tt> file: | |||
# | |||
# LACP bonded mode - and the bond is provisioned as a TRUNK (NOT an ACCESS port) | |||
# Required for bonding: | |||
#aptitude install vlan ifenslave | |||
# echo "8021q" >> /etc/modules | |||
# | |||
#cat /etc/modprobe.d/bonding.conf | |||
#alias bond0 bonding | |||
#options bonding mode=4 miimon=100 downdelay=200 updelay=200 | |||
# | |||
###### Bonded 10Gig setup - LACP Aggregation ####### | |||
## View status in: /proc/net/bonding | |||
auto bond0 | |||
iface bond0 inet manual | |||
bond-slaves eno1 eno2 | |||
# bond-mode 4 = 802.3ad AKA LACP | |||
bond-mode 4 | |||
bond-miimon 100 | |||
bond-downdelay 200 | |||
bond-updelay 200 | |||
bond-lacp-rate 1 | |||
bond-xmit-hash-policy layer2+3 | |||
up ifconfig bond0 0.0.0.0 up | |||
### trunked interface (configured as an 802.3ad AKA LACP bond on upstream switch) | |||
# split out vlan 123 and vlan 456 from this bond on seperate interfaces | |||
auto bond0.123 | |||
iface bond0.123 inet static | |||
address 10.123.0.3 | |||
netmask 255.255.255.0 | |||
mtu 1500 | |||
gateway 10.123.0.1 | |||
vlan-raw-device bond0 | |||
post-up ifconfig bond0.123 mtu 1500 | |||
# note this VLAN has a different MTU value | |||
auto bond0.456 | |||
iface bond0.456 inet static | |||
address 192.168.456.4 | |||
netmask 255.255.255.0 | |||
mtu 9000 | |||
vlan-raw-device bond0 | |||
post-up ifconfig vlan456 mtu 9000 | |||
post-up ifconfig eno1 mtu 9000 && ifconfig eno2 mtu 9000 && ifconfig bond0 mtu 9000 && ifconfig bond0.456 9000 | |||
# Note: upstream bond and member interfaces must have MTU9000, then lower level VLANS can use MTU1500 or MTU9000 | |||
== bridging the bond == | |||
If you want to use the bond in a bridge, simply add the bridge lines as per normal to your /etc/network/interfaces file. Change the bond interface to manual and use it as the bridge interface. Here's a sample bridged bond interfaces file: | |||
# onboard network interface | |||
auto enp4s0 | |||
iface enp4s0 inet manual | |||
# PCIe nic | |||
auto enp8s0 | |||
iface enp8s0 inet manual | |||
# bond inteface | |||
auto bond0 | |||
iface bond0 inet manual | |||
bond-slaves enp4s0 enp8s0 | |||
bond-mode 802.3ad | |||
# bridge interface | |||
auto br0 | |||
iface br0 inet static | |||
address 192.168.1.17 | |||
netmask 255.255.255.0 | |||
network 192.168.1.0 | |||
broadcast 192.168.1.255 | |||
gateway 192.168.1.1 | |||
bridge_ports bond0 | |||
bridge_stp off | |||
bridge_fd 0 | |||
bridge_maxwait 0 | |||
== Using systemd-networkd == | |||
This method does not use the package ifenslave which is mentioned above. If your computer is using systemd, and your network cards are currently working, you don't need anything else. | |||
Note that as is common on unix-type operating systems, case matters - "Bond" is different from "bond" and "Name" is not the same as "name". | |||
=== Enabling systemd-networkd === | |||
If you are not currently using systemd-networkd, you need to enable it. | |||
systemctl enable systemd-networkd | |||
=== Configuring the bond device === | |||
Create a file ending in <tt>.netdev</tt> in <tt>/etc/systemd/network</tt>. Name this after the bonded interface name you want to use (e.g. bond1.netdev). | |||
This example assumes 802.3ad or LACP bonding, for more information see the [https://manpages.debian.org/stretch/systemd/systemd.netdev.5.en.html systemd.netdev] manpage and/or the [https://www.kernel.org/doc/Documentation/networking/bonding.txt kernel documentation]. | |||
Most systems should work with 802.3ad and this is probably the mode you want as it has both network cards working together to give you double the throughput. However, if it doesn't work in your case, you can try another mode, such as active-backup (used in the ifenslave example above). | |||
[NetDev] | |||
Name=bond1 | |||
Description=LAG/Bond to a switch | |||
Kind=bond | |||
[Bond] | |||
Mode=802.3ad | |||
=== Add interfaces to the bond/lag === | |||
There are two ways you can do this. One is to create a .network file for each network interface plus one for the bonded network. The other is to describe the network interfaces in the bonded network's file. Here we'll use the latter method. | |||
Create a file ending in <tt>.network</tt> in <tt>/etc/systemd/network</tt> using the same name as previously (e.g. bond1.network). | |||
systemd-networkd uses a matching system to decide which interface to use. You could use name-based matching here if you like, but do not use mac-based matching as this could cause confusion with the bond changing mac addresses. | |||
This example uses pci-id based matching. To find the addresses for your network cards, use: | |||
lspci -d | grep Ether | |||
then use that information to create the .network file. | |||
[Match] | |||
Path=pci-0000:00:01.0 | |||
Path=pci-0000:05:10.0 | |||
[Network] | |||
Bond=bond1 | |||
Another option is to simply use the names of the network interfaces by replacing the Path= line with Name=<network interface name>. You can also use wildcards, and you can specify both/all devices in a single file: | |||
[Match] | |||
Name=enp* | |||
[Network] | |||
Bond=bond1 | |||
or | |||
[Match] | |||
Name=enp0s01 | |||
Name=enp5s10 | |||
[Network] | |||
Bond=bond1 | |||
=== Giving the bond an IP === | |||
Create a file ending in <tt>.network</tt> in <tt>/etc/systemd/network</tt>. The name (obviously) should not already be used. This tell systemd how to bring up the bonded network. | |||
For a static IP address, you could use: | |||
[Match] | |||
Name=bond1 | |||
[Network] | |||
Address=10.31.1.5 | |||
Gateway=10.31.1.1 | |||
DNS=10.31.1.1 | |||
For DHCP (e.g. for a laptop where you could use wireless and/or wired connections) try: | |||
[Match] | |||
Name=bond1 | |||
[Network] | |||
DHCP=yes | |||
=== Actualise the settings === | |||
If your network was using /etc/network/interfaces before setting up the bonding, rename the file to stop it from being used: | |||
mv /etc/network/interfaces /etc/network/interfaces.save | |||
At this point I recommend rebooting the system. This is the easiest way to clear out any previous network configurations and it tests that systemd-networkd starts as expected. The network should come up with bonding active. You can verify this with: | |||
ip link list | |||
You should see 4 devices, lo, your two physical network interfaces (marked as "SLAVE"), and the bond1 device. Only the bond1 device should have an ip address. It should also be marked as "MASTER". | |||
If you need to make further changes later, or fix problems with your current setup, from now on you can simply restart systemd-networkd after updating the /etc/systemd/network files. | |||
systemctl restart systemd-networkd | |||
=== enabling bridging for virtual machines === | |||
I've added this section because it's not immediately obvious that your existing network bridge configuration probably won't work with systemd-networkd. Prior to setting up my network bond, I was using the bridge utils to create a br0 device using /etc/network/interfaces. Since I've removed that file, I needed a new way to set up the bridge. | |||
Fortunately systemd-networkd is multi-talented and quite adept at handling network bridges. All you need to do is define the bridge and give it the appropriate characteristics. | |||
Like the bond0 device, you need to create a .netdev file to define the device. I created br0.netdev as follows: | |||
[NetDev] | |||
Name=br0 | |||
Kind=bridge | |||
Then I link it to the network bond I'd defined earlier using br0.network: | |||
[Match] | |||
Name=bond1 | |||
[Network] | |||
Bridge=br0 | |||
Finally, I change the management .network file to refer to br0 instead of bond1. Because the previous definitions have made bond1 a slave to br0, this results in the bridge being brought up properly. | |||
=== udev renaming issue === | |||
You will likely only see UDEV rules for your network devices if you have upgraded from previous versions of Debian. New installations name the network cards after their pci addresses. The rules are used to preserve the legacy names for devices (e.g. eth0) in case they are being used elsewhere. | |||
If you are confident that you are '''not''' using the legacy names, you can simply remove the file described below. | |||
"udev" assign network adapter names as per | |||
; /etc/udev/rules.d/70-persistent-net.rules | |||
where rule typically looks like this: | |||
# PCI device 0x10ec:0x8168 (r8169) | |||
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" | |||
The problem with bonding is that two or more NICs may have the very same MAC address which confuses udev when it tries to (re)name adapters as per their MACs and fails because another card with this MAC already exists. When it happens NIC may be left named like "rename2" instead of "eth0" etc. | |||
Possible solution is to change udev rule to assign network interface names as per NICs PCI IDs instead of MAC addresses. This can be done by replacing | |||
ATTR{address}=="xx:xx:xx:xx:xx:xx" | |||
with something like | |||
KERNELS=="0000:04:00.0" | |||
in the file "70-persistent-net.rules". | |||
Corresponding PCI IDs can be found in dmesg: | |||
sudo dmesg | grep eth | |||
Where one can look for line fragment like this: | |||
r8169 0000:04:00.0 eth0: RTL8168e/8111e | |||
# ^^^^^^^^^^^^ | |||
But this is not recommended as it will not find, for example, wireless devices or devices not using legacy names. | |||
The preferred alternative is to find PCI IDs using "<tt>lspci -D | grep Ether</tt>": | |||
0000:04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) | |||
Note that on modern systems, you can translate the PCI address to the network name by using the two middle numbers expressed in base10. In the above example, the controller 0000:04:00.0 would be enp4s00. | |||
== Testing / Debugging == | |||
=== Tip === | |||
In order to get some insight what is happening behind the scenes while experimenting a small script to show some information about the bonding device may be helpful. | |||
#! /bin/sh | |||
echo "Slaves = $(cat /sys/class/net/bond0/bonding/slaves)" | |||
echo "Primary = $(cat /sys/class/net/bond0/bonding/primary)" | |||
echo "Active Slave = $(cat /sys/class/net/bond0/bonding/active_slave)" | |||
r=$(pidof dhclient) | |||
test -n "$r" && ps $r | |||
r=$(pidof wpa_supplicant) | |||
test -n "$r" && ps $r | |||
=== Debugging ifenslave === | |||
The bonding mechanism is based on a kernel module named ''bonding'' which exposes its interface via the virtual /sys filesystem (e.g. /sys/class/net/bond0/*). | |||
Setup and configuration is done in userland with shell-scripts: * /etc/network/if-post-down.d/ifenslave | |||
* /etc/network/if-up.d/ifenslave | |||
* /etc/network/if-pre-up.d/ifenslave | |||
These scripts are called on system initialization and shutdown (actually it is ''ifup'' which calls them). Their intention is to feed the kernel module with the appropriate parameters and settings. | |||
If something with bonding fails at all (and the tip above doesn't help) you may have a look what the scripts do step by step. | |||
To enable verbose output, invoke '''ifup -a -v''' directly (instead of invoking ''/etc/init.d/networking''). The ''-v'' option enables a log of all commands the scripts are executing. This gives at least a trace what is happening when. | |||
Unfortunately this will not show the reactions of the kernel module (like possible error messages), because kernel (module) messages are reported via the syslog utility. | |||
To get a ''real'' insight what is going on you have to do what is called ''invasive debugging''. This means to add lines to the scripts at critical points to send a message to syslog. | |||
; Example | |||
Function ''sysfs_change_down'' in file ''/etc/network/if-pre-up.d/ifenslave'' | |||
logger -t sysfs_change_down sysfs "$1" "$2" | |||
sysfs "$1" "$2" | |||
logger -t sysfs_change_down $(cat /sys/class/net/bond0/bonding/mode) | |||
=== Additional Note For Debian Lenny On Sparc === | |||
''(may be applicable on other architectures as well)'' | |||
# cd /etc/modprobe.d | |||
# cat > aliases-bond.conf | |||
alias bond0 bonding | |||
options bonding mode=1 arp_interval=2000 arp_ip_target=192.168.3.1 | |||
<CTRL-D> | |||
Without this file, you will get a warning when starting up the bonded interface similar to this: | |||
bonding: Warning: either miimon or arp_interval and arp_ip_target module parameters must be specified, otherwise bonding will not detect link failures! see bonding.txt for details. | |||
=== Startup / Configure New Interfaces === | |||
# ifup bond0 | |||
# /etc/init.d/networking start | |||
And more, if you use a [https://wiki.debian.org/DebianLenny Lenny] environment which has been upgraded from [https://wiki.debian.org/DebianEtch Etch], it is strongly recommended to check the result of the following command to check the bonding device mode, because configuration files for Etch and older versions do not work for Lenny and later releases. | |||
cat /sys/class/net/bond0/bonding/mode | |||
1. Ping to other system in a terminal | |||
# ping X.X.X.X | |||
2. Disconnect the active network cable and watch the ping result, the network should be resumed in few seconds | |||
3. Reconnect the disconnected network cable, wait for 30 seconds to let the ARP table being updated | |||
4. Disconnect another network cable and watch the ping result, the network should be resumed in few seconds | |||
=== Change active slave === | |||
1. Use ifenslave to change the active slave. Below example will set eth0 as active slave | |||
# ifenslave -c bond0 eth0 eth1 | |||
# https://wiki.debian.org/Bonding#Change_active_slave | |||
[[Kategorie:Linux/Netzwerk]] | |||
[[Kategorie:Link Aggregation]] |
Aktuelle Version vom 12. November 2024, 18:38 Uhr
topic - Beschreibung
Beschreibung
- Failover und Hochverfügbarkeit
- Netzwerkbindung auf einem Linux-Server konfigurieren
- In einer Windows-Umgebung wird Network Bonding als Network Teaming bezeichnet
- dies ist eine Funktion, die jeder Serverarchitektur hilft, Hochverfügbarkeit und Failover in Szenarien zu gewährleisten, in denen eines der wichtigsten Ethernet-Kabel eine Fehlfunktion hat oder falsch konfiguriert ist.
- Best Practice
- wenn Sie einen Server für Produktionszwecke einrichten.
- Obwohl diese Funktion in einer Linux-Umgebungskonfiguration durchgeführt werden kann, müssen Sie dies jedoch zuerst mit Ihrem Netzwerkadministrator klären, um sicherzustellen, dass die mit Ihrem Server verbundenen Switches Unterstützung für die Netzwerkbindung bieten.
Verfügbaren Modi
Es gibt mehrere Bindungsmodi, die Sie in Ihrer Serverumgebung implementieren können.
Option | Beschreibung |
---|---|
Balance-rr | Dieser Modus bietet Lastausgleich und Fehlertoleranz (Failover) über die Round-Robin-Richtlinie. Bedeutet, dass es Pakete in sequentieller Reihenfolge vom ersten verfügbaren Slave bis zum letzten sendet. |
Active-Backup | Dieser Modus bietet Fehlertoleranzfunktionen über die Active-Backup-Richtlinie. Das bedeutet, dass nach dem Auflegen des Bonding-Ethernet nur noch 1 der Ethernet-Slaves aktiv ist. Der andere Ethernet-Slave wird nur dann aktiv, wenn und nur wenn der aktuell aktive Slave nicht aktiv ist. Wenn Sie diesen Modus wählen, werden Sie feststellen, dass die Bonding-MAC-Adresse von außen auf nur einem Netzwerkadapter sichtbar ist. Dies dient dazu, eine Verwechslung des Schalters zu vermeiden. |
Balance-xor | Dieser Modus bietet Lastausgleich und Fehlertoleranz. Es überträgt basierend auf der ausgewählten Sende-Hash-Richtlinie. Alternative Übertragungsrichtlinien können über die Option xmit_hash_policy ausgewählt werden. |
Broadcast | Dieser Modus bietet nur Fehlertoleranz. Es überträgt alles auf allen Slave-Ethernet-Schnittstellen. |
802.3ad | Dieser Modus bietet Lastausgleich und Fehlertoleranz. Es wird eine Aggregationsgruppe erstellt, die die gleichen Geschwindigkeits- und Duplexeinstellungen hat. Es nutzt alle Slave-Ethernet-Schnittstellen im aktiven Aggregator und basiert auf der 802.3ad-Spezifikation. Um diesen Modus zu implementieren, muss das Ethtool die Basistreiber unterstützen, um die Geschwindigkeit und den Duplexmodus jedes Slaves abzurufen. Der Switch muss auch die dynamische Link-Aggregation unterstützen. Normalerweise erfordert dies einen Eingriff des Network Engineers für eine detaillierte Konfiguration. |
Balance-TLB | Dieser Modus bietet Lastausgleichsmöglichkeiten, da der Name TLB für den Sende-Lastausgleich steht. Für diesen Modus, wenn die Konfiguration tlb_dynamic_lb = 1 ist, wird der ausgehende Verkehr entsprechend der aktuellen Last auf jeden Slave verteilt. Wenn die Konfiguration tlb_dynamic_lb = 0 ist, dann ist der Lastausgleich deaktiviert, jedoch wird die Last nur über die Hastverteilung verteilt. Für diesen Modus muss das Ethtool die Basistreiber unterstützen, um die Geschwindigkeit jedes Slaves zu ermitteln. |
Balance-ALB | Dieser Modus bietet Lastausgleichsmöglichkeiten, da der Name TLB für adaptiven Lastausgleich steht. Ähnlich wie balance-tlb, nur dass sowohl Sende- als auch Empfangsverkehr verbunden sind. Es erhält einen Lastenausgleich, indem es die ARP-Verhandlung erreicht. Der Bonding-Treiber fängt die vom lokalen System gesendeten ARP-Antworten auf ihrem Weg nach draußen ab und überschreibt die Quell-Hardwareadresse mit der eindeutigen Hardwareadresse eines der Slaves in der Bindung. Für diesen Modus muss das Ethtool die Basistreiber unterstützen, um die Geschwindigkeit jedes Slaves wiederherzustellen. |
Installation
# apt install ifenslave
- Gegebenenfalls werden noch die folgenden Programme benötigt
- net-tools
- Beinhaltet das Programm mii-tool, das unabhängig vom Medium den Status der Schnittstelle sowie die Geschwindigkeits- und Duplex-Einstellungen abfragen bzw. einstellen kann.
- Mii-Tool wird für den Modus 4 (802.3ad) und das Abfragen der verfügbaren Schnittstellen benötigt.
- ethtool
- Programm zum Setzen der Geschwindigkeits- und Duplex-Einstellungen bei Ethernet-Schnittstellen.
- Ethtool wird für die Modi 4 (802.3ad), 5 (balance-tlb) und 6 (balance-alb) benötigt.
- Siehe auch ethtool
# apt install net-tools ethtool
- bmon
- Optional ist das folgende Programm
- Bandwith Monitor, ein Programm, das die Datenübertragungsraten pro Gerät in Echtzeit anzeigen kann
# apt install bmon
Anwendungen
Problembehebung
Aufruf
Optionen
Parameter
Umgebung
Rückgabewert
Konfiguration
- Bevor wir mit der Konfiguration beginnen, müssen wir zunächst sicherstellen, dass wir mindestens 2 Ethernet-Schnittstellen in unserem Server konfiguriert haben.
- Um dies zu überprüfen, gehen Sie in den Netzwerk-Konfigurationsordner und listen Sie die verfügbaren Ethernet-Schnittstellen auf.
cd /etc/sysconfig/network-scripts/ ls *ifcfg*eth*
Das Ergebnis ist:
ifcfg-eth0 ifcfg-eth1
Beachten Sie, dass wir derzeit 2 Ethernet-Schnittstellen haben, die auf unserem Server eingerichtet sind, nämlich ETH0 und ETH1.
Lassen Sie uns nun eine Bonding-Schnittstelle namens BOND0 konfigurieren.
- Diese Schnittstelle wird eine virtuelle Ethernet-Schnittstelle sein, die die physikalische Ethernet-Schnittstelle von ETH0 und ETH1 enthält.
vi ifcfg-bond0 DEVICE=bond0 ONBOOT=yes MASTER=yes IPADDR=172.20.43.110 NETMASK=255.255.255.0 GATEWAY=172.20.43.1 BONDING_OPTS="mode=1 miimon=100" TYPE=Ethernet
ls *ifcfg*bon*
Ergebnis
ifcfg-bond0
Das ist alles. Bitte beachten Sie, dass ich innerhalb der BOND0-Schnittstelle eine IP-Adresse angegeben habe.
- Diese IP-Adresse ist die einzige IP-Adresse, die mit unserem Server verbunden ist.
- Um damit fortzufahren, müssen wir die physikalische Ethernet-Schnittstelle in Bezug auf die BOND0-Schnittstelle modifizieren.
vi ifcfg-eth0 DEVICE=eth0 TYPE=Ethernet ONBOOT=yes NM_CONTROLLED=no MASTER=bond0 SLAVE=yes vi ifcfg-eth1 DEVICE=eth1 TYPE=Ethernet ONBOOT=yes NM_CONTROLLED=no MASTER=bond0 SLAVE=yes
Erledigt
- Wir haben die Modifikation der Schnittstelle ETH0 und ETH1 vorgenommen.
- Beachten Sie, dass wir die IP-Adresse in beiden Interfaces entfernt und MASTER = bond0 angehängt haben.
- Dies ist notwendig, um zu bestätigen, dass es sich bei beiden Schnittstellen um virtuelle Schnittstellen handelt, die für die Ethernet-BOND0-Schnittstelle bestimmt sind.
- Um mit der Konfiguration fortzufahren
Erstellen wir eine bonding-Konfigurationsdatei namens bonding.conf unter /etc/modprobe.d
vi /etc/modprobe.d/bonding.conf alias bond0 bonding options bond0 mode=1 miimon=100 modprobe bonding
- Basierend auf der obigen Konfiguration haben wir ein Bindemodul über die Schnittstelle BOND0 konfiguriert
- Wir haben die Bonding-Konfiguration auch dem Verwendungsmodus = 1 zugewiesen, der eine aktive Backup-Richtlinie ist.
- Die Option miimon = 100 stellt die Überwachungsfrequenz für unseren Bonding-Server dar, um den Schnittstellenstatus in Millisekunden zu überwachen.
- Wie oben beschrieben, bietet dieser Modus Funktionen zur Fehlertoleranz in der Konfiguration des Server-Netzwerks.
Da alles eingerichtet ist, starten wir den Netzwerkdienst neu, um die neue Konfiguration zu laden.
service network restart Shutting down interface eth0: [ OK ] Shutting down interface eth1: [ OK ] Shutting down loopback interface: [ OK ] Bringing up loopback interface: [ OK ] Bringing up interface bond0: [ OK ]
- Ausgezeichnet, jetzt haben wir die neue Konfiguration geladen, die wir oben gemacht haben.
- Sie werden feststellen, dass die neue Schnittstelle namens BOND0 in der Netzwerkliste angezeigt wird.
- Sie werden auch feststellen, dass der Schnittstelle ETH0 und ETH1 keine IP-Adresse zugeordnet ist, sondern nur die BOND0-Schnittstelle die IP-Adresse anzeigt.
# ifconfig bond0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88 inet addr:172.20.43.110 Bcast:172.20.43.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe61:e488/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:1723 errors:0 dropped:0 overruns:0 frame:0 TX packets:1110 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:147913 (144.4 KiB) TX bytes:108429 (105.8 KiB) eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:1092 errors:0 dropped:0 overruns:0 frame:0 TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:103486 (101.0 KiB) TX bytes:105439 (102.9 KiB) eth1 Link encap:Ethernet HWaddr 08:00:27:61:E4:88 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:632 errors:0 dropped:0 overruns:0 frame:0 TX packets:28 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:44487 (43.4 KiB) TX bytes:3288 (3.2 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:208 errors:0 dropped:0 overruns:0 frame:0 TX packets:208 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:18080 (17.6 KiB) TX bytes:18080 (17.6 KiB)
- Sie können den Bindungsstatus auch über diesen Befehl überprüfen
cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eth0 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth0 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 08:00:27:61:e4:88 Slave queue ID: 0 Slave Interface: eth1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 08:00:27:c8:46:40 Slave queue ID: 0
Beachten Sie dazu, dass wir die Schnittstellen ETH0 und ETH1 erfolgreich in eine Bonding-Konfiguration im Active-Backup-Modus umgewandelt haben. Es wurde auch angegeben, dass der Server die Schnittstelle ETH0 verwendet, ETH1 wird als Backup-Schnittstelle dienen.
Test
Jetzt, da alles wie erwartet konfiguriert ist. Lassen Sie uns einen einfachen Test durchführen, um sicherzustellen, dass die von uns vorgenommene Konfiguration korrekt ist. Für diesen Test melden wir uns bei einem neuen Server (oder Linux-Desktop) an und beginnen mit dem Pingen unseres Bonding-Servers, um zu sehen, ob während des Tests eine intermittierende Verbindung besteht.
login as: root root@172.20.43.120's password: Last login: Wed Sep 14 12:50:15 2016 from 172.20.43.80 ping 172.20.43.110 PING 172.20.43.110 (172.20.43.110) 56(84) bytes of data. 64 bytes from 172.20.43.110: icmp_seq=1 ttl=64 time=0.408 ms 64 bytes from 172.20.43.110: icmp_seq=2 ttl=64 time=0.424 ms 64 bytes from 172.20.43.110: icmp_seq=3 ttl=64 time=0.415 ms 64 bytes from 172.20.43.110: icmp_seq=4 ttl=64 time=0.427 ms
In dieser Zeit gehen wir zurück zu unserem Bonding-Server und schalten die Ethernet-Schnittstelle ETH0 aus.
Zuerst führen Sie ifconfig eth0 aus:
# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:1092 errors:0 dropped:0 overruns:0 frame:0 TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:103486 (201.0 KiB) TX bytes:105439 (122.9 KiB) ifdown eth0
Nun haben wir die Dienste für die Netzwerkschnittstelle ETH0 abgeschaltet.
- Bindungsstatus überprüfen
cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eth1 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 08:00:27:c8:46:40 Slave queue ID: 0
Sie werden feststellen, dass die ETH0-Schnittstelle nun nicht mehr im Bindungsstatus existiert.
Während dieser Zeit gehen wir zurück zum vorherigen Testserver und überprüfen den kontinuierlichen Ping zu unserem Bonding-Server.
64 bytes from 172.20.43.110: icmp_seq=22 ttl=64 time=0.408 ms 64 bytes from 172.20.43.110: icmp_seq=23 ttl=64 time=0.402 ms 64 bytes from 172.20.43.110: icmp_seq=24 ttl=64 time=0.437 ms 64 bytes from 172.20.43.110: icmp_seq=25 ttl=64 time=0.504 ms 64 bytes from 172.20.43.110: icmp_seq=26 ttl=64 time=0.401 ms 64 bytes from 172.20.43.110: icmp_seq=27 ttl=64 time=0.454 ms 64 bytes from 172.20.43.110: icmp_seq=28 ttl=64 time=0.432 ms 64 bytes from 172.20.43.110: icmp_seq=29 ttl=64 time=0.434 ms 64 bytes from 172.20.43.110: icmp_seq=30 ttl=64 time=0.411 ms 64 bytes from 172.20.43.110: icmp_seq=31 ttl=64 time=0.554 ms 64 bytes from 172.20.43.110: icmp_seq=32 ttl=64 time=0.452 ms 64 bytes from 172.20.43.110: icmp_seq=33 ttl=64 time=0.408 ms 64 bytes from 172.20.43.110: icmp_seq=34 ttl=64 time=0.491 ms
Obwohl die Schnittstelle heruntergefahren wurde, ist haben, immer noch in der Lage sind, unseren Bonding-Server zu pingen und darauf zuzugreifen.
- Weiteren Test
Schalten Sie die ETH0-Schnittstelle wieder ein und die ETH1-Schnittstelle aus.
ifup eth0 cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eth1 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 08:00:27:c8:46:40 Slave queue ID: 0 Slave Interface: eth0 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 08:00:27:61:e4:88 Slave queue ID: 0
Da die ETH0-Schnittstelle bereits hochgefahren war, schalten wir die ETH1-Schnittstelle aus.
ifdown eth1 cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eth0 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth0 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 08:00:27:61:e4:88 Slave queue ID: 0
Nun gehen wir zurück zum Testserver und überprüfen, was auf dem kontinuierlichen Ping zu unserem Bonding-Server passiert.
64 bytes from 172.20.43.110: icmp_seq=84 ttl=64 time=0.437 ms 64 bytes from 172.20.43.110: icmp_seq=85 ttl=64 time=0.504 ms 64 bytes from 172.20.43.110: icmp_seq=86 ttl=64 time=0.401 ms 64 bytes from 172.20.43.110: icmp_seq=87 ttl=64 time=0.454 ms 64 bytes from 172.20.43.110: icmp_seq=88 ttl=64 time=0.432 ms 64 bytes from 172.20.43.110: icmp_seq=89 ttl=64 time=0.434 ms 64 bytes from 172.20.43.110: icmp_seq=90 ttl=64 time=0.411 ms 64 bytes from 172.20.43.110: icmp_seq=91 ttl=64 time=0.420 ms 64 bytes from 172.20.43.110: icmp_seq=92 ttl=64 time=0.487 ms 64 bytes from 172.20.43.110: icmp_seq=93 ttl=64 time=0.551 ms 64 bytes from 172.20.43.110: icmp_seq=94 ttl=64 time=0.523 ms 64 bytes from 172.20.43.110: icmp_seq=95 ttl=64 time=0.479 ms
Wir haben erfolgreich konfiguriert und bewiesen, dass unser Bonding-Server es schafft, das Disaster-Recovery-Szenario bei einem Netzwerkausfall zu erfüllen.
Sicherheit
Dokumentation
RFC
Man-Page
Info-Pages
Siehe auch
Links
Projekt
Weblinks
- http://wiki.debian.org/Bonding
- Bonding Modi auf www.dodgenet.de
- Ausführliche Anleitung zum Bonding auf www.linuxfoundation.org
- https://www.thomas-krenn.com/de/wiki/NIC_Bonding_unter_Debian
- Bonding - Ubuntu Community Documentation
- Bonding im Debian Wiki
- NIC Bonding Debian
- Lastverteilung und Ausfallsicherheit mit mehreren Netzwerkkarten
- Doppelt reissfest - Linux-Magazin, 07/2004
- Erläuterung der verschieden Modi auf LINUX Horizon
- http://blog.brightbox.co.uk/posts/howto-do-ethernet-bonding-on-ubuntu-properly
- bonding.txt (Kernel.org Documentation)
- Bonding unter Ubuntu 12.04.1
TMP
Configure network bonding
- by editing the /etc/network/interfaces
- The following example shows my previous bonding mode 1 configuration within the /etc/network/interfaces file, I will leave interfaces with their names for easier understanding:
auto enp2s0iface enp2s0 inet manualbond-master bond0bond-primary enp2s0 wlp3s0 auto wlp3s0iface wlp3s0 inet manualbond-master bond0bond-primary enp2s0 wlp3s0wpa-ssid 'LinuxHint'wpa-bssid '14:CF:E2:2A:EF:00'wpa-psk '972537288765'auto bond0iface bond0 inet dhcpbond-slaves nonebond-mode active-backupbond-miimon 100bond-downdelay 200bond-updelay 200
Datei:Bild17.pngA network bonding configuration with static IP instead of DHCP would have the last block like:
iface bond0 inet staticaddress 192.168.0.54netmask 255.255.255.0network 192.168.0.0gateway 192.168.0.1
Datei:Bild18.pngYou can run the following command to make sure bonding is working properly:# cat /proc/net/bonding/bond0
Source of examples: How to do Linux Network Bonding
Netzwerkkarten bündeln
Manchmal ist es notwendig, zwei Netzwerkkarten zu bündeln, z. B. für eine höhere Ausfallsicherheit oder um einfach den Durchsatz zu erhöhen. Man spricht auch vom NIC-Teaming oder Bonding, wenn man zwei Netzwerkschnittstellen zu einer virtuellen Einheit zusammenfasst. So wird erreicht, dass das System beide Karten als ein Gerät anspricht. Das bedeutet, dass beide Karten dieselbe Hardware-(MAC-)Adresse haben.
Die Bündelung der Netzwerkkarten wird durch das Dienstprogramm ifenslave bewerkstelligt, das dem Kernel ermöglicht, nur ein Gerät zu sehen und zu verwenden, während es die Datenpakete tatsächlich über die zwei Karten sendet. Hiermit kann sowohl Ausfallsicherheit als auch die Nutzung einer größeren Bandbreite erreicht werden.
Vorbereitung
- Vor dem Versuch, zwei Netzwerkkarten zu bündeln, sollte die Integrität und Funktionalität jeder Karte geprüft werden.
- Das Verwenden des Mii-Tools sollte etwa Folgendes zeigen:
sudo mii-tool
- Ausgabe
eth0: negotiated 100baseTx-FD flow-control, link ok eth1: negotiated 100baseTx-FD flow-control, link ok
Damit die Bündelung der Netzwerkkarten funktioniert, muss der Kernel dies unterstützen. Dies lässt sich wie folgt überprüfen [2]:
$ find /lib/modules/`uname -r` -iname bonding* /lib/modules/2.6.20-16-server/kernel/drivers/net/bonding/bonding.ko
Benutzung/Konfiguration
Zuerst werden alle Netzwerkkarten im zukünftigen Verbund deaktiviert:
sudo ifdown eth0 sudo ifdown eth1 sudo ifdown eth...
Dann wird die Konfiguration erstellt. Die /etc/network/interfaces kann wie oben beschrieben konfiguriert werden. Jedoch müssen einige Einträge enthalten sein und geändert werden. Dies wurde ab Ubuntu 8.04 deutlich vereinfacht, da ab nun die gesamte bonding-Konfiguration in dieser Datei abgelegt wird (aber nicht muss).
Einfach und schnell
Da in den Ubuntu-Versionen neuer als 8.04 alle Bonding-Optionen in /etc/network/interfaces gemacht werden kann, genügt es, lediglich ifenslave-2.6 zu installieren. Das betrifft zumindest die Konfiguration auf Linux-Seite. Manche bonding-Modi benötigen zusätzlich noch eine Konfiguration des Switches.
auto bond0 iface bond0 inet static address 10.0.0.10 netmask 255.255.255.0 network 10.0.0.0 broadcast 10.0.0.255 gateway 10.0.0.1 dns-nameservers 10.0.0.1 bond-slaves eth0 eth1 bond-mode 0 bond-miimon 100 bond-updelay 200 bond-downdelay 200
- Erklärungen
- bond-slaves: Welche Schnittstellen diesem Bond zugehörig sind, "all", falls alle.
- bond-mode: 0 bis 6 oder Names des Modus, in dem der bonding-Treiber arbeiten soll.
- bond-miimon: Das bonding-Modul überprüft alle 100ms den Link-Status aller gebündelten Schnittstellen.
- bond-updelay: Wenn eine Schnittstelle als (wieder) aktiv erkannt wird, werden 200ms abgewartet, ehe der bonding-Treiber das interface wieder in den Verbund integriert, ansonsten sofort.
- bond-downdelay: Gibt es einen Übertragungsfehler oder Aussetzer, so betrachtet das bonding-Modul die Schnittstelle erst nach 200ms als verloren und entfernt diese aus dem bond, ansonsten sofort.
Die Konfiguration für alle anderen Interfaces bis auf das loopback-Interface können entfernt bzw. deaktiviert werden.
- Wer ungeduldig ist, kann nun mit folgenden Befehlen den Treiber laden und die Netzwerke neu starten:
modprobe bonding /etc/init.d/networking stop /etc/init.d/networking start
Sicherer ist es, das System neu zu starten. Es sind keine weiteren Einträge in /etc/modules oder anderswo nötig, der bonding-Treiber wird automatisch nach einem Neustart geladen.
Ausführlicher, teilweise für ältere Versionen
Folgender Eintrag muss hinzugefügt werden
auto bond0 iface bond0 inet static address 10.0.0.10 netmask 255.255.255.0 network 10.0.0.0 broadcast 10.0.0.255 gateway 10.0.0.1 dns-nameservers 10.0.0.2 dns-search example.com slaves eth0 eth1
- Anmerkungen
- Hier wird eine statische Konfiguration verwendet, soll die Maschine ihre IP-Adresse mittels DHCP beziehen, wird iface bond0 inet static durch iface bond0 inet dhcp ersetzt, die eingerückten Zeilen entfallen dann. Die IP-Adress-Einstellungen müssen an das eigene Netzwerk angepasst werden.
- Hier werden die Schnittstellen eth0 und eth1 für den Verbund verwendet. Sollen weitere Schnittstellen eingebunden werden, so werden diese hinten angefügt. Alternativ kann auch slaves all geschrieben werden, wenn alle aktiven Schnittstellen in den Verbund aufgenommen werden sollen.
Des Weiteren sollten für die darin enthaltenen einzelnen Schnittstellen die Funktion "auto" durch "allow" ersetzt werden, damit diese nicht zusätzlich bei dem Systemstart mitgestartet werden.
- Im Skript für den Systemstart ist die Funktion "ifup -a" enthalten und die startet alle Netzwerkschnittstellen, die in der Konfiguration mit "auto" vermerkt sind.
- Ansonsten startet Linux jede einzelne Schnittstelle und zusätzlich den Verbund.
- Das ist falsch, denn die einzelnen Schnittstellen sollen durch den Verbund aktiviert werden.
Deshalb sollte man für die im Verbund enthaltenen Schnittstellen den Eintrag wie folgt ändern:
allow eth1 iface eth1 inet dhcp
- Dabei ist es egal, ob man "dhcp" setzt oder was anderes, da diesen Schnittstellen keine eigene IP-Adresse mehr zugeteilt wird.
- Das ist richtig, da die Schnittstellen nur noch durch EINE IP-Adresse angesprochen werden sollen. Dies muss und sollte die IP-Adresse des Verbundes sein.
Danach sollte nach JEDEM Systemstart der Befehl "ifconfig" für bond0 folgenden Hinweis enthalten:
[...] UP BROADCAST RUNNING MASTER MULTICAST [...]
und für die darin enthaltenen Schnittstellen
[...] UP BROADCAST RUNNING SLAVE MULTICAST [...]
Die Konfiguration des Bonding-Treibers muss angegeben werden, hierfür wird in /etc/modprobe.d mit Superuser-Rechten eine neue Datei bonding.conf erstellt und folgendes eingetragen:
alias bond0 bonding options bonding mode=1 miimon=100
- Anmerkung
- Hier wird Bonding-Mode 1 (active-backup) verwendet, das Mii-Tool soll alle 100 Millisekunden den Link-Status überprüfen.
Das Laden des Moduls erfolgt mit dem Befehl:
sudo modprobe bonding
Damit das auch beim nächsten Neustart noch der Fall ist, sollte das bonding-Modul noch in die /etc/modules eingetragen werden [3]:
bonding
Nun wird das Modul automatisch beim Systemstart geladen.
Der neue Verbund wird mit folgendem Befehl gestartet:
sudo ifup bond0
Bonding Modi
Bei der Konfiguration muss ein Bonding-Modus (bond-mode) angegeben werden, der den Zweck und die Art der Bündelung der Netzwerkschnittstellen angibt.
Modus | Bezeichnung | Zweck | Beschreibung |
---|---|---|---|
0 | balance-rr | Lastverteilung & Ausfallsicherheit | Die genutzte Netzwerkschnittstelle wird im Round-Robin-Verfahren festgelegt, das heißt die verfügbaren Schnittstellen werden in Senderichtung wechselweise genutzt. In Empfangsrichtung kann max. die Geschwindigkeit einer einzelnen Schnittstelle erreicht werden - je mehr Teilnehmer, umso mehr Upload-Gesamtbandbreite, denn diese werden auf die übrigen freien Schnittstellen aufgeteilt. |
1 | active-backup | Ausfallsicherheit | Nur eine Schnittstelle ist aktiv, im Fehlerfalle wird eine der anderen im Verbund genutzt. die Netzwerkkarten können über verschiedene Switches angebunden werden. |
2 | balance-xor | Lastverteilung & Ausfallsicherheit | Es wird für jede Gegenstelle im Netzwerk eine zu nutzende Netzwerkschnittstelle zugewiesen, die Zuordnung geschieht über den Modulo der Division zwischen der Formel (Quell-MAC-Adresse XOR Ziel-MAC-Adresse) und der Anzahl der Slave-Schnittstellen. |
3 | broadcast | Ausfallsicherheit | Daten werden auf allen Netzwerkschnittstellen gesendet. Die Nutzung mehrerer Switches ist möglich. |
4 | 802.3ad | Lastverteilung & Ausfallsicherheit | 802.3ad ist ein Standard der IEEE, der die Bündelung mehrerer Schnittstellen mit gleichen Übertragungseinstellungen (Geschwindigkeit und Duplex-Einstellungen) erlaubt, um eine höhere Bandbreite zu erhalten. Es kann nur ein Switch verwendet werden, dieser muss 802.3ad unterstützen. ethtool oder mii-tool wird benötigt. |
5 | balance-tlb | Lastverteilung | Es wird für jede Gegenstelle im Netzwerk eine zu nutzende Netzwerkschnittstelle zugewiesen. Das Verfahren hierzu ist jedoch komplexer und effizienter als bei balance-xor. Das Programm ethtool wird benötigt. |
6 | balance-alb | Lastverteilung | Erweitertes balance-tlb, zusätzlich zur MAC-basierten Zuordnung der Schnittstellen für ausgehende Verbindungen werden eingehende Verbindungen auf die Schnittstellen verteilt. Das Programm ethtool wird benötigt. |
Eine sichere Variante mit zwei Bonding Interfaces
- Bei Unsicherheiten oder scheinbaren Zufälligkeiten der Funktionalität der Konfiguration kann die folgende Variante gewählt werden.
- Diese geht davon aus, dass ein Interface per DHCP, das andere direkt adressiert wird.
Voraussetzung ist das folgende Paket:
# apt-get install moreutils
- Die Bonding-Parameter werden in /etc/modprobe.d/bonding.conf gesetzt
alias bond0 bonding alias bond1 bonding options bonding max_bonds=2 mode=1 miimon=100 use_carrier=1
Das Bonding Modul muss geladen werden. Dazu wird /etc/modules ergänzt um die Zeile:
bonding
Danach wird die Netzwerkkonfiguration erstellt.
Diese enthält folgende Nebenbedingungen:
- Über eth0 wird eine DHCP-Adresse vermittelt
- Die Interfaces eth0 und eth1 bilden bond0
- Mittels eth2 und eth3 wird statisch eine Adresse an bond1 gebunden
Schnittstellendefinition
- /etc/network/interfaces
auto lo iface lo inet loopback
auto eth0 iface eth0 inet dhcp iface bond0 inet manual iface eth1 inet manual
auto bond1 iface bond1 inet static pre-up /sbin/ifconfig eth2 up pre-up /sbin/ifconfig eth3 up up /sbin/ifenslave bond1 eth2 up /sbin/ifenslave bond1 eth3 post-down /sbin/modprobe -r bond1 eth2 eth3 address … netmask … network … broadcast … gateway … dns-nameservers … dns-search …
Nun muss noch bond0 entsprechend konfiguriert werden. Das geschieht in /etc/rc.local
set -x /sbin/ifconfig eth1 $(/usr/bin/ifdata -pa eth0) \ netmask $(/usr/bin/ifdata -pn eth0) up && \ /sbin/ifconfig bond0 $(/usr/bin/ifdata -pa eth0) \ netmask $(/usr/bin/ifdata -pn eth0) && \ /sbin/ifenslave bond0 eth0 eth1 && \ /sbin/ifenslave -c bond0 eth1 set +x
Variante, die auch funktionierte
- Gewisse Unsicherheiten ergeben sich aus der im Paket linux-doc beschriebenen Dokumentation /usr/share/doc/linux-doc/networking/bonding.txt.gz.
- Folgende Variante im obrigen Beispiel von bond1 funktionierte:
- /etc/network/interfaces
auto bond1 iface bond1 inet static bond-slaves none bond-mode active-backup bond-miimon 100 address … ... auto eth2 iface eth2 inet manual bond-master bond1 bond-primary eth2 eth3 auto eth3 iface eth3 inet manual bond-master bond1 bond-primary eth2 eth3
Nur zufällig funktionierende Varianten
Bei den folgenden Variante sind die in /etc/rc.local eingetragenen Modifikationen still zu legen.
- /etc/network/interfaces
auto bond0 iface bond0 inet dhcp bond-slaves none bond-mode active-backup bond-miimon 100 auto eth0 iface eth0 inet dhcp bond-master bond0 bond-primary eth0 eth1 auto eth1 iface eth1 inet manual bond-master bond0 bond-primary eth0 eth1
Diese Variante funktionierte nicht immer. Für die MAC-Adresse von eth0 wird dabei eine IP Adresse bereit gestellt. Die Mac-Adresse von eth1 wird nicht mit einer IP-Adresse versorgt.
auto bond0 iface bond0 inet dhcp bond-slaves none bond-mode active-backup bond-miimon 100 auto eth0 iface eth0 inet manual bond-master bond0 bond-primary eth0 eth1 auto eth1 iface eth1 inet manual bond-master bond0 bond-primary eth0 eth1
Die letzte Variante, die genau der Beschreibung aus linux-doc entspricht, funktionierte leider gar nicht bei mir.
Hardwareunabhängiges Image
- Aus Gründen der Hochverfügbarkeit kann es nötig sein, ein Image zu bauen, welches auch auf anderen, baugleichen Rechnern läuft.
- Dabei kann dieses Image sowohl ein NFS-Filesystem als auch ein Fibre-Channel-Filesystem sein. Wichtig ist, dass dieses Image bei Hardwareausfall auf einem anderen, baugleichen Rechner läuft.
- Damit dies gewährleistet ist muss die MAC-Adresse aus der Konfiguration der Netzwerkkarte entfernt werden und durch Hardwaremerkmale ersetzt werden. Dazu müssen die entsprechenden Merkmale ermittelt werden.
Dies Kann mit folgendem Befehl beispielsweise erfolgen:
for I in {0,1,2,3,4,5,6,7} do echo eth$I udevadm info -a -p /sys/class/net/eth$I | grep KERNELS udevadm info -a -p /sys/class/net/eth$I | grep 'ATTR{dev_id}' udevadm info -a -p /sys/class/net/eth$I | grep 'ATTR{type}' done
Wichtig ist dabei, dass Merkmale gewählt werden, die nur auf diese Hardwareelemente (Netzwerkanschlüsse) zutreffen.
Im obrigen Beispiel kommt es zu folgender Ausgabe:
eth0 KERNELS=="0000:04:00.0" KERNELS=="0000:00:02.2" KERNELS=="pci0000:00" ATTR{dev_id}=="0x0" ATTR{type}=="1" eth1 KERNELS=="0000:04:00.1" KERNELS=="0000:00:02.2" KERNELS=="pci0000:00" ATTR{dev_id}=="0x0" ATTR{type}=="1" …
Daraus sollte dann die Definition von /etc/udev/rules.d/70-persistent-net.rules überschrieben werden.
# PCI device 0x8086:/sys/devices/pci0000:00/0000:00:02.2/0000:04:00.0 (igb) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNELS=="0000:04:00.0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x8086:/sys/devices/pci0000:00/0000:00:02.2/0000:04:00.1 (igb) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNELS=="0000:04:00.1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
...
Mittels
sudo service udev restart
wird die Änderung getestet bzw. wirksam.
Problembehebung
Problembeschreibung
Wenn man mehrere Netzwerkkarten des gleichen Typs einsetzt, kann es passieren, dass die Netzwerkkarten neu benannt werden. Ein
# ifconfig -a
liefert dann z. B. einen Eintrag wie:
[...] eth?_rename [...]
Um dies zu vermeiden, muss die Datei /etc/network/interfaces editiert werden.
Im Abschnitt bonding muss die Angabe für eine MAC eingefügt werden:
auto bond0 iface bond0 inet static ... hwaddress ether {MAC-ADRESSE} ...
Bitte keine MAC von einer vorhandenen Karte benutzen, sondern selber eine setzen.
TMP
Bonding Arten
- mode=0 (balance-rr)
- mode=1 (active-backup)
- mode=2 (balance-xor)
- mode=3 (broadcast)
- mode=4 (802.3ad) (siehe dazu Link Aggregation und LACP Grundlagen)
- mode=5 (balance-tlb)
- mode=6 (balance-alb)
Konfiguration Debian 5.0 Lenny und neuer
In diesem Beispiel zeigen wir eine Konfiguration mit mode 4 (802.3ad).
Für die Link Aggregation nutzen wir:
- eth0 und
- eth1
/etc/network/interfaces
enthält die folgende Konfiguration:
auto lo bond0 iface bond0 inet static address 10.10.10.174 netmask 255.255.255.0 network 10.10.10.0 gateway 10.10.10.1 slaves eth0 eth1 bond_mode 802.3ad
Als Gegenstelle verwenden wir den Switch eines Intel Modular Servers. Eth0 und eth1 des Servers sind mit den LAN-Ports 1 und 2 am Modular Server Switch verbunden. Diese beide LAN-Ports sind für die Link Aggregation konfiguriert. Details dazu siehe Link Aggregation beim Modular Server und Link Aggregation Lastverteilung Test Modular Server Switch.
Linux Network Bonding
If you have a few years of experience in the Linux ecosystem, and you’re interested in sharing that experience with the community, have a look at our Contribution Guidelines.
Overview
Modern hardware offers multiple network interfaces. However, we need appropriate means to use them effectively. An available way is to bind together existing connections, so the system recognizes them as one. In this way, we increase redundancy or throughput.
In this tutorial, we’ll learn how to use popular network services to create network bonding.
Prerequisites
Let’s notice that we can bind connections in many ways. Here, we’ll use the active-backup mode with two slave connections. With this setup, we increase redundancy, as the backup connection is activated when the primary fails.
Further, we need the Linux kernel to manage network bonding. So, let’s check if the bonding kernel module is available with lsmod:
$ lsmod | grep bond bonding 196608 0
If it isn’t the case, we need to load it with modprobe:
$ sudo modprobe bonding
Next, we need at least two network interfaces. So, we’re going to use a virtual Linux system in the Oracle VM VirtualBox Manager. Subsequently, we’ll provide two NAT interfaces to simulate hardware ethernet cards.
Throughout this article, we’ll be working with Lubuntu 22.04 LTS with the kernel version 5.15.0-46-generic inside VirtualBox 6.1 on Windows 10.
Now, let’s check network interfaces with lshw:
$ sudo lshw -short -c network [sudo] password for joe: H/W path Device Class Description ======================================================= /0/100/3 enp0s3 network 82540EM Gigabit Ethernet Controller /0/100/8 enp0s8 network 82540EM Gigabit Ethernet Controller
So, we have two virtual ethernet cards – enp0s3 and enp0s8.
Bonding With NetworkManager
Let’s use the NetworkManager service to manage network connections. Usually, this tool is available out of the box in most Linux distributions. First, let’s check if it’s running with systemctl:
$ systemctl status NetworkManager ● NetworkManager.service - Network Manager Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; ve> Active: active (running) since Sat 2022-09-03 14:57:17 CEST; 14min ago # ...
If necessary, we should install NetworkManager from the network-manager package.
Using nmtui
nmtui is a text user interface to configure NetworkManager. So, let’s start it and go to Edit a connection menu. Then we’re going to create a new connection with Add. Finally, let’s select Bond: screen
Then, let’s set the profile name and the device’s name – nm-bond: screen01
Now, let’s provide a slave connection with Add and create an Ethernet connection: screen02
Subsequently, in the next panel, we should use one of enp0s3 or enp0s8 devices: screen03
Finally, let’s choose Active-backup as Mode. Then we’ll be asked to specify the primary slave interface – enp0s3: screen06
Checking Configuration
Let’s reboot the system and check the links:
$ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp0s3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master nm-bond state UP mode DEFAULT group default qlen 1000 link/ether 6a:23:45:28:ac:0f brd ff:ff:ff:ff:ff:ff permaddr 08:00:27:42:6c:e3 3: enp0s8: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master nm-bond state UP mode DEFAULT group default qlen 1000 link/ether 6a:23:45:28:ac:0f brd ff:ff:ff:ff:ff:ff permaddr 08:00:27:fa:13:16 4: nm-bond: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 6a:23:45:28:ac:0f brd ff:ff:ff:ff:ff:ff
So we can find out that the bonding is working with two slaves. Moreover, let’s notice that the MAC address of all three interfaces is the same.
Now let’s check the bonding configuration in the /proc/net/bonding/nm-bond file: $ cat /proc/net/bonding/nm-bond
Ethernet Channel Bonding Driver: v5.15.0-47-generic Bonding Mode: fault-tolerance (active-backup) Primary Slave: enp0s3 (primary_reselect always) Currently Active Slave: enp0s3 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Peer Notification Delay (ms): 0 Slave Interface: enp0s3 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 08:00:27:42:6c:e3 Slave queue ID: 0
Slave Interface: enp0s8 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 08:00:27:fa:13:16 Slave queue ID: 0
We can find that the currently used slave link is enp0s3. In addition, the Permanent HW addr contains the MAC address of each slave interface before bonding.
Bonding Connection in Action
Let’s check how the redundancy bonding works. First, let’s ping through nm-bond:
$ ping -c 10 -I nm-bond www.baeldung.com PING www.baeldung.com (172.66.40.248) from 10.0.2.15 nm-bond: 56(84) bytes of data. # ...
--- www.baeldung.com ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9014ms rtt min/avg/max/mdev = 14.011/14.650/15.156/0.453 ms
In addition, let’s check the active interface:
$ cat /sys/class/net/nm-bond/bonding/active_slave enp0s3
Next, let’s just turn down the active slave enp0s3:
$ sudo ip link set enp0s3 down
Then, let’s ping again:
$ ping -c 10 -I nm-bond www.baeldung.com PING www.baeldung.com (172.66.40.248) from 10.0.2.15 nm-bond: 56(84) bytes of data. # ...
--- www.baeldung.com ping statistics --- 10 packets transmitted, 9 received, 10% packet loss, time 9014ms rtt min/avg/max/mdev = 13.863/14.618/15.177/0.414 ms
So we see that the connection works. Finally, let’s make sure that the bond interface has switched to enp0s8:
$ cat /sys/class/net/nm-bond/bonding/active_slave enp0s8
Bonding With systemd-networkd
Instead of NetworkManager, we can use the systemd-networkd service. Assuming that we have NetworkManager working, we need to disable it:
$ systemctl disable NetworkManager
Subsequently, let’s enable systemd-networkd:
$ systemctl enable systemd-networkd
In addition, we should check if the NetworkManager-wait-online service is in use:
$ systemctl status NetworkManager-wait-online
If so, let’s disable it:
$ systemctl disable NetworkManager-wait-online
and enable its networkd counterpart:
$ systemctl enable systemd-networkd-wait-online
Configure systemd-networkd
We can provide configuration files in the /etc/systemd/network folder. Therein, files with the network extension describe the connections, while the file with netdev extension contains the bonding configuration.
Let’s notice that the files are parsed in alphabetic order. So per convention, we should start their names with numbers.
Now, let’s review the setup:
$ ls -1 /etc/systemd/network 10-nd-bond.network 20-enp0s3.network 20-nd-bond.netdev 30-enp0s8.network 99-dhcp.network
First, let’s look into the bond device:
$ cat 20-nd-bond.netdev [NetDev] Name=nd-bond Kind=bond [Bond] Mode=active-backup PrimaryReselectPolicy=always MIIMonitorSec=1s
So in the NetDev section, we define the type and name of the device. Next, we add the device’s details in the Bond section.
Now let’s examine the bond connection:
$ cat 10-nd-bond.network [Match] Name=nd-bond [Network] DHCP=yes
Let’s notice that the Name field in the Match section indicates that this configuration applies to the bonding device. Subsequently, the Network section says that we use DHCP.
Further, let’s move to the enslaved connections enp0s3 and enp0s8:
$ cat 20-enp0s3.network [Match] Name=enp0s3 [Network] Bond=nd-bond PrimarySlave=true
As before, the Match section says which interface this file refers to. Next, we provide the bonding device name in the Network section. Finally, we make enp0s3 the primary slave.
Similarly, for enp0s8, we have:
$ cat 30-enp0s8.network [Match] Name=enp0s8 [Network] Bond=nd-bond
Finally, the 99-dhcp.network contains the fallback setup for any connection whose name matches the enp0* pattern:
$ cat 99-dhcp.network [Match] Name=enp0* [Network] DHCP=yes
Checking the networkd Service
Now let’s reboot the computer and check the service status with networkctl:
$ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp0s3 ether enslaved configured 3 enp0s8 ether enslaved configured 4 nd-bond bond routable configured 4 links listed
So we see that enp0s3 and enp0s8 are enslaved, and the nd-bond link is routable.
Further, let’s disable one slave link, e.g., enp0s8:
$ sudo ip link set enp0s8 down
and check the status again:
$ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp0s3 ether enslaved configured 3 enp0s8 ether off configured 4 nd-bond bond degraded-carrier configured 4 links listed.
Let’s notice the degraded-carrier operational status, which indicates that one of the bonded links is out of use.
netplan
With the netplan command, we can write down the network configuration in a YAML file. netplan doesn’t manage interfaces on its own. Instead, it supplies a renderer with an appropriate configuration. Furthermore, as a renderer, we can use NetworkManager or systemd-networkd.
Configuration
Let’s create the networkd-bond.yaml file and copy it to the /etc/netplan folder:
$ cat /etc/netplan/networkd-bond.yaml # Let network manage bond connection on this system network: version: 2 renderer: networkd ethernets: enp0s3: {} enp0s8: {} bonds: np-bond: dhcp4: yes interfaces: - enp0s3 - enp0s8 parameters: mode: active-backup primary: enp0s3
Let’s notice the ethernets section, which contains empty YAML maps enp0s3 and enp0s8, just to inform netplan about these interfaces.
Application and Validation
Now let’s apply the new bonding configuration:
$ sudo netplan apply
Then, let’s check connections with networkctl:
$ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp0s3 ether enslaved configured 3 enp0s8 ether enslaved configured 4 nd-bond bond no-carrier configuring 5 np-bond bond routable configured 5 links listed.
Let’s notice that the previous link, nd-bond is down. Instead, the new np-bond is up and working. So, let’s check its details:
$ cat /proc/net/bonding/np-bond Ethernet Channel Bonding Driver: v5.15.0-46-generic Bonding Mode: fault-tolerance (active-backup) Primary Slave: enp0s3 (primary_reselect always) # ... Slave Interface: enp0s8 # ... Slave Interface: enp0s3 # ...
Conclusion
In this article, we learned how to bind together internet interfaces. First, we shortly presented the network bonding. Then, we created a bonding interface with NetworkManager and networkd services. Next, we learned how to check the bonding setup and activity.
Finally, we introduced netplan, which translated the YAML configuration into configurations applicable to both of these services.
TMP
Bonding
This article will show how to "bond" two Ethernet connections together to create an auto failover interface.
Installation
First install the ifenslave package, necessary to enable bonding:
# apt-get install ifenslave
Shutdown / Unconfigure Existing Interfaces
# ifdown eth0 (Repeat for all interfaces included in the bond) # /etc/init.d/networking stop
"{i}"Sometimes, ifdown doesn't work, in that case use ifconfig eth0 down.
Configuration - Example 1
Modify the /etc/network/interfaces file:
auto bond0
iface bond0 inet static address 10.31.1.5 netmask 255.255.255.0 network 10.31.1.0 gateway 10.31.1.254 bond-slaves eth0 eth1 bond-mode active-backup bond-miimon 100 bond-downdelay 200 bond-updelay 200
For more detail, see /usr/share/doc/ifenslave/README.Debian and /usr/src/linux/Documentation/networking/bonding.txt.
Configuration - Example 2 ("Laptop-Mode")
Tie cable and wireless network interfaces (RJ45/WLAN) together to define a single, virtual (i.e. bonding) network interface (e.g. bond0).
As long as the network cable is connected, its interface (e.g. eth0) is used for the network traffic. If you pull the RJ45-plug, ifenslave switches over to the wireless interface (e.g. wlan0) transparently, without any loss of network packages.
After reconnecting the network cable, ifenslave switches back to eth0 ("failover mode").
From the outside (=network) view it doesn't matter which interface is active. The bonding device presents its own software-defined (i.e. virtual) MAC address, different from the hardware defined MACs of eth0 or wlan0.
The dhcp server will use this MAC to assign an ip address to the bond0 device. So the computer has one unique ip address under which it can be identified. Without bonding each interface would have its own ip address.
Modify the /etc/network/interfaces file:
# Define slaves auto eth0 iface eth0 inet manual bond-master bond0 bond-primary eth0 bond-mode active-backup auto wlan0 iface wlan0 inet manual wpa-conf /etc/network/wpa.conf bond-master bond0 bond-primary eth0 bond-mode active-backup # Define master auto bond0 iface bond0 inet dhcp bond-slaves none bond-primary eth0 bond-mode active-backup bond-miimon 100
Note: The configuration above has been found working on Debian 6 and later versions. The last verified version is Debian 9.8 (*). The configuration is somewhat contrary to the documentation of interfaces, ifup and ifenslave and the examples under /usr/share/doc/ifenslave/examples/.
Theoretically only the bond0 interface should have the auto attribute. ifup bond0 will bring up the slaves automatically (as documentation says). This is partially true but obviously the configuration options of the slaves are ignored. E.g. wlan0 is brought up without starting wpa_supplicant and the bond-primary setting of eth0 is ignored. (TODO: Is this a bug in ifenslave?)
It seems the slaves must be brought up before bond0 to include their configuration options. To do so via the /etc/init.d/networking script, their definitions must be before the bond0 definition and the auto attributes have to be set.
Of course, they must not be started again when bond0 starts. The option bond-slaves none disables this.
The options bond-master, bond-primary and bond-mode have to be repeated consistently for each slave.
There will be warnings "ifup: interface xyz already configured", but at least it works.
(*) With newer Debian versions the names of the network devices (may) have changed, depending on the upgrade path. Installations from scratch now use "predictable network interface names" (https://wiki.debian.org/NetworkConfiguration#Predictable_Network_Interface_Names). To find the names of your interfaces you will want to look here: $ ls /sys/class/net/
This document still uses the traditional names.
Configuration - Example 3 ("Laptop mode", mostly as per documentation - Debian 9 "stretch")
This is a way to bring up a laptop mode with automatic failover between wired and wireless, with wired preferred if both are available, based on the documentation. However, the documentation example is not complete and not fully correct. Specificly, the changes to the example (usr/share/doc/ifenslave/examples/ethernet+wifi) are: * the eth0 stanza is required, otherwise it will work initially, but bond0 will remove eth0 for good if the eth0 link goes back down after coming up once (like when going from wireless to wired and then back to wireless), instead of just disabling it until it's link comes back up.
- "bond-give-a-chance 10" resulted in the interface wlan0 trying to come up thrice, with the third attempt failing and then being unusable. Removing it entirely fixed that. Instead of deleting it I just commented it out FYI since YMMV.
- the enslavement order seems to matter: if "bond-slaves" is specified the expected way (eth0 wlan0), then wlan0 will initially be the primary interface, only to be changed to eth0 upon the "bond-primary" directive.
- "bond-mode" was changed from "1" to "active-backup" to be at least more readable.
- it would be good practice to have the configuration for the wlan in a separate file so that "interfaces" does not require special protection, so that was changed as well. The contents of "wpa_supplicant.conf" are not specific to bonding and just entered as normal.
So here is the /etc/network/interfaces marvel:
auto bond0 iface bond0 inet static bond-slaves wlan0 eth0 bond-mode active-backup bond-primary eth0 bond-miimon 100 address <ipv4address>/<maskbits> gateway <ipv4address> allow-bond0 eth0 iface eth0 inet manual allow-bond0 wlan0 iface wlan0 inet manual # bond-give-a-chance 10 wpa-bridge bond0 wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
If you use DHCP or some other service, you need to change the "bond0" stanza accordingly, but the other interfaces must remain "manual", as they aren't supposed to get an IP address.
Configuration - Example 4 - (very complex server setup) with LACP Bonded trunk and VLANs split out of the trunk, different MTU's on the VLANs
Example is Debian 11 with lots of hard-to-derive-from-man-pages syntax. You are NOT going to want this config on a desktop computer, this is likely only going to be used in a datacenter with a properly configured (802.3ad or LACP bonding) upstream network switch Example /etc/network/interfaces file:
# # LACP bonded mode - and the bond is provisioned as a TRUNK (NOT an ACCESS port) # Required for bonding: #aptitude install vlan ifenslave # echo "8021q" >> /etc/modules # #cat /etc/modprobe.d/bonding.conf #alias bond0 bonding #options bonding mode=4 miimon=100 downdelay=200 updelay=200 #
###### Bonded 10Gig setup - LACP Aggregation ####### ## View status in: /proc/net/bonding
auto bond0 iface bond0 inet manual bond-slaves eno1 eno2 # bond-mode 4 = 802.3ad AKA LACP bond-mode 4 bond-miimon 100 bond-downdelay 200 bond-updelay 200 bond-lacp-rate 1 bond-xmit-hash-policy layer2+3 up ifconfig bond0 0.0.0.0 up
### trunked interface (configured as an 802.3ad AKA LACP bond on upstream switch) # split out vlan 123 and vlan 456 from this bond on seperate interfaces
auto bond0.123 iface bond0.123 inet static address 10.123.0.3 netmask 255.255.255.0 mtu 1500 gateway 10.123.0.1 vlan-raw-device bond0 post-up ifconfig bond0.123 mtu 1500
# note this VLAN has a different MTU value auto bond0.456 iface bond0.456 inet static address 192.168.456.4 netmask 255.255.255.0 mtu 9000 vlan-raw-device bond0 post-up ifconfig vlan456 mtu 9000 post-up ifconfig eno1 mtu 9000 && ifconfig eno2 mtu 9000 && ifconfig bond0 mtu 9000 && ifconfig bond0.456 9000
# Note: upstream bond and member interfaces must have MTU9000, then lower level VLANS can use MTU1500 or MTU9000
bridging the bond
If you want to use the bond in a bridge, simply add the bridge lines as per normal to your /etc/network/interfaces file. Change the bond interface to manual and use it as the bridge interface. Here's a sample bridged bond interfaces file:
# onboard network interface auto enp4s0 iface enp4s0 inet manual # PCIe nic auto enp8s0 iface enp8s0 inet manual # bond inteface auto bond0 iface bond0 inet manual bond-slaves enp4s0 enp8s0 bond-mode 802.3ad # bridge interface auto br0 iface br0 inet static address 192.168.1.17 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 bridge_ports bond0 bridge_stp off bridge_fd 0 bridge_maxwait 0
Using systemd-networkd
This method does not use the package ifenslave which is mentioned above. If your computer is using systemd, and your network cards are currently working, you don't need anything else.
Note that as is common on unix-type operating systems, case matters - "Bond" is different from "bond" and "Name" is not the same as "name".
Enabling systemd-networkd
If you are not currently using systemd-networkd, you need to enable it.
systemctl enable systemd-networkd
Configuring the bond device
Create a file ending in .netdev in /etc/systemd/network. Name this after the bonded interface name you want to use (e.g. bond1.netdev).
This example assumes 802.3ad or LACP bonding, for more information see the systemd.netdev manpage and/or the kernel documentation.
Most systems should work with 802.3ad and this is probably the mode you want as it has both network cards working together to give you double the throughput. However, if it doesn't work in your case, you can try another mode, such as active-backup (used in the ifenslave example above).
[NetDev] Name=bond1 Description=LAG/Bond to a switch Kind=bond [Bond] Mode=802.3ad
Add interfaces to the bond/lag
There are two ways you can do this. One is to create a .network file for each network interface plus one for the bonded network. The other is to describe the network interfaces in the bonded network's file. Here we'll use the latter method.
Create a file ending in .network in /etc/systemd/network using the same name as previously (e.g. bond1.network).
systemd-networkd uses a matching system to decide which interface to use. You could use name-based matching here if you like, but do not use mac-based matching as this could cause confusion with the bond changing mac addresses.
This example uses pci-id based matching. To find the addresses for your network cards, use:
lspci -d | grep Ether
then use that information to create the .network file.
[Match] Path=pci-0000:00:01.0 Path=pci-0000:05:10.0 [Network] Bond=bond1
Another option is to simply use the names of the network interfaces by replacing the Path= line with Name=<network interface name>. You can also use wildcards, and you can specify both/all devices in a single file:
[Match] Name=enp* [Network] Bond=bond1
or
[Match] Name=enp0s01 Name=enp5s10 [Network] Bond=bond1
Giving the bond an IP
Create a file ending in .network in /etc/systemd/network. The name (obviously) should not already be used. This tell systemd how to bring up the bonded network.
For a static IP address, you could use:
[Match] Name=bond1 [Network] Address=10.31.1.5 Gateway=10.31.1.1 DNS=10.31.1.1
For DHCP (e.g. for a laptop where you could use wireless and/or wired connections) try:
[Match] Name=bond1 [Network] DHCP=yes
Actualise the settings
If your network was using /etc/network/interfaces before setting up the bonding, rename the file to stop it from being used:
mv /etc/network/interfaces /etc/network/interfaces.save
At this point I recommend rebooting the system. This is the easiest way to clear out any previous network configurations and it tests that systemd-networkd starts as expected. The network should come up with bonding active. You can verify this with:
ip link list
You should see 4 devices, lo, your two physical network interfaces (marked as "SLAVE"), and the bond1 device. Only the bond1 device should have an ip address. It should also be marked as "MASTER".
If you need to make further changes later, or fix problems with your current setup, from now on you can simply restart systemd-networkd after updating the /etc/systemd/network files.
systemctl restart systemd-networkd
enabling bridging for virtual machines
I've added this section because it's not immediately obvious that your existing network bridge configuration probably won't work with systemd-networkd. Prior to setting up my network bond, I was using the bridge utils to create a br0 device using /etc/network/interfaces. Since I've removed that file, I needed a new way to set up the bridge.
Fortunately systemd-networkd is multi-talented and quite adept at handling network bridges. All you need to do is define the bridge and give it the appropriate characteristics.
Like the bond0 device, you need to create a .netdev file to define the device. I created br0.netdev as follows:
[NetDev] Name=br0 Kind=bridge
Then I link it to the network bond I'd defined earlier using br0.network:
[Match] Name=bond1 [Network] Bridge=br0
Finally, I change the management .network file to refer to br0 instead of bond1. Because the previous definitions have made bond1 a slave to br0, this results in the bridge being brought up properly.
udev renaming issue
You will likely only see UDEV rules for your network devices if you have upgraded from previous versions of Debian. New installations name the network cards after their pci addresses. The rules are used to preserve the legacy names for devices (e.g. eth0) in case they are being used elsewhere.
If you are confident that you are not using the legacy names, you can simply remove the file described below.
"udev" assign network adapter names as per
- /etc/udev/rules.d/70-persistent-net.rules
where rule typically looks like this:
# PCI device 0x10ec:0x8168 (r8169) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
The problem with bonding is that two or more NICs may have the very same MAC address which confuses udev when it tries to (re)name adapters as per their MACs and fails because another card with this MAC already exists. When it happens NIC may be left named like "rename2" instead of "eth0" etc.
Possible solution is to change udev rule to assign network interface names as per NICs PCI IDs instead of MAC addresses. This can be done by replacing
ATTR{address}=="xx:xx:xx:xx:xx:xx"
with something like
KERNELS=="0000:04:00.0"
in the file "70-persistent-net.rules".
Corresponding PCI IDs can be found in dmesg:
sudo dmesg | grep eth
Where one can look for line fragment like this:
r8169 0000:04:00.0 eth0: RTL8168e/8111e # ^^^^^^^^^^^^
But this is not recommended as it will not find, for example, wireless devices or devices not using legacy names.
The preferred alternative is to find PCI IDs using "lspci -D | grep Ether":
0000:04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
Note that on modern systems, you can translate the PCI address to the network name by using the two middle numbers expressed in base10. In the above example, the controller 0000:04:00.0 would be enp4s00.
Testing / Debugging
Tip
In order to get some insight what is happening behind the scenes while experimenting a small script to show some information about the bonding device may be helpful.
#! /bin/sh echo "Slaves = $(cat /sys/class/net/bond0/bonding/slaves)" echo "Primary = $(cat /sys/class/net/bond0/bonding/primary)" echo "Active Slave = $(cat /sys/class/net/bond0/bonding/active_slave)" r=$(pidof dhclient) test -n "$r" && ps $r r=$(pidof wpa_supplicant) test -n "$r" && ps $r
Debugging ifenslave
The bonding mechanism is based on a kernel module named bonding which exposes its interface via the virtual /sys filesystem (e.g. /sys/class/net/bond0/*).
Setup and configuration is done in userland with shell-scripts: * /etc/network/if-post-down.d/ifenslave
- /etc/network/if-up.d/ifenslave
- /etc/network/if-pre-up.d/ifenslave
These scripts are called on system initialization and shutdown (actually it is ifup which calls them). Their intention is to feed the kernel module with the appropriate parameters and settings.
If something with bonding fails at all (and the tip above doesn't help) you may have a look what the scripts do step by step.
To enable verbose output, invoke ifup -a -v directly (instead of invoking /etc/init.d/networking). The -v option enables a log of all commands the scripts are executing. This gives at least a trace what is happening when.
Unfortunately this will not show the reactions of the kernel module (like possible error messages), because kernel (module) messages are reported via the syslog utility.
To get a real insight what is going on you have to do what is called invasive debugging. This means to add lines to the scripts at critical points to send a message to syslog.
- Example
Function sysfs_change_down in file /etc/network/if-pre-up.d/ifenslave
logger -t sysfs_change_down sysfs "$1" "$2" sysfs "$1" "$2" logger -t sysfs_change_down $(cat /sys/class/net/bond0/bonding/mode)
Additional Note For Debian Lenny On Sparc
(may be applicable on other architectures as well)
# cd /etc/modprobe.d # cat > aliases-bond.conf alias bond0 bonding options bonding mode=1 arp_interval=2000 arp_ip_target=192.168.3.1 <CTRL-D>
Without this file, you will get a warning when starting up the bonded interface similar to this:
bonding: Warning: either miimon or arp_interval and arp_ip_target module parameters must be specified, otherwise bonding will not detect link failures! see bonding.txt for details.
Startup / Configure New Interfaces
# ifup bond0 # /etc/init.d/networking start
And more, if you use a Lenny environment which has been upgraded from Etch, it is strongly recommended to check the result of the following command to check the bonding device mode, because configuration files for Etch and older versions do not work for Lenny and later releases.
cat /sys/class/net/bond0/bonding/mode
1. Ping to other system in a terminal
# ping X.X.X.X
2. Disconnect the active network cable and watch the ping result, the network should be resumed in few seconds
3. Reconnect the disconnected network cable, wait for 30 seconds to let the ARP table being updated
4. Disconnect another network cable and watch the ping result, the network should be resumed in few seconds
Change active slave
1. Use ifenslave to change the active slave. Below example will set eth0 as active slave
# ifenslave -c bond0 eth0 eth1