7
Link Aggregation mit Ubiquiti
Liebe Admin-Gemeinde, guten Tag!
Wir verzweifeln an einem (vielleicht trivialen) Problem, das wir mit Ubiquiti-Komponenten haben.
Der Sachstand:
Seit einigen Jahren leben und arbeiten wir auf einer Insel im Atlantik, fernab von Glasfaser, Kupfer oder WLAN. Wir mußten die Sache selbst in die Hand nehmen und haben mit einem Paar Ubiquiti AirFiber AF-5 eine Verbindung zu einem Knoten an der Küste hergestellt, Entfernung knapp 4km.
Aufgrund der steigenden Anzahl von Anwendern im 5GHz-Bereich wurde und wird diese Verbindung mit der Zeit immer schlechter; wir haben daher einen weiteren Kanal über ein Paar AirFiber 60LR (60 GHz) aufgebaut.
Die Frage:
Gerne würden wir beide Kanäle nutzen, hauptsächlich aus Sicherheitsgründen, aber auch wegen verbesserter Performance. Nur leider gelingt uns der Aufbau einer Link Aggregation nicht, weder mit Unifi-Produkten (UDM-Pro, diverse switches US-xx-yy) noch mit tp-link-Komponenten (TL-SGxxxx, TL-SGxxxx)).
Von Ubiquiti ist keine Unterstützung zu bekommen. Vielleicht kann uns jemand in diesem Team den entscheidenden Tipp geben?
Vielen Dank im Voraus!
Wir verzweifeln an einem (vielleicht trivialen) Problem, das wir mit Ubiquiti-Komponenten haben.
Der Sachstand:
Seit einigen Jahren leben und arbeiten wir auf einer Insel im Atlantik, fernab von Glasfaser, Kupfer oder WLAN. Wir mußten die Sache selbst in die Hand nehmen und haben mit einem Paar Ubiquiti AirFiber AF-5 eine Verbindung zu einem Knoten an der Küste hergestellt, Entfernung knapp 4km.
Aufgrund der steigenden Anzahl von Anwendern im 5GHz-Bereich wurde und wird diese Verbindung mit der Zeit immer schlechter; wir haben daher einen weiteren Kanal über ein Paar AirFiber 60LR (60 GHz) aufgebaut.
Die Frage:
Gerne würden wir beide Kanäle nutzen, hauptsächlich aus Sicherheitsgründen, aber auch wegen verbesserter Performance. Nur leider gelingt uns der Aufbau einer Link Aggregation nicht, weder mit Unifi-Produkten (UDM-Pro, diverse switches US-xx-yy) noch mit tp-link-Komponenten (TL-SGxxxx, TL-SGxxxx)).
Von Ubiquiti ist keine Unterstützung zu bekommen. Vielleicht kann uns jemand in diesem Team den entscheidenden Tipp geben?
Vielen Dank im Voraus!
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7604231703
Url: https://administrator.de/forum/link-aggregation-mit-ubiquiti-7604231703.html
Ausgedruckt am: 16.03.2025 um 09:03 Uhr
7 Kommentare
Neuester Kommentar
Lesen und verstehen: 
Link Aggregation (LAG) im Netzwerk
Bedenke das eine LACP Link Aggregation immer nur an einem einzigen, dedizierten Endgerät klappt NICHT aber gesplittet über 2 Geräte. Für gesplittete LACP LAGs braucht es zwingend das MLAG Feature was Accesspoints in der Regel gar nicht können. Das solltest du auf dem Radar haben! Solltest du das versuchen wir dir weder der UBQT Support noch der beste Tip helfen!
Es klappt einzig und allein nur wenn dein Bridge AP zwei RJ-45 Ports hat und man diese mit einem LACP LAG koppeln kannt. Logischerweise muss der Switch auf der anderen Seite dann auch standardkonforme 802.3ad LAGs supporten. Ansonsten scheitert eine Link Aggregation sofort.
Link Aggregation (LAG) im Netzwerk
Bedenke das eine LACP Link Aggregation immer nur an einem einzigen, dedizierten Endgerät klappt NICHT aber gesplittet über 2 Geräte. Für gesplittete LACP LAGs braucht es zwingend das MLAG Feature was Accesspoints in der Regel gar nicht können. Das solltest du auf dem Radar haben! Solltest du das versuchen wir dir weder der UBQT Support noch der beste Tip helfen!
Es klappt einzig und allein nur wenn dein Bridge AP zwei RJ-45 Ports hat und man diese mit einem LACP LAG koppeln kannt. Logischerweise muss der Switch auf der anderen Seite dann auch standardkonforme 802.3ad LAGs supporten. Ansonsten scheitert eine Link Aggregation sofort.
Moin,
ein normales Lagg nach ad Standard wird da aus Erfahrung scheitern. Der Hintergrund sind die unterschiedlichen und gerade bei Wireless variablen Bandbreiten. Das verträgt der Standard nicht.
Besser wäre hier auf Loadbalcing zu setzen. Im einfachsten Fall eben failover mäßig.
Gruß
Spirit
ein normales Lagg nach ad Standard wird da aus Erfahrung scheitern. Der Hintergrund sind die unterschiedlichen und gerade bei Wireless variablen Bandbreiten. Das verträgt der Standard nicht.
Besser wäre hier auf Loadbalcing zu setzen. Im einfachsten Fall eben failover mäßig.
Gruß
Spirit
Das stimmt aber für AP Bridges die zwei zu einem LAG bündelbare Ports haben nicht zwingend. Dort klappt das natürlich wie z.B. bei Mikrotik APs u.a.
Was aber in der Tat nicht klappt ist ein LAG über mehrere APs weil, wie du richtig sagst, es hier zu einem Speed Problem kommt was der 802.3ad Standard in sich nicht supportet! Mal abgesehen davon das kein AP Hersteller dieses Feature (MLAG) auf AP Bridges implementiert hat.
Leider hat der TO versäumt eine kurze Topologie Skizze zu senden. Versteht man die Beschreibung richtig dann will er ein Load Sharing über parallele Layer 2 AP Links, was so im Layer 2 generell technisch nicht möglich ist mit LAGs.
Hier wäre es deutlich besser ein Layer 3 Sharing zu machen mit ECMP. Sprich also die parallelen Links über dedizierte Transfer IP Netze zu routen und dann z.B. mit OSPF und ECMP ein Sharing über alle diese Links zu machen. Das sollte auch mit den UBQT Gurken einfach möglich sein. Ein 25 Euro Mikrotik AP könnte das z.B. problemlos.
Das hätte dann auch den großen Vorteil das damit aller Broad- und Multicast Traffic nicht mehr diese Bridge Funk Links belastet und damit einen massiven Performance Verlust auf der Funkstrecke, die ja eh nur einen Bruchteil der Ethernet Bandbreite hat, vermeidet.
Fazit:
Es ist zu befürchten das der TO ein gänzlich falsches Netzdesign für diese Anbindung gemacht hat und deshalb scheitert. Das ist aber Kristallkugelei weil man letztlich die Topologie nicht kennt.
Was aber in der Tat nicht klappt ist ein LAG über mehrere APs weil, wie du richtig sagst, es hier zu einem Speed Problem kommt was der 802.3ad Standard in sich nicht supportet! Mal abgesehen davon das kein AP Hersteller dieses Feature (MLAG) auf AP Bridges implementiert hat.
Leider hat der TO versäumt eine kurze Topologie Skizze zu senden. Versteht man die Beschreibung richtig dann will er ein Load Sharing über parallele Layer 2 AP Links, was so im Layer 2 generell technisch nicht möglich ist mit LAGs.
Hier wäre es deutlich besser ein Layer 3 Sharing zu machen mit ECMP. Sprich also die parallelen Links über dedizierte Transfer IP Netze zu routen und dann z.B. mit OSPF und ECMP ein Sharing über alle diese Links zu machen. Das sollte auch mit den UBQT Gurken einfach möglich sein. Ein 25 Euro Mikrotik AP könnte das z.B. problemlos.
Das hätte dann auch den großen Vorteil das damit aller Broad- und Multicast Traffic nicht mehr diese Bridge Funk Links belastet und damit einen massiven Performance Verlust auf der Funkstrecke, die ja eh nur einen Bruchteil der Ethernet Bandbreite hat, vermeidet.
Fazit:
Es ist zu befürchten das der TO ein gänzlich falsches Netzdesign für diese Anbindung gemacht hat und deshalb scheitert. Das ist aber Kristallkugelei weil man letztlich die Topologie nicht kennt.
Zunächst danke für Ihre rasche Rückmeldung!
In Bild 1 habe ich den Ist-Zustand festgehalten: Glasfaserverbindung über Modem der Telefónica an den AF-5 an der Küste und weiter zu AF-5 auf unserer Finca. Von dort in den WLAN-Eingang des UDM Pro und weiter ins LAN.
Bild 2 zeigt den Sollzustand: Neben der Funkverbindung AF-5 zu AF-5 steht die 60GHz-Verbindung über 2 Stück 60LR. Die ?-Blöcke sind switches, über die LAG realisiert werden soll. Testinstallation mit TP-SGxxxx funktioniert nicht.
Vielleicht gibt es geeignete Komponenten für die ?-Blöcke oder eine andere Lösung, an die wir als Softwerker einfach nicht gedacht haben...
Vielleicht gibt es geeignete Komponenten für die ?-Blöcke oder eine andere Lösung, an die wir als Softwerker einfach nicht gedacht haben...
Ich würde einfach auf beiden Seiten einen Loadbalacer nutzen und die Links als separate lines betrachten. Dann hättest du automatisch ein failover. Wahrscheinlich ist das aber mit Kanonen auf Spatzen geschossen auch wenn das mit zwei PfSense Installation einfach zu realisieren wäre.
Anderer Seits brauchst du bei aquis MLAG Option ebenfalls zwei weitere Geräte, eines auf jeder Seite da die Ubiquiti Teile sowas nicht können.
Loadbalacing müsste auch mit Mikrotiks möglich sein. Habe ich aber noch nicht gemacht.
Anderer Seits brauchst du bei aquis MLAG Option ebenfalls zwei weitere Geräte, eines auf jeder Seite da die Ubiquiti Teile sowas nicht können.
Loadbalacing müsste auch mit Mikrotiks möglich sein. Habe ich aber noch nicht gemacht.
Bild 2 zeigt den Sollzustand:
Kollege @Spirit-of-Eli hat es ja schon gesagt...Das ist so mit Layer 2 LAGs technisch nicht zu lösen. Logisch das der UBQT da dann auch nicht helfen kann.
Das würde MLAG support erzwingen was aber kein Hersteller supportet auf solchen Geräten:
Fazit:
Löse das mit 2 dediziert gerouteten Bridgelinks auf dem "?" Device (Router ??) und entweder...
- mit 2 statischen default Routen gleicher Metrik
- einem dynmaischen Routing Protokoll was ECMP kann wie z.B. OSPF.
Ersteres macht eine Round Robin Verteilung aller Sessions. Zweites eine dynamsiche je nach verfügbarer Bandbreite und Qualität.
Das ist eine sehr einfache und effiziente Lösung.
Alternative wäre die "?" mit Dual WAN Balancing Routern zu ersetzen. Auch die können je nach konfigurierter Policy eine Lastverteilung auf 2 geroutete Interfaces (Links) realisieren!
Danke liebe Beide.
Wir beschaffen zwei kleine Mikrotik-Router unter RouterOS und versuchen unser Glück.
Über das Ergebnis berichten wir hier.
Beste Grüße aus TF
ste
Wir beschaffen zwei kleine Mikrotik-Router unter RouterOS und versuchen unser Glück.
Über das Ergebnis berichten wir hier.
Beste Grüße aus TF
ste
1
