aqui
Goto Top

Link Aggregation (LAG) im Netzwerk

article-picture

back-to-topEinleitung


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 das automatische Aushandeln der Trunk Memberports über LACPDUs (Link Aggregation Control Protocol Data Units) im Active oder Passive Mode wobei letzterer keine LACPDUs schickt. Der Active Mode ist immer zu bevorzugen, da er...
  • einen Ausfall eines physischen Member Ports auch bei Erhalt des Link Status immer automatisch erkennt, da die LACPDUs das Gegenüber nicht mehr erreichen.
  • bewirkt das beide Geräte sich gegenseitig die LAG Parameter und Konfiguration dynamisch bestätigen. Bei passiver, statischer Link Aggregation werden Konfigurations- oder Verkabelungsfehler oft nicht erkannt.

Zusätzlich zu beachten ist das eine Link Aggregation bei Herstellern oftmals unterschiedlich bezeichnet wird wie z.B. Teaming bzw. Bonding im Server Bereich. Gemeint ist aber immer dasselbe.
Cisco bezeichnet im Switching Umfeld 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.

back-to-topLastverteilung


Die Verteilung der Netzwerk Last auf die LAG Memberlinks basiert 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 bessere und granularere Verteilung des Traffics auf die Memberlinks zu erreichen.
Die Güte bzw. Granularität der Lastverteilung auf die einzelnen LAG Links ist bei 802.1ax von der Entropie der Mac- oder IP Adressen bzw. Anwendungen (TCP/UDP) oder Segmentierung (VLAN ID) im Netz abhängig. Je mehr Komponenten in die Hashberechnung einfliessen desto homogener und granularer ist die Lastverteilung auf den Memberlinks.

back-to-topLAG Design


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

lag-design

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 zwischen unterschiedlichen Herstellern nicht kompatibel. (Siehe dazu auch hier).
  • Nicht Full-Stacking fähige Einzelswitches und solche ohne MLAG Support erlauben kein Aufsplitten der Memberport von LACP LAGs auf unterschiedliche Geräte! In dem Fall müssen LAGs immer auf einem 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 einzelnen Port Parametern wie VLAN Tagging usw. immer nur auf dem virtuellen LAG Interface. Dadurch ist immer absolut sichergestellt das diese Portkommandos sicher auf alle Member Interfaces identisch distribuiert werden, was einen Parameter Mismatch und den Ausfall verhindert.

back-to-topLAG Troubleshooting


In der Regel konfiguriert man beide LACP LAG "Enden" in den LACP "Active" Mode, was bedeutet das beide Seiten aktiv versuchen eine LACP Verbindung aufzubauen. In der Regel ist das unproblematisch, denn im Verlauf des automatischen Negotiation Prozesses beider Seiten einigen sich die Member dynamisch letztendlich wer Active und wer Passive ist.
In seltenen Fällen kann dies aber auch scheitern und die Memberports kommen nicht zueinander so das der LAG nicht zustande kommt.
Sollte das der Fall sein konfiguriert man immer dediziert eine Seite in den Active Mode und die andere Seite in den Passive Mode um so die Modi fest vorzugeben.
Sollte auch dies scheitern dreht man die Active / Passive Rollen der Member um und versucht es erneut. Üblicherweise löst dies dann fehlerhafte Auto Negotiation Probleme beim LACP.
Es sei noch einmal betont das es auch statische, proprietäre Verfahren einiger Hersteller gibt die nicht mit einem standartisierten LACP LAG kompatibel sind und in der Regel auch nicht mit statischen Verfahren anderer Hersteller so das LAGs unter solchen Bedingungen so gut wie immer scheitern.

Das folgende Tutorial zeigt Praxisbeispiele des obigen Designs anhand gängiger Hardware Komponenten für kleine und mittlere Netzwerke (KMU Hardware).
Los gehts...


back-to-topLAG mit Firewall am Beispiel pfSense und 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

back-to-topMember Interface Zuordnung

memneu.

back-to-topLAG Interface Assignment

lagassneu.

back-to-topVLANs auf einem LAG Interface

(Hier nur mit VLAN 10 als Beispiel. Weitere VLANs ggf. hinzufügen.)
vlanneu.


back-to-topLAG 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.
sophosutm


back-to-topLAG mit Switches

back-to-topCisco 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 
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)

back-to-topCisco SG Modellreihe und CBS Business Modelle

lag1
lag2

back-to-topRuckus ICX

lag "Firewall" dynamic
ports ethernet 1/1/1  1/1/2
Der Ruckus ICX zeigt mit einem Show Kommando die fehlerfreie Funktion des LAGs:
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 
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).

back-to-topMikrotik

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

back-to-topZyxel GS1900

LAG anlegen
zylag
Member Ports hinzufügen
zylagmem
LAG Status
zylagstat

back-to-topHP ProCurve

(Beispiel HPE 5406zl-Switch, 4er Active Trunk mit Memberports B1 bis B4)
HP5406zl# conf t
HP5406zl(config)# trunk B1-B4 Trk1 lacp 
(Beispiel HPE 2910-Switch, 2er Active Trunk mit Memberports 51 und 52)
HP2910# conf t
HP2910(config)# trunk 51-52 Trk1 lacp 

back-to-topHPE V1910

Wichtig !: Unbedingt den Punkt Dynamic LACP auf enable setzen ! Danach werden im GUI einfach die LAG Member Ports markiert, was dann automatisch das virtuelle LAG Interface BAGG-x erzeugt wobei das x für die Link Aggregation Gruppe steht.
hp1.
LACP ist dann auch aktiv wenn man es auf Dynamic wie oben beschrieben gesetzt hat.
hp2.

back-to-topNetGear ProSafe

ng1neu.
ng2.

back-to-topTP-Link

⚠️ Kleine TP-Link Switches haben eine Besonderheit bei der Link Aggregation die man beachten sollte! (Portgruppen, siehe Handbuch)
Beispiel bei einem einfachen 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 bei TP-Link immer gruppiert was auch bei Modellen mit 24 oder 48 Ports der Fall ist.
Nutzt man die Ports 7 und 8 für seine Aggregation muss man sie zwingend auf Ports innerhalb 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! Memberport müssen also immer innerhalb einer gemeinsamen Portgruppe liegen.
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 !
tp1.
tp2.

back-to-topQNAP NAS

qnap

back-to-topLinux Systemd LAG mit Bordmittel

Dank an @colinardo für diesen Tip !


back-to-topMLAG (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 Sicht der Geräte bzw. Hardware Redundanz ist das natürlich ein Nachteil und ein Grund warum Hersteller sehr oft sog. MLAG Verfahren in ihre Produkte integriert haben. Ein MLAG Setup erlaubt dann ein Splitting der LAG Memberports auf 2 unterschiedliche Switches und damit redundante Netzwerk Designs die das Folgende erlauben:
mlag
Leider gibt es keinen einheitlichen MLAG Standard in diesem Umfeld, so das MLAG Verfahren nicht kompatibel sind zwischen verschiedenen Herstellern.
Zudem ist dadurch bedingt 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 dynamisch LACP Sessiondaten nach Herstellerverfahren aus und "gaukelt" einem LACP-LAG Endgerät vor das dieser in Wahrheit gesplittete LAG virtuell nur von einem einzigen Gerät kommt.
So ist es sehr einfach möglich auch redundante LAG Netzwerk Designs ohne Stacking 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.
Es kommt aber auch bei Core Switch Designs vor das 2 physische Fullstacks mit einem MLAG verbunden werden. In so einem Design laufen also auch Switchstacks mit MLAGs Hand in Hand.
Bei nicht Stacking fähigen Switches hat die MLAG Funktion somit eine sehr sinnvolle und wichtige Funktion bei Hochverfügbarkeit und Redundanz Designs.
Ein weiterer Grund ist das einfache Stacking Verfahren einzelner Hersteller oft keinen Reboot (Wartung, Update etc.) von einzelnen Stack Memberswitches innerhalb des Stacks zulassen. So muss immer der gesamte Stack rebootet werden was in der Regel 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. Besonders in 24x7 Rechenzentren mit einer 24/7 Hochverfügbarkeit ein großer Vorteil bei der Netzwerk Infrastruktur Wartung.

back-to-topWeiterfü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

VLAN LACP Trunk mit OPNsense
OPNsense + Dell X Switche VLAN Trunk Setup

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

Content-ID: 1586053518

Url: https://administrator.de/contentid/1586053518

Printed on: October 9, 2024 at 23:10 o'clock

LauneBaer
LauneBaer Dec 06, 2021 at 12:13:02 (UTC)
Goto Top
Vielen Dank für die wie immer schöne Anleitung. Werde ich gleich bookmarken face-smile

Hier ist noch ein "wird" zu viel: face-smile
Zu beachten ist das eine Link Aggregation wird bei Herstellern oftmals unterschiedlich bezeichnet wird.
aqui
aqui Dec 06, 2021 updated at 12:55:28 (UTC)
Goto Top
Danke für die 💐 und den Hinweis ! face-wink
em-pie
em-pie Dec 06, 2021 updated at 13:10:09 (UTC)
Goto Top
Moin,

mal wieder eine gute Anleitung, besten Dank, "Alter Hase" face-smile

Zur Erweiterung könnte man noch das CLI-Set für die ProCurves ergänzen face-smile
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
aqui
aqui Dec 06, 2021, updated at Dec 07, 2021 at 09:43:19 (UTC)
Goto Top
👍 Ist ergänzt !
colinardo
colinardo Dec 07, 2021 updated at 12:23:57 (UTC)
Goto Top
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

back-to-top/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

back-to-top/etc/systemd/network/02-bond0.network

IP-Einstellungen des Bonding-Interfaces festlegen (Options-Referenz)
[Match]
Name=bond0

[Network]
Address=192.168.100.2/24

back-to-top/etc/systemd/network/03-nic1.network

NIC1 zum Bond hinzufügen
[Match]
Name=eth1

[Network]
Bond=bond0

back-to-top/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
Danach noch prüfen ob der Bond mit den richtigen Optionen eingerichtet wurde
ip link show
cat /proc/net/bonding/bond0
Wenn nicht das journal prüfen
journalctl -r

Grüße Uwe
aqui
aqui Dec 07, 2021 updated at 17:49:23 (UTC)
Goto Top
Ebenso bei dir Uwe, wie immer, TOP ! Danke für die Ergänzung. 👍
(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...?!)
Aber es ist ja auch so gut zu finden. 😉
colinardo
colinardo Dec 07, 2021 updated at 19:41:26 (UTC)
Goto Top
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.
Link Aggregation (LAG) im Netzwerk
Aber es ist ja auch so gut zu finden. 😉
Joa, denke ich auch, alles gut.
aqui
aqui Dec 07, 2021 updated at 22:38:34 (UTC)
Goto Top
Jepp, hatt ich auch versucht aber wenn ich den so
 Für Linux Systemd [content:1586053518#1596209268 HIER] klicken. 
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.
LauneBaer
LauneBaer Dec 08, 2021 at 07:47:22 (UTC)
Goto Top
Zitat von @aqui:
Kommentar vom @LauneBaer (der natürlich auch sehr nett ist !)

Ey, ich erkenne Sarkasmus, wenn ich ihn sehe! face-smile face-smile face-smile
colinardo
colinardo Dec 08, 2021 updated at 10:28:49 (UTC)
Goto Top
Zitat von @aqui:

Joa, hatt ich auch versucht aber wenn ich den so
 Für Linux Systemd [content:1586053518#1596209268 HIER] klicken. 
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?
Ansonsten nehme mit den Details deiner Browser-Umgebung direkt Kontakt mit @Frank auf.
em-pie
em-pie Dec 08, 2021 at 10:51:07 (UTC)
Goto Top
Moin,

der Link im Ausgangspost von @aqui auf den Kommentar von @colinardo funktioniert auch bei mir problemlos (MS Edge 95.0.irgendwas)
aqui
aqui Dec 08, 2021 at 18:04:19 (UTC)
Goto Top
Danke fürs Feedback. Habe @Frank schon ne PM geschickt. Komisch...muss ich gleich mal mit Firefox probieren. Hatte das bis dato hier nur mit Safari (MacBook) getestet. Keine Erweiterungen.
Ex0r2k16
Ex0r2k16 Dec 14, 2021 at 14:20:13 (UTC)
Goto Top
Zitat von @colinardo:


[Match]
Name=bond0

[Network]
Address=192.168.100.2/24

back-to-top/etc/systemd/network/03-nic1.network

NIC1 zum Bond hinzufügen
> [Match]
> Name=eth1
> 
> [Network]
> Bond=bond0
> 

back-to-top/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? face-wink Ansonsten top. Thx!
colinardo
colinardo Dec 14, 2021 updated at 15:53:26 (UTC)
Goto Top
Zitat von @Ex0r2k16:
Müsste es hier nicht eth0 und eth1 heißen? face-wink Ansonsten top. Thx!
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) face-smile.

Grüße Uwe
Ex0r2k16
Ex0r2k16 Dec 16, 2021 at 06:34:49 (UTC)
Goto Top
Zitat von @colinardo:

Zitat von @Ex0r2k16:
Müsste es hier nicht eth0 und eth1 heißen? face-wink Ansonsten top. Thx!
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) face-smile.

Grüße Uwe

oh okay alles klar face-smile
110135
110135 Jan 01, 2023 updated at 11:25:21 (UTC)
Goto Top
Moin,

wie immer - eine super Anleitung. Ich würde - sofern erwünscht - noch weitere Systeme beisteuern:

HPE / H3C Comware:
1. Anlegen des BAGG-Interfaces:
interface Bridge-Aggregation1
 description LAG to XYZ
 port link-type trunk
 port trunk permit vlan all
 link-aggregation mode dynamic
 
2. Zuordnen des phys. Interfaces zur Link-Aggregation
 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
Anmerkung: Hierbei werden ALLE VLANs erlaubt und tagged übertragen!

Aruba OS-CX
1. Anlegen des LAG-Interfaces:
interface lag 1
    no shutdown
    description UPLINK-TO-XYZ
    no routing
    vlan trunk native 1
    vlan trunk allowed all
    lacp mode active
2. Zuordnen des phys. Interface zur Link-Aggregation:
interface 1/1/24
    no shutdown
    description **** UPLINK to XYZ-eth0 ****
    lag 1
VG,
Florian
clSchak
clSchak Apr 26, 2023 updated at 19:57:42 (UTC)
Goto Top
Hi

additiv zu den Aruba, die größeren Geräte (zumindest die 8xxx) können Multi-Chassis Lags, setzt aber ein eingerichtetes VSX voraus:

Basis VSX Config
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

das auf die Switche ausführen und diese dann über Port 1/1/1-1/1/2 miteinander verbinden

via
show vsx status

Überprüfen ob es auf beiden angekommen und "in Betrieb" ist

Anschließend können die LACP Lags eingerichtet werden

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"  

auf den Switchen ausführen, auf denen die Lag-Endpunkte sind, die Gegenstelle kann dann wie oben von @aqui beschrieben konfiguriert werden.

Kleines Manko an der Stelle, VSX und MCT brauchen unter umständen 1-2 Minuten bis die wieder "Up" sind nach einem Switch-Reboot, verhält sich dahingegeben nicht "so schnell" wie ein normales LACP / MRP oder was auch immer face-smile

Grundlagen sind hier gut beschrieben zu VSX: https://random-it-blog.de/linux/aruba-8360-basic-and-vsx-configuration-p ...