11
Mikrotik Switching und Routing Problem
Mikrotik Experten an die Front !
Folgendes Switching Design mit VLAN Routing soll zum Fliegen kommen und bereitet mir an einem Punkt Kopfzerbrechen. Ja ja...das kommt auch mal vor.
Im Grunde ein simples Design bis auf eine winzige Kleinigkeit die nicht funktioniert.
Setup Details...
Der Mikrotik hat 2 VLANs mit der VID 1 und 11 die alle im internen Switch 1 liegen (Ports: sfp1, ether1 bis 5) Der angeschlossene VLAN L2 Switch hat diese VLANs ebenso definiert. Beide Switches sind über einen tagged Link gekoppelt.
Beim MT-2011 ist das der sfp1 Port der auf den Port 24 des L2 Switches geht.
Beide Switches haben je 2 untagged Endgeräteports:
MT-2011: ether-1 = VLAN 1, ether-5 = VLAN 11
L2 Switch: Port 1 = VLAN 1, Port 3 = VLAN 11
In allen Endgeräte Ports stecken IP Geräte mit entsprechend passender IP Adressierung:
192.168.1.0 /24 = VLAN 1
10.1.1.0 /24 = VLAN 11
Alle Geräte können sich innerhalb ihrer VLANs fehlerfrei untereinander pingen. Aus Layer 2 Sicht funktioniert das Design also.
Ziel ist es nun, das der MT-2011 zwischen diesen beiden VLANs routen soll.
Dazu müssen also nur die die beiden VLAN Interfaces vlan-1 und vlan-11 in die jeweiligen VLANs gehängt werden.
192.168.1.233 = vlan-1 Interface
10.1.1.254 = vlan-11 Interface
Auch das funktioniert fehlerlos mit dem VLAN-11 Interface. Aber eben nur mit diesem.
Hier kann sowohl der 2011 alle Endgeräte im VLAN 11 pingen als auch die Engeräte das VLAN-11 Interface des Mikrotik.
Einzig das VLAN 1 Interface bekommt trotz identischer Konfiguration keine Verbindung in das VLAN 1.
Hier die einzelnen Steps:
1.) Definition der VLANs auf dem internen Switch 1 Chip:
2.) Zuweisung der Switchports:
Secure = Nur Annahme von Pakete mit definierten VLAN Tags 1 und 11 alle anderen werden gedropt.
Add if missing = Addiert outgoing die VLAN IDs 1 und 11 auf dem tagged Link zum L2 Switch
Always strip = Entfernt den VLAN Tag auf Endgeräteport
Switch1CPU = Interner Uplink zur Routing CPU
Das klappt fehlerfrei.
3.) Man sieht hier das der MT Switch sauber die Mac Adressen aus den VLAN Segmenten lernt:
Layer 2 klappt deshalb auch ohne Fehler.
4.) Ports ether1 und ether5 bekommen sfp1 als Masterport :
Damit wird sfp1 an die Router CPU gekoppelt.
5.) VLAN Routing Interfaces eingerichtet und auf sfp1 gebunden :
6.) IP Adressen auf die korrespondierenden VLAN Interfaces gebunden :
Frage: Was läuft da schief mit dem VLAN 1 Interface ?
Warum kann das nicht auf das interne VLAN 1 zugreifen ?
Jemand eine zündende Idee wo oder was der Fehler sein könnte ?
Folgendes Switching Design mit VLAN Routing soll zum Fliegen kommen und bereitet mir an einem Punkt Kopfzerbrechen. Ja ja...das kommt auch mal vor.
Im Grunde ein simples Design bis auf eine winzige Kleinigkeit die nicht funktioniert.
Setup Details...
Der Mikrotik hat 2 VLANs mit der VID 1 und 11 die alle im internen Switch 1 liegen (Ports: sfp1, ether1 bis 5) Der angeschlossene VLAN L2 Switch hat diese VLANs ebenso definiert. Beide Switches sind über einen tagged Link gekoppelt.
Beim MT-2011 ist das der sfp1 Port der auf den Port 24 des L2 Switches geht.
Beide Switches haben je 2 untagged Endgeräteports:
MT-2011: ether-1 = VLAN 1, ether-5 = VLAN 11
L2 Switch: Port 1 = VLAN 1, Port 3 = VLAN 11
In allen Endgeräte Ports stecken IP Geräte mit entsprechend passender IP Adressierung:
192.168.1.0 /24 = VLAN 1
10.1.1.0 /24 = VLAN 11
Alle Geräte können sich innerhalb ihrer VLANs fehlerfrei untereinander pingen. Aus Layer 2 Sicht funktioniert das Design also.
Ziel ist es nun, das der MT-2011 zwischen diesen beiden VLANs routen soll.
Dazu müssen also nur die die beiden VLAN Interfaces vlan-1 und vlan-11 in die jeweiligen VLANs gehängt werden.
192.168.1.233 = vlan-1 Interface
10.1.1.254 = vlan-11 Interface
Auch das funktioniert fehlerlos mit dem VLAN-11 Interface. Aber eben nur mit diesem.
Hier kann sowohl der 2011 alle Endgeräte im VLAN 11 pingen als auch die Engeräte das VLAN-11 Interface des Mikrotik.
Einzig das VLAN 1 Interface bekommt trotz identischer Konfiguration keine Verbindung in das VLAN 1.
Hier die einzelnen Steps:
1.) Definition der VLANs auf dem internen Switch 1 Chip:
2.) Zuweisung der Switchports:
Add if missing = Addiert outgoing die VLAN IDs 1 und 11 auf dem tagged Link zum L2 Switch
Always strip = Entfernt den VLAN Tag auf Endgeräteport
Switch1CPU = Interner Uplink zur Routing CPU
Das klappt fehlerfrei.
3.) Man sieht hier das der MT Switch sauber die Mac Adressen aus den VLAN Segmenten lernt:
4.) Ports ether1 und ether5 bekommen sfp1 als Masterport :
Damit wird sfp1 an die Router CPU gekoppelt.
5.) VLAN Routing Interfaces eingerichtet und auf sfp1 gebunden :
6.) IP Adressen auf die korrespondierenden VLAN Interfaces gebunden :
Frage: Was läuft da schief mit dem VLAN 1 Interface ?
Warum kann das nicht auf das interne VLAN 1 zugreifen ?
Jemand eine zündende Idee wo oder was der Fehler sein könnte ?
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: 329880
Url: https://administrator.de/forum/mikrotik-switching-und-routing-problem-329880.html
Ausgedruckt am: 22.12.2024 um 18:12 Uhr
11 Kommentare
Neuester Kommentar
Kann es sein, dass der Switch die Tags für VLAN 1 entfernt und die Pakete untagged aus dem Interface wirft?
Hierzu auch das Stichwort PVID.
Hierzu auch das Stichwort PVID.
Hallo @aqui,
eventuell hast Du oder jemand anderes die "default" Konfiguration nicht gelöscht und nun hängt am diesem Port
wo ursprünglich der WAN Port war, bzw. dafür vorgesehen war, und dort wird NAT gemacht, kann das sein?
Alternativ bitte einmal prüfen ob dort eventuell auf dem MikroTik eine Firewallregel oder mangle rule automatisch mit
dem erstellen des VLANs oder dem Interface angelegt wurde die dann einfach nicht angepasst wurde, kann das sein?
Gruß
Dobby
eventuell hast Du oder jemand anderes die "default" Konfiguration nicht gelöscht und nun hängt am diesem Port
wo ursprünglich der WAN Port war, bzw. dafür vorgesehen war, und dort wird NAT gemacht, kann das sein?
Alternativ bitte einmal prüfen ob dort eventuell auf dem MikroTik eine Firewallregel oder mangle rule automatisch mit
dem erstellen des VLANs oder dem Interface angelegt wurde die dann einfach nicht angepasst wurde, kann das sein?
Gruß
Dobby
Ich habe den Mikrotik vorher komplett nackig gemacht und den Haken gesetzt das er keine Default Konfig laden soll. Der Mikrotik ist also jungfräulich konfiguriert.
Das da noch Reste von alten Konfigs sind kann ich sehr sicher ausschliessen. Routerboard Firmware ist auf dem aktuellsten Stand.
Ich vermute auch sowas was der Lord schon angesprochen hat, das es ggf. etwas mit dem VLAN 1 Tag und dessen internem Handling zu tun hat, denn das VLAN 1 ist ja als Default VLAN immer etwas Besonderes.
Ich habe mir den Trunk (Tagged Link) mal angesehen mit dem Wireshark und gesehen das der MT aber Frames aus dem VLAN 1 sauber mit einem .1q Tag "1" versieht. Der Switch am anderen auch mit einem entsprechenden "tag native VLAN" Kommando. Extern ist das Tagging fehlerfrei.
Aus Layer 2 Sicht klappt diese Verbindung ja auch fehlerlos im VLAN 1
Ich befürchte aber auch wie der Lord das ggf. der MT intern das VLAN 1 Tag abstrippt oder ignoriert und das das VLAN Interface dann nicht mehr zuordbar ist. Es ist ja auffällig das es mit dem VLAN 10 fehlerlos klappt, mit VLAN 1 und gleicher Konfig aber nicht.
Beispiele Im Internet wie z.B. hier gehen immer von VLAN IDs aus die nicht 1 sind.
Ich werde als Quercheck die Konfig mal ändern und das VLAN 1 in 10 umbenennen und entsprechend eine Zuordnung machen.
Sollte das dann klappen würde das die Vermutung mit dem VLAN 1 Handling dann bestätigen.
Hier steht auch noch ein fataler Satz was den switch-1 Port anbetrifft das der nicht am Switch Chip angeschlossen ist.
Würde das stimmen wäre das auch eine Erklärung, denn das VLAN 1 kommt in meinem Setup über switch-1 rein.
Dagegen spricht aber das die L2 Forwarding Database des Switch 1 Chips sauber alle Mac Adressen des VLAN 1 lernt. Ich werde das testweise auch mal auf ether-2 umändern.
Werde berichten....
Das da noch Reste von alten Konfigs sind kann ich sehr sicher ausschliessen. Routerboard Firmware ist auf dem aktuellsten Stand.
Ich vermute auch sowas was der Lord schon angesprochen hat, das es ggf. etwas mit dem VLAN 1 Tag und dessen internem Handling zu tun hat, denn das VLAN 1 ist ja als Default VLAN immer etwas Besonderes.
Ich habe mir den Trunk (Tagged Link) mal angesehen mit dem Wireshark und gesehen das der MT aber Frames aus dem VLAN 1 sauber mit einem .1q Tag "1" versieht. Der Switch am anderen auch mit einem entsprechenden "tag native VLAN" Kommando. Extern ist das Tagging fehlerfrei.
Aus Layer 2 Sicht klappt diese Verbindung ja auch fehlerlos im VLAN 1
Ich befürchte aber auch wie der Lord das ggf. der MT intern das VLAN 1 Tag abstrippt oder ignoriert und das das VLAN Interface dann nicht mehr zuordbar ist. Es ist ja auffällig das es mit dem VLAN 10 fehlerlos klappt, mit VLAN 1 und gleicher Konfig aber nicht.
Beispiele Im Internet wie z.B. hier gehen immer von VLAN IDs aus die nicht 1 sind.
Ich werde als Quercheck die Konfig mal ändern und das VLAN 1 in 10 umbenennen und entsprechend eine Zuordnung machen.
Sollte das dann klappen würde das die Vermutung mit dem VLAN 1 Handling dann bestätigen.
Hier steht auch noch ein fataler Satz was den switch-1 Port anbetrifft das der nicht am Switch Chip angeschlossen ist.
Würde das stimmen wäre das auch eine Erklärung, denn das VLAN 1 kommt in meinem Setup über switch-1 rein.
Dagegen spricht aber das die L2 Forwarding Database des Switch 1 Chips sauber alle Mac Adressen des VLAN 1 lernt. Ich werde das testweise auch mal auf ether-2 umändern.
Werde berichten....
Eventuell hilft es in solchen Fällen (ist dann leider nicht besonders schön) die PVID auf der Gegenseite auf VLAN 1 zu ändern, damit ungetaggete Pakete dem VLAN 1 zugeordnet werden.
Aber das will man eigentlich nicht...
Was ist das denn für ein Switch? Vielleicht hilft es dort, das Default-VLAN auf etwas anderes zu ändern...
Aber das will man eigentlich nicht...
Was ist das denn für ein Switch? Vielleicht hilft es dort, das Default-VLAN auf etwas anderes zu ändern...
Mit welchem Tag das VLAN auf dem Link übertragen wird ist erstmal egal es muss nicht 1 sein. Die beiden Netze sollen nur in unterschiedlichen VLANs transportiert werden.
Der ingress Port auf beiden Seiten ist ja immer untagged und wie man es intern tagged ist eher kosmetisch. In so fern stört es nicht wenn das Interface dann "VLAN-10" heisst. Hauptsache es hat eine IP Connectivity und Routing ist möglich ins VLAN 11
Es ist ein Edge Core Switch (Accton) mit einem Cisco ähnlichen CLI. Ich kann aber auch einen Catalysten nehmen zum Testen. Das macht aber kein Unterschied.
Ich werde alle Varianten mal testen und berichten...
Der ingress Port auf beiden Seiten ist ja immer untagged und wie man es intern tagged ist eher kosmetisch. In so fern stört es nicht wenn das Interface dann "VLAN-10" heisst. Hauptsache es hat eine IP Connectivity und Routing ist möglich ins VLAN 11
Es ist ein Edge Core Switch (Accton) mit einem Cisco ähnlichen CLI. Ich kann aber auch einen Catalysten nehmen zum Testen. Das macht aber kein Unterschied.
Ich werde alle Varianten mal testen und berichten...
OK, wenn das VLAN-Tag nicht unbedingt 1 sein muss würde ich das auch tatsächlich lieber nicht benutzen.
VLAN 1 ist ja per Quasi-Standard das Management-VLAN der meisten Switches und Router und wird von denen speziell behandelt.
Wenn es sich vermeiden lässt würde ich daher tatsächlich das VLAN 1 lieber nicht benutzen
VLAN 1 ist ja per Quasi-Standard das Management-VLAN der meisten Switches und Router und wird von denen speziell behandelt.
Wenn es sich vermeiden lässt würde ich daher tatsächlich das VLAN 1 lieber nicht benutzen
Hallo,
@aqui,
kann es sein das dein Problem die VLAN ID 1 ist?
Das VLAN 1 als default VLAN könnte anders behandelt werden als alle anderen VLAN ID's.
Wenn du für dein Test die VLAN ID von 1 auf ein andere änderst, was passiert dann?
brammer
@aqui,
kann es sein das dein Problem die VLAN ID 1 ist?
Das VLAN 1 als default VLAN könnte anders behandelt werden als alle anderen VLAN ID's.
Wenn du für dein Test die VLAN ID von 1 auf ein andere änderst, was passiert dann?
brammer
Stimmt. Das hatte der Lord oben auch schon vermutet und ich insgeheim auch.
Ich werde das heute mal ändern und auch den Switchport und mal testen. More to come...
Ich werde das heute mal ändern und auch den Switchport und mal testen. More to come...
Problem gelöst !!
Es ist tatsächlich das VLAN 1.
Ich habe das eben testweise mit dem VLAN 100 ersetzt bei gleicher Grundkonfiguration und schon war sofort das 192.168.1.0er LAN pingbar von allen Ports und auch L2 Switch.
Es scheint dann wirklich so zu sein das das VLAN Interface mit dem Index 1 Tabu ist und es immer ein VLAN >1 sein muss.
Nebenbei: Der Switchport 1 der in dem einen zitierten Dokument oben noch (fälschlicherweise) ausgeschlossen wurde funktioniert fehlerlos. Es macht keinen Unterschied ob man den Port ether-1 oder jeden anderen nimmt sofern mit auf dem gleichen Switchchip bleibt.
Es ist tatsächlich das VLAN 1.
Ich habe das eben testweise mit dem VLAN 100 ersetzt bei gleicher Grundkonfiguration und schon war sofort das 192.168.1.0er LAN pingbar von allen Ports und auch L2 Switch.
Es scheint dann wirklich so zu sein das das VLAN Interface mit dem Index 1 Tabu ist und es immer ein VLAN >1 sein muss.
Nebenbei: Der Switchport 1 der in dem einen zitierten Dokument oben noch (fälschlicherweise) ausgeschlossen wurde funktioniert fehlerlos. Es macht keinen Unterschied ob man den Port ether-1 oder jeden anderen nimmt sofern mit auf dem gleichen Switchchip bleibt.
1
Hallo,
@aqui, macht aber nach den RFC's erstmal keinen Sinn das es mit dem VLAN 1 nicht geht.
Hast du einen Ansatz wieso das mit VLAN 1 nicht geht?
Oder ein Ticket beim Hersteller eröffnet?
brammer
@aqui, macht aber nach den RFC's erstmal keinen Sinn das es mit dem VLAN 1 nicht geht.
Hast du einen Ansatz wieso das mit VLAN 1 nicht geht?
Oder ein Ticket beim Hersteller eröffnet?
brammer
Das stimmt, zumal ja auch das Tagging laut Wireshark sauber mit einem 1er Tag über den Uplink kam. Die Fehlfunktion kann als nur switchintern liegen.
Das kann in der Tat nur ein Firmware Bug sein oder das es wegen irgendwelchem internen Handling diese ID ausschliesst.
Es ist aber offensichtlich das es daran liegt, ich konnte das problemlos auf anderen MPSBE basierten Plattformen wie hexLite usw. sofort reproduzieren.
Kleine Konfig Geschichte am Rande zu dem Thema.
Da es jetzt fehlerfrei funktionierte hatte ich mutig versucht den Uplink zwischen L2 Switch und Mikrotik mit 2 Gig Links zu machen im 802.3ad Bonding (LAG) mit ether1 und sfp1.
Das klappte auch soweit bis diese beiden Ports Switchchip intern auf Tagging gesetzt wurden, dann brach die LACP Verbindung zusammen und baute sich nicht wieder auf. Der MT antwortete nicht mehr auf LACP Requests des L2 Switches. Auch ein Reboot des MT half nicht. LACP blieb dann stumm.
Mit einer Master Slave konfig lief das Bonding aber stabil. Nur das man da eben dann kein tagged Link hat.
Also wenns etwas anspruchsvoller von der Konfig wird hat der MT da noch etwas Luft nach oben. Jedenfalls auf den MIPSBE Plattformen
Mit einem singulären Link klappt das obige jetzt aber wunderbar stabil und performant so das man damit problemlos in den Wirkbetrieb gehen kann.
<edit>
Das o.a. Bonding Problem besteht in den aktuellen MT Images mit neuer VLAN Konfig NICHT mehr !
Siehe dazu auch:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
</edit>
Das kann in der Tat nur ein Firmware Bug sein oder das es wegen irgendwelchem internen Handling diese ID ausschliesst.
Es ist aber offensichtlich das es daran liegt, ich konnte das problemlos auf anderen MPSBE basierten Plattformen wie hexLite usw. sofort reproduzieren.
Kleine Konfig Geschichte am Rande zu dem Thema.
Da es jetzt fehlerfrei funktionierte hatte ich mutig versucht den Uplink zwischen L2 Switch und Mikrotik mit 2 Gig Links zu machen im 802.3ad Bonding (LAG) mit ether1 und sfp1.
Das klappte auch soweit bis diese beiden Ports Switchchip intern auf Tagging gesetzt wurden, dann brach die LACP Verbindung zusammen und baute sich nicht wieder auf. Der MT antwortete nicht mehr auf LACP Requests des L2 Switches. Auch ein Reboot des MT half nicht. LACP blieb dann stumm.
Mit einer Master Slave konfig lief das Bonding aber stabil. Nur das man da eben dann kein tagged Link hat.
Also wenns etwas anspruchsvoller von der Konfig wird hat der MT da noch etwas Luft nach oben. Jedenfalls auf den MIPSBE Plattformen
Mit einem singulären Link klappt das obige jetzt aber wunderbar stabil und performant so das man damit problemlos in den Wirkbetrieb gehen kann.
<edit>
Das o.a. Bonding Problem besteht in den aktuellen MT Images mit neuer VLAN Konfig NICHT mehr !
Siehe dazu auch:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
</edit>
