Link Aggregation (LAG) im Netzwerk

Inhaltsverzeichnis
Einleitung
Das Bündeln mehrerer, paralleler Links zu einem virtuellen Link mit Link Aggregation nach dem IEEE Standard 802.3ad (seit dem Jahr 2008 IEEE 802.1ax) bietet in Netzwerk Designs zwei wesentliche Vorteile:
- Bandbreiten- bzw. Kapazitätserhöhung durch Lastverteilung
- Automatisches Failover, Ausfallredundanz
Besonders bei der Anbindung kritischer Komponenten mit hohen Traffic Lasten wie Server, NAS, Firewall oder Router sind LAGs eine Option, die Anforderung an die Netzwerk Kapazität und Verfügbarkeit deutlich zu erhöhen und einem Hardware- oder Link Ausfall proaktiv vorzubeugen.
Link Aggregation geht im Netzwerk (fast) immer mit LACP (Link Aggregation Control Protokoll) einher. Das LACP Protokoll sorgt für eine Verteilung der Netzwerk Last auf Hashing Basis entweder der Mac- oder der IP Adressen. Bessere Komponenten nutzen zusätzlich den TCP/UDP Port sowie die VLAN ID zur Hashberechnung um eine granularere Verteilung des Traffics zu erreichen. Die Güte der Lastverteilung ist bei 802.1ax von der Entropie der Mac- oder IP Adressen bzw. Anwendungen im Netz abhängig.
Zu beachten ist das eine Link Aggregation bei Herstellern oftmals unterschiedlich bezeichnet wird. Gemeint ist aber immer dasselbe. Teaming bzw. Bonding im Server Bereich. Cisco bezeichnet LAGs als "Ether Channel". Die Masse der anderen Switch Hersteller als "Trunk", was gelegentlich Verwirrung erzeugt. Auch Hypervisoren wie VmWare, HyperV usw. nutzen eigene, teils proprietäre und zum LACP nicht kompatible Verfahren der Linkbündelung. Es kommt also im Detail immer auf eine korrekte Beschreibung an und "LACP LAG" bezeichnet es immer eindeutig.
Ein klassisch redundantes LAG Standard Netzwerkdesign (Tier 2) sieht z.B. so aus:
Das hier als einfaches Beispiel gezeigte Internet Anbindung mit einem singulären Router/Firewall ist bei einem Design mit zweifacher Provider Anbindung (Router oder Firewall Cluster) natürlich doppelt auszulegen. (Infos dazu u.a. auch hier).
Für einen LACP LAG gelten in jedem Falle die folgenden, zwingenden Grundvoraussetzungen:
- LACP LAGs müssen immer beidseitig konfiguriert werden.
- LAG Member Links müssen zwingend die gleiche Geschwindingkeit haben. Die Mischung von Glasfaser und Kupfer Links ist erlaubt solange die Link Geschwindigkeit gleich ist. SFP bzw. SFP+ Module können beidseitig ebenso gemischt werden. Relevant ist immer nur die gleiche Member Link Speed.
- Ein LACP LAG ist nur dann auf 2 Komponenten teilbar wenn die beiden Endkomponenten in einem Full Stack arbeiten oder andere MLAG Protokolle (Multi-chassis Link AGgregation) wie z.B. vPC (Cisco), MCT (Ruckus) usw. dies supporten. MLAG Protokolle sind immer Hersteller proprietär und zw. Herstellern nicht kompatibel. (Siehe dazu auch hier).
- Nicht Full-Stacking fähige Einzelswitches und solche ohne MLAG Support erlauben kein Aufsplitten von LACP LAGs ! In dem Fall müssen LAGs immer auf dem selben Gerät enden.
Je nach Hersteller und Feature Support schwankt die maximale Anzahl an bündelbaren LAG Interfaces. Bei einfachen Switches und Router/Firewalls sind es meist 4. Bessere Systeme supporten 8 bis 12 Interfaces. Ein Blick ins Datenblatt klärt diese Limits.
Das folgende Tutorial zeigt Praxisbeispiele des obigen Designs anhand gängiger Hardware Komponenten für kleine und mittlere Netzwerke (KMU Hardware).
Los gehts...
LAG mit Firewall am Beispiel pfSense/OPNsense
Für beide Firewall Modelle gelten unbedingt folgende Voraussetzungen:
- LAG Member Interfaces dürfen im Interface Assignment (Zuordnung) nicht zugeordent sein !
- LAG Member Interfaces dürfen keine IP und/oder DHCP Bindung haben !
Man bildet zuerst ein virtuelles LAG Interface (Gruppe) was dann als fertiger LAG über das Interface Assignment als ein virtuelles Interface zugewiesen wird, eine IP bekommt und an einen DHCP Server gebunden wird.
Bei VLAN Nutzung werden diesem Interface dann die entsprechenden VLAN IDs zugewiesen. Analog wie auf einem klassischen Ethernet Interface
Member Interface Zuordnung
LAG Interface Assignment
VLANs auf einem LAG Interface
(Hier nur mit VLAN 10 als Beispiel. Weitere VLANs ggf. hinzufügen.)
LAG mit Sophos UTM Firewall
Auch hier bildet man vorher eine Link Aggregation Gruppe der man die physischen Interfaces zuweist. Dieser Gruppe weist man dann über "Neues Interface ein Interface mit IP und DHCP zu.
LAG mit Switches
Cisco Catalyst (IOS, IOS-XE)
interface Port-channel1
description 2Port LAG
switchport mode trunk
switchport trunk allow vlan all
!
interface GigabitEthernet1/1/1
description Memberlink 1
switchport mode trunk
switchport trunk allow vlan all
channel-group 1 mode active
!
interface GigabitEthernet2/1/1
description Memberlink 2
switchport mode trunk
switchport trunk allow vlan all
channel-group 1 mode active
(Anmerkung: Das Kommando switchport trunk allow vlan all erlaubt hier ALLE VLANs auf dem Link. Natürlich kann man das auch nur dediziert erlauben wie z.B. switchport trunk allow vlan add 1,10 nur spezifisch für die VLANs 1 und 10)
Cisco SG Modellreihe und CBS Business Modelle
Ruckus ICX
lag "Firewall" dynamic id 1
ports ethernet 1/1/1 2/1/1
Port [Sys P] [Port P] [ Key ] [Act][Tio][Agg][Syn][Col][Dis][Def][Exp][Ope]
1/1/1 1 1 20001 Yes L Agg Syn Col Dis No No Ope
1/1/2 1 1 20001 Yes L Agg Syn Col Dis No No Ope
Partner Info and PDU Statistics
Port Partner Partner LACP LACP
System ID Key Rx Count Tx Count
1/1/1 32768-000d.b95a.49ea 299 4 6
1/1/2 32768-000d.b95a.49ea 299 4 6
Mikrotik
Die Mikrotik Link Aggregation (Bonding) wird in einem separaten Tutorial HIER beschrieben.
Zyxel GS1900
LAG anlegenMember Ports hinzufügen
LAG Status
HP ProCurve
(Beispiel HPE 5406zl-Switch)HP5406zl# conf t
HP5406zl(config)# trunk B1-B4 Trk1 lacp
HP5406zl(config)# sh trunk
HP2910# conf t
HP2910(config)# trunk 51-52 Trk1 lacp
HP2910(config)# sh trunk
HPE V1910
Wichtig !: Unbedingt den Punkt Dynamic LACP auf enable setzen ! Danach werden im GUI einfach die LAG Member Ports markiert, was dann automatisch das LAG Interface BAGG-x erzeugt wobei das x für die Link Aggregation Gruppe steht.LACP ist dann auch aktiv wenn man es auf Dynamic wie oben beschrieben gesetzt hat.
NetGear ProSafe
TP-Link
Der TP-Link hat eine Besonderheit bei der Link Aggregation die man kennen sollte ! (Portgruppen, siehe Handbuch) ! Beispiel hier bei einem 8 Port Modell:
Die Switchports 1 bis 4 sind fest der LAG Gruppe 1 zugewiesen und die Ports 5 bis 8 der Gruppe LAG 2. LAG fähige Ports sind hier gruppiert was auch bei Modellen mit 24 oder 48 Ports der Fall ist.
Nutzt man die Ports 7 und 8 für seinen Aggregation muss man sie zwingend auf Ports der Gruppe LAG-2 legen. Versucht man diese Ports in den LAG-1 zu legen, scheitert die LAG Konfig mit einer Fehlermeldung des Switches !
Ein LAG auf den Ports 4 und 5 ist mit diesem "Gruppenzwang" technisch unmöglich auf diesem Switch, denn dann wäre ein Memberport Mitglied der Gruppe 1 und einer der Gruppe 2 was nicht supportet ist !
Auch andere (Billig) Hersteller haben häufig bei LAGs diese feste Zuweisung auf dedizierte Portgruppen. Darauf sollte man immer achten bei der Switch Konfiguration um keinen Frust aufkommen zu lassen !
QNAP NAS
Linux Systemd LAG mit Bordmittel
Dank an @colinardo für diesen Tip !
MLAG (Multi-Chassis Link Aggregation)
Der dem LACP LAG zugrundeliegende Standard IEEE 802.3ad (bzw. neu 802.3ax) erlaubt generell kein Aufsplitten der LAG Member Ports auf unterschiedliche Geräte. Ein LAG ist also immer eine reine Punkt zu Punkt Verbindung von einzelnen Geräten. Der Grund ist das der Standard sehr schlank ist und auf Address Hashing basiert. Zusätzlich besitzt er keinerlei weitergehenden Recovering Verfahren sollten Pakete verloren gehen. Ein Grund auch warum ein LAG kein per Paket Sharing Verfahren ist sondern immer Session bezogen.
Aus Redundanz Sicht ist das natürlich ein Nachteil, so das Hersteller sehr oft sog. MLAG Verfahren in ihre Produkte integriert haben. Dies erlaubt dann ein Splitting der LAG Memberports und redundante Designs die das Folgende erlauben:

Eines ist aber allen gemeinsam: Ein Switchpaar tauscht untereinander LACP Sessiondaten nach Herstellerverfahren aus und "gaukelt" einem LACP-LAG Endgerät vor das der LAG nur von einem einzigen Gerät kommt. So ist es einfach möglich auch redundante LAG Netzwerk Designs zu realisieren. MLAGs finden sich nicht nur häufig in Fabric basierten Datacenter Switches mit TRILL oder SPB sondern auch in Campus- und Provider Switches wie z.B. Mikrotik.
MLAG Verfahren sind aber mit der aufkommenden Full Stacking Technologie bei Switches etwas in den Hintergrund geraten, denn bei Full- und Horizontal Stacking fähigen Switches sind MLAG Konfigurationen überflüssig geworden. Ein Full Stacking fähiger Switchstack stellt sich physisch als ein einzelnes Gerät dar. Das gilt dann auch für LACP LAGs. Die MLAG Funktion ist also quasi im Stacking inkludiert.
Bei nicht Stacking fähigen Switches hat die MLAG Funktion aber weiter eine sinnvolle Funktion bei Hochverfügbarkeit und Redundanz.
Weiterführende Links
Link Aggregation Grundlagen
https://de.wikipedia.org/wiki/Link_Aggregation
Windows Link Aggregation (Teaming)
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
VmWare ESXi und LACP LAGs
https://rickardnobel.se/lacp-and-esxi-5-1/
Cisco EtherChannel Grundlagen
https://www.youtube.com/watch?v=j6-kadxwIFQ
Linux Link Aggregation (Bonding)
https://administrator.de/tutorial/netzwerk-management-server-mit-raspber ...
Link Aggregation mit Mikrotik
https://administrator.de/contentid/367186#toc-19
MLAG Link Aggregation mit Mikrotik
https://help.mikrotik.com/docs/display/ROS/Multi-chassis+Link+Aggregatio ...
Grundlagen Glasfaser Verkabelung
https://www.youtube.com/watch?v=fRKT6Z9rgUw
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-Key: 1586053518
Url: https://administrator.de/contentid/1586053518
Ausgedruckt am: 22.05.2022 um 17:05 Uhr
15 Kommentare
Neuester Kommentar
Moin,
mal wieder eine gute Anleitung, besten Dank, "Alter Hase"
Zur Erweiterung könnte man noch das CLI-Set für die ProCurves ergänzen
Will man eine LAG auf einem HP-Switch (Non-Aruba-OS) per CLI definieren, funktioniert das wie folgt (am Beispiel eines HPE 5406zl-Switches):
Und am Beispiel eines HPE 2910-Switches:
Hier sieht man, dass bei HP ein Trunk eine LAG definiert, wohingegen es bei Cisco (und anderen) einen Port/ eine LAG beschreibt, welche VLANs-Tags transportieren können.
Gruß
em-pie
mal wieder eine gute Anleitung, besten Dank, "Alter Hase"
Zur Erweiterung könnte man noch das CLI-Set für die ProCurves ergänzen
Will man eine LAG auf einem HP-Switch (Non-Aruba-OS) per CLI definieren, funktioniert das wie folgt (am Beispiel eines HPE 5406zl-Switches):
HP5406zl# conf t
HP5406zl(config)# trunk B1-B4 Trk1 lacp
HP5406zl(config)# sh trunk
Und am Beispiel eines HPE 2910-Switches:
HP2910# conf t
HP2910(config)# trunk 51-52 Trk1 lacp
HP2910(config)# sh trunk
Hier sieht man, dass bei HP ein Trunk eine LAG definiert, wohingegen es bei Cisco (und anderen) einen Port/ eine LAG beschreibt, welche VLANs-Tags transportieren können.
Gruß
em-pie
Wie immer TOP @aqui 👍 .Merci!
Und vielleicht noch als Mini-Ergänzung für die Linux-Konsolen-Junkies die die Bonding Konfiguration mit reinen Systemd-Bordmitteln (systemd-networkd) abfackeln möchten (mache ich ganz gerne mal wenn kein extra Networkmanager zum Einsatz kommen soll, da systemd ja meist eh schon vorhanden ist):
Man erstelle die folgenden vier Dateien im Verzeichnis /etc/systemd/network mit den Inhalten
Bonding Device mit Optionen erstellen, siehe Options-Referenz
IP-Einstellungen des Bonding-Interfaces festlegen (Options-Referenz)
NIC1 zum Bond hinzufügen
NIC2 zum Bond hinzufügen
Nun lade man die systemd Konfiguration neu, starte den systemd-networkd Dienst und aktivere diesen
Danach noch prüfen ob der Bond mit den richtigen Optionen eingerichtet wurde
Wenn nicht das journal prüfen
Grüße Uwe
Und vielleicht noch als Mini-Ergänzung für die Linux-Konsolen-Junkies die die Bonding Konfiguration mit reinen Systemd-Bordmitteln (systemd-networkd) abfackeln möchten (mache ich ganz gerne mal wenn kein extra Networkmanager zum Einsatz kommen soll, da systemd ja meist eh schon vorhanden ist):
Man erstelle die folgenden vier Dateien im Verzeichnis /etc/systemd/network mit den Inhalten
/etc/systemd/network/01-bond0.netdev
Bonding Device mit Optionen erstellen, siehe Options-Referenz[NetDev]
Name=bond0
Kind=bond
[Bond]
Mode=802.3ad
TransmitHashPolicy=layer2+3
LACPTransmitRate=slow
MIIMonitorSec=1
UpDelaySec=1
DownDelaySec=1
/etc/systemd/network/02-bond0.network
IP-Einstellungen des Bonding-Interfaces festlegen (Options-Referenz)[Match]
Name=bond0
[Network]
Address=192.168.100.2/24
/etc/systemd/network/03-nic1.network
NIC1 zum Bond hinzufügen[Match]
Name=eth1
[Network]
Bond=bond0
/etc/systemd/network/04-nic2.network
NIC2 zum Bond hinzufügen[Match]
Name=eth2
[Network]
Bond=bond0
Nun lade man die systemd Konfiguration neu, starte den systemd-networkd Dienst und aktivere diesen
sudo systemctl daemon-reload
sudo systemctl enable systemd-networkd --now
ip link show
cat /proc/net/bonding/bond0
journalctl -r
Grüße Uwe
Zitat von @aqui:
(Leider kann ich keinen Link, weder mit Permanent Link noch klassisch, oben auf deinen Kommentar einbinden. Der landet immer nur auf dem ersten Kommentar und nicht auf deinem. Vermutlich ein Bug...?!)
Also der hier geht bei mir zumindest mobil, Desktop hab ich gerade nicht zur Hand.(Leider kann ich keinen Link, weder mit Permanent Link noch klassisch, oben auf deinen Kommentar einbinden. Der landet immer nur auf dem ersten Kommentar und nicht auf deinem. Vermutlich ein Bug...?!)
https://administrator.de/contentid/1586053518#comment-1596209268
Aber es ist ja auch so gut zu finden. 😉
Joa, denke ich auch, alles gut.Ey, ich erkenne Sarkasmus, wenn ich ihn sehe!
Zitat von @aqui:
Joa, hatt ich auch versucht aber wenn ich den so
einbaue, dann hopst die Anzeige nur zum ersten Kommentar vom @LauneBaer (der natürlich auch sehr nett ist !) Permanent Link ebenso.
Hab's mal dringelassen zum Testen. Da gibts irgendwie ne böse Wechselwirkung mit den "toc" Inhaltsverzeichnis.
Habe das hier jetzt auch mit einem Desktop-Browser nicht nachstellen können, sowohl ein Firefox, Chrome, Edge machen die Verlinkung hier einwandfrei, nutzt du eventuell irgendwelche Browser-Erweiterungen?Joa, hatt ich auch versucht aber wenn ich den so
Für Linux Systemd [https://administrator.de/contentid/1586053518#comment-1596209268 HIER] klicken.
Hab's mal dringelassen zum Testen. Da gibts irgendwie ne böse Wechselwirkung mit den "toc" Inhaltsverzeichnis.
Ansonsten nehme mit den Details deiner Browser-Umgebung direkt Kontakt mit @Frank auf.
Moin,
der Link im Ausgangspost von @aqui auf den Kommentar von @colinardo funktioniert auch bei mir problemlos (MS Edge 95.0.irgendwas)
der Link im Ausgangspost von @aqui auf den Kommentar von @colinardo funktioniert auch bei mir problemlos (MS Edge 95.0.irgendwas)
Zitat von @colinardo:
[Match]
Name=bond0
[Network]
Address=192.168.100.2/24
</code>
NIC1 zum Bond hinzufügen
NIC2 zum Bond hinzufügen
[Match]
Name=bond0
[Network]
Address=192.168.100.2/24
</code>
/etc/systemd/network/03-nic1.network
NIC1 zum Bond hinzufügen> [Match]
> Name=eth1
>
> [Network]
> Bond=bond0
>
/etc/systemd/network/04-nic2.network
NIC2 zum Bond hinzufügen> [Match]
> Name=eth2
>
> [Network]
> Bond=bond0
>
Müsste es hier nicht eth0 und eth1 heißen?
Servus @ex0r2k16.
Das kommt darauf an welche Interfaces man hier bündeln möchte, hier waren es im Beispiel eben eth1 und eth2, und eth0 war bei mir ohne Bond an ein anderes Netz gebunden (Maschine hatte 3 NICs)
.
Grüße Uwe
Das kommt darauf an welche Interfaces man hier bündeln möchte, hier waren es im Beispiel eben eth1 und eth2, und eth0 war bei mir ohne Bond an ein anderes Netz gebunden (Maschine hatte 3 NICs)
Grüße Uwe
Zitat von @colinardo:
Servus @ex0r2k16.
Das kommt darauf an welche Interfaces man hier bündeln möchte, hier waren es im Beispiel eben eth1 und eth2, und eth0 war bei mir ohne Bond an ein anderes Netz gebunden (Maschine hatte 3 NICs)
.
Grüße Uwe
Servus @ex0r2k16.
Das kommt darauf an welche Interfaces man hier bündeln möchte, hier waren es im Beispiel eben eth1 und eth2, und eth0 war bei mir ohne Bond an ein anderes Netz gebunden (Maschine hatte 3 NICs)
Grüße Uwe
oh okay alles klar