triage4490
Goto Top

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?

Content-ID: 669522

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

Ausgedruckt am: 15.11.2024 um 17:11 Uhr

aqui
aqui 15.11.2024 aktualisiert um 16:13:35 Uhr
Goto Top
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.
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.
Triage4490
Triage4490 15.11.2024 aktualisiert um 16:22:43 Uhr
Goto Top
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.

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 face-smile

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...
aqui
aqui 15.11.2024 aktualisiert um 16:37:10 Uhr
Goto Top
"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. face-wink
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.