Trunk,Bonding, LACP

Link Aggregation bezeichnet im Rahmen der Netzwerktechnik verschiedene Verfahren zur Bündelung mehrerer physischer LAN-Schnittstellen zu einem logischen Kanal zum Zwecke der Erhöhung des Datendurchsatzes und der Ausfallsicherheit gegenüber einer einfachen Netzwerkschnittstelle. Beispielsweise verläuft im Normalfall vom LD-Server (p_intern) eine einzige physische Verbindung zum Core-Switch im Datenverteiler. Gerade in großen Umgebunden, wo sehr viel Datenverkehr dauerhaft herrscht macht es dann Sinn eine mehrere physische Verbindungen zu einer Logischen zu bündeln. Es ist wichtig, dass beide Seiten LACP beherrschen.

Benötigte Netzwerkschnittstellen ermitteln

Zunächst ist es erforderlich die entsprechenden Netzwerkschnittstellen des LD-Servers mit ihrer MAC-Adresse zu ermitteln. Das geht mit gängigen Tools wie ip oder inxi.

Nachdem diese Informationen vorliegen wird zunächst das bestehende Interface p_intern in p_intern1 umbenannt.

root@ldhost:~ # cd /etc/systemd/network/

[Match]
MACAddress=00:0c:29:0f:f1:dd
[Link]
Name=p_intern1

Und danach ein weiteres physisches Interface mit der Bezeichnung p_intern2 definiert.

[Match]
MACAddress=00:0c:29:0f:f1:de
[Link]
Name=p_intern2

Im Anschluss muss dem Kernel die geänderte Schnittstellenkonfiguration mitgeteilt und der Server neu gestartet werden.

root@ldhost:~ # update-initramfs -u -k all
root@ldhost:~ # reboot

Bündelung der Netzwerkschnittstellen

Nach dem Serverneustart müssen diese beiden physischen Adapter per Name dem logischen Netzwerk intern zugeordnert werden. Dies geschieht im Container puppeteer-g3 in der Datei ldhost.yaml.

root@puppeteer-g3:~ # vi /etc/logodidact/hiera/custom.d/ldhost.yaml

In Anlehnung an das Bonding, benennt man dazu das Interface p_intern um in b_intern, wobei das b für bond steht. Den Parameter ovs_type ändern Sie von OVS_Port auf OVSBond.

Zusätzlich dazu werden drei weitere Einträge ovs_bondlacp, ovs_bondmode und ovs_bonds ergänzt. Bei dem Eintrag ovs_bonds müssen die zuvor definierten Netzwerkkarten für das Bonding angegeben werden (p_intern 1, p_intern2, usw.).

[...]
profile::network:
  interface:
    b_intern:
      ovs_type: OVSBond
      ovs_bonds: p_intern1 p_intern2
      vlan-mode: access
      vlan-untagged: ld-intern
      ovs_bondmode: tcp
      ovs_bondlacp: active
      type: manual
    intern:
      type: static
[...]

Openvswitch und Server neustarten

Die getätigten Änderungen wie gewohnt in GIT commiten und einen prun im ldhost durchführen zur Übernahme der geänderten Schnittstellenkonfiguration.

root@puppeteer-g3:~ # git add .
root@puppeteer-g3:~ # git commit -m "(Kuerzel): Bonding aktiviert"
root@ldhost:~ # prun

Am Ende muss der openvswitch-switch-Service gestoppt, die ovs-Datenbank gelöscht und der Server neugestartet werden.

root@ldhost:~ # service openvswitch-switch stop; systemctl stop openvswitch-switch.service; [ -h "/etc/openvswitch/conf.db" ] && rm -v /var/lib/openvswitch/conf.db || rm -v /etc/openvswitch/conf.db; /sbin/root@ldhost:~ # reboot

Überprüfung

Nach dem Neustart sollte man zwingend überprüfen, ob die logische Schnittstelle b_intern korrekt angelegt wurde.

Das ist möglich mit dem Befehl ovs-vsctl show im ldhost. Es sollte folgendes als Ausgabe erscheinen:

[...]
Port b_intern
    tag: 10
    Interface "p_intern2"
    Interface "p_intern1"
[...]

Mittels ethtool b_intern kann nun noch verifiziert werden, dass die Schnittstelle auch einen aktiven Uplink zu Gegenstelle (Core-Switch) besitzt.

Settings for b_intern:
    Link detected: yes