15
Mikrotik MLag
Hallo,
da ich gerade mich wieder in Mikrotik eingewöhne und MLag (Multi-chassis Link Aggregation Group) überall anders konfiguriert wird, will ich mal nur paar grundlegende Fragen zu Design und Best-Practice stellen...
Ich bin nach dieser Anleitung vorgegangen:
https://help.mikrotik.com/docs/display/ROS/Multi-chassis+Link+Aggregatio ...
Soweit, so verständlich. Mikrotik Geräte sind CRS326 mit SFP und QSFP+.
Gehen wir davon aus, das ich drei Clients habe. In diesem Fall Debain-Server. Wenn ich es richtig verstanden habe, muss jeder Bond der über Mlag gehen soll, seine eigene ID haben:
Switch 1:
Switch 2
Das wäre die Grundconfig. Alle Clients haben ihren Bond. Nun würde als nächstes das Einrichten des Peering-Links stattfinden und dazu habe ich Fragen:
Ist es empfehlenswert die QSFP+ Interfaces ebenfalls in einen Bond zu stecken? Zur Erinnerung: Jeder QSFP+ Anschluss ist jeweils im System mit 4 Interfaces bedacht (also qsfpplus2-1, qsfpplus2-2, ... qsfpplus1-1, qsfpplus1-2, usw.). Wenn ja, benötigt dieser Bond ebenfalls ein mlag-id?
Oder müssen hier für jede Mlag-ID separate Peering-Link mit eigenen Interfaces angelegt werden?
Ist es richtig, das man nach wie vor über das gesamte Gerät, nur eine Bridge haben sollte? Habe da im Hinterkopf das bei mehreren das Hardware-Offloading sonst nicht mehr funktioniert.
Gruß
da ich gerade mich wieder in Mikrotik eingewöhne und MLag (Multi-chassis Link Aggregation Group) überall anders konfiguriert wird, will ich mal nur paar grundlegende Fragen zu Design und Best-Practice stellen...
Ich bin nach dieser Anleitung vorgegangen:
https://help.mikrotik.com/docs/display/ROS/Multi-chassis+Link+Aggregatio ...
Soweit, so verständlich. Mikrotik Geräte sind CRS326 mit SFP und QSFP+.
Gehen wir davon aus, das ich drei Clients habe. In diesem Fall Debain-Server. Wenn ich es richtig verstanden habe, muss jeder Bond der über Mlag gehen soll, seine eigene ID haben:
Switch 1:
/interface bonding
add mlag-id=10 mode=802.3ad name=deb0-bond slaves=sfp-sfpplus1
add mlag-id=11 mode=802.3ad name=deb1-bond slaves=sfp-sfpplus2
add mlag-id=12 mode=802.3ad name=deb2-bond slaves=sfp-sfpplus3
/interface bridge
add name=bridge1 vlan-filtering=yes
/interface bridge port
add bridge=bridge1 interface=deb0-bond
add bridge=bridge1 interface=deb1-bond
add bridge=bridge1 interface=deb2-bondSwitch 2
/interface bonding
add mlag-id=10 mode=802.3ad name=deb0-bond slaves=sfp-sfpplus1
add mlag-id=11 mode=802.3ad name=deb1-bond slaves=sfp-sfpplus2
add mlag-id=12 mode=802.3ad name=deb2-bond slaves=sfp-sfpplus3
/interface bridge
add name=bridge1 vlan-filtering=yes
/interface bridge port
add bridge=bridge1 interface=deb0-bond
add bridge=bridge1 interface=deb1-bond
add bridge=bridge1 interface=deb2-bondDas wäre die Grundconfig. Alle Clients haben ihren Bond. Nun würde als nächstes das Einrichten des Peering-Links stattfinden und dazu habe ich Fragen:
Ist es empfehlenswert die QSFP+ Interfaces ebenfalls in einen Bond zu stecken? Zur Erinnerung: Jeder QSFP+ Anschluss ist jeweils im System mit 4 Interfaces bedacht (also qsfpplus2-1, qsfpplus2-2, ... qsfpplus1-1, qsfpplus1-2, usw.). Wenn ja, benötigt dieser Bond ebenfalls ein mlag-id?
Oder müssen hier für jede Mlag-ID separate Peering-Link mit eigenen Interfaces angelegt werden?
Ist es richtig, das man nach wie vor über das gesamte Gerät, nur eine Bridge haben sollte? Habe da im Hinterkopf das bei mehreren das Hardware-Offloading sonst nicht mehr funktioniert.
Gruß
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1788005525
Url: https://administrator.de/contentid/1788005525
Printed on: April 19, 2024 at 16:04 o'clock
15 Comments
Latest comment
Du arbeitest in den QSFP Ports mit Breakout Optiken oder Kabeln, ist das richtig verstanden ?
Wenn ja, dann sind die daraus resultierenden 4 Einzelinterfaces auch immer wie getrennte Einzelinterfaces zu sehen. Vom physischen QSFP Port sind sie dann vollkommen entkoppelt.
Es macht schon Sinn den Peering Port auf einen Bond zu legen, denn damit hat man immer eine Leitungsredundanz die bei mLAGs nicht ganz unwichtig ist.
Von der Verfügbarkeit des Peering Ports hängt die mLAG Funktion ab. Wenn das nur ein singulärer Port wäre bestünde die Gefahr eines sog. "Split Brain" bei Ausfall und damit inkonsistenter LAG Zustandsinformationen bei den Peer Membern, was in der Praxis meist mit einem Linkverlust einhergeht. Zumindestens einseitig.
Best Practise ist oft, noch einen einfachen untagged Port als zusätzlichen Backup Peer zum primären Bonding Peer zu nehmen. Hängt aber davon ab welches Sicherheitsniveau man im Design anstrebt und ob der Hersteller das Feature technisch zulässt von der Konfig. Ein Bonding Peer Link hat also definitv Vorteile.
Und ja, eine Bridge reicht. Warum sollte man denn auch überhaupt mehrere benötigen ? In einem VLAN Design mit Filtering wäre das auch völlig überflüssig.
Wenn ja, dann sind die daraus resultierenden 4 Einzelinterfaces auch immer wie getrennte Einzelinterfaces zu sehen. Vom physischen QSFP Port sind sie dann vollkommen entkoppelt.
Es macht schon Sinn den Peering Port auf einen Bond zu legen, denn damit hat man immer eine Leitungsredundanz die bei mLAGs nicht ganz unwichtig ist.
Von der Verfügbarkeit des Peering Ports hängt die mLAG Funktion ab. Wenn das nur ein singulärer Port wäre bestünde die Gefahr eines sog. "Split Brain" bei Ausfall und damit inkonsistenter LAG Zustandsinformationen bei den Peer Membern, was in der Praxis meist mit einem Linkverlust einhergeht. Zumindestens einseitig.
Best Practise ist oft, noch einen einfachen untagged Port als zusätzlichen Backup Peer zum primären Bonding Peer zu nehmen. Hängt aber davon ab welches Sicherheitsniveau man im Design anstrebt und ob der Hersteller das Feature technisch zulässt von der Konfig. Ein Bonding Peer Link hat also definitv Vorteile.
Wenn ja, benötigt dieser Bond ebenfalls ein mlag-id?
Nein, denn er gehört primär nicht zum mLAG und benötigt keine solche ID. Ist ein klassisches Standard Bonding Interface. (Siehe auch hier.) Er sollte immer in ein dediziertes Management VLAN gelegt werden was von produktiven VLANs strikt getrennt ist.Und ja, eine Bridge reicht. Warum sollte man denn auch überhaupt mehrere benötigen ? In einem VLAN Design mit Filtering wäre das auch völlig überflüssig.
Ich verwende das originale QSFP+ DAC zwischen den beiden Mikrotik CRS326:
https://www.varia-store.com/de/produkt/100842-q-da0001-40-gbps-direct-at ...
Aber ich glaube ich sehe das Problem: Nur die qsfpplus1-1 und qsfpplus2-1 sind aktiv und die anderen (qsfpplus1-2,qsfpplus1-3, usw.) sind es nicht. Ich gehe davon aus, das dies nur Platzhalter sind. Über die geht im LACP-Bond einfach Null Traffic... somit kann ich mir das sparen.
Meine Switch-Config sieht auf beiden jetzt so aus:
Ich würde das mlag-bond auflösen und entsprechend nur jeweils das erste Interface der Qsfp verwenden. Das ist erstmal die Grundlage, danach folgen jetzt drei weitere VLANs.
Aber in diesem Setup habe ich noch ein kleines Problem: Ich habe das Management auf Port ether1 gelegt, bei beiden (Adressen sw0 10.10.10.1/24 und sw1 10.10.10.2/24). Nun aber kann ich jeweils wenn der primäre Switch im Mlag eingesteckt ist, das Management Interface des sw1 nicht mehr erreichen. Wie kann man das am besten umsetzen?
https://www.varia-store.com/de/produkt/100842-q-da0001-40-gbps-direct-at ...
Aber ich glaube ich sehe das Problem: Nur die qsfpplus1-1 und qsfpplus2-1 sind aktiv und die anderen (qsfpplus1-2,qsfpplus1-3, usw.) sind es nicht. Ich gehe davon aus, das dies nur Platzhalter sind. Über die geht im LACP-Bond einfach Null Traffic... somit kann ich mir das sparen.
Meine Switch-Config sieht auf beiden jetzt so aus:
/interface bridge
add name=bridge vlan-filtering=yes
/interface bonding
add mode=802.3ad name=mlag-bond slaves=\
qsfpplus2-1,qsfpplus2-2,qsfpplus2-3,qsfpplus2-4
add mlag-id=10 mode=802.3ad name=pve0-bond slaves=sfp-sfpplus2
add mlag-id=11 mode=802.3ad name=pve1-bond slaves=sfp-sfpplus4
add mlag-id=12 mode=802.3ad name=pve2-bond slaves=sfp-sfpplus6
/interface bridge mlag
set bridge=bridge peer-port=mlag-bond
/interface bridge port
add bridge=bridge interface=pve0-bond
add bridge=bridge interface=pve1-bond
add bridge=bridge interface=pve2-bond
add bridge=bridge interface=mlag-bond pvid=999
add bridge=bridge interface=ether1
/interface bridge vlan
add bridge=bridge tagged=mlag-bond vlan-ids=1
/ip address
add address=10.10.10.2/24 interface=bridge network=10.10.10.0
/system identity
set name=sw1Ich würde das mlag-bond auflösen und entsprechend nur jeweils das erste Interface der Qsfp verwenden. Das ist erstmal die Grundlage, danach folgen jetzt drei weitere VLANs.
Aber in diesem Setup habe ich noch ein kleines Problem: Ich habe das Management auf Port ether1 gelegt, bei beiden (Adressen sw0 10.10.10.1/24 und sw1 10.10.10.2/24). Nun aber kann ich jeweils wenn der primäre Switch im Mlag eingesteckt ist, das Management Interface des sw1 nicht mehr erreichen. Wie kann man das am besten umsetzen?
Ich verwende das originale QSFP+ DAC zwischen den beiden Mikrotik CRS326:
Das kann eigentlich nicht sein....Eine Standard QSFP Optik ist immer eine fat pipe also einmal 40 GiG wie man es auch von 1G oder 10 G kennt.
Wenn sich dein QSFP Port in 4mal 10G Interfaces splittet beim Nutzen dieser Optik hast du definitiv eine falsche Optik beschafft, nämlich eine sog. Breakout Optik mit MTP Stecker.
https://www.youtube.com/watch?v=WtbubSPLeyQ
Wenn du einen reinen 40G Link willst ist das die falsche Optik, denn dann ist es immer besser eine BiDi Optik zu verwenden mit normalem LC Stecker wie auch bei SFP+ aber keine Breakout Optik.
Der Vorteil ist klar, denn bei SR4 erhälst du immer 4 mal 10G Subinterfaces die man dann in einen LAG zusammenführen muss was dann wieder eine sehr unökonomische Auslastung bedeutet da man wieder ein Hashing basiertes Balancing machen muss und so niemals homogen die 40G nutzen kann. In der Beziehung sind Breakout Optiken wie die SR4 mit Splitting immer eine schlechte Wahl bei 40G.
DAC/Twinax Kabel und auch AOC Kabel kommen ja auch als reine 40G Links ohne irgendwelches Splitting auf 4 Interfaces:
https://www.fs.com/de/products/74636.html?attribute=1393&id=182157
https://www.fs.com/de/products/74586.html?attribute=1691&id=196847
Möglich also das du da generell die falschen Optiken beschafft hast ?!
Es geht natürlich mit SR4 Splitting ist aber eine sehr unökonomische Art die 40G QSFP Ports zu nutzen.
Ich habe das Management auf Port ether1 gelegt,
Das ist auch ziemlich unübliche, denn in einem VLAN Setup legt man das auch nicht auf ein Interface vonden auf ein VLAN IP Interface im Management VLAN !Da solltest du also ggf. nichmal dein Basisdesign überdenken !
Wie bereits geschrieben: Ich verwende das originale Kabel. Bei Mikrotik hat es die Produktnummer "Q+DA0001". Während das Breakout-Kabel, wie du es meinst, bei Mikrotik die Produktnummer "Q+BC0003-S+" hat. Ich kann da gerne ein Bild von machen, wenn es nicht geglaubt wird.
Ich kann es mir nur so erklären: Für den Fall das ein Breakout-Kabel verwendet wird, hat man da Platzhalter im OS vorgesehen. Die lassen sich auch nicht aktivieren und bleiben inaktiv.
VLANs kommen noch, ich wollte grundlegend erstmal ein flaches Subnetz um die reine MLAG-Funktion zu testen. Einfach aus dem Grund, das selbst Mikrotik sagt, das es trotz stable RouterOS nicht zu 100% nach Standard implementiert wurde.
Ich kann es mir nur so erklären: Für den Fall das ein Breakout-Kabel verwendet wird, hat man da Platzhalter im OS vorgesehen. Die lassen sich auch nicht aktivieren und bleiben inaktiv.
VLANs kommen noch, ich wollte grundlegend erstmal ein flaches Subnetz um die reine MLAG-Funktion zu testen. Einfach aus dem Grund, das selbst Mikrotik sagt, das es trotz stable RouterOS nicht zu 100% nach Standard implementiert wurde.
Ich habe es mittlerweile hinbekommen und das Setup läuft. Bisher nur das Management VLAN aktiv.
Was mir aber derzeit etwas komisch vorkommt, aber vielleicht gibt es dafür eine Erklärung:
Beim Testen des Durchsatzes mit Iperf3 kommt es zu übermäßig vielen Retransmissions...
Das ist doch nicht normal, oder?
/interface bridge
add igmp-snooping=yes name=bridge priority=0x2000 vlan-filtering=yes
/interface vlan
add interface=bridge name=Management-VLAN10 vlan-id=10
/interface bonding
add mode=802.3ad name=mlag-bond slaves=qsfpplus2-1,qsfpplus1-1
add mlag-id=10 mode=802.3ad name=pve0-bond slaves=sfp-sfpplus2
add mlag-id=11 mode=802.3ad name=pve1-bond slaves=sfp-sfpplus4
add mlag-id=12 mode=802.3ad name=pve2-bond slaves=sfp-sfpplus6
add mlag-id=13 mode=802.3ad name=ro0-bond slaves=sfp-sfpplus22
add mlag-id=14 mode=802.3ad name=ro1-bond slaves=sfp-sfpplus21
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
/interface bridge mlag
set bridge=bridge peer-port=mlag-bond
/interface bridge port
add bridge=bridge interface=mlag-bond pvid=999
add bridge=bridge interface=pve0-bond
add bridge=bridge interface=pve1-bond
add bridge=bridge interface=pve2-bond
add bridge=bridge interface=ether1
add bridge=bridge interface=ro0-bond
add bridge=bridge interface=ro1-bond
/interface bridge vlan
add bridge=bridge tagged=mlag-bond vlan-ids=1
add bridge=bridge tagged="mlag-bond,bridge,Management-VLAN10,pve2-bond,pve1-bo\
nd,pve0-bond,ro0-bond,ro1-bond" vlan-ids=10
/ip address
add address=10.10.10.1/28 interface=Management-VLAN10 network=10.255.255.0Was mir aber derzeit etwas komisch vorkommt, aber vielleicht gibt es dafür eine Erklärung:
Beim Testen des Durchsatzes mit Iperf3 kommt es zu übermäßig vielen Retransmissions...
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 1.10 GBytes 9.42 Gbits/sec 8 1.20 MBytes
[ 5] 1.00-2.00 sec 1.09 GBytes 9.38 Gbits/sec 18 1.09 MBytes
[ 5] 2.00-3.00 sec 1.09 GBytes 9.39 Gbits/sec 8 1.01 MBytes
[ 5] 3.00-4.00 sec 1.09 GBytes 9.35 Gbits/sec 34 672 KBytes
[ 5] 4.00-5.00 sec 1.09 GBytes 9.40 Gbits/sec 42 953 KBytes
[ 5] 5.00-6.00 sec 1.09 GBytes 9.38 Gbits/sec 23 864 KBytes
[ 5] 6.00-7.00 sec 1.09 GBytes 9.40 Gbits/sec 9 1.24 MBytes
[ 5] 7.00-8.00 sec 1.09 GBytes 9.38 Gbits/sec 17 1.10 MBytes
[ 5] 8.00-9.00 sec 1.09 GBytes 9.37 Gbits/sec 9 863 KBytes
[ 5] 9.00-10.00 sec 1.09 GBytes 9.40 Gbits/sec 27 962 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 10.9 GBytes 9.39 Gbits/sec 195 sender
[ 5] 0.00-10.00 sec 10.9 GBytes 9.39 Gbits/sec receiverDas ist doch nicht normal, oder?
Na ja 200 Retrans bei 10 Gb/s das ist absolut tolerabel. Da musst du dir keine Sorgen machen !
Hallo,
ich klink mir hier mal ein mit einem fast gleichen Setup mit 2 CRS326 mit SFP und QSFP+.
Im Mikrotik bereich bin ich noch ein Neuling,
daher fang ich mal von grund auf am mit meiner Config:
2 CRS326, mit original Mikrotik DAC 40G Kabel verbunden.
Über die beiden 40G Ports sollen die beiden Switch verbunden werden.
Firmwareversion beider Switch ist 7.8 (aktuellste Version).
Nach dem Updaten kompletter reset ohne Config.
Die Switch sollen nur L2 machen, kein Routing.
Im Momen noch keine LAG Devices angeschlossen.
Anschließend die Basis Switch Configuration:
Anschließend eine IP auf die bridge1 gebunden.
Das gleiche mit dem zweiten Switch.
Anschließend bin ich wie folgt vorgegangen:
Anschließend den Test gestartet, ob die die Kommunikation über die beiden Switch mit den SFP+ Ports klappt-
leider nicht. Meine vermutung war daher, ob es ev. an den Bridges liegt.
Zum testen hab ich einfach auf jeden Switch einen Port von der bridge1 zur MLAG bridge hinzugefügt,
aber es hat auch nicht funktioniert.
ich klink mir hier mal ein mit einem fast gleichen Setup mit 2 CRS326 mit SFP und QSFP+.
Im Mikrotik bereich bin ich noch ein Neuling,
daher fang ich mal von grund auf am mit meiner Config:
2 CRS326, mit original Mikrotik DAC 40G Kabel verbunden.
Über die beiden 40G Ports sollen die beiden Switch verbunden werden.
Firmwareversion beider Switch ist 7.8 (aktuellste Version).
Nach dem Updaten kompletter reset ohne Config.
Die Switch sollen nur L2 machen, kein Routing.
Im Momen noch keine LAG Devices angeschlossen.
Anschließend die Basis Switch Configuration:
/interface bridge
add name=bridge1 vlan-filtering=yes
/interface bridge port
add bridge=bridge1 interface=sfp-sfpplus1 hw=yes
#Hier hab ich alle sfp-plus1 bis 24 Ports hinzugefügt.-Meine Frage: Ich nehm an, dass man die Peer Ports
auch auf der gleichen Bridge haben muss, wie die regulären Ports, oder? Gibts einen Befehl,
mit diesen man gleich Port 1-24 hinzufügen kann, zb sfp-sfpplus1-24 ? Anschließend eine IP auf die bridge1 gebunden.
Das gleiche mit dem zweiten Switch.
Anschließend bin ich wie folgt vorgegangen:
/interface bonding
add mode=802.3ad name=mlag-bond slaves=qsfpplus2-1,qsfpplus1-1
#Da ich beide QSFP Ports verwenden möchte für MLAG, einen Bond erstellt
/interface bridge
add name=MLAG vlan-filtering=yes
#Eigene Bridge für MLAG erstellt
/interface bridge port
add bridge=MLAG interface=mlag-bond pvid=4000
#mlag-Bond hinzugefügt
/interface bridge vlan
add bridge=MLAG tagged=mlag-bond vlan-ids=1
#Default VLAN 1 taggen, da untagged VLAN4000
/interface bridge mlag
/interface/bridge/mlag> set bridge=MLAG peer-port=mlag-bond
#Bond als Peer Port definierenAnschließend den Test gestartet, ob die die Kommunikation über die beiden Switch mit den SFP+ Ports klappt-
leider nicht. Meine vermutung war daher, ob es ev. an den Bridges liegt.
Zum testen hab ich einfach auf jeden Switch einen Port von der bridge1 zur MLAG bridge hinzugefügt,
aber es hat auch nicht funktioniert.
Auf keinen Fall mehrere Bridges erstellen! Es wird eine Bridge erstellt und mehr nicht, sonst läuft der Traffic nicht über die Switch-Hardware, sondern alles über die mikrige CPU. Die schafft dann natürlich auch den Durchsatz nicht.
Danke, das mit der Bridge war tatsächlich der Fehler, danke
Andere Frage noch:
Per Winbox finde ich den 2ten Switch nicht mehr, wenn ich ihn versuche über den MLAG Bond zu erreichen.
Aber er ist pinbar und per Webinterface erreichbar.
Andere Frage noch:
Per Winbox finde ich den 2ten Switch nicht mehr, wenn ich ihn versuche über den MLAG Bond zu erreichen.
Aber er ist pinbar und per Webinterface erreichbar.
Zitat von @fritzkarl85:
Danke, das mit der Bridge war tatsächlich der Fehler, danke
Andere Frage noch:
Per Winbox finde ich den 2ten Switch nicht mehr, wenn ich ihn versuche über den MLAG Bond zu erreichen.
Aber er ist pinbar und per Webinterface erreichbar.
UnterDanke, das mit der Bridge war tatsächlich der Fehler, danke
Andere Frage noch:
Per Winbox finde ich den 2ten Switch nicht mehr, wenn ich ihn versuche über den MLAG Bond zu erreichen.
Aber er ist pinbar und per Webinterface erreichbar.
/tool macserver/ip neighbor discovery-settingsDas alles braucht man natürlich nur wenn man kein Management-Interface eingerichtet hat über den man das Device per IP erreichen kann. Die Erkennung der Devices in Winbox läuft aber primär über den mac-server auf Layer-2 und das Neighbor-Discovery.
Wenn eine Firewall aktiv ist muss man hier natürlich auch eine Freigabe der Winbox-Ports tätigen (8291/tcp).
Cheers birggs.
Anschließend eine IP auf die bridge1 gebunden.
Leider falsch und im VLAN Setup bei dir (LAN Filtering aktiv!) kontraproduktiv und wird dazu führen das dein Setup nicht rennt, zumindestens aber große Probleme mit IP bekommt.In einem VLAN Umfeld kommt niemals eine IP Adresse auf das bridge Interface!!
Das hiesige Mikrotik VLAN Tutorial weisst explizit und in rot extra auf diesen Punkt hin!!
Ich nehm an, dass man die Peer Ports auch auf der gleichen Bridge haben muss, wie die regulären Ports
Ja! Denn im reinen Layer 2 VLAN Betrieb sind doch alle Ports gleichberechtigt, egal ob Kupfer oder SFP! Kollege @Fenris14 hat es schon gesagt.Die genaue Bonding / LAG Konfig findes man u.a. auch im LAG Tutorial.
Hallo
aqui - wieder mal danke für deinen Input.
Die IP hab ich nun aufs VLAN Interface gebunden wie im Tutorial beschrieben.
Zusätzlich noch den Fehler korrigiert und die Bridge Tagged in alle VLANs gesetzt.
Hab jetzt aber noch immer mit Problemen zu kämpfen, dass der Ping zu den beiden Aruba Switchen immer wieder mal abbricht - geht 10s - ist für 4 wieder weg, usw.
Hier mal meine jetztige konfig auf beiden Switchs (bis auf die IP).
.
Hat noch jemand einen Tipp für mich?
aqui - wieder mal danke für deinen Input.
Die IP hab ich nun aufs VLAN Interface gebunden wie im Tutorial beschrieben.
Zusätzlich noch den Fehler korrigiert und die Bridge Tagged in alle VLANs gesetzt.
Hab jetzt aber noch immer mit Problemen zu kämpfen, dass der Ping zu den beiden Aruba Switchen immer wieder mal abbricht - geht 10s - ist für 4 wieder weg, usw.
Hier mal meine jetztige konfig auf beiden Switchs (bis auf die IP).
/interface bridge
add igmp-snooping=yes name=MLAG vlan-filtering=no
/interface bridge port
add bridge=MLAG interface=sfp-sfpplus1 hw=yes
add bridge=MLAG interface=sfp-sfpplus2 hw=yes
add bridge=MLAG interface=sfp-sfpplus3 hw=yes
add bridge=MLAG interface=sfp-sfpplus4 hw=yes
add bridge=MLAG interface=sfp-sfpplus5 hw=yes
add bridge=MLAG interface=sfp-sfpplus6 hw=yes
add bridge=MLAG interface=sfp-sfpplus7 hw=yes
add bridge=MLAG interface=sfp-sfpplus8 hw=yes
add bridge=MLAG interface=sfp-sfpplus9 hw=yes
add bridge=MLAG interface=sfp-sfpplus10 hw=yes
add bridge=MLAG interface=sfp-sfpplus11 hw=yes
add bridge=MLAG interface=sfp-sfpplus12 hw=yes
add bridge=MLAG interface=sfp-sfpplus13 hw=yes
add bridge=MLAG interface=sfp-sfpplus14 hw=yes
add bridge=MLAG interface=sfp-sfpplus15 hw=yes
add bridge=MLAG interface=sfp-sfpplus16 hw=yes
add bridge=MLAG interface=sfp-sfpplus17 hw=yes
add bridge=MLAG interface=sfp-sfpplus18 hw=yes
add bridge=MLAG interface=sfp-sfpplus19 hw=yes
add bridge=MLAG interface=sfp-sfpplus20 hw=yes
add bridge=MLAG interface=sfp-sfpplus21 hw=yes
add bridge=MLAG interface=sfp-sfpplus22 hw=yes
add bridge=MLAG interface=sfp-sfpplus23 hw=yes
add bridge=MLAG interface=sfp-sfpplus24 hw=yes
add bridge=MLAG interface=ether1 hw=yes
#Hier hab ich alle sfp-plus1 bis 24 Ports hinzugefügt.-Meine Frage: Ich nehm an, dass man die Peer Ports
#auch auf der gleichen Bridge haben muss, wie die regulären Ports, oder? Gibts einen Befehl,
#mit diesen man gleich Port 1-24 hinzufügen kann, zb sfp-sfpplus1-24 ?
/interface vlan
add interface=MLAG name=DEFAULT vlan-id=1
add interface=MLAG name=VLAN10 vlan-id=10
add interface=MLAG name=VLAN30 vlan-id=30
add interface=MLAG name=VLAN40 vlan-id=40
/interface bonding
add mode=802.3ad name=mlag-bond slaves=qsfpplus2-1,qsfpplus1-1
#Da ich beide QSFP Ports verwenden möchte für MLAG, einen Bond erstellt
/interface bridge port
add bridge=MLAG interface=mlag-bond pvid=4000
#mlag-Bond hinzugefügt
/interface bridge vlan
add bridge=MLAG tagged=mlag-bond vlan-ids=1
#Default VLAN 1 taggen, da untagged VLAN4000
/interface bridge mlag
set bridge=MLAG peer-port=mlag-bond
#Bond als Peer Port definieren
/interface bridge port
print
remove numbers=0,1,2
#Interfaces von der bridge fürs Bonding entfernen
/interface bonding
add mlag-id=10 mode=802.3ad name=bond-esx101 slaves=sfp-sfpplus1
add mlag-id=20 mode=802.3ad name=bond-esx102 slaves=sfp-sfpplus2
add mlag-id=30 mode=802.3ad name=bond-esx103 slaves=sfp-sfpplus3
#Bonds für die Devices erstellen - fortlaufende ID für jedes Bonding
/interface bridge port
add bridge=MLAG interface=bond-esx101
add bridge=MLAG interface=bond-esx102
add bridge=MLAG interface=bond-esx103
#Bonds zur bridge hinzufügen
/interface bridge vlan
set
add bridge=MLAG tagged=MLAG vlan-ids=1
add bridge=MLAG tagged=MLAG,mlag-bond,bond-esx101,bond-esx102,bond-esx103 vlan-ids=10
add bridge=MLAG tagged=MLAG,mlag-bond,bond-esx101,bond-esx102,bond-esx103 vlan-ids=30
add bridge=MLAG tagged=MLAG,mlag-bond,bond-esx101,bond-esx102,bond-esx103 vlan-ids=40
#VLANs hinzufügen- und auf bridge und Interfaces taggen
/ip address
add address=10.1.1.91/24 interface=DEFAULT
/interface bridge
set MLAG vlan-filtering=yesHat noch jemand einen Tipp für mich?
Wieso heisst deine Bridge "MLAG"? Das ist ja ein recht verwirrender Name. Sinnvoller wäre ja eher sowas wie "vlan-bridge". Die VLAN Bridge hat ja gar nichts mit einem MLAG oder LAG zu tun. Zumal du ja auch die Interface verwirrenderweise auch noch MLAG genannt hast?
Die Konfig oben ist sehr verwirrend und unklar und damit für ein zielführendes Troubleshooting mehr oder minder unbrauchbar.
Da ist vermutlich sehr viel im Argen in deiner MT Konfig. ☹️
Bevor man ins Eingemachte geht mit dem Troubleshooting wäre es sehr sinnvoll einmal...
Sehr wahrscheinlich wäre ein separater Troubleshooting Thread inkl. Doku für dein Setup für eine zielführende Hilfe sinnvoller.
Die Konfig oben ist sehr verwirrend und unklar und damit für ein zielführendes Troubleshooting mehr oder minder unbrauchbar.
- Mal wird der Bonding Port hinzugefügt, dann fehlt er aber in der Übersichtsliste, dann wird er wieder entfernt.
- Die IP Adresse endet auf einem nicht existenten Interface "Default" im Nirwana.
- Unklar ist ob du wirklich einen MLAG nutzt, also einen gesplitteten LAG was dann auch die Gegenstelle supporten muss oder ob es nicht ein ganz normaler Standard LACP LAG ist. Laut deiner Aussage oben nutzt du einen normalen LAG und keinen MLAG!! 🤔
Da ist vermutlich sehr viel im Argen in deiner MT Konfig. ☹️
Bevor man ins Eingemachte geht mit dem Troubleshooting wäre es sehr sinnvoll einmal...
- Über die Eröffnung eines neuen Threads mit hiesigem Verweis auf die URL nachzudenken anstatt diesen Thread hier zu "kapern"...
- die Netz Topologie zu verstehen. Eine kl. Skizze wäre hier hilfreich
- anhand der Topologie zu klären ob du wirklich MLAG (gesplittete LAGs) oder ganz normale Standard LACP LAGs verwendest. (Siehe dazu auch HIER)
- zu klären ob VLANs vorhanden sind und ob der MT routet (L3) oder nur im L2 Mode (Switching) arbeitet
- Ob die Arubas Spanning Tree mit Single Span machen und am LAG Trunk PVID 1 nutzen
- Das ganze aktuelle LAG Setup final einmal in einem CLI, WinBox oder GUI Screenshot zu sehen
Sehr wahrscheinlich wäre ein separater Troubleshooting Thread inkl. Doku für dein Setup für eine zielführende Hilfe sinnvoller.
Mittlerweile scheint es so, das ich das Problem gefunden habe.
Mit deaktivierten HW Offloading funktioniert es jetzt seit 20min problemlos.
Mal wird der Bonding Port hinzugefügt, dann fehlt er aber in der Übersichtsliste, dann wird er wieder entfernt.
->Welcher Bonding Port? Geht es um die sfp-sfpplus1 bis 3? - macht im Nachhinein betrachtet vermutlich nicht viel Sinn, diese überhaupt hinzuzufügen - da gebe ich dir recht. Mir gehts da aber darum zuerst die komplette Bridge zu erstellen und anschließen die Ports rauszunehmen, die man für die Bondings braucht.
Die IP Adresse endet auf einem nicht existenten Interface "Default" im Nirwana.
->Steht eigentlich in der Config - Default ist das Standard VLAN1 Interface
Unklar ist ob du wirklich einen MLAG nutzt, also einen gesplitteten LAG was dann auch die Gegenstelle supporten muss oder ob es nicht ein ganz normaler Standard LACP LAG ist. Laut deiner Aussage oben nutzt du einen normalen LAG und keinen MLAG!! 🤔
-> Lt. welcher Aussage? Da kann ich dir nicht ganz folgen. Es soll auf jeden Fall MLAG genutzt werden.
die Netz Topologie zu verstehen. Eine kl. Skizze wäre hier hilfreich
-> Skizze ist gut, die folgt
anhand der Topologie zu klären ob du wirklich MLAG (gesplittete LAGs) oder ganz normale Standard LACP LAGs verwendest.
->siehe Skizze - 2 Mikrotik im Core, 2 Aruba mal zum testen als Access
zu klären ob VLANs vorhanden sind und ob der MT routet (L3) oder nur im L2 Mode (Switching) arbeitet
-> MT macht wie weiter oben beschrieben nur L2, kein Routing. VLAN sind vorhanden (1,10,20,30, siehe config)
Ob die Arubas Spanning Tree mit Single Span machen und am LAG Trunk PVID 1 nutzen
->STP deaktiviert auf den Aruba Switchs
Das ganze aktuelle LAG Setup final einmal in einem CLI, WinBox oder GUI Screenshot zu sehen
Mit deaktivierten HW Offloading funktioniert es jetzt seit 20min problemlos.
Mal wird der Bonding Port hinzugefügt, dann fehlt er aber in der Übersichtsliste, dann wird er wieder entfernt.
->Welcher Bonding Port? Geht es um die sfp-sfpplus1 bis 3? - macht im Nachhinein betrachtet vermutlich nicht viel Sinn, diese überhaupt hinzuzufügen - da gebe ich dir recht. Mir gehts da aber darum zuerst die komplette Bridge zu erstellen und anschließen die Ports rauszunehmen, die man für die Bondings braucht.
Die IP Adresse endet auf einem nicht existenten Interface "Default" im Nirwana.
->Steht eigentlich in der Config - Default ist das Standard VLAN1 Interface
Unklar ist ob du wirklich einen MLAG nutzt, also einen gesplitteten LAG was dann auch die Gegenstelle supporten muss oder ob es nicht ein ganz normaler Standard LACP LAG ist. Laut deiner Aussage oben nutzt du einen normalen LAG und keinen MLAG!! 🤔
-> Lt. welcher Aussage? Da kann ich dir nicht ganz folgen. Es soll auf jeden Fall MLAG genutzt werden.
die Netz Topologie zu verstehen. Eine kl. Skizze wäre hier hilfreich
-> Skizze ist gut, die folgt
anhand der Topologie zu klären ob du wirklich MLAG (gesplittete LAGs) oder ganz normale Standard LACP LAGs verwendest.
->siehe Skizze - 2 Mikrotik im Core, 2 Aruba mal zum testen als Access
zu klären ob VLANs vorhanden sind und ob der MT routet (L3) oder nur im L2 Mode (Switching) arbeitet
-> MT macht wie weiter oben beschrieben nur L2, kein Routing. VLAN sind vorhanden (1,10,20,30, siehe config)
Ob die Arubas Spanning Tree mit Single Span machen und am LAG Trunk PVID 1 nutzen
->STP deaktiviert auf den Aruba Switchs
Das ganze aktuelle LAG Setup final einmal in einem CLI, WinBox oder GUI Screenshot zu sehen
Ahh, ok, die Skizze ist sehr hilfreich. 👍
Gut, du hast dann in der Tat je einen MLAG der beiden MTs auf den Aruba. Aber auch einen Standard LACP LAG nämlich vermutlich den über die beiden QSFP Ports die die MTs verbinden, richtig?
Da fehlt dann noch der LAG "Kringel" in der Zeichnung.
Dieser Bonding Port der QSFPs muss dann natürlich auch Memberport der (VLAN) Bridge sein!
Das gilt auch für die MLAG Ports wie du hier im Mikrotik Beispiel Setup deutlich sehen kannst:
https://help.mikrotik.com/docs/display/ROS/Multi-chassis+Link+Aggregatio ...
Die Memberports der LAGs, egal ob Standard LAG über die QSFPs oder einzelnen Memberports des MLAG dürfen selber nicht Memberports der Bridge!!
Die beiden MTs sind dann vermutlich die Core Switches die dann wie beschrieben nur L2 machen mit 4 VLANs.
Gut, die einzige IP Adresse sollte dann auf das VLAN Interface gebunden sein welches Im Management VLAN liegt, das fehlt übrigens auch oben im Setup. Es gibt dann logischerweise auch nur ein einziges VLAN IP Interface nämlich das was die Management Connection auf dem MT realisiert.
Die Frage ist warum du RSTP Spanning Tree abgedreht hast. Das ist keine gute Idee in einem MLAG Design und besonders nicht wenn du es einseitig nur auf den Arubas gemacht hast und nicht auch auf den MTs. Dadurch müssen die Arubas diese BPDU Pakete fluten.
Normal im Default machen die MTs Single Span mit RSTP und die STP Priority steht im Default auf hex 0x8000 sprich dezimal 32768 der Default Priority.
Hier ist es für ein sauberes RSTP Design zwingend erforderlich, das du die MTs als Root und Backup Root Switch setzt.
Sprich der eine bekommt als STP Priority in der VLAN Bridge 0x2000 (8192) gesetzt und der andere 0x4000 (16384). (STP Bridge Priorities sind immer Vielfache von 4096!)
Damit hast du dann eine saubere STP Hierarchie in dem Setup und du solltest unbedingt STP im RSTP Mode mit der Default Priority auf den Arubas wieder aktivieren.
Damit ist sichergestellt das es bei einem temporären MLAG Split nicht zu einem Loop im Netz kommt. Ein wichtiger Grund einen sauberen Spanning Tree über alle Switches zu haben.
Ggf. nochmal eine vollständiges export eines der MTs sofern wir die Konfig nochmal checken sollen.
Gut, du hast dann in der Tat je einen MLAG der beiden MTs auf den Aruba. Aber auch einen Standard LACP LAG nämlich vermutlich den über die beiden QSFP Ports die die MTs verbinden, richtig?
Da fehlt dann noch der LAG "Kringel" in der Zeichnung.
Dieser Bonding Port der QSFPs muss dann natürlich auch Memberport der (VLAN) Bridge sein!
Das gilt auch für die MLAG Ports wie du hier im Mikrotik Beispiel Setup deutlich sehen kannst:
https://help.mikrotik.com/docs/display/ROS/Multi-chassis+Link+Aggregatio ...
Die Memberports der LAGs, egal ob Standard LAG über die QSFPs oder einzelnen Memberports des MLAG dürfen selber nicht Memberports der Bridge!!
Die beiden MTs sind dann vermutlich die Core Switches die dann wie beschrieben nur L2 machen mit 4 VLANs.
Gut, die einzige IP Adresse sollte dann auf das VLAN Interface gebunden sein welches Im Management VLAN liegt, das fehlt übrigens auch oben im Setup. Es gibt dann logischerweise auch nur ein einziges VLAN IP Interface nämlich das was die Management Connection auf dem MT realisiert.
Die Frage ist warum du RSTP Spanning Tree abgedreht hast. Das ist keine gute Idee in einem MLAG Design und besonders nicht wenn du es einseitig nur auf den Arubas gemacht hast und nicht auch auf den MTs. Dadurch müssen die Arubas diese BPDU Pakete fluten.
Normal im Default machen die MTs Single Span mit RSTP und die STP Priority steht im Default auf hex 0x8000 sprich dezimal 32768 der Default Priority.
Hier ist es für ein sauberes RSTP Design zwingend erforderlich, das du die MTs als Root und Backup Root Switch setzt.
Sprich der eine bekommt als STP Priority in der VLAN Bridge 0x2000 (8192) gesetzt und der andere 0x4000 (16384). (STP Bridge Priorities sind immer Vielfache von 4096!)
Damit hast du dann eine saubere STP Hierarchie in dem Setup und du solltest unbedingt STP im RSTP Mode mit der Default Priority auf den Arubas wieder aktivieren.
Damit ist sichergestellt das es bei einem temporären MLAG Split nicht zu einem Loop im Netz kommt. Ein wichtiger Grund einen sauberen Spanning Tree über alle Switches zu haben.
Ggf. nochmal eine vollständiges export eines der MTs sofern wir die Konfig nochmal checken sollen.
