Link Aggregation (LAG) im Netzwerk

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

Es wird daher häufig in Netzwerken verwendet, in denen eine erhöhte Verfügbarkeit gefordert ist (Ausfallsicherheit, Redundanz). Sie kommt immer zusammen mit einer Bandbreitenerhöhung daher, so das man in diesen Netzen gleich 2 Fliegen mit einer Klappe schlägt. Man erhöht die Ausfallsicherheit bei gleichzeitiger Erhöhung der Lastkapazitäten.

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 oder die Kombination beider. 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" oder "Port 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. Desahlb bezeichnet "LACP LAG" es immer eindeutig.

Ein klassisches, redundantes LAG Standard Netzwerkdesign (Tier 2) sieht z.B. so aus:


Die 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 dabei 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, Stackwise Virtual (Cisco), MCT (Brocade/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.

Ein LAG Interface wird auf einem Endgerät wie Switch, Router bzw. Firewall, Server / NAS usw. logisch immer wie ein einzelnes Interface gesehen.
Je nach Hersteller und Feature Support schwankt die maximale Anzahl an bündelbaren LAG Member 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 LAG Interface und seine Memberports müssen zwingend identisch konfiguriert sein! Ist das nicht der Fall bleibt ein LACP LAG inaktiv. Deshalb erlauben viele Hersteller eine Konfig von Port Parametern wie VLAN Tagging usw. immer nur auf dem virtuellen LAG Interface. So ist immer absolut sichergestellt das diese Portkommandos sicher auf die Member Interfaces distribuiert werden.

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 !

Bei beiden ist die Vorgehensweise identisch, die im Übrigen auch bei allen anderen Firewall und Router Herstellern ähnlich ist.
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)

Der Index "1" der Channel Group verweist auf das Port Channel Interface 1
(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 spezifisch für die VLANs 1 und 10)

Cisco SG Modellreihe und CBS Business Modelle

Ruckus ICX

Der Ruckus ICX zeigt mit einem Show Kommando die fehlerfreie Funktion des LAGs:
Man sieht im Status "Ope" (= Operational) das beide Ports im LACP Link Aggregation aktiv sind und erkennt auch die Mac Adressen der Firewall an beiden Memberports (Siehe Screenshot LAG Interface OPNsense oben).

Mikrotik

Die Mikrotik Link Aggregation (Bonding) wird in einem separaten Tutorial HIER beschrieben.

Zyxel GS1900

LAG anlegen
Member Ports hinzufügen
LAG Status

HP ProCurve

(Beispiel HPE 5406zl-Switch)
(Beispiel HPE 2910-Switch)

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) Designs

Der dem LACP LAG zugrundeliegende Standard IEEE 802.3ad (bzw. neu 802.3ax) erlaubt, wie oben bereits erwähnt, prinzipbedingt generell kein Aufsplitten der LAG Member Ports auf unterschiedliche Geräte.
Ein LAG ist also immer eine reine Punkt zu Punkt Verbindung von zwei einzelnen Geräten.
Der Grund dafür ist, das der Standard sehr schlank (einfach) ist und auf IP oder Mac Address Hashing basiert. Zusätzlich besitzt er keinerlei weitergehende Recovering Verfahren sollten einzelne Pakete verloren gehen oder in falscher Reihenfolge am Ziel ankommen. Ein Grund auch warum ein LAG kein per Paket Sharing Verfahren ist, sondern immer nur rein Session bezogen zwischen 2 Partnern.

Aus Redundanz Sicht ist das natürlich ein Nachteil und ein Grund warum Hersteller sehr oft sog. MLAG Verfahren in ihre Produkte integriert haben. Dies erlaubt dann ein Splitting der LAG Memberports auf 2 unterschiedliche Switches und redundante Designs die das Folgende erlauben:
Leider gibt es keinen einheitlichen MLAG Standard in diesem Umfeld, so das MLAG Verfahren nicht kompatibel sind zwischen verschiedenen Herstellern.
Dadurch ist zusätzlich die Namensgebung oft unterschiedlich wie "Multi Chassis Trunk" (MCT, Ruckus), "Virtual Port Channel" (vPC, Cisco), "vLAG, virtual LAG" usw.
Eines ist aber allen gemeinsam: Ein Switchpaar tauscht untereinander LACP Sessiondaten nach Herstellerverfahren aus und "gaukelt" einem LACP-LAG Endgerät vor das dieser an sich gesplittete LAG nur von einem einzigen Gerät kommt.
So ist es sehr 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 einfachen Campus- und Provider Switches wie z.B. Mikrotik.
MLAG Verfahren sind mit der aktuell aufkommenden bzw. etablierten Full Stacking Technologie bei Switches mehr oder weniger 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 natürlich auch für LACP LAGs. Die MLAG Funktion ist also quasi im physischen Stacking inkludiert.
Bei nicht Stacking fähigen Switches hat die MLAG Funktion aber weiter eine sehr sinnvolle Funktion bei Hochverfügbarkeit und Redundanz Designs.
Ein weiterer Grund ist das einfache Stacking Verfahren einzelner Hersteller keinen einzelnen Reboot (Wartung, Update etc.) von Stack Memberswitches zulassen. So muss immer der gesamte Stack rebootet werden was einen Ausfall bedeutet. In einem MLAG Design wäre das nicht erforderlich. Hier ist der Reboot eines einzelnen Members möglich ohne das es zu einem Netzwerk Ausfall kommt.

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)
Netzwerk Management Server mit Raspberry Pi

Link Aggregation mit Mikrotik
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41

MLAG Link Aggregation mit Mikrotik
https://help.mikrotik.com/docs/display/ROS/Multi-chassis+Link+Aggregatio ...

LACP LAGs mit Linux
Link Aggregation (LAG) im Netzwerk

LAG Performance mit Multicast Streaming prüfen:
Fehlersuche im lokalem Netzwerk (RSTP, MRP, Multicast)

Grundlagen Glasfaser Verkabelung
https://www.youtube.com/watch?v=fRKT6Z9rgUw

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

[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=802.3ad
TransmitHashPolicy=layer2+3
LACPTransmitRate=slow
MIIMonitorSec=1
UpDelaySec=1
DownDelaySec=1

[Match]
Name=bond0

[Network]
Address=192.168.100.2/24

[Match]
Name=eth1

[Network]
Bond=bond0

[Match]
Name=eth2

[Network]
Bond=bond0

sudo systemctl daemon-reload
sudo systemctl enable systemd-networkd --now

ip link show
cat /proc/net/bonding/bond0

journalctl -r

 Für Linux Systemd [content:1586053518#1596209268 HIER] klicken. 

 Für Linux Systemd [content:1586053518#1596209268 HIER] klicken. 

> [Match]
> Name=eth1
> 
> [Network]
> Bond=bond0
> 

> [Match]
> Name=eth2
> 
> [Network]
> Bond=bond0
> 

interface Bridge-Aggregation1
 description LAG to XYZ
 port link-type trunk
 port trunk permit vlan all
 link-aggregation mode dynamic
 

 interface GigabitEthernet1/0/0/45
 port link-mode bridge
 description LAG to XYZ - eth0
 port link-type trunk
 port trunk permit vlan all
 port link-aggregation group 1

interface lag 1
    no shutdown
    description UPLINK-TO-XYZ
    no routing
    vlan trunk native 1
    vlan trunk allowed all
    lacp mode active

interface 1/1/24
    no shutdown
    description **** UPLINK to XYZ-eth0 ****
    lag 1

vrf KEEPALIVE
interface vlan 999
  vrf attach KEEPALIVE
  ip mtu 9198
  ip address 172.16.99.1/30
interface lag 100
  no routing
  vlan trunk allowed all
  no shutdown
  lacp mode active
interface 1/1/1-1/1/2
  lag 100
  no shutdown
  mtu 9198
vsx
  inter-switch-link lag 100
  role secondary / primary
  keepalive peer 172.16.99.2 source 172.16.99.1 vrf KEEPALIVE  // muss jeweils auf die Gegenstelle zeigen
  vsx-sync mclag-interfaces neighbor ospf snmp ssh static-routes stp-global vrrp vsx-global

show vsx status

interface lag 10 multichassis
  no shutdown
  lacp mode active
  no routing
  vlan trunk allowed all
interface 1/1/3
  lag 10
  no shutdown
  mtu 9198
  description "LAG-Link1-zu-Verteilerswitch"