MikroTik CRS326-24G vlan1 - tagged zu CSS610-8G
Hallo in die Runde,
ich habe ein Verständnisproblem. Kurzer Umriss meines Netzwerkaufbaus.
KabelInternet->Fritzbox->CRS326-24G-2S+ Internet am CRS326 über Port 1 (nicht in der Bridge)
Der CRS326 kümmert sich um 3 vlan´s (10;20;30)
Die Config habe ich nach der sehr guten Anleitung von @aqui durchgeführt.
Standart Vlan ist 1 (Evtl. kommt noch ein Management Vlan).
Am CRS326 hängt dann noch an Port 6 ein RBD53iG-5HacD2HnD (Vlan 10; 20)
sowie an Port 7 und 8 je ein RBD52G-5HacD2HnD (Vlan 10;20;30)
Zusätzlich an Port 25 des CRS326 über sfp-upling ist dann der CSS610-8G wo dann mehrere PC´s sowie Drucker
und 3D-Drucker und RPi dran hängen. Alles im Vlan 1 (noch soll auf vlan 10).
So und nun mein Verständnisproblem, alles funktioniert - DHCP auf allen Vlan durch den CRS326. Die Wlan AP´s
mit zusätzlichen virtuellen WLan´s im Vlan 20 und 30 - kein Problem.
Das Vlan 1 ist auf der "bridge" des CRS326 - (Tagged "bridge") und auch der sfp-Uplink zum CSS610.
Eigentlich sollte doch der Uplink-Port als "untagged" für vlan1 sein. Bei den RBD´s funktioniert das auch.
Wenn ich nun den sfp-Upling als "tagged" rausnehme, schmeiße ich den CSS610 komplett aus dem Netz.
Ich komme mit einem dort angeschlossenen PC noch auf die Config-Seite des CSS610 aber mehr auch
nicht. Kein Internet und auch kein Kontakt mehr über winbox zum CRS326 im Keller.
Mit einem Laptop an Port2 am CRS326 schalte ich dann den sfp-Uplink wieder "vlan 1 tagged" dann hängt
der CSS610 sofort wieder im Netz.
Der CSS610 ist eigentlich im Standardsetup. Keine Vlan´s weil er keine weiterreichen muss.
Ich hoffe ich habe es einigermaßen verständlich beschrieben, suche schon seit 3 Tagen nach einer Lösung, aber
leider habe ich noch nichts gefunden. Vielleicht muss das auch so und ich habe etwas wesentliches nicht verstanden.
Bitte nicht steinigen, vielleicht habt ihr ja einen entsprechenden Hinweis!
Viele Grüße
Mario
ich habe ein Verständnisproblem. Kurzer Umriss meines Netzwerkaufbaus.
KabelInternet->Fritzbox->CRS326-24G-2S+ Internet am CRS326 über Port 1 (nicht in der Bridge)
Der CRS326 kümmert sich um 3 vlan´s (10;20;30)
Die Config habe ich nach der sehr guten Anleitung von @aqui durchgeführt.
Standart Vlan ist 1 (Evtl. kommt noch ein Management Vlan).
Am CRS326 hängt dann noch an Port 6 ein RBD53iG-5HacD2HnD (Vlan 10; 20)
sowie an Port 7 und 8 je ein RBD52G-5HacD2HnD (Vlan 10;20;30)
Zusätzlich an Port 25 des CRS326 über sfp-upling ist dann der CSS610-8G wo dann mehrere PC´s sowie Drucker
und 3D-Drucker und RPi dran hängen. Alles im Vlan 1 (noch soll auf vlan 10).
So und nun mein Verständnisproblem, alles funktioniert - DHCP auf allen Vlan durch den CRS326. Die Wlan AP´s
mit zusätzlichen virtuellen WLan´s im Vlan 20 und 30 - kein Problem.
Das Vlan 1 ist auf der "bridge" des CRS326 - (Tagged "bridge") und auch der sfp-Uplink zum CSS610.
Eigentlich sollte doch der Uplink-Port als "untagged" für vlan1 sein. Bei den RBD´s funktioniert das auch.
Wenn ich nun den sfp-Upling als "tagged" rausnehme, schmeiße ich den CSS610 komplett aus dem Netz.
Ich komme mit einem dort angeschlossenen PC noch auf die Config-Seite des CSS610 aber mehr auch
nicht. Kein Internet und auch kein Kontakt mehr über winbox zum CRS326 im Keller.
Mit einem Laptop an Port2 am CRS326 schalte ich dann den sfp-Uplink wieder "vlan 1 tagged" dann hängt
der CSS610 sofort wieder im Netz.
Der CSS610 ist eigentlich im Standardsetup. Keine Vlan´s weil er keine weiterreichen muss.
Ich hoffe ich habe es einigermaßen verständlich beschrieben, suche schon seit 3 Tagen nach einer Lösung, aber
leider habe ich noch nichts gefunden. Vielleicht muss das auch so und ich habe etwas wesentliches nicht verstanden.
Bitte nicht steinigen, vielleicht habt ihr ja einen entsprechenden Hinweis!
Viele Grüße
Mario
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 93516589439
Url: https://administrator.de/forum/mikrotik-crs326-24g-vlan1-tagged-zu-css610-8g-93516589439.html
Ausgedruckt am: 25.12.2024 um 02:12 Uhr
13 Kommentare
Neuester Kommentar
Das Vlan 1 ist auf der "bridge" des CRS326 - (Tagged "bridge") und auch der sfp-Uplink zum CSS610.
Das ist sehr wahrscheinlich dein Kardinalsfehler!Das VLAN 1 ist in der Regel bei allen Herstellern das Native VLAN bzw. PVID VLAN was bei tagged Uplinks (man achte auf das "k" ) immer UNtagged übertragen wird!
Das, wie bei dir, fälschlicherweise zu taggen ist also immer kontraproduktiv und erzeugt dann genau dein Fehlerbild. Das o.a. MT Tutorial weisst auch darauf hin.
Eigentlich sollte doch der Uplink-Port als "untagged" für vlan1 sein
Genau so ist es!! Du hast also deinen eigenen Fehler schon selber erkannt! Alles außer 1 tagged und die Port PVID ist auf 1 gesetzt. (Siehe Tutorial)schmeiße ich den CSS610 komplett aus dem Netz.
Nein, vermutlich nur weil du dann am CSS VLAN 1 dann auch fälschlicherweise getagged hast! Wenn du auf einer Seite UNtagged sendest auf der anderen aber tagged empfängst (oder vice versa) kommen diese beiden Enden logischerweise niemals zusammen. Du sägst dir dann quasi deinen eigenen Ast ab was du im Verbindungsverlust dann ja auch siehst. Fazit: Beide Uplink Seiten müssen immer das gleiche Port Setup haben in Bezug aufs Tagging und Port Mode.
Siehe auch VLAN Schnellschulung!
Mit einem Laptop an Port2 am CRS326 schalte ich dann den sfp-Uplink wieder "vlan 1 tagged" dann hängt der CSS610 sofort wieder im Netz.
Was dann auch sofort diesen Verdacht des ungleichen Tagging Setups an den beiden Verbindungsports eindrucksvoll bestätigt!Der CSS610 ist eigentlich im Standardsetup. Keine Vlan´s weil er keine weiterreichen muss.
Dann muss dort der Verbindungsport auf PVID 1 gesetzt sein und Mode: Allow untagged denn es kommt ja von der anderen Seite das VLAN 1 nur untagged.Gut wäre es noch wenn du den CRS (und NUR den CRS) der ja quasi "Core Switch" bei dir ist in der Bridge Priority hochsetzt um sicher Spanning Tree Loops zu vermeiden! Z.B. 0x2000 (8192) statt des 0x8000 (32768) Defaults.
Meine Verwunderung ist bzw. war, dass nur Probleme mit dem vlan1 zum CSS610 bestanden.
Das kommt ab und zu einmal vor wenn man das VLAN 1 nicht korrekt einrichtet!Die Problematik ist das es im Default da ist aber man es in einem VLAN Umfeld in der VLAN Bridge immer statisch einrichten muss und zwar BEVOR man das VLAN Filtering aktiviert!
Andernfalls ist es ausgegraut und funktioniert im VLAN Umfeld nicht mehr. (Siehe Tutorial Hinweis im VLAN Setup der Bridge!
Immer wenn ich die "bridge" so eingestellt habe, wie Du es hier und in Deinem Tutorial schreibst, war der Uplink tot.
Vielleicht machst du hier einen grundsätzlichen Denkfehler?!Wenn es stimmt und du wie du selber sagst keine VLANs auf dem CSS hast sondern der nur als einfacher, flacher L2 Switch agiert muss dort auch KEIN VLAN Setup vorgenommen werden.
Abgesehen davon ist der CSS ein SwitchOS only Switch!! Dort gibt es keine solche Konfig wie die des CRS mit RouterOS. SwitchOS ist immer Layer 2 only. Vergiss das nicht!
Den CSS Port steckt man dann am CRS in einen ebenso konfigurierten untagged VLAN Accessport mit der entsprechenden PVID des VLANs was der CSS bedienen soll und fertisch.
Wie gesagt: Der CSS ein SwitchOS Switch ist und kein Router OS Switch!!
Die Konfig dort sieht also deutlich anders aus! Sehr wahrscheinlich machst du hier dann etwas grundsätzlich falsch mit dessen Trunk Port Konfiguration?! Ein Screenshot des Setups wäre für alle Helfenden hier sicher sehr hilfreich.
aber ich komme nicht mehr auf die GUI
Bedenke das der CSS wenn er keinen DHCP Server "sieht" der ihm im Default VLAN eine IP verpasst er dann als Fallback die .88.1 IP verwendet.Wenn du nun z.B. mit einem Client der eine ganz andere IP in dem Netz hat versuchst darauf zuzugreifen scheitert das weil die Netzwerk IP nicht stimmt.
Es gibt dann 2 Optionen:
- PC temporär eine statische .88.x IP geben und auf den CSS zugreifen
- Vorher sicherstellen das der CSS in einem Netzwerk mit DHCP Server ist um sich eine zum Netz passende IP zu ziehen. Welche das ist sieht man dann in den "Leases".
Aber auch hier kein Erfolg
Meinst du nicht es würde vielleicht Sinn machen einmal den Screenshot deines Setups von beiden Seiten zu posten?!Dann können wir dir auch sofort sagen wo du den Fehler gemacht hast, denn das es klappt ja (sofern alle Komponenten nicht defekt sind) steht natürlich außer Frage....
Wäre ja nochmal interessant zu erfahren WO du deinen Fehler gemacht hast damit andere davon lernen können?! 🤔 Der tiefere Sinn eines Forums...
Das alleinige, durchgängige Aktivieren des Spanning Trees kann es nicht sein. Wenn es nur mit Spanning Tree klappt ist das ein Indiz das du ein Loop im Netzwerk hast.
Das alleinige, durchgängige Aktivieren des Spanning Trees kann es nicht sein. Wenn es nur mit Spanning Tree klappt ist das ein Indiz das du ein Loop im Netzwerk hast.
Der Loop kann durch einen VLAN Mismatch an den Bridges bei untagged Ports passieren wenn man da nicht aufpasst. Also z.B. wenn ein untagged Port oder das PVID VLAN eines Trunks auf einer Seite in ein fremdes VLAN auf der anderen Seite gerät. Da man hier nicht alle deine Bridge und Port Konfigs kennt kommt es auf dich an beim Troubleshooting.
Wenn du der Sache dennoch auf den Grund gehen willst, kannst du den RSTP Test erstmal mit dem isolierten Core machen und steckst dann sukzessive einen Uplink Trunk nach dem anderen zu und prüfst ob das Chaos einsetzt oder nicht. Die Komponente bei der es passiert ist dann meist der Buhmann.
Letztendlich sollte man so ein Switch Setup niemals ohne ein durchgehendes Spanning Tree Protokoll betreiben was du ja dann auch richtig umgesetzt hast. Wenn der Core dann durch seine höhere STP Priority auch noch den Root Switch vorgibt ist das bilderbuchmäßig gelöst.
Rennt es damit fehlerlos kannst du es auch damit belassen und freust dich an der Funktion! 😉
Wenn du der Sache dennoch auf den Grund gehen willst, kannst du den RSTP Test erstmal mit dem isolierten Core machen und steckst dann sukzessive einen Uplink Trunk nach dem anderen zu und prüfst ob das Chaos einsetzt oder nicht. Die Komponente bei der es passiert ist dann meist der Buhmann.
Letztendlich sollte man so ein Switch Setup niemals ohne ein durchgehendes Spanning Tree Protokoll betreiben was du ja dann auch richtig umgesetzt hast. Wenn der Core dann durch seine höhere STP Priority auch noch den Root Switch vorgibt ist das bilderbuchmäßig gelöst.
Rennt es damit fehlerlos kannst du es auch damit belassen und freust dich an der Funktion! 😉