6
LACP bzw LAG Hash mit Mikrotik SwOS
Hallo zusammen,
nach dem ich mir jetzt an RouterOS ein wenig die Zähne ausgebissen habe und das so weit funktioniert, habe ich ein wenig mit SwOS/RouterOS und LAGs gespielt.
Im RouterOS lässt sich das Hash-Protokoll für die LAGs ja entsprechend einstellen. Nach dem ich nun ein LAG mit Layer 3+4 und zwei 10G Ports erstellt hatte (in diesem Fall ein CRS326-24S+2Q+), hatte ich bei "voller Auslastung" Paketverluste, aber immerhin fast 18 Gigabit. Das gleiche hab ich dann mit SwOS versucht, mangels Hash-Protokoll schätze ich aber dass das wirklich nur simples Layer 2 ist, damit sind es dann eben knappe 7-8 Gigbit gewesen.
Wenn ich es richtig verstanden habe, muss die CPU bei RouterOS und Layer 3+4 ziemlich ackern - im Wiki steht da im kleingedrucken auch "Only 802.3ad and balance-xor bonding modes are hardware offloaded.", balance-xor müsste Layer 2+3 sein...aber damit krieg ich von einer Maschine nur dann vollen Speed vom Bond, wenn ich mehrere Streams gleichzeitig starte und das Betriebssystem der Maschine entsprechend die Pakete verteilen kann bzw. die Maschine eben auch ein LAG hat UND das Betriebssystem verteilen kann.
Kann SwOS denn überhaupt Layer 2+3 oder wirklich nur simples Layer 2?
nach dem ich mir jetzt an RouterOS ein wenig die Zähne ausgebissen habe und das so weit funktioniert, habe ich ein wenig mit SwOS/RouterOS und LAGs gespielt.
Im RouterOS lässt sich das Hash-Protokoll für die LAGs ja entsprechend einstellen. Nach dem ich nun ein LAG mit Layer 3+4 und zwei 10G Ports erstellt hatte (in diesem Fall ein CRS326-24S+2Q+), hatte ich bei "voller Auslastung" Paketverluste, aber immerhin fast 18 Gigabit. Das gleiche hab ich dann mit SwOS versucht, mangels Hash-Protokoll schätze ich aber dass das wirklich nur simples Layer 2 ist, damit sind es dann eben knappe 7-8 Gigbit gewesen.
Wenn ich es richtig verstanden habe, muss die CPU bei RouterOS und Layer 3+4 ziemlich ackern - im Wiki steht da im kleingedrucken auch "Only 802.3ad and balance-xor bonding modes are hardware offloaded.", balance-xor müsste Layer 2+3 sein...aber damit krieg ich von einer Maschine nur dann vollen Speed vom Bond, wenn ich mehrere Streams gleichzeitig starte und das Betriebssystem der Maschine entsprechend die Pakete verteilen kann bzw. die Maschine eben auch ein LAG hat UND das Betriebssystem verteilen kann.
Kann SwOS denn überhaupt Layer 2+3 oder wirklich nur simples Layer 2?
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: 669522
Url: https://administrator.de/forum/lacp-bzw-lag-hash-mit-mikrotik-swos-669522.html
Ausgedruckt am: 30.12.2024 um 17:12 Uhr
6 Kommentare
Neuester Kommentar
18 Gig wäre ein reiner "Phantasiewert", denn das Hashing (egal was) bestimmt ja immer nur auf welchem physischen Memberlink eines LAGs eine Session gelegt wird. Da die physische Link Speed durch die Ethernet Infrastruktur immer fest vorgegeben ist bleibt diese unveränderlich. Ein physischer 10Gig Link kann also technisch niemals auf 18 Gig "hochgetaktet" werden. Die Daten der Session fliessen also immer nur mit 10Gig von einem Port zum anderen.
Durch den LAG kommt es aber zu einer Verteilung auf die einzelnen Memberlinks und damit zu einer Verteilung der Auslastung an sich.
802.3ad basierte LACP LAGs haben durch die unterschiedliche Address Entropie, egal ob L3 oder L2, nie eine homogene Auslastung. Das wird umso schlechter je weniger Attribute in die Hash Berechnung einfliessen. Gute Systeme nutzen die Adresse, die VLAN ID (sofern vorhanden) und den TCP/UDP Port. Das erhöht die Granularität bei der Verteilung.
Sofern der SwitchOS MT also keine Auswahloption beim LAG Hashing Algorithmus hat kannst du zu 90% davon ausgehen das er auch nur L2 macht.
Weitere Infos zur LAG Thematik, wie immer, HIER.
Durch den LAG kommt es aber zu einer Verteilung auf die einzelnen Memberlinks und damit zu einer Verteilung der Auslastung an sich.
802.3ad basierte LACP LAGs haben durch die unterschiedliche Address Entropie, egal ob L3 oder L2, nie eine homogene Auslastung. Das wird umso schlechter je weniger Attribute in die Hash Berechnung einfliessen. Gute Systeme nutzen die Adresse, die VLAN ID (sofern vorhanden) und den TCP/UDP Port. Das erhöht die Granularität bei der Verteilung.
Kann SwOS denn überhaupt Layer 2+3 oder wirklich nur simples Layer 2?
Das ist eine gute Frage! In der Regel sieht es in der Realität so aus das reine L2 Switches nichts von höherliegenden Layern "kennen". Sie "sehen" also immer nur auf den Layer 2, also Mac Adressen. Ein Port ASIC solch einfacher Switches müsste also deutlich tiefer ins Paket sehen als nur den einfachen L2/Mac Header um L3 Informationen der Frames auswerten zu können. Ein Feature das solche ASICs in der Entwicklung deutlich teurer und aufwendiger werden lässt und was oft ausschliesslich bei Premium Switches gegeben ist. Im LowBudget Bereich rein nach Preis kaufender Clientel aber so gut wie nie gefordert bzw. verbaut ist. Man erkennt es daran das auch bei reinen L2 Switches eine Auswahloption des Hashing Algorithmus gegeben ist.Sofern der SwitchOS MT also keine Auswahloption beim LAG Hashing Algorithmus hat kannst du zu 90% davon ausgehen das er auch nur L2 macht.
Weitere Infos zur LAG Thematik, wie immer, HIER.
Zitat von @aqui:
18 Gig wäre ein reiner "Phantasiewert", denn das Hashing (egal was) bestimmt ja immer nur auf welchem physischen Memberlink eines LAGs eine Session gelegt wird. Da die physische Link Speed durch die Ethernet Infrastruktur immer fest vorgegeben ist ist die unveränderlich. Ein physischer 10Gig Link kann also technisch niemals auf 18 Gig "hochgetaktet" werden. Die Daten der Session fliessen also imemr nur mit 10Gig.
18 Gig wäre ein reiner "Phantasiewert", denn das Hashing (egal was) bestimmt ja immer nur auf welchem physischen Memberlink eines LAGs eine Session gelegt wird. Da die physische Link Speed durch die Ethernet Infrastruktur immer fest vorgegeben ist ist die unveränderlich. Ein physischer 10Gig Link kann also technisch niemals auf 18 Gig "hochgetaktet" werden. Die Daten der Session fliessen also imemr nur mit 10Gig.
Sorry - ich hätte ein wenig weiter ausholen müssen: Zwei 10G im LACP, ein 40G QSFP+ auf der Gegenseite.
Logisch, dass ein 10G Link nicht mehr als 10G kann
LACP LAGs haben durch die unterschiedliche Address Entropie egal ob L3 oder L2 nie eine homogene Auslastung. Das wird umso schlechter je weniger Attribute in die Hash Berechnung einfliessen. Gute Systeme nutzen die Adresse, die VLAN ID (sofern vorhanden) und den TCP/UDP Port. Das erhöht die Granularität bei der Verteilung.
"Gute Systeme"...was kann ich mir darunter jetzt vorstellen? ;) Dass ein Linux Kernel das höchstwahrscheinlich besser kann, als das etwas halbherzige Teaming von Microsoft wäre jetzt z.B. etwas, was ich mir darunter vorstelle...
Kann SwOS denn überhaupt Layer 2+3 oder wirklich nur simples Layer 2?
Das ist eine gute Frage! In der regel ist es so das reine L2 Switches nichts von höherliegenden Layern "kennen", sie "sehen" also immer nur auf Layer 2 also Mac Adressen. Ein Port ASIC solch einfacher Switches müsste also deutlich tiefer ins Paket sehen als nur den einfachen L2/Mac Header. Ein Feature was oft ausschliesslich bei Premium Switches gegeben ist das solche ASICs in der Entwicklung deutlich teurer und aufwendiger ist was im LowBudget Bereich rein nach Preis kaufender Clientel so gut wie nie gefordert ist.Sofern der SwitchOS MT also keine Auswahloption beim LAG Hashing Algorithmus hat kannst du zu 90% davon ausgehen das er auch nur L2 macht.
Weitere Infos zur LAG Thematik, wie immer, HIER.
Naja - laut Wiki kann der CRS326-24S+2Q+mit RouterOS Hardware Layer3 Offloading. Dann müsste SwOS das ja eigentlich auch können...aber ich finde da keine Infos oder ich hab sie übersehen...bzw. ich finde auch generell keine Infos darüber, selbst im Mikrotik-Forum ist der Info-Gehalt relativ dürftig...
"Gute Systeme"...was kann ich mir darunter jetzt vorstellen?
Cisco Catalyst, Ruckus ICX, Juniper, Extreme & Co. Die NetGear und TP-Link Fraktion natürlich nicht. Ist doch immer die gleiche Netzwerk Leier. 
Dann müsste SwOS das ja eigentlich auch können
Wie denn?? SwitchOS kann rein gar nichts an Layer 3 Funktionen außer dem Management IP Zugriff. Sieht man ja auch im Setup wo sämtliche L3 Funktionen erwartungsgemäß fehlen.
Hey,
da hast du den Hinweistext wohl nicht richtig gelesen....
Wenn du wirklich 802.3ad oder balance-xor konfiguriert hast, dann läuft dies über den ASIC also über den Switch-Chip und NICHT über die CPU.
Zitat:
Im ROS kannst du als Hash Algorithmus "Layer2, Layer 2und3 oder Layer 3und4 wählen.
SwitchOS ist hauptsächlich nur für Layer2 Funktionalitäten, glaube nur bei ACLS kannst du noch Layer 3 und 4 mit hinzuziehen, das wars dann aber.
Wenn man Layer 3 und höher Funktionalitäten benötigt, setzt man ROS ein.
und nicht vergessen, den Hash Algorithmus auf beiden Seiten (Switch und Endgerät) gleich einzustellen.
@aqui hat ja das meiste schon dazu gesagt.
Gruß
Wenn ich es richtig verstanden habe, muss die CPU bei RouterOS und Layer 3+4 ziemlich ackern - im Wiki steht da im kleingedrucken auch "Only 802.3ad and balance-xor bonding modes are hardware offloaded."
da hast du den Hinweistext wohl nicht richtig gelesen....
Wenn du wirklich 802.3ad oder balance-xor konfiguriert hast, dann läuft dies über den ASIC also über den Switch-Chip und NICHT über die CPU.
Zitat:
"....switch chips support bridge hardware offloading with bonding interfaces. Only 802.3ad and balance-xor bonding modes are hardware offloaded, other bonding modes will use the CPU's resources."
Im ROS kannst du als Hash Algorithmus "Layer2, Layer 2und3 oder Layer 3und4 wählen.
SwitchOS ist hauptsächlich nur für Layer2 Funktionalitäten, glaube nur bei ACLS kannst du noch Layer 3 und 4 mit hinzuziehen, das wars dann aber.
Wenn man Layer 3 und höher Funktionalitäten benötigt, setzt man ROS ein.
und nicht vergessen, den Hash Algorithmus auf beiden Seiten (Switch und Endgerät) gleich einzustellen.
@aqui hat ja das meiste schon dazu gesagt.
Gruß
1den Hash Algorithmus auf beiden Seiten (Switch und Endgerät) gleich einzustellen.
Das ist zwar wünschenswert aber nicht zwingend. Jede Seite entscheidet ja selber für sich wie sie ihre Sessions mit ihrem lokalen Hashing verteilt. Es ist also durchaus nicht unüblich das ein Frame in einer Richtung über Memberlink x und in der anderen Richtung über Memberlink y geht. Da es ja rein Layer 2 ist ist das für den Betrieb irrelevant und erhöht auch noch die Granularität.Wäre sowas erforderlich könnte man z.B. nie verschiedene LAG Hardware zueinanderbringen obwohl der LACP Standard weltweit gleich ist. Der Standard selber schreibt es deshalb nicht vor aber es macht Sinn um auf beiden Seiten die gleiche granulare Verteilung zu bekommen. Hängt aber natürlich auch immer von den verfügbaren Algorithmen auf beiden Seiten ab.
Man muss beim LAG Design deshalb auch genau hinsehen. Ist z.B. auf einer Seite ein Routing Gateway werden alle Frames immer nur mit einer einzigen Mac Adresse gesendet. Hier wäre es z.B. kontraproduktiv nur nach L2 bzw. Mac Adressen zu hashen.
Wenn es das denn nun war als Lösung bitte nicht vergessen deinen Tread dann auch als erledigt zu markieren!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
