7
LAG über 3 Funkbridges mit Mikrotik Switch
Hallo,
Ich möchte zwischen 2 Mikrotik eine LAG über 3 Ports aufbauen. Aber ich habe keine direkte physische Verbindung der Switches, sondern 3 Ubiquiti Funkbridges. (2x 1Gbps, 1 x 0,5 Gbps). Ob IEEE 802.1AX-2008 das abdeckt habe ich nicht gefunden, die Norm ist recht schwach definiert.
Hat jemand so was schon mal realisiert? Oder Kommentare dazu, ob die Idee für arg verwegen ist?
Technisch irrelevant, aber der Vollständigkeit halber, was wir vorhaben:
Es handelt sich um eine ausgelagerte Failover-IT, im Wesentlichen schubsen wir nachts Backups rüber, tagsüber nutzen wir den Internetzugang der Gegenseite noch mit.
Das machen wir schon 5 Jahre mit einer 0,5er-Strecke, die 2x 1 kämen jetzt dazu.
Im Ernstfall reichen mir die gebündelten 2,5 Gbit sogar für den Failover-Betrieb, da der Kunde hauptsächlich mit Thin Clients arbeitet.
Die Bridges habe ich ohnehin schon, und ein LAG über zwei günstige Switches hätte halt den Charme, dass ich den Traffic nicht splitten muss.
Der Mikrotik hat den Vorteil, dass er a) günstig ist, b weitestgehend konfigurierbar und ich c) Glasfaser und Kupfer mixen kann, d) habe ich die 10 Gbit im up/downlink.
Danke für alle sinnvollen Hinweise.
Ich möchte zwischen 2 Mikrotik eine LAG über 3 Ports aufbauen. Aber ich habe keine direkte physische Verbindung der Switches, sondern 3 Ubiquiti Funkbridges. (2x 1Gbps, 1 x 0,5 Gbps). Ob IEEE 802.1AX-2008 das abdeckt habe ich nicht gefunden, die Norm ist recht schwach definiert.
Hat jemand so was schon mal realisiert? Oder Kommentare dazu, ob die Idee für arg verwegen ist?
Technisch irrelevant, aber der Vollständigkeit halber, was wir vorhaben:
Es handelt sich um eine ausgelagerte Failover-IT, im Wesentlichen schubsen wir nachts Backups rüber, tagsüber nutzen wir den Internetzugang der Gegenseite noch mit.
Das machen wir schon 5 Jahre mit einer 0,5er-Strecke, die 2x 1 kämen jetzt dazu.
Im Ernstfall reichen mir die gebündelten 2,5 Gbit sogar für den Failover-Betrieb, da der Kunde hauptsächlich mit Thin Clients arbeitet.
Die Bridges habe ich ohnehin schon, und ein LAG über zwei günstige Switches hätte halt den Charme, dass ich den Traffic nicht splitten muss.
Der Mikrotik hat den Vorteil, dass er a) günstig ist, b weitestgehend konfigurierbar und ich c) Glasfaser und Kupfer mixen kann, d) habe ich die 10 Gbit im up/downlink.
Danke für alle sinnvollen Hinweise.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1104828239
Url: https://administrator.de/contentid/1104828239
Ausgedruckt am: 21.11.2024 um 13:11 Uhr
7 Kommentare
Neuester Kommentar
Moin,
Können die Ubiquitis überhaupt 3 L2 Verbindung gewährleisten?
Wenn nicht, ist dein Vorhaben zum scheitern verurteilt.
Zu dem sind laggs über Funktverbindung höhst wahrscheinlich instabil wenn überhaupt supportet da die links eine variable Bandbreite aufweisen werden. Das ist gegen die Spezifikation.
Gruß
Spirit
Können die Ubiquitis überhaupt 3 L2 Verbindung gewährleisten?
Wenn nicht, ist dein Vorhaben zum scheitern verurteilt.
Zu dem sind laggs über Funktverbindung höhst wahrscheinlich instabil wenn überhaupt supportet da die links eine variable Bandbreite aufweisen werden. Das ist gegen die Spezifikation.
Gruß
Spirit
Dir auch 
Können die Ubiquitis überhaupt 3 L2 Verbindung gewährleisten?
Sieht so aus:
https://help.ui.com/hc/en-us/articles/205142890-airMAX-How-to-Configure- ...
Ich denke nicht, das wird typischerweise mit "costs" geregelt.
Gruß
Spirit
Gruß
Oliver
Können die Ubiquitis überhaupt 3 L2 Verbindung gewährleisten?
Sieht so aus:
https://help.ui.com/hc/en-us/articles/205142890-airMAX-How-to-Configure- ...
Wenn nicht, ist dein Vorhaben zum scheitern verurteilt.
Zu dem sind laggs über Funktverbindung höhst wahrscheinlich instabil wenn überhaupt supportet da die links eine variable Bandbreite aufweisen werden. Das ist gegen die Spezifikation.
Zu dem sind laggs über Funktverbindung höhst wahrscheinlich instabil wenn überhaupt supportet da die links eine variable Bandbreite aufweisen werden. Das ist gegen die Spezifikation.
Ich denke nicht, das wird typischerweise mit "costs" geregelt.
Gruß
Spirit
Gruß
Oliver
Es wäre mir neu das die Bandbreite über "Costs" definiert wird. Normalerweise lässt sich der Parameter eher mit "güthe" über setzen.
Mit einem anderen Hersteller hat bei einem Scenario solch eine lagg Anbindung nicht funktioniert und der Hersteller hat da auch ein p vor gesetzt. Was spricht dagegen die Anbindung direkt über Mikrotik umzusetzen? Aber selbst das wird glaub ich nicht supportet.
Mit einem anderen Hersteller hat bei einem Scenario solch eine lagg Anbindung nicht funktioniert und der Hersteller hat da auch ein p vor gesetzt. Was spricht dagegen die Anbindung direkt über Mikrotik umzusetzen? Aber selbst das wird glaub ich nicht supportet.
Zitat von @Spirit-of-Eli:
Es wäre mir neu das die Bandbreite über "Costs" definiert wird. Normalerweise lässt sich der Parameter eher mit "güthe" über setzen.
Mit einem anderen Hersteller hat bei einem Scenario solch eine lagg Anbindung nicht funktioniert und der Hersteller hat da auch ein p vor gesetzt. Was spricht dagegen die Anbindung direkt über Mikrotik umzusetzen? Aber selbst das wird glaub ich nicht supportet.
Es wäre mir neu das die Bandbreite über "Costs" definiert wird. Normalerweise lässt sich der Parameter eher mit "güthe" über setzen.
Mit einem anderen Hersteller hat bei einem Scenario solch eine lagg Anbindung nicht funktioniert und der Hersteller hat da auch ein p vor gesetzt. Was spricht dagegen die Anbindung direkt über Mikrotik umzusetzen? Aber selbst das wird glaub ich nicht supportet.
Über das Wort muss man ja nicht streiten. Costs, Prioritäten, Metrik, Latenzen die Begriffe sind verschieden, die Methoden teils auch, je nach Hersteller. Soweit ich die Definition des 802.1AX verstehe ist es "der Norm" recht egal, was der Hersteller da zwischendrin zaubert, er muss nur gewährleisten, dass die Pakete "in order" ankommen.
Bei Mikrotik gibt es meines Wissens eine lacp-system-prioritxy und eine port-priority.
Und so lange ich zwischen den beiden Switches layer2-transparent bin, sollten die beiden Mikrotik miteinander reden und die die Priorisierung regeln können.
Die Ubiquiti wurden deswegen gewählt, weil zum einen die vorhandene Bridge schon von Ubiquiti ist und diese schon 5 Jahre ihren Dienst ohne jede Störung tut. Die Kosten lagen damals kurz vor Null, Einrichtung in wenigen Minuten.
Und selbst mit 4 LR60 liegt man bei vorhandenen Masten gerade mal bei 1200€ Hardware für zwei Gigabit Funkstrecken. (Long range bis 12 km). Von daher bleibe ich definitiv bei UI, was die Bridges betrifft.
Die Überlegung wäre - wenn schon - eher, ob ich statt Mikrotik Edgerouter von UI einsetze, denn die können neben der Layer2 auch ein Layer3-Bonding. Der Mikrotik hätte für allerdings den Charme der günstigen SFP+ports und ist damit für wenig Geld zukunftsoffen.
Ich werde wohl mal mit zwei MIkrotik "auf dem Tisch" verkabelt LAG-Tests machen und einfach 1x10GB und 2x1GB zusammen bonden und sehen, wie sich das Bonding schlägt. Dann kann man den nächsten Schritt mit der Funkstrecke gehen.
1
Ich denke das das Vorhaben zum Scheitern verurteilt ist. Grund ist das das drunterliegende 802.3ad LAG Verfahren keine Laufzeitunterschiede augleichen kann. Der Standard sieht das nicht vor. Genau deshalb sind exakt gleiche Link Speeds zwingend.
Das kannst du im WLAN niemals gewährleisten durch die Dynamik bei der Bandbreite. Da wird es ganz sicher zu Packet Reassembling Problemen kommen.
Der 2te KO ist das LACP LAGs immer Punkt zu Punkt Connections sind. Die Steuerframes können also technisch schon gar nicht über die Funkstrecke ausgetauscht werden. Wenn dem so wäre müsstest du ja auch einen LAG über eine simple LAN Bridge zum Laufen bringen können was aber technisch nicht geht, da nicht supportet. Ein WLAN ist netztechnisch nichts anderes als eine Bridge.
Aus meiner Sicht 2 wasserdichte KO Kriterien für ein Scheitern.
Ich würde es mit Routing lösen.
Betreibe alle 3 Links als geroutete Netzwerke und nutze OSPF. OSPF macht per Default ECMP also einen Sessin basierten Lastenausgleich. Das klappt auch über WLANs völlig problemlos.
Der Mikrotik supportet OSPF so das die Realisierung damit ein Kinderspielt ist.
Das kannst du im WLAN niemals gewährleisten durch die Dynamik bei der Bandbreite. Da wird es ganz sicher zu Packet Reassembling Problemen kommen.
Der 2te KO ist das LACP LAGs immer Punkt zu Punkt Connections sind. Die Steuerframes können also technisch schon gar nicht über die Funkstrecke ausgetauscht werden. Wenn dem so wäre müsstest du ja auch einen LAG über eine simple LAN Bridge zum Laufen bringen können was aber technisch nicht geht, da nicht supportet. Ein WLAN ist netztechnisch nichts anderes als eine Bridge.
Aus meiner Sicht 2 wasserdichte KO Kriterien für ein Scheitern.
Ich würde es mit Routing lösen.
Betreibe alle 3 Links als geroutete Netzwerke und nutze OSPF. OSPF macht per Default ECMP also einen Sessin basierten Lastenausgleich. Das klappt auch über WLANs völlig problemlos.
Der Mikrotik supportet OSPF so das die Realisierung damit ein Kinderspielt ist.
1Zitat von @aqui:
Ich denke das das Vorhaben zum Scheitern verurteilt ist. Grund ist das das drunterliegende 802.3ad LAG Verfahren keine Laufzeitunterschiede augleichen kann. Der Standard sieht das nicht vor. Genau deshalb sind exakt gleiche Link Speeds zwingend.
Das kannst du im WLAN niemals gewährleisten durch die Dynamik bei der Bandbreite. Da wird es ganz sicher zu Packet Reassembling Problemen kommen.
Der 2te KO ist das LACP LAGs immer Punkt zu Punkt Connections sind. Die Steuerframes können also technisch schon gar nicht über die Funkstrecke ausgetauscht werden.
Ich denke das das Vorhaben zum Scheitern verurteilt ist. Grund ist das das drunterliegende 802.3ad LAG Verfahren keine Laufzeitunterschiede augleichen kann. Der Standard sieht das nicht vor. Genau deshalb sind exakt gleiche Link Speeds zwingend.
Das kannst du im WLAN niemals gewährleisten durch die Dynamik bei der Bandbreite. Da wird es ganz sicher zu Packet Reassembling Problemen kommen.
Der 2te KO ist das LACP LAGs immer Punkt zu Punkt Connections sind. Die Steuerframes können also technisch schon gar nicht über die Funkstrecke ausgetauscht werden.
Die Bridge ist transparent in L2, von daher kann ein Steuerframe schon laufen. Ubiquiti macht das ja mit dem NxN auch, allerdings ist da alles proprietär.
Wenn dem so wäre müsstest du ja auch einen LAG über eine simple LAN Bridge zum Laufen bringen können was aber technisch nicht geht, da nicht supportet. Ein WLAN ist netztechnisch nichts anderes als eine Bridge.
Ein Kabel bietet im Vergleich zur Bridge - etwas böse ausgedrückt - aber auch nur den Layer 1 mehr. Den der LAG nicht braucht.
Aus meiner Sicht 2 wasserdichte KO Kriterien für ein Scheitern.
Ich hätte schon eine Chance gesehen, weil ja die Spezifikation nicht verbietet durchaus auch Sessionhandling zu betreiben, ich (bzw. der Hersteller) muss ja nicht jeden Paketstrom aufteilen.
Ich würde es mit Routing lösen.
Betreibe alle 3 Links als geroutete Netzwerke und nutze OSPF. OSPF macht per Default ECMP also einen Sessin basierten Lastenausgleich. Das klappt auch über WLANs völlig problemlos.
Der Mikrotik supportet OSPF so das die Realisierung damit ein Kinderspielt ist.
Das ist das Totschlagargument. Wenn es eins sichere funktionierende Lösung gibt, wäre es natürlich saublöd, sich mit den unwahrscheinlichen - oder in Deinen Augen sogar infausten - Lösungen zu beschäftigen.
D.h., Du würdest die Mikrotik als Router laufen lassen, auf 3 Ports je eine LAN2LAN Kopplung realisieren und dann OSPF "drüber legen". Was mir schlicht und einfach nicht bewusst war ist, dass OSPF grundsätzlich ECMP kann.
Das klingt gut und wäre vor allem auch "auf dem Schreibtisch" zu testen, mit zwei 10GB und einer 1GB-Verbindung.
Zudem bringt mir das Routing mehr Flexibilität, ich kann beispielsweise die 500Mbit Funkstreckke ohne großes Theater auch testweise aus der Aggregation raus nehmen und nur als Internet Uplink nutzen.
Danke
Gruß
Oliver
Und...das Routing minimiert die Broad- und Multicast Last ganz erheblich auf deinem Funklink was massgeblich für die Performance auf der Funkstrecke ist.
