129
VLAN Konfiguration mit dd-wrt bzw. Mikrotik hinter FritzBox
Hallo Experten,
ich versuche seit einigen Tagen ein VLAN zu Hause hinzukriegen. Leider komme ich irgenwie nicht ans Ziel und hoffe jemand kann mich auf meinen Fehler stoßen.
Vorab, ich habe hier im Forum und schon einiges gelesen u.a. auch [ VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern dieses HowTo]
Mir ist jetzt Dank dieses Forums auch bekannt, dass die FritzBox kein VLAN beherrscht und habe deshalb einen alten Linksys Router dahinter geschaltet um das VLAN zu "managen".
So jetzt zu meinem Problem mit folgender Konfiguration:
Die Fritzbox stellt die Verbindung zum Internet her und stellt das WLAN bereit. Diese ist über Port 1 am WAN Ports meines ddwrt's verbunden.
Der ddwrt wiederum ist an port 1 mit einem netgear-8-port-switch an Port 8 angeschlossen, der wiederrum stellt über Port 1 eine weitere Verbindung zu einem weiteren Netgear-5-Port-switch zu Port 5 eine Verbindung her. Alle o.g. Ports sind im vlan1 und getagged, bis natürlich auf Port1 der Fritzbox. Der WAN Port des ddwrt sollte mit dessen port1 im gleichen Vlan1 sein, so hoffe ich.
An den Switches sind die anderen Ports im vlan12, vlan13 bzw. vlan14 und zwar alle untagged.
Wenn ich jetzt über telnet mich auf den ddwrt einlogge und die Clients im Vlan12 anpingge, gibts kein Verbindung, die beiten netgear-swichtes sind jedoch anpingbar.
Ich hätte jetzt erwartet, das ich vom Vlan1 des ddwrt auf die Clients der anderen Vlans zugreifen kann. Ebenso von Clients die an der Fritzbox bzw. sich in deren WLAN befinden einen Zugriff auf alle Vlans bekomme, jedoch nicht umgekehrt. Also von einem Client im vlan12 keinen Zugriff auf die angeschlossenen Geräte an der Fritzbox bzw. vlan13 oder vlan14.
Mein Ziel ist es also vom vlan1 bzw. von der Fritzbox auf alles Zugriff erhalten, jedoch nicht umgekehrt, d.h. vlan12, vlan13 und vlan14 sollen voneinander abgeschottet sein.
Wenn möglich auch alles im selben subnetz 192.168.150.0. DHCP ist auf dem ddwrt ausgeschaltet und soll von der Fritzbox bereitgestellt werden.
Ein am port 2 (vlan12) des ddwrt angeschlossener Client bekommt keine IP über DHCP zugewiesen, der sollte eigentlich von der Fritzbox eine zugewiesen bekommen.
Wenn ich bei diesem Client die IP manuell im gleichen Subnetz zuweise, dann kann er auch Clients im vlan12 die am 5-Port-Swich im vlan12 hängen anpingen und eben den 5-port-switch.
Allerdings nicht den ddwrt, den ersten 8-port-switch und die Fritzbox auch nicht ?!?
Umgekehrt kann der client im vlan12 am 5-port-switch auch diesen switch anpingen sowie den ersten 8-port-switch, aber nicht die Fritzbox und auch nicht den Client am ddwrt im vlan12 ?!?
Ist mein Vorhaben (un)möglich oder habe ich eine Konfigurationsfehler? Muss ich etwa für die einzelnen Vlans ein eigenes Subnetz mit dhcp einrichten?
Kann ich das überhaupt so mit der Fritzbox (kein vlan) lösen?
Bin für jeden Hinweis dankbar.
Noch einen allgemeine Frage: Läuft auf dem ddwrt einen Radiusserver oder ist das nur die Konfigurationsmöglichkeit um eine Server-IP zu hinterlegen?
So jetzt noch ein paar Bilder mit der Konfiguration:
ich versuche seit einigen Tagen ein VLAN zu Hause hinzukriegen. Leider komme ich irgenwie nicht ans Ziel und hoffe jemand kann mich auf meinen Fehler stoßen.
Vorab, ich habe hier im Forum und schon einiges gelesen u.a. auch [ VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern dieses HowTo]
Mir ist jetzt Dank dieses Forums auch bekannt, dass die FritzBox kein VLAN beherrscht und habe deshalb einen alten Linksys Router dahinter geschaltet um das VLAN zu "managen".
So jetzt zu meinem Problem mit folgender Konfiguration:
Die Fritzbox stellt die Verbindung zum Internet her und stellt das WLAN bereit. Diese ist über Port 1 am WAN Ports meines ddwrt's verbunden.
Der ddwrt wiederum ist an port 1 mit einem netgear-8-port-switch an Port 8 angeschlossen, der wiederrum stellt über Port 1 eine weitere Verbindung zu einem weiteren Netgear-5-Port-switch zu Port 5 eine Verbindung her. Alle o.g. Ports sind im vlan1 und getagged, bis natürlich auf Port1 der Fritzbox. Der WAN Port des ddwrt sollte mit dessen port1 im gleichen Vlan1 sein, so hoffe ich.
An den Switches sind die anderen Ports im vlan12, vlan13 bzw. vlan14 und zwar alle untagged.
Wenn ich jetzt über telnet mich auf den ddwrt einlogge und die Clients im Vlan12 anpingge, gibts kein Verbindung, die beiten netgear-swichtes sind jedoch anpingbar.
Ich hätte jetzt erwartet, das ich vom Vlan1 des ddwrt auf die Clients der anderen Vlans zugreifen kann. Ebenso von Clients die an der Fritzbox bzw. sich in deren WLAN befinden einen Zugriff auf alle Vlans bekomme, jedoch nicht umgekehrt. Also von einem Client im vlan12 keinen Zugriff auf die angeschlossenen Geräte an der Fritzbox bzw. vlan13 oder vlan14.
Mein Ziel ist es also vom vlan1 bzw. von der Fritzbox auf alles Zugriff erhalten, jedoch nicht umgekehrt, d.h. vlan12, vlan13 und vlan14 sollen voneinander abgeschottet sein.
Wenn möglich auch alles im selben subnetz 192.168.150.0. DHCP ist auf dem ddwrt ausgeschaltet und soll von der Fritzbox bereitgestellt werden.
Ein am port 2 (vlan12) des ddwrt angeschlossener Client bekommt keine IP über DHCP zugewiesen, der sollte eigentlich von der Fritzbox eine zugewiesen bekommen.
Wenn ich bei diesem Client die IP manuell im gleichen Subnetz zuweise, dann kann er auch Clients im vlan12 die am 5-Port-Swich im vlan12 hängen anpingen und eben den 5-port-switch.
Allerdings nicht den ddwrt, den ersten 8-port-switch und die Fritzbox auch nicht ?!?
Umgekehrt kann der client im vlan12 am 5-port-switch auch diesen switch anpingen sowie den ersten 8-port-switch, aber nicht die Fritzbox und auch nicht den Client am ddwrt im vlan12 ?!?
Ist mein Vorhaben (un)möglich oder habe ich eine Konfigurationsfehler? Muss ich etwa für die einzelnen Vlans ein eigenes Subnetz mit dhcp einrichten?
Kann ich das überhaupt so mit der Fritzbox (kein vlan) lösen?
Bin für jeden Hinweis dankbar.
Noch einen allgemeine Frage: Läuft auf dem ddwrt einen Radiusserver oder ist das nur die Konfigurationsmöglichkeit um eine Server-IP zu hinterlegen?
So jetzt noch ein paar Bilder mit der Konfiguration:
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: 355892
Url: https://administrator.de/forum/vlan-konfiguration-mit-dd-wrt-bzw-mikrotik-hinter-fritzbox-355892.html
Ausgedruckt am: 23.12.2024 um 01:12 Uhr
129 Kommentare
Neuester Kommentar
Moin,
dein Problem ist, dass die VLANs 12 und 13 gar nicht am DD-WRT ankommen.
Wenn ich das richtig gesehen habe, gehen von deinem DD_WRT drei Kabel zum SW01 (Netgear 8Port)?
Ändere folgendes:
Dein nächstes Problem:
du hast/ willst für alles VLANs das gleiche SUbnetz nehmen.
das funktioniert so nicht.
Angenommen, du du hast 20 Leute und möchtest die auf verschiedene Räume (VLANs) aufteilen. Jeder PErson gibst du einen Zettel mit einer RaumNr und individuellen-Nr([RaumNr].[ind. Nr] = IP-Adresse). Jetzt steht auf allen Zetteln im Bereich der RaumNr. die selbe Nr. und auch an den Türen der Räume hast du überall die selbe Nr. geschrieben. Woher sollen die Leute denn jetzt wissen, in welchen Raum sie sollen??
Der nächste Knackpunkt: du möchtest, dass die FritzBox auch in den VLANs IPs verteilt. Das kann SIe nicht.
Du kannst nur einen DHCP-Scope dort anlegen, müsstest aber 4 haben (VLAN1 FritzBox, VLAN1 DD-WRT, VLAN12, VLAN13)...
Lass die Fritzbox DHCP für ihr Netz spielen (192.168.178.0/24) und der DD-WRT macht VLAN für sein VLAN 1, VLAN12 und VLAN13)
€dit:
Setze dich zudem nochmal intensiv mit den Definitionen von tagged und untagged-Paketen auseinander.
folgend mal zwei Beispiele, wie du das Umsetzen könntest (hoffe, habe auf die schnelle nichts "verbaselt"):
Deine Clients an den Switchen würden jeweils am Switch einen UNTAGGED-Port bekommen (es sei denn, es sind Hypervisor im Spiel, die die VLANs zu den VMs durchreichen sollen).
Und bei Windows-Cliens musst du auch die Firewalls auf den Clients anpassen, sofern Pakete aus VLAN-fremden Netzen ankommen sollen
Gruß
em-pie
dein Problem ist, dass die VLANs 12 und 13 gar nicht am DD-WRT ankommen.
Wenn ich das richtig gesehen habe, gehen von deinem DD_WRT drei Kabel zum SW01 (Netgear 8Port)?
Ändere folgendes:
- Zwischen DD-WRT und SW01 (Netgear 8-Port)
- VLAN 1 auf untagged (weil es ein Default-VLAN ist)
- VLAN12 auf untagged (sofern dediziertes Kabel zum SW01 geht, ansonstens tagged)
- VLAN13 auf untagged (sofern dediziertes Kabel zum SW01 geht, ansonstens tagged)
- Zwischen SW01 (Netgear 8-Port) und SW02 (Netgear 5-Port)
- VLAN 1 auf untagged (weil es ein Default-VLAN ist)
- VLAN12 auf Tagged
- VLAN13 auf Tagged
Dein nächstes Problem:
du hast/ willst für alles VLANs das gleiche SUbnetz nehmen.
das funktioniert so nicht.
Angenommen, du du hast 20 Leute und möchtest die auf verschiedene Räume (VLANs) aufteilen. Jeder PErson gibst du einen Zettel mit einer RaumNr und individuellen-Nr([RaumNr].[ind. Nr] = IP-Adresse). Jetzt steht auf allen Zetteln im Bereich der RaumNr. die selbe Nr. und auch an den Türen der Räume hast du überall die selbe Nr. geschrieben. Woher sollen die Leute denn jetzt wissen, in welchen Raum sie sollen??
Der nächste Knackpunkt: du möchtest, dass die FritzBox auch in den VLANs IPs verteilt. Das kann SIe nicht.
Du kannst nur einen DHCP-Scope dort anlegen, müsstest aber 4 haben (VLAN1 FritzBox, VLAN1 DD-WRT, VLAN12, VLAN13)...
Lass die Fritzbox DHCP für ihr Netz spielen (192.168.178.0/24) und der DD-WRT macht VLAN für sein VLAN 1, VLAN12 und VLAN13)
€dit:
Setze dich zudem nochmal intensiv mit den Definitionen von tagged und untagged-Paketen auseinander.
folgend mal zwei Beispiele, wie du das Umsetzen könntest (hoffe, habe auf die schnelle nichts "verbaselt"):
Und bei Windows-Cliens musst du auch die Firewalls auf den Clients anpassen, sofern Pakete aus VLAN-fremden Netzen ankommen sollen
Gruß
em-pie
Alle o.g. Ports sind im vlan1 und getagged
Das ist schon mal der erste Fehler. Oder soll dieser 8 Port Switch ein zentraler Verteiler sprich sowas wie ein Core für deine VLAN Netze sein.Ansonsten musst du das Tagging rein nur auf den Uplink Ports definieren wo a.) der DD-WRT angeschlossen ist und b.) der Uplink zum anderen Switch.
Klar, denn auf diesen Ports musst du mit dem VLAN Tag ja die Information mitgeben für welches VLAN das übertragene Paket ist so das der Empfänger das wieder richtig zuordnen kann.
Siehe auch "VLAN Schnellschulung":
Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet
Ist der Switch zentraler Verteiler dann kannst du natürlich alle Ports fürs Tagging einrichten.
Das VLAN 1 ist immer das Default VLAN und an tagged Ports IMMER untagged. Hier irrst du also gewaltig. Mit der PVID stellt man bei NetGear ein in welches VLAN ungetaggter Traffic geforwardet werden soll. In der Regel steht das auf PVID 1 dann. Siehe dazu auch:
Warum gibt es PVID bei VLANs?
In der Beziehung ist NetGears VLAN Konfig so ziemlich das gruseligste was es gibt. Aber egal...
Die Kaskade mit FritzBox und DD-WRT über den LAN Port ist soweit genau richtig !
Der WAN Port des ddwrt sollte mit dessen port1 im gleichen Vlan1 sein, so hoffe ich.
Nein, das ist falsch !Der WAN Port des DD-WRT geht DIREKT per Kabel auf die LAN Ports der FritzBox. Da sollte kein VLAN zwischen sein. Es sei denn du willst dieses Transfernetz zur FB auch in einem VLAN betreiben. Dann kannst du dafür auch ein abgeschottetes VLAN nehmen. Das VLAN 1 solltest du da besser nicht nehmen.
Technisch natürlich möglich birgt aber erhebliche Gefahren eines Loops da dort ja alle Default Ports drin liegen.
Besser also immer ein dediziertes VLAN nehmen wie z.B. 99 und dort dann WAN Port DD-WRT und LAN Port FB zusammenstecken.
Für den Anfang solltest du das um Komplikationen zu vermeiden nicht machen sondern FB und DD-WRT rein mit einem Kabel ohne Switch verbinden.
Ich hätte jetzt erwartet, das ich vom Vlan1 des ddwrt auf die Clients der anderen Vlans zugreifen kann
Ja, das sollte auch gehen wenn du das Routing am DD-WRT sauber konfiguriert hast und die Clients alle die jeweilige DD-WRT IP Adresse in ihrem VLAN Segment als Gateway konfiguriert haben...oder sie dynmaisch per DHCP vom DD-WRT bekommen (ipconfig !)Ebenso von Clients die an der Fritzbox bzw. sich in deren WLAN befinden einen Zugriff auf alle Vlans bekomme, jedoch nicht umgekehrt.
Das kommt darauf an !!!Extrem wichtig ist hier das du im DD-WRT den Router Mode am WAN Port aktiviert hast, sprich also das NAT ausgeschaltet hast. Ansonsten kannst du die NAT Firewall des DD-WRT nicht überwinden !
NAT sollte generell AUS auf dem DD-WRT, was dann aber auch erzwingt das du statische IP Routen in der FritzBox definiert hast für alle deine VLANs ! Ist das geschehen ??
Siehe dazu auch hier:
Mit einem WLAN zwei LAN IP Netzwerke verbinden
Das sollte ein Muß im Setup des DD-WRT sein !!
Ein am port 2 (vlan12) des ddwrt angeschlossener Client bekommt keine IP über DHCP zugewiesen, der sollte eigentlich von der Fritzbox eine zugewiesen bekommen.
Das ist natürlich völliger Quatsch. Wie sollte das gehen.Ersten ist ja das VLAN 12 am DD-WRT Router terminiert. DHCP nutzt UDP Broadcasts die dieser Router niemals forwarden würde. Folglich können diese Broadcasts auch niemals die FritzBox erreichen und eine Antwort triggern.
Aber auch wenn wäre das ziemlicher Blödsinn, denn das VLAN 12 hat ja einen ganz anderen IP Bereich als das Koppelnetz zw. DD-WRT WAN Port und FB LAN Port. Es wäre also fatal wenn VLAN 12 Clients hier so eine falsche IP bekämen.
Abgesehen davon kann der DHCP Server der FB niemals einen 2ten DHCP Scope vergeben. Das geht also technisch schon gar nicht. 3 triftige Gründe also warum das scheitern MUSS ! Leuchtet dir sicher auch selber ein, oder ?
Das der VLAN 12 Client andere Geräte im VLAN 12 pingen kann aber nicht das VLAN 12 Interface des DD-WRT zeigt das zwar das VLAN richtig eingerichtet ist aber nicht der Tagged Uplink auf den DD-WRT, denn scheinbar können Pakete das VLAN 12 Interface des Routers nicht erreichen.
Auch sollten VLAN 12 Clients ja vom DD-WRT entsprechende IP Adressen per DHCP bekommen. Hier stimmt also schon grundsätzlich was nicht mit der DD-WRT tagged Anbindung auf den Switch oder der IP Adressierung im VLAN 12 !
Ist mein Vorhaben (un)möglich oder habe ich eine Konfigurationsfehler?
Dein Vorhaben ist ein simpler Bilderbuchklassiker. Wenn man alles richtig macht ist das mit 15 Minuten Konfig Klickerei erledigt.Technisch ist das natürlich möglich...eben da simpler Standard !
Läuft auf dem ddwrt einen Radiusserver
Das ist ein Radius Client. Vergiss das Thema Radius aber erstmal komplett sondern löse deine VLAN Tagging und deine IP Konfig Fehler !!Was gar nicht geht ist natürlich in einem segmentierten, gerouteten Netz wie deinem die gleiche IP Adressierung zu verwenden. Ein fundamentaler Verstoß gegen Adress Standards. Hier hast du vermutlich auch ein Wissensdefizit was es auszugleichen gilt.
Kollege em-pie hat ja oben auch schon alles explizit beschrieben.
Grundproblem ist deine VLAN 12 und 13 Connectivity am Router. Und die vollkommen falsche IP Adressierung. Eigentlich hättest du beim lesen des o.a. VLAN Tutorials dieses erkennen müssen.
Da stimmt also schon was generell nicht !
Das mit den 3 Kabeln zum Switch ist natürlich auch Blödsinn, das ist die Steinzeit Variante der Konfig wo man alle VLANs einzeln zum Switch zieht pro Port, dann müssen aber alle Port logischerweise untagged sein.
Kann man machen, muss man aber nicht.
Sinniger ist das mit einem Tagged Port zu machen und EINEM Link !!
Dann muss man allerdings auch logischerweise taggen auf beiden Enden !
Also das Tutorial nochmal genau und in Ruhe lesen und auch verstehen. Dann klappt das auch auf Anhieb
Hallo zusammen,
vielen Dank erstmal für Eure ausführlichen und wertvollen Informationen.
@ em-pie
Wenn ich das richtig gesehen habe, gehen von deinem DD_WRT drei Kabel zum SW01 (Netgear 8Port)?
Nein, es geht nur ein Kabel vom ddwrt zum sw01, daher hatte ich das getagged.
Nur zum Verständnis was bedeutet Default-VLAN ? Ist das Vlan 1 eine Besonderheit? Oder anders gefragt, was wäre wenn das nicht VLAN 1 sondern VLAN 5 wäre müßte man, dann taggen? Hier habe ich ein Verständnisproblem. Aus den Forenbeiträge hab ich das so verstanden, dass die beiden Switches über ein einziges Kabel verbunden werden müssen und eben diese beiden Ports getagged werden, damit der sw02 weiß an welchen Port, das ganze gehen soll.
Anscheinend habe ich hier im VLAN1 den Port 1 und 8 getagged, was ungetagged sein muss.
Vielen Dank auch für die beiden Beispiele. Wenn ich das richtig verstanden habe, dann habe ich bei der Variante mit der Router-Kaskade aus dem VLAN12 keine Verbindung zu den Clients die an der FB hängen. Und bei der Variante ohne Kaskade, erreiche ich aus dem VLAN12 die Clients die an der FB hängen. Ist das der Unterschied, oder liege ich falsch?
@ aqui
Ansonsten musst du das Tagging rein nur auf den Uplink Ports definieren wo a.) der DD-WRT angeschlossen ist und b.) der Uplink zum anderen Switch.
So hab ich das gemacht bzw. wollte das so machen, war wohl etwas irreführend ausgedrückt.
Wenn ich die Skizze von em-pie richtig verstehe, dann habe ich bei nur im VLAN1 die Ports 1 und 8 am sw01 falsch auf tagged gesetzt. Diese müssen wohl auf untagged?
Das VLAN 1 ist immer das Default VLAN und an tagged Ports IMMER untagged.
Das VLAN 1 solltest du da besser nicht nehmen.
Also ist das VLAN 1 ein Sonderfall? Und die FB kennt nur VLAN1 ?
Routing in der Fritzbox, habe ich nicht konfiguriert, weil ich alles im gleichen Subnetz betreiben wollte. Dass das nicht geht habe ich jetzt aus euren Beiträgen erkannt und werde dies und DHCP auf dem ddwrt konfigurieren.
Wenn man alles richtig macht ist das mit 15 Minuten Konfig Klickerei erledigt.
Für jemanden wie mich, der sich in das Thema einarbeitet sicherlich ein paar Tage
Das mit den 3 Kabeln zum Switch ist natürlich auch Blödsinn
Sinniger ist das mit einem Tagged Port zu machen und EINEM Link !!
Dann muss man allerdings auch logischerweise taggen auf beiden Enden !
Wie schon oben geschrieben, die Switches sind mit nur einem Kabel verbunden.
Der ddwrt-Port1 geht an sw01-Port8 und sw01-Port1 geht an sw02-Port5
Hier meine Konfiguration mit berichtigtem tagging in VLAN1:
vielen Dank erstmal für Eure ausführlichen und wertvollen Informationen.
@ em-pie
Wenn ich das richtig gesehen habe, gehen von deinem DD_WRT drei Kabel zum SW01 (Netgear 8Port)?
Nein, es geht nur ein Kabel vom ddwrt zum sw01, daher hatte ich das getagged.
Nur zum Verständnis was bedeutet Default-VLAN ? Ist das Vlan 1 eine Besonderheit? Oder anders gefragt, was wäre wenn das nicht VLAN 1 sondern VLAN 5 wäre müßte man, dann taggen? Hier habe ich ein Verständnisproblem. Aus den Forenbeiträge hab ich das so verstanden, dass die beiden Switches über ein einziges Kabel verbunden werden müssen und eben diese beiden Ports getagged werden, damit der sw02 weiß an welchen Port, das ganze gehen soll.
Anscheinend habe ich hier im VLAN1 den Port 1 und 8 getagged, was ungetagged sein muss.
Vielen Dank auch für die beiden Beispiele. Wenn ich das richtig verstanden habe, dann habe ich bei der Variante mit der Router-Kaskade aus dem VLAN12 keine Verbindung zu den Clients die an der FB hängen. Und bei der Variante ohne Kaskade, erreiche ich aus dem VLAN12 die Clients die an der FB hängen. Ist das der Unterschied, oder liege ich falsch?
@ aqui
Ansonsten musst du das Tagging rein nur auf den Uplink Ports definieren wo a.) der DD-WRT angeschlossen ist und b.) der Uplink zum anderen Switch.
So hab ich das gemacht bzw. wollte das so machen, war wohl etwas irreführend ausgedrückt.
Wenn ich die Skizze von em-pie richtig verstehe, dann habe ich bei nur im VLAN1 die Ports 1 und 8 am sw01 falsch auf tagged gesetzt. Diese müssen wohl auf untagged?
Das VLAN 1 ist immer das Default VLAN und an tagged Ports IMMER untagged.
Das VLAN 1 solltest du da besser nicht nehmen.
Also ist das VLAN 1 ein Sonderfall? Und die FB kennt nur VLAN1 ?
Routing in der Fritzbox, habe ich nicht konfiguriert, weil ich alles im gleichen Subnetz betreiben wollte. Dass das nicht geht habe ich jetzt aus euren Beiträgen erkannt und werde dies und DHCP auf dem ddwrt konfigurieren.
Wenn man alles richtig macht ist das mit 15 Minuten Konfig Klickerei erledigt.
Für jemanden wie mich, der sich in das Thema einarbeitet sicherlich ein paar Tage
Das mit den 3 Kabeln zum Switch ist natürlich auch Blödsinn
Sinniger ist das mit einem Tagged Port zu machen und EINEM Link !!
Dann muss man allerdings auch logischerweise taggen auf beiden Enden !
Wie schon oben geschrieben, die Switches sind mit nur einem Kabel verbunden.
Der ddwrt-Port1 geht an sw01-Port8 und sw01-Port1 geht an sw02-Port5
Hier meine Konfiguration mit berichtigtem tagging in VLAN1:
Also:
Mal als Grundlage:
Der gesamte Netzwerktraffic besteht aus mehreren Protokollen und Schichten/ Layern.
Die Thematik VLAN spielt sich im Layer2 des ISO/OSI-Referenzmodells ab.
In dem hier eingesetzten Ethernet-Protokoll wird. Wenn VLANs zum Einsatz kommen, wird im Ethernet Frame an einer bestimmten Stelle die VLAN-ID eingesetzt. siehe z.B. Hier
Wird an einem Switch ein Port auf untagged für z.B. das VLAN 12 gesetzt, bedeutet das folgendes:
Wird ein Port auf tagged für ein oder mehrere VLANs gesetzt, dann passiert folgendes:
Zum Default-VLAN (i.d.R. 1)
Wenn ein Port für ein oder mehrere VLANs auf tagged gesetzt wird, muss er gleichzeitig auf für ein VLAN auf untagged gesetzt werden, i.d.R. ist das das Default-VLAN.
Kommt am getaggten Port ein Paket ohne eine VLAN-ID an, so wird das Paket genommen, die Default-VLAN-ID eingefügt und auf dem Default-VLAN weiterverarbeitet.
In deinem obigen Fall also:
Zwischen den Switchen und dem DD-WRT die Port für die VLANS 12 und 13 taggen und für das VLAN1 untaggen.
Somit kannst du über das eine Kabel in deinem Fall drei VLANs übertragen (1, 12 und 13)
Deine Clients, die vermutlich mit VLANs nichts anfangen können, werden die Ports dann für die jeweiligen VLANs auf untagged gesetzt.
Was meine beiden Beispiele machen:
Router-Kaskade:
Du hast hier vier Netze: VLAN 1 (FritzBox + DD-WRT WAN), VLAN1 (DD-WRT LAN-Default), VLAN 12 (DD-WRT LAN VLAN12) und VLAN 13 (DD-WRT LAN VLAN13)
Damit die drei DD-WRT-Netze mit dem FritzBox-Netz "schnacken" können, muss
Keine Router-Kaskade
Hier hast du drei Netze:
Für die FritzBox bedeutet dass, dass du nur zwei Statische Routen dort eintragen musst, und diese an den LAN-Port mit der IP aus dem VLAN 1 des DD-WRT verweist. das Routing übernimmt dann auch wieder der DD-WRT...
Mal als Grundlage:
Der gesamte Netzwerktraffic besteht aus mehreren Protokollen und Schichten/ Layern.
Die Thematik VLAN spielt sich im Layer2 des ISO/OSI-Referenzmodells ab.
In dem hier eingesetzten Ethernet-Protokoll wird. Wenn VLANs zum Einsatz kommen, wird im Ethernet Frame an einer bestimmten Stelle die VLAN-ID eingesetzt. siehe z.B. Hier
Wird an einem Switch ein Port auf untagged für z.B. das VLAN 12 gesetzt, bedeutet das folgendes:
- das angeschlossene Gerät soll mit Devices im VLAN 12 kommunizieren
- das Endgerät kann selbst nicht mit VLANs im Ethernet-Frame umgehen
- der Switch nimmt das Paket am Port entgegen, fügt den Tag 12 in das Ethernet-Frame ein und leitet das Paket dann innerhalb des VLAN12 weiter
- Ist ein Paket für das Endgerät bestimmt, nimmt der Switch das Paket, entfernt den Tag und sendet es über den Port zum Endgerät.
Wird ein Port auf tagged für ein oder mehrere VLANs gesetzt, dann passiert folgendes:
- der Switch nimmt das Paket entgegen, prüft, welche ID im VLAN-Frame enthalten ist und leitet es entsprechend weiter.
Zum Default-VLAN (i.d.R. 1)
Wenn ein Port für ein oder mehrere VLANs auf tagged gesetzt wird, muss er gleichzeitig auf für ein VLAN auf untagged gesetzt werden, i.d.R. ist das das Default-VLAN.
Kommt am getaggten Port ein Paket ohne eine VLAN-ID an, so wird das Paket genommen, die Default-VLAN-ID eingefügt und auf dem Default-VLAN weiterverarbeitet.
In deinem obigen Fall also:
Zwischen den Switchen und dem DD-WRT die Port für die VLANS 12 und 13 taggen und für das VLAN1 untaggen.
Somit kannst du über das eine Kabel in deinem Fall drei VLANs übertragen (1, 12 und 13)
Deine Clients, die vermutlich mit VLANs nichts anfangen können, werden die Ports dann für die jeweiligen VLANs auf untagged gesetzt.
Was meine beiden Beispiele machen:
Router-Kaskade:
Du hast hier vier Netze: VLAN 1 (FritzBox + DD-WRT WAN), VLAN1 (DD-WRT LAN-Default), VLAN 12 (DD-WRT LAN VLAN12) und VLAN 13 (DD-WRT LAN VLAN13)
- Der WAN-Port und das FritzBox-Netz sind in ein und dem selben Subnetz.
- Hinter dem DD-WRT-Router befinden sich drei eigene Netze: VLAN 1, VLAN12 und VLAN13
- Damit Pakete zwischen den 3 Netzen ausgetaucht werden können, braucht es einen Router, macht dein DD-WERT automatisch, sofern er in allen Netzen eine IP hat.
Damit die drei DD-WRT-Netze mit dem FritzBox-Netz "schnacken" können, muss
- der DD-WRT das FritzBox-Netz kennen (tut er, über den WAN-Port)
- die FritzBox wissen, wie Sie die drei DD-WRT-Netze findet: Statische Routen, die diese drei Netze auf den WAN-Port des DD-WRT senden
Keine Router-Kaskade
Hier hast du drei Netze:
- VLAN1 das FritzBox netz und das Default-VLAN des DD-WRT, da der DD-WRT nicht über den WAN-Port im FritzBox-Netz hängt, sondern über den LAN-Port
- VLAN 12 hängt nur am LAN des DD-WRT
- VLAN 12 hängt nur am LAN des DD-WRT
Für die FritzBox bedeutet dass, dass du nur zwei Statische Routen dort eintragen musst, und diese an den LAN-Port mit der IP aus dem VLAN 1 des DD-WRT verweist. das Routing übernimmt dann auch wieder der DD-WRT...
Also ist das VLAN 1 ein Sonderfall? Und die FB kennt nur VLAN1 ?
Ja und nein !Die FB kennt gar kein Tagging !!!
Sie kann also keinerlei VLAN Informationen senden und deshalb kommen aus ihr auch immer nur untagged Pakete raus...logisch !
In welches VLAN dein Switch untagged Pakete forwarded bestimmst immer DU selber ! und zwar mit der PVID. Die PVID ist in der Regel immer 1, sprich also der Switch forwardet untagged Traffic immer ins VLAN 1. Setzt du die PVID auf 10 forwardet er den Traffic in VLAN 10....so einfach ist das.
Da untagged ja per se keinerlei VLAN Informationen hat muss man also dem Switch sagen WIE er mit diesem Traffic an tagged Ports umgehen soll.
Also bestimmst du am Switch in welches VLAN der untagged Traffic der FB gesendet wird.
Wie bereits gesagt solltest du keinen Switch zw. FB und DD-WRT haben sondern das immer direkt mit einem Patch Kabel machen so kommst du niemals in die Gefahr das ungeschützter Traffic in einen deiner VLANs landet weil du einen VLAN Konfig Fehler gemacht hast !!!
Zum Thema PVID und untagged Traffic siehe auch hier:
Warum gibt es PVID bei VLANs?
(gelöst) Accesspoint im VLAN nicht erreichbar
Wie schon oben geschrieben, die Switches sind mit nur einem Kabel verbunden.
Es geht hier um die Anbindung des DD-WRT Routers ! Auch der muss mit einen (ein Kabel !) Patchkabel angebunden sein wenn man ihm die VLANs per .1q Tagging übertragen will.Hier je ein Kabel pro VLAN zu ziehen geht zwar ist aber tiefste Steinzeit. Bei 10 VLANs und mehr wirds dann so oder so witzig !!
Der Router wird genau so angebunden wie der Switch Uplink Port zw. den Switches.
Zum Rest hat Kollege em-pie ja schon ausführlich und richtg Stellung genommen !
Einfach das VLAN Tutorial lesen, verstehen und strategisch vorgehen bei der Konfig
Dann sollte jetzt meine oben gepostete Konfiguratiom am Switch stimmen. Hier hatte ich durch mein Missverständis den Port 1 auch im VLAN 1 auf tagged gesetzt. Was ich jetzt berichtigt habe.
Bei der Konfiguration des ddwrt bin ich mir aber noch nicht sicher.
Nach der deutlichen Erläuterung, habe ich eigentlich die Variante ohne Kaskade vor. Jetzt ist die Frage, ob ich durch den gesetzten Haken "WAN-Port dem Switch zuweisen" im Setup des ddwrt, die FB trotzdem am WAN Port anschliessen kann und ein Netzwerk ohne Kaskade habe? Dadurch habe ich einen Port mehr zur Verfügung.
Oder bewirkt dieser Haken etwas anderes und ich muss tatsälich die FB an Port1 des ddwrt anschliessen?
Ausserdem bin ich mir auch nicht bei den gesetzten Haken in der ddwrt-Vlan Konfiguration, stimmen diese? Ist die Bride Zuweisung korrekt?
@ aqui
Das ist auch so, zwischen FB und ddwrt sowie ddwrt zu Swtich1 als auch Swtich1 zu Switch2 ist jeweils nur ein Kabel gezogen. Am ddwrt habe ich die Ports 2-4 den entsprechenden VLANs zugewiesen, damit ich diese Ports am ddwrt ebenfalls für das VLAN nutzen kann und nicht brach liegen.
Dank Euch bin ich schon ein gutes Stück weiter gekommen, jetzt hapert es noch an der ddwrt Konfiguration. Hoffe Ihr könnt mir hierbei auch noch helfen.
Bei der Konfiguration des ddwrt bin ich mir aber noch nicht sicher.
Nach der deutlichen Erläuterung, habe ich eigentlich die Variante ohne Kaskade vor. Jetzt ist die Frage, ob ich durch den gesetzten Haken "WAN-Port dem Switch zuweisen" im Setup des ddwrt, die FB trotzdem am WAN Port anschliessen kann und ein Netzwerk ohne Kaskade habe? Dadurch habe ich einen Port mehr zur Verfügung.
Ausserdem bin ich mir auch nicht bei den gesetzten Haken in der ddwrt-Vlan Konfiguration, stimmen diese? Ist die Bride Zuweisung korrekt?
@ aqui
Es geht hier um die Anbindung des DD-WRT Routers ! Auch der muss mit einen (ein Kabel !) Patchkabel angebunden sein wenn man ihm die VLANs per .1q Tagging übertragen will.
Das ist auch so, zwischen FB und ddwrt sowie ddwrt zu Swtich1 als auch Swtich1 zu Switch2 ist jeweils nur ein Kabel gezogen. Am ddwrt habe ich die Ports 2-4 den entsprechenden VLANs zugewiesen, damit ich diese Ports am ddwrt ebenfalls für das VLAN nutzen kann und nicht brach liegen.
Dank Euch bin ich schon ein gutes Stück weiter gekommen, jetzt hapert es noch an der ddwrt Konfiguration. Hoffe Ihr könnt mir hierbei auch noch helfen.
Wenn dein DD-WRT sowieso schon mit einem Bein am Switch im VLAN1 steht, kannst du die Fritzbox auch an den Switch an VLAN1 anschließen... Die siehen sich ja dann...
Das allerdings nur so umsetzen, wenn du keine Routerkaskade vorhast (was du ja auch geschrieben hast)
Und offensichtlich kannst du den WAN-Port den SwitchPorts hinzufügen:
https://www.dd-wrt.com/wiki/index.php/WAN_Port
Das allerdings nur so umsetzen, wenn du keine Routerkaskade vorhast (was du ja auch geschrieben hast)
Und offensichtlich kannst du den WAN-Port den SwitchPorts hinzufügen:
https://www.dd-wrt.com/wiki/index.php/WAN_Port
...ist jeweils nur ein Kabel gezogen.
Das ist gut und richtig !ddwrt Konfiguration. Hoffe Ihr könnt mir hierbei auch noch helfen.
Im Tutorial hast du ja die entsprechenden Screenshots. Damit klappte das hier fehlerfrei auf einem WRT54.Allerdings erst nach einen Reboot
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
So, nachdem ich wieder mehrere Stunden damit verbracht habe und es immer noch nicht funktionert, bitte ich Euch nochmal um Hilfe.
Der ddwrt ist soweit konfiguriert, dass an port 2 bis port 4 die vlans 12 - 14 geschaltet sind und auh dhcp mit eigenem subnetz geschaltet ist.
Wenn ich mich auf die Konsole des ddwrt schalte, kann ich die gateways 192.168.12.1 (v12), 192.168.13.1 (v13) und 192.168.14.1 (v14) sowie die IP 192.168.150.254 im vlan1 und sogar die IP 192.168.150.1 der Fritzbox anpingen.
Allerdings schaffe ich es nicht den switch anzupingen, der an port1 des ddwrt angeschlossen ist.
Wenn ich einen Rencher an die Ports 2-4 des ddwrt anschliesse, dann bekomme ich über dhcp auch die ensprechend richtige IP des VLANs zugewiesen. Allerdings nicht am Port 1 sowie am WAN Port, der ja zum ddwrt Switchport geschaltet ist.
Hier habe ich sicherlich noch einen Fehler bei der Konfiguration, allerdings welchen? Bin langsam am verzweifeln! Hab die Tutorials mehrfach durchgelesen, aber bekomme den Fehler nicht raus.
Das habe ich so gedeutet, dass für Vlan 12-14 der Port1 getagged sein muss und für vlan1 eben nicht.
Dafür ist vlan1 der LAN Bridge zugewiesen. Wie erkennt der ddwrt, dass das für die Ports 1 und WAN gilt, wenn ich bei Port1 für vlan1 keinen Haken setzen darf?
Ist hier der Fehler?
Meine Konfiguration sieht wie folgt aus, findet Ihr einen Fehler?
Routingtabelle hat sich wohl selbst angelegt und sieht so aus:
Nochmal eine allgemeine Frage zum Verständnis bezüglich Router-Kaskade:
Bei einer Kaskade habe ich gelesen, dass aus dem Fritz-Netz keine Zugriff auf das Netz hinter dem WAN Port des ddwrt stattfinden können. Wird das durch das Setzen der statischen Routen in der FB im obigen Beispiel dennoch erreicht?
Der ddwrt ist soweit konfiguriert, dass an port 2 bis port 4 die vlans 12 - 14 geschaltet sind und auh dhcp mit eigenem subnetz geschaltet ist.
Wenn ich mich auf die Konsole des ddwrt schalte, kann ich die gateways 192.168.12.1 (v12), 192.168.13.1 (v13) und 192.168.14.1 (v14) sowie die IP 192.168.150.254 im vlan1 und sogar die IP 192.168.150.1 der Fritzbox anpingen.
Allerdings schaffe ich es nicht den switch anzupingen, der an port1 des ddwrt angeschlossen ist.
Wenn ich einen Rencher an die Ports 2-4 des ddwrt anschliesse, dann bekomme ich über dhcp auch die ensprechend richtige IP des VLANs zugewiesen. Allerdings nicht am Port 1 sowie am WAN Port, der ja zum ddwrt Switchport geschaltet ist.
Hier habe ich sicherlich noch einen Fehler bei der Konfiguration, allerdings welchen? Bin langsam am verzweifeln! Hab die Tutorials mehrfach durchgelesen, aber bekomme den Fehler nicht raus.
Wenn ein Port für ein oder mehrere VLANs auf tagged gesetzt wird, muss er gleichzeitig auf für ein VLAN auf untagged gesetzt werden, i.d.R. ist das das Default-VLAN.
Das habe ich so gedeutet, dass für Vlan 12-14 der Port1 getagged sein muss und für vlan1 eben nicht.
Dafür ist vlan1 der LAN Bridge zugewiesen. Wie erkennt der ddwrt, dass das für die Ports 1 und WAN gilt, wenn ich bei Port1 für vlan1 keinen Haken setzen darf?
Ist hier der Fehler?
Meine Konfiguration sieht wie folgt aus, findet Ihr einen Fehler?
Routingtabelle hat sich wohl selbst angelegt und sieht so aus:
Nochmal eine allgemeine Frage zum Verständnis bezüglich Router-Kaskade:
Bei einer Kaskade habe ich gelesen, dass aus dem Fritz-Netz keine Zugriff auf das Netz hinter dem WAN Port des ddwrt stattfinden können. Wird das durch das Setzen der statischen Routen in der FB im obigen Beispiel dennoch erreicht?
Allerdings schaffe ich es nicht den switch anzupingen, der an port1 des ddwrt angeschlossen ist.
WO und WIE ist dieser Switch genau angeschlossen ?? Im gleichen Netz wie die FB also im .150.0er VLAN ?Bedenke hierbei immer das das Management Interface des Switches untagged im VLAN 1 liegt und der Switch auch einen Gateway Eintrag haben muss.
Pingst du vom DD-WRT z.B. mit einer Absender IP von 192.168.12.1 könnte der Switch ohne Gateway Eintrag auf den DD-WRT niemals antworten...logisch.
Hier nochmal die Frage zum Rückweg:
Kannst du auch von der FB direkt oder irgend einem Client im .150.0er Netz:
a.) Die FP .1 anpingen ?
b.) den DD-WRT .254 anpingen ?
c.) eins der VLAN IPs .12.1 usw. anpingen ?
Das wäre wichtig zu wissen und... welches Gateway dieser Client eingestellt hat ? .150.1 die FB oder .150.254 den DD-WRT.
Wenn es die FB ist musst du hier logischerweise 3 statische Routen haben:
192.168.12.0 255.255.255.0 GW: 192.168.150.254
192.168.13.0 255.255.255.0 GW: 192.168.150.254
192.168.14.0 255.255.255.0 GW: 192.168.150.254
Kannst du auch bequem abkürzen mit einer einzigen Summary Route:
192.168.0.0 255.255.240.0 GW: 192.168.150.254
Das routet dir dann alle IP Netze von .0.0 bis .15.0 auf den DD-WRT !
Diese Route(n) entfallen wenn der DD-WRT im .150.0er Netz DHCP macht, weil er sich dann selber als Gateway propagiert. Schaden kann es aber nicht sie auf der FB zu belassen...just in case.
Auch hier wieder die Frage: Klappt die DHCP Adressvergabe vom DD-WRT im .150.0er Netz ?
Keiner deiner DD-WRT Ports ist tagged. Deshalb die weitere Frage WIE der Switch angebunden ist ? So wie es aussieht ziehst du ja steinzeitmässig 4 Strippen also jeweils eine pro VLAN statt einen .1q tagged Uplink, ist das richtig ?
Das die FB zu pingen ist erstmal ein gutes Zeichen.
WO und WIE ist dieser Switch genau angeschlossen ?? Im gleichen Netz wie die FB also im .150.0er VLAN ?
Bedenke hierbei immer das das Management Interface des Switches untagged im VLAN 1 liegt und der Switch auch einen Gateway Eintrag haben muss.
Bedenke hierbei immer das das Management Interface des Switches untagged im VLAN 1 liegt und der Switch auch einen Gateway Eintrag haben muss.
Ja, im 150.0 VLAN1.
Der Switch ist mit seinem Port 8 (VLAN1 untagged) am Port 1 des ddwrt angesschlossen. Und der ddwrt (150.254) ist über WAN (als Switchport konfiguriert) mit der Fritzbox verbunden.
Switch-IP ist 150.5 und Gateway ist 150.1, also die Fritzbox.
Pingst du vom DD-WRT z.B. mit einer Absender IP von 192.168.12.1 könnte der Switch ohne Gateway Eintrag auf den DD-WRT niemals antworten...logisch.
Hier nochmal die Frage zum Rückweg:
Kannst du auch von der FB direkt oder irgend einem Client im .150.0er Netz:
a.) Die FP .1 anpingen ?
b.) den DD-WRT .254 anpingen ?
c.) eins der VLAN IPs .12.1 usw. anpingen ?
Das wäre wichtig zu wissen und... welches Gateway dieser Client eingestellt hat ? .150.1 die FB oder .150.254 den DD-WRT.
Kannst du auch von der FB direkt oder irgend einem Client im .150.0er Netz:
a.) Die FP .1 anpingen ?
b.) den DD-WRT .254 anpingen ?
c.) eins der VLAN IPs .12.1 usw. anpingen ?
Das wäre wichtig zu wissen und... welches Gateway dieser Client eingestellt hat ? .150.1 die FB oder .150.254 den DD-WRT.
a), b) und c): JA, der Client hat die FB .150.1. als Gateway.
Wenn es die FB ist musst du hier logischerweise 3 statische Routen haben:
192.168.12.0 255.255.255.0 GW: 192.168.150.254
192.168.13.0 255.255.255.0 GW: 192.168.150.254
192.168.14.0 255.255.255.0 GW: 192.168.150.254
192.168.12.0 255.255.255.0 GW: 192.168.150.254
192.168.13.0 255.255.255.0 GW: 192.168.150.254
192.168.14.0 255.255.255.0 GW: 192.168.150.254
Ja, habe ich auch so.
Auch hier wieder die Frage: Klappt die DHCP Adressvergabe vom DD-WRT im .150.0er Netz ?
Nein, das ist ja mein Problem, obwohl der DCHP im Setup eingeschaltet ist.Keiner deiner DD-WRT Ports ist tagged. Deshalb die weitere Frage WIE der Switch angebunden ist ? So wie es aussieht ziehst du ja steinzeitmässig 4 Strippen also jeweils eine pro VLAN statt einen .1q tagged Uplink, ist das richtig ?
Dann verstehe ich die grundsätzliche VLAN Konfigaration des ddwrt nicht!
Ich deute das Häckchen Tagged unter Port 1 so, dass die VLANs 12,13,14 am Port 1 getagged sind.
Habe ich ein grundsätzliches Verständnisproblem ? Der Haken ist doch in Deinem o.g. Tutorial auch so gesetzt?
Nur verstehe ich nicht was das für VLAN1 bedeutet (siehe Frage oben).
Ist Port 1 im VLAN 1 tagged oder untagged?
Deshalb die weitere Frage WIE der Switch angebunden ist ? So wie es aussieht ziehst du ja steinzeitmässig 4 Strippen also jeweils eine pro VLAN statt einen .1q tagged Uplink, ist das richtig ?
Nein, das habe ich doch oben schon mehrmals geschrieben. Es gibt nur jeweils ein Kabel zwischen FB, ddwrt und Swichtes. Deshalb mach ich mir ja den ganzen Stress.
Welchen Router hast du als Basis für den DD-WRT genommen?
Wenn ich mir mal folgende Seite anschaue, wäre es denkbar, dass deine Hardware gar kein 802.1q (VLan Trunk) supportet
https://www.dd-wrt.com/wiki/index.php/VLAN_Support
Dann wäre es allerdings auch klar, warum du nicht mehrere VLANs über ein phys. Medium bekommst
Wenn ich mir mal folgende Seite anschaue, wäre es denkbar, dass deine Hardware gar kein 802.1q (VLan Trunk) supportet
https://www.dd-wrt.com/wiki/index.php/VLAN_Support
Dann wäre es allerdings auch klar, warum du nicht mehrere VLANs über ein phys. Medium bekommst
Hardware ist ein Linksys WRT54GL v1.1, laut Liste sollte der 802.1q beherrschen.
Das Porblem ist halt wie oben schon geschrieben, dass der Port 1 keine IP über DHCP vergibt, wohingegen der WAN Port dies tut und beide sollten eigentlich gleich geschaltet sein.
Selbst wenn ich dem Rechner am port1 eine feste IP zuweise, bekomme ich keine Verbindung zum ddwrt, scheint als ob der Port 1 tot wäre.
Das Porblem ist halt wie oben schon geschrieben, dass der Port 1 keine IP über DHCP vergibt, wohingegen der WAN Port dies tut und beide sollten eigentlich gleich geschaltet sein.
Selbst wenn ich dem Rechner am port1 eine feste IP zuweise, bekomme ich keine Verbindung zum ddwrt, scheint als ob der Port 1 tot wäre.
Hmm...
habe selbst gerade kein DD-WRT zur Hand, aber wenn ich mir dieses HowTo mal so betrachte... schalte am Switch den Port (8?), an dem der DD-WRT ankommt, für das VLAN1 auch auf tagged, während du deinen Port 1 am dd-wrt ebenfalls für alle vier VLANs setzt und unten den Haken bei Tagged aktivierst.
Ich nehme mal stark an, die Kiste kann nicht differenzieren zwischen VLAN a-d = tagged und VLAN z (als Default VLAN) = untagged
Das würde jedenfalls erklären, warum bei einer direkten Verdrahtung kein Endgerät mit den eingehenden Paketen klar kommt und du dadruch keinerlei DHCP-ADressen an Port 1 abbekommst.
Setz an deinem Laptop mal ein WireShark ein und hänge dich direkt an Port 1 des DD-WRT und schaue mal, was da so ankommt, speziell die Ethernet-Frames
habe selbst gerade kein DD-WRT zur Hand, aber wenn ich mir dieses HowTo mal so betrachte... schalte am Switch den Port (8?), an dem der DD-WRT ankommt, für das VLAN1 auch auf tagged, während du deinen Port 1 am dd-wrt ebenfalls für alle vier VLANs setzt und unten den Haken bei Tagged aktivierst.
Ich nehme mal stark an, die Kiste kann nicht differenzieren zwischen VLAN a-d = tagged und VLAN z (als Default VLAN) = untagged
Das würde jedenfalls erklären, warum bei einer direkten Verdrahtung kein Endgerät mit den eingehenden Paketen klar kommt und du dadruch keinerlei DHCP-ADressen an Port 1 abbekommst.
Setz an deinem Laptop mal ein WireShark ein und hänge dich direkt an Port 1 des DD-WRT und schaue mal, was da so ankommt, speziell die Ethernet-Frames
Hab am Switch den port 8 auf tagged gesetzt. Leider immer noch kein Erfolg.
Aufzeichnung mit Wireshark, kommt nicht viel an, nur ein Paket, kann aber nichts damit anfangen.
Aufzeichnung mit Wireshark, kommt nicht viel an, nur ein Paket, kann aber nichts damit anfangen.
Hmm..
gemäß dem obigen Link müsstest du wohl auch die VLANs 2 - 11 am Port 1 am DD-WRT mit anhaken.
Zumindest hat es der AUto im o.g. blog so realisiert. Er will eigentlich nur VLAN 1, 3, 4 und 5 verwenden, hat/ musste wohl aber auch das VLAN2 mit auswählen...
wobei sich das dann aber nicht mit @aquis HowTo deckt: VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Allerdings will er am Port 1 auch kein untagged VLAN und tagged VLANs parallel nutzen...
gemäß dem obigen Link müsstest du wohl auch die VLANs 2 - 11 am Port 1 am DD-WRT mit anhaken.
Zumindest hat es der AUto im o.g. blog so realisiert. Er will eigentlich nur VLAN 1, 3, 4 und 5 verwenden, hat/ musste wohl aber auch das VLAN2 mit auswählen...
wobei sich das dann aber nicht mit @aquis HowTo deckt: VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Allerdings will er am Port 1 auch kein untagged VLAN und tagged VLANs parallel nutzen...
Nein auch das setzen der vlans2-11 auf tagged am port1 ändert nichts.
Ich kann jedoch durch vorherige Einstellung am Switch 1 ( Port 8 im Clan 1 auf tagged) vom ddwrt jetzt den dahinter liegenden switch2 sowie die angeschlossenen Clients anpingen.
Switch1 ist nach wie vor nicht anpingen
Ich kann jedoch durch vorherige Einstellung am Switch 1 ( Port 8 im Clan 1 auf tagged) vom ddwrt jetzt den dahinter liegenden switch2 sowie die angeschlossenen Clients anpingen.
Switch1 ist nach wie vor nicht anpingen
Wenn ich mir mal folgende Seite anschaue, wäre es denkbar, dass deine Hardware gar kein 802.1q (VLan Trunk) supportet
Der WAN Port ist so oder so immer besonders, denn der hängt NICHT an dem embeddeten 4 Port Switch.Fraglich ob dort überhaupt eine Layer 2 Verbindung auf die Ports des 4 Port Switches (ich gehe mal von einem WRT54 aus) möglich ist. Ich denke nicht oder wenn dann nur über die Option eines Bridging Interfaces in Software. Ob damit dann auch Tags übertragen werden ist eine andere Frage.
Das Tutorial nutzt den WAN Port rein als Punkt zu Punkt Port für einen kaskadierten Router ins Internet und macht das gesamte VLAN Handling nur auf den LAN Ports die dem integrierten Switchport zugewiesen sind.
Das funktioniert fehlerlos.
Ich kann da gerne auch nochmal einen Labortest machen....
Der WAN Port ist so oder so immer besonders, denn der hängt NICHT an dem embeddeten 4 Port Switch.
Könnte ich dann die Probleme evtl. umgehen, in dem ich dann doch die Variante mit der Routerkaskade nehme oder aber ich bleibe bei dieser Variante und wickel das ganze ohne den WAN Port ab. Also an Port1 kommt die FB rein und Port 2 am ddwrt geht dann zum switch.
Ich kann da gerne auch nochmal einen Labortest machen....
Das wäre natürlcih super, wenn ein Experte das prüfen kann.Zitat von @sonyandi:
Könnte ich dann die Probleme evtl. umgehen, in dem ich dann doch die Variante mit der Routerkaskade nehme oder aber ich bleibe bei dieser Variante und wickel das ganze ohne den WAN Port ab. Also an Port1 kommt die FB rein und Port 2 am ddwrt geht dann zum switch.
Der WAN Port ist so oder so immer besonders, denn der hängt NICHT an dem embeddeten 4 Port Switch.
Könnte ich dann die Probleme evtl. umgehen, in dem ich dann doch die Variante mit der Routerkaskade nehme oder aber ich bleibe bei dieser Variante und wickel das ganze ohne den WAN Port ab. Also an Port1 kommt die FB rein und Port 2 am ddwrt geht dann zum switch.
Warum steckst du die FritzBox nicht einfach mit an den Netgear Switch und machst an dem Port, an dem die Fritte hängt, ein untagged VLAN1 und lässt das gefriermel mit dem WAN-Port weg!?
Edit:
Satzbau begradigt
in dem ich dann doch die Variante mit der Routerkaskade nehme
War das nicht so oder so dein Ziel ?? Dein Thread trägt ja die Überschrift "...mit dd-wrt hinter FritzBox". Das impliziert doch das du eine Kaskade machst, oder verstehen wir da jetzt was grundsätzlich falsch ?!...und lässt das gefriereml mit dem WAN-Port weg!?
Eben. Vom WAN Port sollte nur eine einzige Strippe zur FB gehen. Da reicht ein Kabel, ist ja so oder so ne Punkt zu Punkt Verbindung ?!Warum soll da unbedingt ein Switch dazwischen ?
Wenn du das zwingen machen musst, dann ist es besser das WAN Port VLAN nicht über eine tagged Verbindung mit zu übertragen. Dann nutze da besser konservativ ein Kabel.
Sprich also ein isoliertes VLAN mit 2 untagged Ports einrichten. In einen steckst du den WAN Port DD-WRT und in den anderen die FB.
Die lokalen VLAN legst du dann auf einen tagged Link des embeddeten 4 Port Switches den du an einen tagged Port der anderen lokalen VLANs am Switch terminierst.
Das sind dann zwar 2 Strippen statt einer ist aber eine sicherere Konfig ohn Frickelei.
Werde eure Lösungsansätze versuchen am WE umzusetzten.
Vielen Dank fürs erste für eure hilfreichen Kommentare.
Vielen Dank fürs erste für eure hilfreichen Kommentare.
Wir sind gespannt...
So, melde mich wieder zurück.
Nachdem ich die letzten Tage wieder mehrere Stunden, damit verbracht habe eine Lösung zu finden und keine Konstellation zum Erfolg geführt hat, habe ich mich entschieden den ddwrt aus dem Netzwerk zu nehmen.
Ich habe fast alle Konfigurationen ausprobiert und getestet leider ohne Erfolg.
Ich bin jetzt wieder bei dem Punkt als ich den Thread aufgemacht habe, also Fritzbox (P1) an Switch1 (P8) und von Switch 1 (P1) an Switch 2 (P5).
Allerdings habe ich diesmal die Verbindungen im VLAN 1 alle auf untagged, sowohl zur Fritzbox als auch zwischen den Switches. Tagged ist nur VLAN12,13,14 auf den Ports 1 und 8 auf Switch1 sowie auf den Ports 5 und 1 auf Switch2.
Eben so wie es em-pie witer oben beschrieben hat.
Was soll ich sagen? Jetzt scheint es zu funktionieren. Angeschlossene Clients an der FB (auch über WLAN) haben Zugriff auf alle VLANs. Die Clients an den Switches haben nur Verbindung zu den Clients im jeweils gleichen VLAN und bekommen auch eine Verbindung zu den Clients die an der FB hängen.
Zumindest hatte ich mir das so vorgestellt: Die VLANs 12, 13, 14 sollten getrennte Netze sein, die jeweils keine Verbindung zum anderes VLAN herstellen können und im WLAN möchte ich auf alles zugreifen können.
Das ganze funktioniert im gleichen Subnetz und die FB verteilt über DHCP alle IPs auch in den VLANs. Wieso, weiß ich nicht. Laut den obigen Kommentaren sollte das ja nicht funktionieren oder ich hab das irgendwie falsch verstanden.
Auf jeden Fall Danke nochmals an em-pie und aqui für eure Zeit und Hilfe.
Hier nochmal eine Skizze über den Aufbau, sowie die Konfiguration der Switches:
Nachdem ich die letzten Tage wieder mehrere Stunden, damit verbracht habe eine Lösung zu finden und keine Konstellation zum Erfolg geführt hat, habe ich mich entschieden den ddwrt aus dem Netzwerk zu nehmen.
Ich habe fast alle Konfigurationen ausprobiert und getestet leider ohne Erfolg.
Ich bin jetzt wieder bei dem Punkt als ich den Thread aufgemacht habe, also Fritzbox (P1) an Switch1 (P8) und von Switch 1 (P1) an Switch 2 (P5).
Allerdings habe ich diesmal die Verbindungen im VLAN 1 alle auf untagged, sowohl zur Fritzbox als auch zwischen den Switches. Tagged ist nur VLAN12,13,14 auf den Ports 1 und 8 auf Switch1 sowie auf den Ports 5 und 1 auf Switch2.
Eben so wie es em-pie witer oben beschrieben hat.
Was soll ich sagen? Jetzt scheint es zu funktionieren. Angeschlossene Clients an der FB (auch über WLAN) haben Zugriff auf alle VLANs. Die Clients an den Switches haben nur Verbindung zu den Clients im jeweils gleichen VLAN und bekommen auch eine Verbindung zu den Clients die an der FB hängen.
Zumindest hatte ich mir das so vorgestellt: Die VLANs 12, 13, 14 sollten getrennte Netze sein, die jeweils keine Verbindung zum anderes VLAN herstellen können und im WLAN möchte ich auf alles zugreifen können.
Das ganze funktioniert im gleichen Subnetz und die FB verteilt über DHCP alle IPs auch in den VLANs. Wieso, weiß ich nicht. Laut den obigen Kommentaren sollte das ja nicht funktionieren oder ich hab das irgendwie falsch verstanden.
Auf jeden Fall Danke nochmals an em-pie und aqui für eure Zeit und Hilfe.
Hier nochmal eine Skizze über den Aufbau, sowie die Konfiguration der Switches:
Zumindest hatte ich mir das so vorgestellt: Die VLANs 12, 13, 14 sollten getrennte Netze sein, die jeweils keine Verbindung zum anderes VLAN herstellen können
Wenn genau DAS deine Intention war hätten wir uns die gesamte Eierei mit dem DD-WRT ja auch gleich von Anfang an sparen können !!!Einen Router brauchst du in den VLANs einzig und allein nur dann wenn du auch VLAN übergreifend kommunizieren willst. Will man das nicht ist der Router überflüssig.
Soll das, wie jetzt bei dir, gar nicht der Fall sein, dann hast du mit den VLANs 12, 13 und 14 drei vollkommen isolierte Netze. Genau also dein Ziel.
Die Internet / FritzBox Kommunikation findet dann nun ausschliesslich nur noch im VLAN 1 statt. Dir sollte aber auch klar sein das so keinerlei Zugriff auf die VLANs 12, 13 und 14 je möglich sein wird.
Weder zw. den VLANs untereinander, noch von den VLANs ins Internet, noch aus VLAN 1. Das ist in dieser jetzigen Konstellation technisch ausgeschlossen.
Wenn das eh dein Ziel war mit 3 isolierten Netzen...alles gut ! Wie gesagt diese Lösung hättst du schneller haben können
Bleibt dann die Frage warum du uns mit dem DD-WRT und L3 VLAN Routing vorher an der Nase rumgeführt hast ???
Die Internet / FritzBox Kommunikation findet dann nun ausschliesslich nur noch im VLAN 1 statt. Dir sollte aber auch klar sein das so keinerlei Zugriff auf die VLANs 12, 13 und 14 je möglich sein wird.
Weder zw. den VLANs untereinander, noch von den VLANs ins Internet, noch aus VLAN 1. Das ist in dieser jetzigen Konstellation technisch ausgeschlossen.
Weder zw. den VLANs untereinander, noch von den VLANs ins Internet, noch aus VLAN 1. Das ist in dieser jetzigen Konstellation technisch ausgeschlossen.
Warum soll das nicht gehen ?
Also von der FB zu den VLANS 12,13,14 und zurück bekomme ich eine Verbindung hin, ebenso komme ich von den VLANS ins Internet.
Nur eben zwischen den VLANS 12,13,14 untereinander bekomme ich keine Verbindung hin, das war ja auch mein Ziel.
Die VLANs sollen den gleichen Internetzugang über die FB nutzen und aus der FB möchte ich auf alle VLANs zugreifen können.
Bleibt dann die Frage warum du uns mit dem DD-WRT und L3 VLAN Routing vorher an der Nase rumgeführt hast ???
Sorry, war keine Absicht. Bin davon ausgegangen, dass zum VLAN dazugehört, da ich auch bevor ich den Thread aufgemacht habe, das ganze ohne versucht habe und dennoch auf die Schnauze gefallen bin. Irgendwo habe ich dann gelesen, dass ein VLAN mit der FB ohne "VLAN Manager" nicht möglich ist. Dann erst kam der ddwrt ins Spiel.
Warum soll das nicht gehen ?
Dazu liest du dir die VLAN Schnellschulung einmal durch:Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet
VLANs sind auf einem reinen Layer 2 VLAN Switch also immer in sich vollkommen getrennte Netze ! Eine Kommunikation zw. den VLANs ist auf einem reinen Layer 2 Switch technisch unmöglich.
Das ist also Fakt. Das ist z.B. bei 3 VLANs so zu sehen als ob du 3 einzelnen Switches hast mit jeweils einem Netz die NICHT miteinander verbunden sind. Da ist ,ebenso wie bei VLANs, keinerlei Kommunikation möglich.
Leuchtet dir sicher auch ein, oder ?
Du brauchst also wenn du zw. den VLAN kommunizieren willst IMMER einen Router.
Das kann ein Layer 3 Switch sein (also der Router im Switch) oder ein externer Router oder Firewall (siehe Tutorial)
Ohne das geht es de facto nicht...wie auch bei einer vollkommen physischen Trennung der VLAN Netze ?!
Nur eben zwischen den VLANS 12,13,14 untereinander bekomme ich keine Verbindung hin
Vollkommen logisch OHNE einen Router. Nur mal doof nachgefragt: Das grundlegende Konzept von VLANs hast du aber verstanden, oder ? (VLAN Schnellschulung oben)und dennoch auf die Schnauze gefallen bin
Dafür gibts ja uns und das Forum dass ein VLAN mit der FB ohne "VLAN Manager" nicht möglich ist. Dann erst kam der ddwrt ins Spiel.
Das ist auch richtig. Die FB kann generell keinerlei VLANs weil sie dieses Feature gar nicht an Bord hat und somit auch nicht kennt.Da hilft dann in der Tat nur eine andere HW die VLANs supportet wie die im o.a. Tutorial genannten üblichen Verdächtigen.
Ein kleiner 35 Euro Mikrotik Router würde deine Anforderungen in 10 Minuten erledigen:
http://varia-store.com/Wireless-Systeme/MikroTik-RouterBoard/MikroTik-R ...
VLANs sind auf einem reinen Layer 2 VLAN Switch also immer in sich vollkommen getrennte Netze ! Eine Kommunikation zw. den VLANs ist auf einem reinen Layer 2 Switch technisch unmöglich.
Das ist also Fakt. Das ist z.B. bei 3 VLANs so zu sehen als ob du 3 einzelnen Switches hast mit jeweils einem Netz die NICHT miteinander verbunden sind. Da ist ,ebenso wie bei VLANs, keinerlei Kommunikation möglich.
Leuchtet dir sicher auch ein, oder ?
Das ist also Fakt. Das ist z.B. bei 3 VLANs so zu sehen als ob du 3 einzelnen Switches hast mit jeweils einem Netz die NICHT miteinander verbunden sind. Da ist ,ebenso wie bei VLANs, keinerlei Kommunikation möglich.
Leuchtet dir sicher auch ein, oder ?
Soweit habe ich das auch verstanden, das will ich ja auch, dass die VLANs 12,13,14 untereinander keine Kommunikation haben.
Nur mal doof nachgefragt: Das grundlegende Konzept von VLANs hast du aber verstanden, oder ? (VLAN Schnellschulung oben)
Ich denke schon. Bei mir hapert es nur noch bei der Kommunikation von den VLANs 12,13,14 von und zur Fritzbox. Du hast geschrieben, dass aus diesen VLANS keine Verbindung zur FB und Internet stattfinden kann, aber genau das will ich. Und in der momentanen Konstellation funktioniert das auch bei 2 Clients nur beim dritten komischerweise nicht.
Also ich habe das so verstanden, wenn ich bspw. vom Smartphone über das WLAN der FB auf einen Client im VLAN 12 zugreifen möchte, dann kommt von der FB das Paket untagged an Port 8 des Switch1 an und wird durch die PVID mit ID 1 versehen. Durch die Mitgliedschaft von Vlan 1 mit den Ports 1-8 wird das Paket u.a. auch an Port 2 was ja Mitglied von V1 und V12 ist weitergeleitet.
Ebenso stelle ich mir den Rückweg so vor: Wenn vom Client eine Internetseite aufgerufen wird, dann wird das eingehende Paket am Port 2 des Switch1 wegen PVID 12 mit der ID 12 versehen und entsprechend der Mitgliedschaft von V12 an die Ports 1, 2, 5 und 8 weitergeleitet.
Liegt evtl. hier mein Verständnisproblem? Wie wird das eingehende Paket an Port 8 verarbeitet?
Benötige ich für diese Konstellation tatsächlich noch einen L3 Router?
das will ich ja auch, dass die VLANs 12,13,14 untereinander keine Kommunikation haben.
Dann sind wir uns ja alle einig und dann brauchst du keinen Router Bei mir hapert es nur noch bei der Kommunikation von den VLANs 12,13,14 von und zur Fritzbox.
Wie gesagt, die kann es NICHT geben ! Wie auch, denn die 3 VLANs sind ,wie wir oben ja nun schon gemeinsam festgestellt haben, vollkommen isoliert.Du kannst die FB in VLAN 12 stecken (PVID 12), dann kann sie mit VLAN 12 reden aber niemals mit 13 und 14. Logisch, denn die VLANs sind ja...genau !! Vollkommen getrennt !!
Wenn du sie in 13 steckst sind 12 und 14 trotzdem isoliert. Gleiches Spiel, jedes VLAN ist ein vollständig isoliertes Netz das haben wir ja nun verstanden.
Die FB bräuchte 3 Router Interfaces, dann könnte man sie mit einem Bein ins 12er, mit einem ins 13er und mit einem ins 14er stec ken und hätte die Lösung !
Kann die FritzBox aber nicht, da sie durch ihre HW Beschränkung nur einen einzigen Routerport hat (LAN)
3 Strippen Lösung entfällt also auch.
Alternativ kann man das mit einem tagged Uplink machen (hatten wir oben ja schon durchgekaut mit dir und dem DD-WRT) und die 3 VLANs dann auf 3 logische Subinterfaces in der FB terminieren wie im o.a. VLAN Tutorial im Detail beschrieben.
Würde gehen, aber auch das supportet die FB nicht. Ihr fehlt das VLAN Feature !
Was willst du also machen...?? Mit FB ist das nicht zu lösen.
Fazit:
Wie man es dreht oder wendet, mit der FritzBox bekommt man es NICHT gelöst weil ihr alle diese technischen Fähigkeiten fehlen die man für eine Lösung braucht.
Das leuchtet sicher auch dir ein, oder ?
Zu deinem Punkten im Einzelnen:
wenn ich bspw. vom Smartphone über das WLAN der FB auf einen Client im VLAN 12 zugreifen möchte, dann kommt von der FB das Paket untagged an Port 8 des Switch1
Das hast du richtig verstanden !Mal ganz davon abgesehen das die FritzBox NIEMALS getaggte Pakete senden können wird weil...du ahnst es schon... GENAU !! ...sie supportet KEIN VLAN Tagging weil ihr wie oben schon mehrfach gesagt das Feature dazu fehlt in der Firmware !!! Sie kann also getaggte Pakete weder senden noch kann sie sie lesen.
Das WLAN ist mit einer Bridge intern in der FB einfach an den LAN Port verbunden. Somit sind WLAN und LAN immer ein gemeinsames IP Netz, verhalten sich also wie ein Draht.
Klar, die Pakete kommen dann untagged am Switchport an der es ins VLAN 12 schickt. Dort kannst du alles erreichen aber VLAN 13 und 14 sind ja...tadaaa, du ahnst was kommt...isoliert !! Keine Chance also für Pakete dahin zu kommen weder Bridging noch Routing !
Ein Switchport kann NIEMALS untagged Mitglied zweier VLANs sein, das ist technisch unmöglich. Geht nur tagged aber Tagging kann die FB wieder nicht lesen...siehe oben !
Wie wird das eingehende Paket an Port 8 verarbeitet?
Durch die Switch PVID bestimmst du in welches VLAN des Switches diese eingehenden ungetaggten Pakete geforwardet werden. Mehr nicht.Der Switch kann es also nur entweder in 12 oder 13 oder 14 forwarden niemals aber in mehrere VLANs.
Ist ja auch logisch, weil dann die Layer 2 Domains der VLANs überlappen würden was tödlich wäre.
Hier ist das Mysterium PVID erklärt:
Warum gibt es PVID bei VLANs?
Hope this helps...?!
Hallo aqui,
sorry wenn ich lästig bin, aber muss nochmal genau nachhaken um es richtig zu verstehen.
Warum gerade V12 ?
Wenn wie in meinem Beispiel das Paket an Port 8 ankommt und dieser die PVID 1 hat dann wird das Paket mit VLAN-ID 1 versehen, richtig ? Dann dürfte das doch nicht mit 12 kommunizieren, sondern laut deiner Erläuterung nur im V1 bleiben, oder ?
Und wie ist in diesem Zusammenhang die Mitgliedschaft zu verstehen ? Ein Port der Mitglied in V1 und V13 ist, so deute ich es, kann mit beiden VLANs kommunizieren, oder ?
Und was bewirkt solch eine Konfiguration, wenn Port 5 mit PVID 12 in V12 und V13 als Member eingetragen ist? Wird dann die Mitgliedschaft in V13 nicht beachtet, obwohl ich es so hinterlegen kann. Das wäre sehr irreführend und der Grund für meine Verständinsschwiereigkeiten. Oder ist es so, dass der an Port 5 angeschlossenen Client mit V12 und V13 kommunizieren kann?
Aber wie entscheidet Port 8, der ja PVID 1 hat, ob er in V12, 13 oder 14 forwarded? Laut den Angaben oben sollte alles in V1 bleiben.
Apropos, hab mir den Mikrotic hap ac bestellt, der hat gigabit und WLAN.
sorry wenn ich lästig bin, aber muss nochmal genau nachhaken um es richtig zu verstehen.
Klar, die Pakete kommen dann untagged am Switchport an der es ins VLAN 12 schickt. Dort kannst du alles erreichen aber VLAN 13 und 14 sind ja...tadaaa, du ahnst was kommt...isoliert !! Keine Chance also für Pakete dahin zu kommen weder Bridging noch Routing !
Warum gerade V12 ?
Wenn wie in meinem Beispiel das Paket an Port 8 ankommt und dieser die PVID 1 hat dann wird das Paket mit VLAN-ID 1 versehen, richtig ? Dann dürfte das doch nicht mit 12 kommunizieren, sondern laut deiner Erläuterung nur im V1 bleiben, oder ?
Und wie ist in diesem Zusammenhang die Mitgliedschaft zu verstehen ? Ein Port der Mitglied in V1 und V13 ist, so deute ich es, kann mit beiden VLANs kommunizieren, oder ?
Ein Switchport kann NIEMALS untagged Mitglied zweier VLANs sein, das ist technisch unmöglich.
Vielleicht führen ja die Konfigurationmöglichkeiten im Netgear zu meinen Verständnisproblemen, aber ich kann doch bspw. Port 5 im V12 und gleichzeitig im V13 auf U setzten. Wie entscheidet dann der Switch zu welchem VLAN der Port 5 untagged gehört? Holt er sich dann das VLAN aus der PVID die Port 5 zugewiesen ist?Und was bewirkt solch eine Konfiguration, wenn Port 5 mit PVID 12 in V12 und V13 als Member eingetragen ist? Wird dann die Mitgliedschaft in V13 nicht beachtet, obwohl ich es so hinterlegen kann. Das wäre sehr irreführend und der Grund für meine Verständinsschwiereigkeiten. Oder ist es so, dass der an Port 5 angeschlossenen Client mit V12 und V13 kommunizieren kann?
Durch die Switch PVID bestimmst du in welches VLAN des Switches diese eingehenden ungetaggten Pakete geforwardet werden. Mehr nicht.
Der Switch kann es also nur entweder in 12 oder 13 oder 14 forwarden niemals aber in mehrere VLANs.
Der Switch kann es also nur entweder in 12 oder 13 oder 14 forwarden niemals aber in mehrere VLANs.
Aber wie entscheidet Port 8, der ja PVID 1 hat, ob er in V12, 13 oder 14 forwarded? Laut den Angaben oben sollte alles in V1 bleiben.
Apropos, hab mir den Mikrotic hap ac bestellt, der hat gigabit und WLAN.
sorry wenn ich lästig bin
Nee, bist du nicht. Hauptsache du verstehst es Warum gerade V12 ?
Weil das dein Beispiel war. Welche VLAN ID ist egal. kannst auch 2, 10, 77, 999 oder was auch immer nehmen. Nur größer als 4094 darf die ID niemals sein da die Range von 1 bis 4096 geht und 4095 und 4096 reserviert sind !Wenn wie in meinem Beispiel das Paket an Port 8 ankommt und dieser die PVID 1 hat dann wird das Paket mit VLAN-ID 1 versehen, richtig ?
Ja, richtig !Er forwardet dann untagged Traffic an diesem Port 8 immer ins VLAN 1, dem Default VLAN.
Ein Port der Mitglied in V1 und V13 ist, so deute ich es, kann mit beiden VLANs kommunizieren, oder ?
Ja, genau richtig !Obwohl ein Port niemals untagged mitglied in 2 VLANs sein kann.
Bei deinem Beispiel steht die PVID auf 1 and dem Port und er ist Tagged angehakt im VLAN 13.
Das bedeutet dann:
- Alle dort an Port 8 eingehenden untagged Pakete forwardet der Switch in VLAN 1
- Alle dort an Port 8 eingehenden tagged Pakete mit der ID 13 forwardet der Switch in VLAN 13
- Alle dort an Port 8 eingehenden tagged Pakete die eine Tag haben der NICHT 13 ist schmeisst der Switch in den Mülleimer.
Vielleicht führen ja die Konfigurationmöglichkeiten im Netgear zu meinen Verständnisproblemen,
Das wird sicher so sein.NetGear ist bekanntermaßen das Übelste was man sich an Konfig GUI antun kann weil massiv unlogisch. Gut wenn man von einem Cisco GUI kommt ist man vermutlich "versaut" aber es fordert doch ein gehöriges Maß an Einarbeitung bis man diese NG Logik durchdrungen hat
Ein Grund bei VLANs die Finger von NG zu lassen
Wie entscheidet dann der Switch zu welchem VLAN der Port 5 untagged gehört?
Das entscheidet er rein nach dem Setting der PVID an diesem Port. Die PVID bestimmt immer fest was der Switch mit untagged Paketen macht die an diesem Port reinkommen.Steht wie PVID auf 13 werden untagged Pakete dort ins VLAN 13 geforwardet bzw. auch alle Pakete aus dem VLAN 13 dort untagged ausgesendet. So einfach ist das. Die Port PVID ist der Schlüssel.
Und was bewirkt solch eine Konfiguration, wenn Port 5 mit PVID 12 in V12 und V13 als Member eingetragen ist?
Das dürfte nicht gehen. Ist ja auch logisch.Stell dir mal vor du hast in VLAN12 die IP 10.10.10.0 /24 und im VLAN13 aber das Netz 20.20.20.0 /24. Z.B. 10er ist ein internes, Firewall geschütztes Netz und das 20er wäre das offene Internet.
Dann würde ja Traffic aus dem 10er IP Netz ins 20er Netz geflutet und andersrum. Eine Katastrophe und tödlich aus Sicherheitssicht. Luechtet dir ein.
Wenn der Port also Member in VLAN 12 UND 13 ist dann ist das immer nur Tagged. D.h. Eingehender Traffic MUSS hier einen Tagg haben damit er sauber in die entsprechenden VLANs getrennt werden kann.
Untagged Paketen fehlt ja vollkommen eine VLAN ID so das der Switch oder ein Endgerät niemals lesen kann welchem VLAN es dieses Paket zuordnen soll.
Das geht immer und ausschliesslich nur über die VLAN ID die dem Paket anhängt !!
Bei dir in der Konfig steht ja auch klar VLAN Memebership und eben nicht PVID. Das meint dann ganz klar ein Tagging.
Also der Switch akzeptiert hier eingehende Pakete mit dem Tag 12 und 13 und forwardet sie entsprechen und sendet auch alle Pakete aus den VLANs 12 und 13 dort aus MIT einem entsprechenden VLAN Tag dieser beiden VLANs. Ganz einfach eigenlich aber üble NG Logik.
Aber wie entscheidet Port 8, der ja PVID 1 hat, ob er in V12, 13 oder 14 forwarded?
Wieder ganz einfach:- Alle dort an Port 8 ein- ausgehenden untagged Pakete forwardet der Switch in VLAN 1 (PVID 1)
- Alle dort an Port 8 ein- ausgehenden tagged Pakete mit der ID 12 forwardet der Switch in VLAN 12 (er liest die VLAN ID oder fügt sie an.)
- Alle dort an Port 8 ein- ausgehenden tagged Pakete mit der ID 13 forwardet der Switch in VLAN 13
- Alle dort an Port 8 ein- ausgehenden tagged Pakete mit der ID 14 forwardet der Switch in VLAN 14
- Alle dort an Port 8 ein- ausgehenden tagged Pakete die einen VLAN Tag haben der NICHT 12, 13 oder 14 ist schmeisst der Switch in den Mülleimer.
Apropos, hab mir den Mikrotic hap ac bestellt, der hat gigabit und WLAN.
Glückwunsch ! Eine sehr gute Wahl !Wenn der Port also Member in VLAN 12 UND 13 ist dann ist das immer nur Tagged. D.h. Eingehender Traffic MUSS hier einen Tagg haben damit er sauber in die entsprechenden VLANs getrennt werden kann.
Untagged Paketen fehlt ja vollkommen eine VLAN ID so das der Switch oder ein Endgerät niemals lesen kann welchem VLAN es dieses Paket zuordnen soll.
Das geht immer und ausschliesslich nur über die VLAN ID die dem Paket anhängt !!
Bei dir in der Konfig steht ja auch klar VLAN Memebership und eben nicht PVID. Das meint dann ganz klar ein Tagging.
Also der Switch akzeptiert hier eingehende Pakete mit dem Tag 12 und 13 und forwardet sie entsprechen und sendet auch alle Pakete aus den VLANs 12 und 13 dort aus MIT einem entsprechenden VLAN Tag dieser beiden VLANs. Ganz einfach eigenlich aber üble NG Logik.
Untagged Paketen fehlt ja vollkommen eine VLAN ID so das der Switch oder ein Endgerät niemals lesen kann welchem VLAN es dieses Paket zuordnen soll.
Das geht immer und ausschliesslich nur über die VLAN ID die dem Paket anhängt !!
Bei dir in der Konfig steht ja auch klar VLAN Memebership und eben nicht PVID. Das meint dann ganz klar ein Tagging.
Also der Switch akzeptiert hier eingehende Pakete mit dem Tag 12 und 13 und forwardet sie entsprechen und sendet auch alle Pakete aus den VLANs 12 und 13 dort aus MIT einem entsprechenden VLAN Tag dieser beiden VLANs. Ganz einfach eigenlich aber üble NG Logik.
Die Logik hat mich tatsächlich in die irre getrieben.
Prinzip verstanden ??
Danke für diese klip und klare Erklärung.
Mittlerweile ist der Mikrotik eingetroffen und ich habe erste Konfigurationsversuche unternommen.
Dazu auch diese Beiträge hinzugezogen:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
AVM Router mit Mikrotik Router für VLAN und Netgear GS724Tv4 für VLAN und Port Trunking
Mikrotik mehrere VirtualAccessPoints mit gleicher SSID
Irgendwie hab ich es noch nicht geschafft ihm die IP 192.168.150.254 zu verpassen und ins Netz einzuspeisen, werde nachher weitermachen.
Das Ding ist ja noch komplizierter als der ddwrt, hmm.
Ein kleiner 35 Euro Mikrotik Router würde deine Anforderungen in 10 Minuten erledigen:
Mal gucken wieviele Tage 10 Minuten in meiner Zeitrechnung sind Irgendwie hab ich es noch nicht geschafft ihm die IP 192.168.150.254 zu verpassen und ins Netz einzuspeisen
Das ist kinderleicht !WICHTIG dafür:
- Unbedingt das WinBox Tool installieren !!! https://download2.mikrotik.com/routeros/winbox/3.11/winbox.exe
- Die Default Konfig des Routers VORHER löschen !
Das WinBox Tool brauchst du unbedingt, da du VORHER die im Router befindliche Default Konfig löschen musst um ihn individuell zu konfigurieren.
Die Default Konfig ist unbrauchbar für dein Design (Ein Port als NAT Port und der Rest als 4 Port Switch) und muss vorher entfernt werden.
Durch das Löschen dieser Default Konfig verlierst du den DHCP Server und die IP der Default Konfig. Damit fehlt dann jegliche IP Adressierung und dann ist logischerweise das WebGUI nicht mehr ansprechbar.
Das WinBox Tool garantiert die Verbindung aber auch ohne IP Adresse, also nur mit der Mac Adresse !!
Damit kommst du dann problemlos wieder auf die Box auch ohne IP Konfig.
Dann mit entferneter Default Konfig einen Port in dein Netz hängen dann siehst du nach dem Öffnen des WinBox Tools den Mikrotik sofort durch seine Autodiscovery.
Nun mit dem Tool unter IP Adress auf diesem eth Port der im Netz hängt die IP 192.168.150.254 konfigurieren Damit hängt dann dieser Port dann mit der 192.168.150.0er in deinem Netz und ist anpingbar und auch wieder über das Web GUI und auch WinBox ansprechbar. Je nachdem welches schöner für dich ist (WinBox ist in Farbe
)Fertisch !
Achte darauf das die .150.254 nirgend woanders in Benutzung ist und auch nicht Teil eines DHCP Pools.
Der Rest steht alles im Tutorial:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Bzw. hier zur VLAN Konfig:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
In den weiterführenden Links unten findest du weitere Beispielthreads die dir die erfolgreiche Einrichtung mit Switches von HP, TP-Link und auch NetGear zeigen !
AVM Router mit Mikrotik Router für VLAN und Netgear GS724Tv4 für VLAN und Port Trunking
Wenn du diese Grundkonfig hast, dann ggf. auf die aktuelle 6.40.5 Firmware updaten um das aktuelle Firmware Image drin zu haben und ggf. Bugs zu vermeiden !
https://mikrotik.com/download
Hallo aqui,
habe jetzt den mikrotik entsprechende den Anleitungen eingerichtet.
Aus dem Fritznetz kann ich die einzelnen VLANs 192.168.15x.254 anpingen, jedoch nicht umgekehrt. Schliesse ich den Laptop an Port 2 des mikrotik kann ich nur 192.168.152.254 anpingen und keine 192.168.150.1, das sollte doch möglich sein, oder?
In der FB habe ich die Routen gesetzt und im Mikrotik sind diese, soweit ich das erkenne, auch vollständig. Im 150er Netz stellt der DHCP der FB die Adressen in den VLANs 12,13,14 der Mikrotik.
Die Fb ist am Port 1 des Mikrotik angeschlossen und Port 5 des MK geht an Port 8 des Netgear-Switches. Die Vlans 12, 13 und 14 habe ich ether5 mit angehaktem "use Service tag" zugewiesen nur bei Vlan1 habe ich das Häckchen nicht gesetzt. Unter Bridge 1 habe ich vlan1, ether1 und ether5 zusammengefasst.
Hoffe habe keinen Fehler gemacht, hier das ganze in Bildern, erkennst du einen Fehler?
habe jetzt den mikrotik entsprechende den Anleitungen eingerichtet.
Aus dem Fritznetz kann ich die einzelnen VLANs 192.168.15x.254 anpingen, jedoch nicht umgekehrt. Schliesse ich den Laptop an Port 2 des mikrotik kann ich nur 192.168.152.254 anpingen und keine 192.168.150.1, das sollte doch möglich sein, oder?
In der FB habe ich die Routen gesetzt und im Mikrotik sind diese, soweit ich das erkenne, auch vollständig. Im 150er Netz stellt der DHCP der FB die Adressen in den VLANs 12,13,14 der Mikrotik.
Die Fb ist am Port 1 des Mikrotik angeschlossen und Port 5 des MK geht an Port 8 des Netgear-Switches. Die Vlans 12, 13 und 14 habe ich ether5 mit angehaktem "use Service tag" zugewiesen nur bei Vlan1 habe ich das Häckchen nicht gesetzt. Unter Bridge 1 habe ich vlan1, ether1 und ether5 zusammengefasst.
Hoffe habe keinen Fehler gemacht, hier das ganze in Bildern, erkennst du einen Fehler?
jedoch nicht umgekehrt.
Hast du auch eine Default Route auf dem Mikrotik zur FritzBox eingerichtet ??? Sieht so aus als ob die fehlt und im Mikrotik sind diese, soweit ich das erkenne, auch vollständig.
Wieso der Plural hier ?? Routen wäre völliger Quatsch und falsch !!Der MT braucht nur eine einzige Default Route (Auf die FB) mehr nicht !!
Im 150er Netz stellt der DHCP der FB die Adressen in den VLANs 12,13,14 der Mikrotik.
Das ist richtig !Hast du mit ipconfig -all (Windows) auch mal gecheckt das das sauber passt von den Adressen ?? Gateway = MT Adresse und DNS = immer die FB Adresse ?
Hoffe habe keinen Fehler gemacht, hier das ganze in Bildern, erkennst du einen Fehler?
Klingt alles sehr gut und richtig !Das einzige was komplett unverständlich ist: Wozu brauchst du diese (überflüssigen) Bridges ?
Im VLAN Tutorial zum MT ist davon keinerlei Rede:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Wozu hast du die also da drinnen ?? Die sind alle vollkommen überflüssig. Im Gegenteil...sie gehen auf Kosten der Gesamtperformance.
So sähe eine für dich richtige Konfig aus (DHCP Server der Übersicht halber weggelassen):
Hast du auch eine Default Route auf dem Mikrotik zur FritzBox eingerichtet ??? Sieht so aus als ob die fehlt
Wieso der Plural hier ?? Routen wäre völliger Quatsch und falsch !!
Damit meine ich die Routen für die einzelnen VLANSWozu brauchst du diese (überflüssigen) Bridges ?
Ich möchte gerne die ports 2-4 am Mikrotik den einzelnen VLANS zuordnen, später möchte ich auch WLAN AP den VLANS zuweisen, das sollte doch auch möglich sein.Daher habe ich die Bridges konfiguriert, oder ist das falsch und wird anders konfiguriert?
Habe jetzt den Service Tag bei den VLAN an Port 5 wieder entfernt, sowie vlan1 komplett gelöscht und auch die bridges. Erst mal so zum laufen bekommen
Irgenwie scheint der MK keine Adressen zu vergeben, kann ich aber erst heute abend tatsächlich prüfen.
Wofür steht eigentlich das Interface sfp1 ?
Das ganze sieht jetzt so aus:
Diese sind automatich angelegt worden
Nööö...das wird nie und nimmer nicht "automatisch" angelegt. Wer sollte das denn machen. Oder.......hast du den Port 1 als DHCP Client konfiguriert ??
Dann (und nur dann) stimmt, das , denn dann zieht der MT sich am Port 1 von der FritzBox eine IP, das Default Gateway und auch DNS.
Das wäre aber tödlich, denn dann wäre diese IP dynamsich und könnte sich ändern.
Das sollte immer statisch konfiguriert sein und dann musst du auch die Default Route logischerwese selber und statisch definieren im Setup des MT.
Automatisch geht da nix. Lässt eher den bösen Verdacht aufkommen das da nochwas falsch ist und die im Router befindliche Default Konfig NICHT vorher von dir gelöscht wurde !!!
Kann das evtl. sein ???
Damit meine ich die Routen für die einzelnen VLANS
Das ist Quatsch, die muss man nicht konfigurieren. Sowie du die VLAN IPs definierst stehen die als local connected automatisch in der Roouting Tabelle. Dazu muss und darf man nichts extra zusätzlich konfigurieren. Hast du vermutlich auch nicht, oder ?Wofür steht eigentlich das Interface sfp1 ?
SFP ist ein Steckslot für Glasfaser Optiken, sog SFP Optiken. Ein Port um Glasfaser Verbindungen anzuschliessen.Ich möchte gerne die ports 2-4 am Mikrotik den einzelnen VLANS zuordnen
Das ist ganz einfach und macht man über den internen Switch und nicht mit so einer Bridge FrickeleiGuckst du hier.
Beispiel ist VLAN 12 als Client Port an eth2 und tagged Uplink an eth5.
Analog machst du das dann für Port 3 = VLAN 13 und eth4 = VLAN 14
Die Schritte im einzelnen:
1.)
- VLANs einrichten mit IP usw und mit VLAN ID auf tagged Switch Uplink Port ether 5 mappen
- Port ether 2 mit ether 5 als Master Port einstellen (für ether 3 und 4 analog)
- Den internen Switch entsprechend der VLANs zuweisen
- Port ether 2 untagged VLAN 12 zuweisen (Mode secure, id strip)
- Für ether 3 und 4 mit vlan ID 13 und 14 entsprechend wiederholen.
- Uplink Port ether 5 und die Switch CPU anbinden
- In der Switch VLAN Zuweisung der VLAN ID die Member Ports zuweisen inkl. Switch CPU
Das wars. Damit kannst du in die Port 2-4 entsprechen de Endgeräte zu den VLANs einstecken und die VLANs gehen gleichzeitig Tagged als Uplink auf den Switch. Clients im VLAN auf dem Switch können dann die Clients an den Ports 2-4 pingen und auch die zur VLAN korrespondierende Mikrotik VLAN IP.
Auch VLAN übergreifende Pings klappen nun sowie ein Ping der FritzBox LAN IP .150.1
Damit die DHCP IP Adresszuweisung vom MT in den VLANs funktioniert musst du auch den DHCP Server komplett konfigurieren !! Hast du das gemacht unter dem Reiter "Networks" ?
Hier die Konfig wie es aussehen sollte:
Damit wäre die Konfig dann vollständig so wie du sie haben willst.
...hast du den Port 1 als DHCP Client konfiguriert ??
Nein.... die im Router befindliche Default Konfig NICHT vorher von dir gelöscht wurde !!!
Doch habe ich, aber jetzt habe ich alles nochmal resetet und nochmal neu angefangen.... macht man über den internen Switch und nicht mit so einer Bridge Frickelei
Danke für diese tolle Anleitung, jetzt klappt das auch mit der Adressvergabe, und die Ports sind den einzelnen VLANs zugewiesen, sowohl am MK und den beiden Switches.Als nächstes sollen dann WLAN AP den Vlans zugewiesen werden.
Geht das auch über den internen Switch? Zumindest werden in der VLAN Port Zuweisung keine WLAN Interfaces zur Auswahl angeboten.
In der Switch VLAN Zuweisung der VLAN ID die Member Ports zuweisen inkl. Switch CPU
Habe statt Default VLAN ID 0 mit der bei mir in den Switchen hinterlegten 1 ersetzt, hoffe das ist richtig.
Auch VLAN übergreifende Pings klappen nun sowie ein Ping der FritzBox LAN IP .150.1
Ja, das klappt. Allerdings kann ich weder den ersten 150.5. noch den zweiten Switch 150.4 anpingen. Warum? Die jeweiligen Clients dahinter kann ich anpingen.Damit die DHCP IP Adresszuweisung vom MT in den VLANs funktioniert musst du auch den DHCP Server komplett konfigurieren !! Hast du das gemacht unter dem Reiter "Networks" ?
Natürlich nicht, das Ding ist 'ne Wissenschaft für sich, hab ich jetzt aber nachgeholt.Mit der derzeitigen Konfiguration kann ich VLAN übergreifend alles im Netz erreichen, wie setze ich hier die Sperren? Mein Ziel ist es, dass die einzelnen VLANs gegeneinander isoliert sind. Ich möchte nur aus dem Netz der FB alle VLANs erreichen.
Z.B. soll aus VLAN 12 kein Zugriff auf Clients in VLAN 13 oder 14 stattfinden, ebenso umgekehrt.
Als nächstes sollen dann WLAN AP den Vlans zugewiesen werden.
Geht das auch über den internen Switch?
Nein, leider nicht. Da kommst du dann um eine Bridge nicht drumrum... Geht das auch über den internen Switch?
Allerdings kann ich weder den ersten 150.5. noch den zweiten Switch 150.4 anpingen. Warum?
Die Management Interfaces der Switches liegen IMMER im Default VLAN 1 bei den Switches.Daraus kann man schlussfolgern das dein VLAN nicht richtig vom MT auf über den Trunk an ether 5 auf die Switches übertragen werden.
Das Problem wird vermutlich durch das VLAN 1 Tagging ausgelöst was du oben statt der 0 gemacht hast. Das solltest du mal wieder rückgängig machen !
Bedenke auch das du jetzt zwingend ein Default Gateway in der Mangement IP Konfig der Switches hinzufügen musst, ansonsten kannst du das Switch Management aus deinen anderen VLANs NICHT mehr erreichen !
Dieses Problem der VLAN 1 Übertragung untagged hatte ich schonmal an einen MT und ist dort leider nicht trivial. Ich habe mich damals mit einem kleinen Workaround beholfen:
Mikrotik Switching und Routing Problem
Das ist umständlich und muss natürlich nicht sein wenn man das VLAN 1 Tagged am Uplink zum Switch !
Hier die Lösung wie du das VLAN 1 des/der Switches an den MT anbindest um so darauf zugreifen zu können:
- Der MT kann auf dem Uplink das VLAN 1 nicht untagged annehmen wie es sonst auf einem Tagged Uplink üblich ist. Du musst also das VLAN 1 auch taggen auf dem Uplink.
Das überträgt dann das VLAN 1 Tagged vom Switch zum MT. Jetzt muss der MT das Default VLAN 1 auch nur noch Taggen auf seinem Uplink Port (ether 5) und du musst ihm natürlich eine IP im VLAN 1 vergeben !
- Dazu legst du ein VLAN 1 an, setzt die VLAN ID auf 1 und bindest das ebenfalls an den Port ether 5 (Tagged Uplink auf den Switch)
- Dann vergibst du eine IP Adresse für das VLAN 1 (hier im Beispiel 192.168.1.1 /24) und mappst das auf das VLAN 1 Interface
- Jetzt passt du noch die interne MT Switchkonfig an indem du das VLAN 1 hinzufügst unter dem VLAN Reiter und ihm die Ports ether 5 und die CPU hinzufügst.
Wenn du willst kannst du natürlich auch noch einen DHCP Server für das VLAN 1 aktivieren um in diesem VLAN auch IPs automatisch zu verteilen.
Achtung: Die beiden statischen Switch Management IPs und der MT dürfen nicht im Pool sein ! Ideal hier: .1.1 (MT) und .1.253 und .1.254 (SW 1 u.2)
wie setze ich hier die Sperren?
Das machst du in den Firewall Setups. Dazu musst du als erstes am besten die genauen Regeln auf Papier festlegen und die umsetzen.So sähe z.B. eine einfache Lösung aus die UDP und TCP Verbindungen aus dem VLAN 12 ins VLAN 13 verbieten und auch umgekehrt.
Nein, leider nicht. Da kommst du dann um eine Bridge nicht drumrum...
Bleib dann die oben von dir vorgeneommene Switch VLAN ID und Member Port Zuweisung bestehen, oder ist das wieder hinfällig? Kann ich einfach zusätzlich eine bride konfigurieren und den dhcp der brigde zuweisen?
Das Problem wird vermutlich durch das VLAN 1 Tagging ausgelöst was du oben statt der 0 gemacht hast. Das solltest du mal wieder rückgängig machen !
Habe ich jetzt auf 1 gelassen, nachdem ich das Vlan 1 nach Deiner Anleitung neu angelegt habe, das ist doch richtig oder muss das trotzdem auf 0 ?Bedenke auch das du jetzt zwingend ein Default Gateway in der Mangement IP Konfig der Switches hinzufügen musst, ansonsten kannst du das Switch Management aus deinen anderen VLANs NICHT mehr erreichen !
Bisher habe ich dort die 150er Adressen aus dem FB Pool und als GW die FB mit 150.1 muss ich jetzt dort Adressen aus dem VLAN1 (192.168.151.x) Pool reinnehmen ? Welcher GW muss rein? Verstehe ich es richtig, dass dann die switches ein eigenes VLAN 1 haben?
Ich habe in der FB eine neue Route angelegt, ist das korrekt ?
192.168.151.0 255.255.255.0 192.168.150.254
In deinem Screenshot erkenne ich die Dst. Adress nicht, welche Adressen müssen hier rein, 192.168.151.0 ?
Auch nach den Einträgen in der Firewall können sich die clients aus vlan12 und 13 gegenseitig anpingen.
Dazu musst du als erstes am besten die genauen Regeln auf Papier festlegen und die umsetzen.
Ich möchte vom FB netz auf alles zugreifen können, also alle VLANs.Innerhalb der einzelnen VLANS sollen alle Clients untereinander eine Verbindung herstellen können, und über die FB eine Verbindung ins Internet bekommen.
VLAN-übergreifend sollen es zwischen den Clients keine Verbindung geben.
Die Konfiguration der switches kann ich erst heute Abend machen, da ich momentan nicht draufkomme.
Über VPN komme ich auch auf die einzelnen VLANs, auch dem ich jetzt die Routen im VPN Client angelegt habe.
Bleib dann die oben von dir vorgeneommene Switch VLAN ID und Member Port Zuweisung bestehen
Ja, du musst die SSID nur mit den VLAN Interfaces bridgen.Andere Alternative wäre die WLAN Interfaces in separaten IP Netzen laufen zu lassen, dann spart man sich die Bridges und routet. Hätte auch den Vorteil das man wieder per Firewall sichern kann.
Probleme gibts dann nur wenn man mDNS wie Bonjour usw. im LAN und WLAN nutzen will oder muss, denn das ist nicht routing fähig und man müsste mit Proxies arbeiten.
Das musst du aber entscheiden da wir nicht "sehen" können was du da machst im Netz....
Kann ich einfach zusätzlich eine bride konfigurieren und den dhcp der brigde zuweisen?
Ja auch das ginge...muss ich jetzt dort Adressen aus dem VLAN1 (192.168.151.x) Pool reinnehmen ?
Ja !Das musst du zwingend machen. Du bridgst ja nicht mehr zwischen FB und MT. Der Link zw. FB und MT an Port 1 ist ein rein gerouteter Point to Point Link und sollte das auch bleiben so.
Das VLAN 1 am MT ist dann ein separates IP Segment was dann dem VLAN 1 deiner gesamten Switch Infrastruktur dahinter entspricht. Deshalb muss es auch einen separaten IP Bereich haben wie z.B. .151.0 /24. So kannst du das VLAN 1 weiter nutzen auf den Switches.
Das WLAN auf der FB selber ist damit dann isoliert bzw. auch geroutet. Du kannst das auch weiter nutzen wie auch Endgeräte im .150.0er Netz dort. Das ist ja aus MT Sicht ein normal geroutetes Netzwerk.
Du könntest sogar die gleiche WLAN SSID nutzen. Besser wäre eine separate aber das ist Kosmetik.
Ich möchte vom FB netz auf alles zugreifen können, also alle VLANs.
Ja, das ist genau mit dieser Konstellation oben problemlos möglich und war ja auch der tiefere Sinn Innerhalb der einzelnen VLANS sollen alle Clients untereinander eine Verbindung herstellen können
Kein Thema, denn das sind ja Layer 2 Netze und dort greifen keine Firewall Regeln !VLAN-übergreifend sollen es zwischen den Clients keine Verbindung geben.
Das blockst du dann mit den Firewall Regeln auf dem MT wie oben beschrieben !Aber bitte immer NACHHER nachdem alles Routing und alle Grundfunktionen sauber laufen.
Es macht keinen Sinn sich während der Installation selber Fallen zu stellen mit ACLs nach denen man sich dann einen Wolf sucht. Siehst du sicher selber ein !
Also erst alles sauber zum Spielen bringen...dann erst Schotten dicht machen !
erkenne ich die Dst. Adress nicht, welche Adressen müssen hier rein, 192.168.151.0
Wenn du einzelne Hosts filtern willst musst du hier natürlich auch diese Host Adressen angeben.Der kundige Netzwerker weiss das die 0 (bei 24 Bit) immer das Netz selber kennzeichnet (Alle Hostbits auf 0). Für die Filterregel bedeutet das dann: Das gesamte Netzwerk wird gefiltert !!
Auch nach den Einträgen in der Firewall können sich die clients aus vlan12 und 13 gegenseitig anpingen.
Das ist auch klar ! Der kundige Netzwerker weiss das Ping auf dem ICMP Protokoll basiert !!!Die Filterregel oben filtert aber nur UDP und TCP Traffic wie du sehen kannst, ICMP ist nicht dabei !
Erweitere sie also auf ICMP dann ist auch mit dem Pingen sofort Schluss !
Hättest du auch selber gesehen wenn du dir mal einen kleinen Webserver auf einem Rechner gestartet hättest wie der HFS Server: http://www.rejetto.com/hfs/
Der startet OHNE Installation indem du einfach nur die EXE Datei startest...
Dann musst du nicht mehr pingen sondern kannst mit dem Browser eine TCP 80 Session dahin aufmachen (HTTP). Dann hättest du schon gesehen das das nicht mehr klappt zw. den Netzen.
Fazit: Immer mal nachdenken WIE sich die IP Pakete im netz bewegen.
Der Wireshark ist hier übrigens dein bester Freund den Horizont mal zu erweitern !
Die Konfiguration der switches kann ich erst heute Abend machen,
Nimm dir Zeit und Ruhe....!Über VPN komme ich auch auf die einzelnen VLANs,
VPN über die FB oder MT ??? Hier bist du leider wieder sehr oberflächlich auch dem ich jetzt die Routen im VPN Client angelegt habe.
Ist wie immer überflüssiger Quatsch und passiert automatisch wenn man es an der FB richtig einrichtet !Jedenfalls wenn man das FB VPN nutzt. Guckst du hier:
https://avm.de/service/vpn/praxis-tipps/mit-fritzfernzugang-auf-mehrere- ...
https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publicati ...
(Der MT kann das aber auch, nur mal nebenbei bemerkt...)
Hallo aqui,
danke für die Beatwortung meiner Fragen, ohne dich hätte ich vor Verzweiflung den MT wieder zurückgeschickt.
Kannst du mir bitte die offenen Frage auch noch beantworten:
Muss ich jetzt alle möglichen Protokolle einzeln eingeben, oder gibt es einen Eintrag mit dem alles gesperrt ist?
Hab jetzt erstmal die Regeln, so wie du empfohlen hast, alle wieder rausgenommen.
Gestern hab ich es leider nicht hinbekommen, die Switche so zu konfigurieren, dass ich draufkomme.
Konfig am Switch1 sieht wie folgt aus, wobei der MT an Port 8 reingeht und am Port 1 raus zum zweiten Switch geht:
Denke das entspricht Deiner Cisco Konfig von oben.
Wo ich mir jedoch unsicher bin, sind die orange unterlegten Memberships von Port 2-7 im V1. Müssen die raus oder ggf. auf T?
Wüßte nicht wie man am iPhone diese Routen hinterlegen kann, daher hatte ich gehofft, dass die FB mit den bereits hinterlegten Routen das hinbekommt.
Nachtrag:
Vom Iphone habe ich gerade getestet, das geht ohne weitere Konfiguration
D.h. die FB Routen greifen doch und es Bedarf keiner Routingeinträge im VPNClient.
danke für die Beatwortung meiner Fragen, ohne dich hätte ich vor Verzweiflung den MT wieder zurückgeschickt.
Kannst du mir bitte die offenen Frage auch noch beantworten:
Habe ich jetzt auf 1 gelassen, nachdem ich das Vlan 1 nach Deiner Anleitung neu angelegt habe, das ist doch richtig oder muss das trotzdem auf 0 ?
Der kundige Netzwerker weiss das Ping auf dem ICMP Protokoll basiert !!!
Betonung liegt auf kundigeMuss ich jetzt alle möglichen Protokolle einzeln eingeben, oder gibt es einen Eintrag mit dem alles gesperrt ist?
Hab jetzt erstmal die Regeln, so wie du empfohlen hast, alle wieder rausgenommen.
Nimm dir Zeit und Ruhe....!
Ja, das brauche ich wirklich Gestern hab ich es leider nicht hinbekommen, die Switche so zu konfigurieren, dass ich draufkomme.
Konfig am Switch1 sieht wie folgt aus, wobei der MT an Port 8 reingeht und am Port 1 raus zum zweiten Switch geht:
Wo ich mir jedoch unsicher bin, sind die orange unterlegten Memberships von Port 2-7 im V1. Müssen die raus oder ggf. auf T?
VPN über die FB oder MT ??? Hier bist du leider wieder sehr oberflächlich
Ich nutze das VPN der FB.Ist wie immer überflüssiger Quatsch und passiert automatisch wenn man es an der FB richtig einrichtet !
Hatte ich eigentlich erwartet, jedoch bekam ich erst eine Verbindung hin, als ich erst im Shrew VPN Client die gleichen Routen wie in der FB hinterlegt habe.Wüßte nicht wie man am iPhone diese Routen hinterlegen kann, daher hatte ich gehofft, dass die FB mit den bereits hinterlegten Routen das hinbekommt.
Nachtrag:
Vom Iphone habe ich gerade getestet, das geht ohne weitere Konfiguration
D.h. die FB Routen greifen doch und es Bedarf keiner Routingeinträge im VPNClient.
ohne dich hätte ich vor Verzweiflung den MT wieder zurückgeschickt.
Das liegt aber weniger am MT als an dem der davor sitzt... Wie gut das es Foren wie dieses gibt... Kannst du mir bitte die offenen Frage auch noch beantworten:
Ich hoffe und verspreche mir alle Mühe zu geben...Betonung liegt auf kundige
Dr. Google weiss das aber auch... Muss ich jetzt alle möglichen Protokolle einzeln eingeben,
99,8% basiert auf UDP und TCP. Wenn du die sperrst und noch ICMP dazu, damit man nicht pingen kann, ist so gut wie alles tot.Wie gesagt...einfach mal mit dem Wireshark deinen Traffic ansehen
Konfig am Switch1 sieht wie folgt aus, wobei der MT an Port 8 reingeht und am Port 1 raus zum zweiten Switch geht:
Das sieht soweit sehr gut aus. Bei Billigswitchen gibt es aber oftmals Stress mit dem VLAN 1. Wie du siehst hast du den einmal als PVID 1 eingestellt. (Da geht aller untagged Traffic hin) gleichzeitig taggest du aber dieses VLAN auch. Das mögen viele Switches nicht die NICHT mit Auto PVID arbeiten wie z.B. Cisco.Hier solltest du dir ein testweise mal Dummy VLAN einrichten z.B. 99 und die PVID NUR des MT Ports auf 99 setzen.
Damit verhinderst du einen Konflikt mit Tag und Untag an diesem Port.
Am Switch Verbindungs Uplink kannst du es lassen.
Ein Endgerät sollte dann im Default VLAN 1 an beiden Switches auch beide Switch IPs UND die MT IP im VLAN 1 pingen können.
Wenn das geht kannst du auch alles anderen IPs in allen VLANs und die FB pingen (Wir arbeiten ja noch ohne Firewall Filterlisten
)sind die orange unterlegten Memberships von Port 2-7 im V1
Das ist in der Tat komisch. Vermutlich wohl wieder diese absolut kranke VLAN Logik bei NetGear.Keine Ahnung was das ist ist. Dort sollte eigentlich KEIN U mehr stehen unter der ID 1 da die ja den anderen VLAN zugeordnet sind. Krank.....
Vielleicht hilft da das Handbuch zur Klärung. Müsste ich auch nachlesen was der Unsinn bedeutet...
Ich nutze das VPN der FB.
Gut, dann hast du ja oben gesehen wie die zu konfigurieren ist wenn weitere IP Netze hinter der FB sind. Deine statische Routen im Client sind in jedem Falle falsch und müssen nicht sein !als ich erst im Shrew VPN Client die gleichen Routen wie in der FB hinterlegt habe.
Mmmhhh...ok mag einen Eigenart des Shrews sein. Hast du wind 10 ??Mittlerweile gibts den FB Client auch für Win 10:
https://avm.de/fritz-labor/betaversion-fritzfernzugang-vpn-fuer-windows- ...
Aber erstmal so lassen...never touch a runnig system
Wüßte nicht wie man am iPhone diese Routen hinterlegen kann
Das iPhone lernt alles diese Routen beim IPsec Verbindungsaufbau wie es üblich ist. Die FB Konfig mit den IP Netzen hinter der FB zeigt ja wie es geht und so ist es auch Standard bei IPsec.Im Zweifel macht du immer ein Gateway Redirect mit den IPsec Clients, dann geht alles durch den Tunnel.
Vom Iphone habe ich gerade getestet, das geht ohne weitere Konfiguration. D.h. die FB Routen greifen doch und es Bedarf keiner Routingeinträge im VPNClient.
So sollte es sein...ist eben Apple und nicht Winblows 
Bei Billigswitchen gibt es aber oftmals Stress mit dem VLAN 1.
Heißt das, wenn ich das default Vlan von V1 auf bspw. auf V11 sowohl in den Switches als auch im MT, ändere umgehe ich dieses Problem? Oder darf ich V1 nicht ändern?Hier solltest du dir ein testweise mal Dummy VLAN einrichten z.B. 99 und die PVID NUR des MT Ports auf 99 setzen.
Hab ich gemacht, auch die Einträge in V1 bei Port 2-7 entfernt , so siehts jetzt aus:
Muss ich jetzt am MT auch noch die ID 99 irgendwo reinnehmen?
Vielleicht hilft da das Handbuch zur Klärung.
Daraus bin ich noch nicht schlau geworden. Werde es noch mal in Ruhe lesen, aber so ein Fall ist da auch nicht beschrieben.Müsste ich auch nachlesen was der Unsinn bedeutet...
Naja, den Unsinn hab ich ja so konfiguriert. Er lässt es ja zu! Nur ob es richtig ist weiß ich nicht.Jetzt habe ich dem Switch1 die Statische IP 192.168.151.5 und GW 151.1 verpasst. (Ging nur mit Direktverbindung über Laptop, sonst komm ich nicht drauf)
Ein Tracert aus dem FB Netz liefert folgendes:
Und auf dem MT selbst:
Wieso findet der MT den Switch nicht, die 151er Route ist ja da?
Zu den Clients hinter dem Switch klappt die Verbindung.
Hier nochmal die aktuelle Konfig am MT :
sowohl in den Switches als auch im MT, ändere umgehe ich dieses Problem?
Ja ! Auf dem MT musst du es NICHT ändern. Es geht rein nur um den Switch, nur hier müsste man es anpassen. Der MT tagged ja schon das VLAN 1, der kennt diesen Dualismus nicht.Wenn du dem Switch ein VLAN (99) einrichtest was du gar nicht verwendest, dann vermeidest du den Konflikt.
Dann setzt du die PVID auf 99 und taggst das VLAN 1 wie schon gemacht.
Auf dem Link kommen ja niemals untagged Pakete an und deshalb musst du auch keine Angst haben das was im VLAN 99 versickert.
Es dient lediglich um auf dem NG Konfig Sicherheit zu schaffen das es dort keinen Konflikt gibt mit dem VLAN 1.
Obwohl wir ja noch nichtmal wissen ob es einen Konflikt gibt. Es wäre nur ein Workaround sollte das ggf. ein Problem sein. Da es beim Cisco sauber klappt kannst du ja sehen das es netzwerktechnisch eine korrekte Konfig ist.
Hab ich gemacht, auch die Einträge in V1 bei Port 2-7 entfernt , so siehts jetzt aus:
Jetzt hast du da aber einen fatalen Fehler gemacht !!!VLAN 1 MUSS Tagged sein ! Der MT tagged doch auch ! Siehe MT VLAN 1 Konfig oben... ether 5 und VLAN ID 1 ==> d.h. die Frames kommen getaggt da raus. Wenn du untagged auf der Switchseite machst kann er die nicht lesen und schmeisst die weg und du hast keine Verbindung !
Muss ich jetzt am MT auch noch die ID 99 irgendwo reinnehmen?
Nein. Wie gesagt nur Workaround am Switch und nur weils NG ist. Daraus bin ich noch nicht schlau geworden.
Keine Sorge da wird wohl auch nur NG schlau draus.... Naja, den Unsinn hab ich ja so konfiguriert.
Nee, nee...du bist unschuldig. Die Anzeige ist ja widersprüchlich in sich.Ein Tracert aus dem FB Netz liefert folgendes:
OK, bedeutet das es bis zum MT geht aber der die beiden IPs nicht erreichen kann !Ist klar, denn mit VLAN 1 untagged am Switch kann es nicht gehen wie oben schon beschrieben, das war dein Fehler.
Dann nochmal checken:
- Switch 1 und 2 brauchen natürlich einen Default Gateway Eintrag auf die MT IP 192.168.151.1
- Stecke eine TestPC in das VLAN 1 auf beiden Switches
- Pinge die Switch IPs ==> Das muss klappen
- Pinge die MT IP 192.168.151.1 ==> Das muss auch klappen
- Wenn ja dann klappt auch das Pingen aus den anderen VLANs
Wieso findet der MT den Switch nicht, die 151er Route ist ja da?
==> Fehler ist VLAN 1 untagged an Switch Port 8. Da der MT tagged kann das nicht gehen.Sinnvoll wäre nochmal der Output des VLAN Reriters in der Switch Konfig. Hier hast du leider nur die Ports gepostet. Aber wenn du das wie oben gemacht hast ist das OK.
Der Rest sieht auch sauber und richtig aus.
Ja ! Auf dem MT musst du es NICHT ändern. Es geht rein nur um den Switch, nur hier müsste man es anpassen. Der MT tagged ja schon das VLAN 1, der kennt diesen Dualismus nicht.
Was ich meine ist, dass ich überhaupt kein V1 mehr nutze, sondern das Default vlan in 11 ändere sowohl auf MT und den Switches und V1 nirgends wo mehr auftaucht. Wäre das eine Lösung?
VLAN 1 MUSS Tagged sein !
Hier die Berichtigung, Konfig sieht jetzt so aus, aber trotzdem klappt die Verbindung nicht.
* Switch 1 und 2 brauchen natürlich einen Default Gateway Eintrag auf die MT IP 192.168.151.1
Das ist so:
* Stecke eine TestPC in das VLAN 1 auf beiden Switches
- Pinge die Switch IPs ==> Das muss klappen
- Pinge die MT IP 192.168.151.1 ==> Das muss auch klappen
Erkennst du noch einen Fehler in der Konfig.
Sinnvoll wäre nochmal der Output des VLAN Reriters in der Switch Konfig. Hier hast du leider nur die Ports gepostet. Aber wenn du das wie oben gemacht hast ist das OK.
Was ist VLAN Reriters ? Das sagt mir nichts und weiß nicht wo ich das finde bzw. aufrufe.
Was ich meine ist, dass ich überhaupt kein V1 mehr nutze, sondern das Default vlan in 11 ändere
Das wäre dann die einfachste Lösung Damit entledigst du dich dann des VLAN 1 "Problems".
Es geht aber auch so wie oben beschreiben wie hier im Labor Setup Mit Cisco SG200 und MT RB50G wasserdicht getestet.
kann ich 151.5 den switch pingen aber den MT 151.1 nicht.
Das zeigt das die VLAN 1 Frames am Port 8 nicht richtig zum MT übertragen werden Aus Switch Konfig Sicht hast du alles richtig gemacht wenn man deine Screenshots oben ansieht.
Möglich das noch was am MT faul ist.
Leider hast du nicht die oben nachgefragen Output des VLAN Reiters (Sorry, Typo !) in der Switch Konfig des MT gepostet.
Der wäre noch wichtig ! Hier muss für die VLAN ID 1 der Port ether 5 und die Switch CPU eingetragen sein !
Ob der Switch das VLAN 1 tagged am Port 8 kann man recht schnell mit dem Wireshark sehen. Du musst dafür nur einen geschwätzigen Winblows Rechner ins VLAN 1 hängen und mit einem anderen dir mal die Frames ansehen an Port 8 mit dem Kabelhai.
Vive versa den Hai an Port ether 5 klemmen und dort auch messen. Beide Enden (ether 5 und auch Switch Port 8) müssen den VLAN 1 Tag mitschicken bei Paketen aus diesem VLAN !!
Hier am Beispiel VLAN 1:
Du kannst hier im Sniffer Trace schön die entsprechenden VLAN Tags in den Paketen sehen und so auch verifizieren das die Komponenten alles richtig machen...oder auch nicht.
(Die Pakete hier aus dem .1.0er Netz (Testsetup VLAN 1) musst du dir bei dir als .151.0er denken
)Oder wie gesagt VLAN 1 vergessen und alles nur mit VLAN 11 machen wenn du keine Lust mehr hast den Fehler zu suchen
Hallo aqui,
habe jetzt das VLan 1 verbannt und alles mit V11 abgebildet, nur in den NG Switches kann ich das Vlan 1 nicht löschen. Es kommt die Meldung dass das nicht möglich ist. Auf jeden Fall hat es keine Port/Vlan/Member Zuordnung mehr. Leider bekomme ich immer noch keine Verbindung zu den Switches.
Ich stelle mir gerade die Frage, wieso am MT im V11 an ether5 kein Service Tag gesetzt ist.
Woher weiß der MT, welches Vlan/Port getaggt ist? Wird das durch den Eintrag "add if missing" auf dem Port Reiter gemacht?
habe jetzt das VLan 1 verbannt und alles mit V11 abgebildet, nur in den NG Switches kann ich das Vlan 1 nicht löschen. Es kommt die Meldung dass das nicht möglich ist. Auf jeden Fall hat es keine Port/Vlan/Member Zuordnung mehr. Leider bekomme ich immer noch keine Verbindung zu den Switches.
Der wäre noch wichtig ! Hier muss für die VLAN ID 1 der Port ether 5 und die Switch CPU eingetragen sein !
Das ist der Fall, jetzt allerdings mit V11:Ob der Switch das VLAN 1 tagged am Port 8 kann man recht schnell mit dem Wireshark sehen.
Das hab ich nicht mehr geschafft.Oder wie gesagt VLAN 1 vergessen und alles nur mit VLAN 11 machen wenn du keine Lust mehr hast den Fehler zu suchen
Leider klappts trotzdem nicht und Lust habe ich eigentlich auch keine mehr Ich stelle mir gerade die Frage, wieso am MT im V11 an ether5 kein Service Tag gesetzt ist.
nur in den NG Switches kann ich das Vlan 1 nicht löschen.
Nee, klar das ist das Default VLAN. Muss man ja auch nicht. Auch wenn dem VLAN 1 keinerlei Ports zugewiesen sind stört das ja nicht.wieso am MT im V11 an ether5 kein Service Tag gesetzt ist.
Der "Service Tag" hat nichts mit dem VLAN Tag zu tun !!Der wird für das Feature "Provider Bridge" benutzt also einen Double Tagging. Damit kann ein Provider z.B. einen inneren und einen äußeren Tag setzen um so z.B. 4096 Kunden über sein Layer 2 Netz zu übertragen die in sich wieder bis 4096 VLANs haben können.
Also vergessen, das ist ne reine Provider Funktion und wir hier nicht benutzt !
https://forum.mikrotik.com/viewtopic.php?t=31823
Woher weiß der MT, welches Vlan/Port getaggt ist?
Das sieht er an der Einstellung VLAN ID = 11 und Interface = ether 5So vom Aufbau hast du alles richtig gemacht.
Man kann jetzt nur vermuten das die Management IP Adressen der Switches NICHT ins VLAN 11 gehängt sind !
Hast du das mal quergecheckt indem du einen PC dort ins VLAN 11 gehängt hast und von dort mal die Management IP Adressen angepingt hast ??
Es sollte natürlich auch klar sein das die Management IPs jetzt IPs aus dem VLAN 11 sein müssen ! UND das das Default Gateway des Switch Managements auf die VLAN 11 IP Adresse des MTs zeigen muss.
Von dem Test PC in VLAN 11 muss also nicht nur die beiden IP Adressen der Switches im VLAN 11 pingbar sein sondern auch die MT IP Adresse !
Hier ein entsprechender Testaufbau und Funktionscheck der genau deinem Netzdesign entspricht. Zum Testen steckt ein Windows PC im VLAN 11 und ein Raspberry Pi in VLAN 12. Beide bekommen ihre IP Adressen per DHCP vom Mikrotik.
Mikrotik Konfig mit VLAN 11 (ether 5):
Switchkonfig mit Management IP in VLAN 11 (Testweise via DHCP vom MT):
Switchkonfig mit Tagged Uplink auf MT (Port 8):
Windows PC in VLAN 11 (IP: .1.148, via DHCP vom MT):
(Hängt am Port 2 des Switches)
Ping Check von diesem PC auf alle beteiligten IP Adressen:
Druckfehler im Kommentar !!: Der RasPi ist natürlich in VLAN 12 ! Siehe seine IP.)
Ping Check vom Raspberry auf alle beteiligten IP Adressen:
(Hängt an Port ether 2 des Mikrotik und testweise an Port 1 des Switches der im VLAN 12 untagged ist)
Wie du selber sehen kannst funktioniert das Design absolut fehlerfrei und wie erwartet und konfiguriert !
Nun bist DU wieder dran...
Die Konfig des MT ist identisch mit deinen Screenshots.
Bei der Switch Konfig hast du den Port 8 mit PVID 1 untagged in V1, bei mir sieht das jetzt nach der Änderung so aus:
Wie gesagt hab den V1 komplett rausgeschmissen, im MT ebenso. Der MT in Deinen Screenshots hat ja auch kein V1 mehr. Den Port 7 habe ich für den Test erstmal V11 zugeordnet.
Switch 1+2 lassen sich pingen, aber der der MT nicht. Wie breits oben beschrieben aus dem FB Netz kann ich den MT pingen aber die Switches nicht.
Von meinem raspi der am zweiten Switch auch im V12 hängt siehts so aus:
Hier kann ich den MT anpingen, den SW2 an dem der raspi selbst hängt nicht anpingen!!
Der SW1 lässt sich sporadisch anpingen, soll das mal einer verstehen
Den zweite WinPC der jetzt testweise im V11 hängt, ebenfalls am SW2, ist dann wieder nicht anpingbar.
Bei der Switch Konfig hast du den Port 8 mit PVID 1 untagged in V1, bei mir sieht das jetzt nach der Änderung so aus:
Hast du das mal quergecheckt indem du einen PC dort ins VLAN 11 gehängt hast und von dort mal die Management IP Adressen angepingt hast ??
Mein erstes Problem ist hierbei, dass der DHCP im VLAN 11 überhaupt keine Adresse verteilt, obwohls so wie oben nach Deiner Anleitung konfiguriert. Also habe ich die Adressen manuell reingesetzt. Hier das Ergebnis:Switch 1+2 lassen sich pingen, aber der der MT nicht. Wie breits oben beschrieben aus dem FB Netz kann ich den MT pingen aber die Switches nicht.
Es sollte natürlich auch klar sein das die Management IPs jetzt IPs aus dem VLAN 11 sein müssen ! UND das das Default Gateway des Switch Managements auf die VLAN 11 IP Adresse des MTs zeigen muss.
So ist es.Von meinem raspi der am zweiten Switch auch im V12 hängt siehts so aus:
Der SW1 lässt sich sporadisch anpingen, soll das mal einer verstehen
Den zweite WinPC der jetzt testweise im V11 hängt, ebenfalls am SW2, ist dann wieder nicht anpingbar.
Nun bist DU wieder dran...
Mir wäre eine Teamviewersitzung lieber, als der Schlagabtausch Bei der Switch Konfig hast du den Port 8 mit PVID 1 untagged in V1
Ja, du hast recht. Ich war zu faul den Port im Setup jetzt noch auf "Tagged ONLY" zu stellen was man machen kann. Das untagged Traffic per Default dort ins VLAN 1 geforwardet wird ist, wie bei allen Switches an Tagged Ports, ja ein Standard Verhalten.Ich hatte es weggelassen, weil es ja nicht stört. Da das VLAN 1 ja eh nicht mehr in Benutzung ist, ist das dann eher kosmetisch. Man könnte es natürlich noch abschalten am Switch wenn man es ganz sauber konfigurieren möchte
Dein Fehler am Switch ist vermutlich WIEDER der Dualismus den du jetzt schon wieder hast mit dem VLAN 11.
Vermutlich hast du das wieder mal im Eifer des Gefechts übersehen ?!
Du hast die ID 11 einerseits als PVID eingetragen (also das VLAN in das aller untagged Traffic soll) und gleichzeitig hast du es als Tagged eingetragen an Port 8.
Genau DAS wollten wir aber explizit mit unserer Konfig vermeiden oben !!!
Vermutlich stolpert der NG dadrüber.
Es wäre also sinnvoller und sicherer den NG am Port 8 auf der PVID 1 zu belassen und das VLAN 11 dort NUR Tagged zu übertragen.
Damit stürzt man den Switch nicht in ein mögliches Konfig Dilemma. Eben genau das was der Sinn und Zweck des obigen Schrittes war, dann das Switch Management ins VLAN 11 zu hieven.
Hier warst du also etwas zu übereifrig. Sicher gut gemeint aber kontraproduktiv in diesem Falle hier.
Fakt ist das scheinbar irgendwas schief läuft an der Switch Schnittstelle Port 8 auf den MT.
Ich vermute das der Switch hier nicht oder nicht richtig tagged oder eben die o.a. Probleme hat wenn untagged sprich die PVID und tagged für ein gleiches VLAN am Port definiert ist.
Das also bitte dringend wieder umstellen !
Dadurch das Endgeräte keine DHCP IP im VLAN 11 bekommen kannst du sehen das es keinerlei Layer 2 Verbindung zw. MT und Switch gibt. DHCP Broadcasts der Clients kommen also schon gar nicht am MT an.
Ein sicheres Indiz dafür das irgendwas am Switchport 8 bzgl. VLAN 11 schiefläuft. Schei... NG
Als ersten Schritt solltest du das also erstmal wieder umstellen wie oben beschrieben.
Wenn du dann mit dem Rechner und dem "WinBox" (Mikrotik) Tool im VLAN 11 bist, dann solltest du den MT sehen dort.
Der MT sendet zyklisch Layer 2 Broadcasts aus um sich dem WinBox Tool bekannt zu machen. Das macht er sinnvollerweise deshalb, damit man mit dem WinBox Tool den MT auch ohne IP Adresse konfigurieren kann.
Wenn du also den MT im WinBox Tool siehst, dann ist das auch immer ein Indiz dafür das es L2 mässig klappt und dann klappt zu 99,9% auch die DHCP IP Adressvergabe im VLAN 11 vom MT.
Wie gesagt es liegt rein am VLAN 11 und dem Tagging dort zum Switch.
Was nochmal hilfreich wäre ist ein Scrennshot der Switch Management Konfig, das die Mgmt IPs auch wirklich im VLAN 11 sind !!
Was den Rest anbetrifft ein paar Fragen:
- Der RasPi der im VLAN 12 ist, kann der die VLAN 12 IP Adresse des MT pingen ? Wenn ja, zeigt das das dort wenigstens das 12er Tagging an Port 8 auf ether 5 funkltioniert !
- Gilt das auch für den DHCP ? Bekommt der RasPi seine IP vom VLAN 12 DHCP Server des MT ?
Damit kann der RasPi natürlich auch die VLAN 11 IP und auch die von 13 und 14 pingen, denn diese IPs liegen ja direkt auf dem MT selber. Ping Antworten laufen dann über den VLAN 12 Tag zurück der ja funktioniert.
Pingst du aber vom RasPi die Switch IPs dann muss der MT routen und die Frames über VLAN 11 mit einem ID 11er Tag aussenden an Port 8, klar.
Genau DAS scheitert aber irgendwie bei dir, deshalb kann vermutlich keiner aus den anderen Netzen die Switches erreichen und umgekehrt und es ist dann auch klar das von den VLAN 11 Mgmt Interfaces der Switches nichts anderes erreicht werden kann.
Es kann also nur noch 3 Gründe geben:
- 1.) Das Tagging in VLAN 11 funktioniert nicht oder nicht richtig (Mögl. Lösung oben)
- 2.) Die Mgmt IP Adressen der Switches sind nicht wirklich in VLAN 11 (Screenshot)
- 3.) Die Mgmt IP Adressen der Switches haben kein Default Gateway auf die VLAN 11 IP des MT eingestellt.
Das der RasPi nur sporadisch SW1 pingen kann ist schon komisch.
Das zeigt das auch die Switchverbindung zw. SW 1 und SW 2 irgendwie betroffen ist ?!
Machst du irgendwie Spanning Tree wie RSTP oder sowas aktiv auf den Switches ??
Hast du ggf. irgendwo bewusst oder unbewusst einen Loop gesteckt ?
Das Verhalten sieht irgendwie etwas nach einen Ethernet oder STP Loop aus.
Um das sicher zu eliminieren nimm bitte zum Testen erstmal nur EINEN Switch. Ziehe also den 2ten Switch mal ab von Port 1 vom ersten und belasse nur den der am ether 5 Port des MT hängt.
Dann machst du auf diesem Switch die VLAN Änderung so wie oben beschrieben, PVID auf 1 und 11, 12, 13 und 14 Tagged auf Port 8.
Dann Connectivity testen, WinBox Sichtbarkeit, DHCP in VLAN 11, Pings usw.
Sollte das dann klappen, dann den Uplink Port 1 zum anderen Switch auch so einstellen: PVID auf 1 und 11, 12, 13 und 14 Tagged.
Analog auch für den Uplink Port an Switch 2: PVID auf 1 und 11, 12, 13 und 14 Tagged
Dann MUSS das klappen.
Wenn nicht dann sendest du eine Teamviewer ID via PM
Es wäre also sinnvoller und sicherer den NG am Port 8 auf der PVID 1 zu belassen und das VLAN 11 dort NUR Tagged zu übertragen.
Hab ich wieder umgestellt:
Was nochmal hilfreich wäre ist ein Scrennshot der Switch Management Konfig, das die Mgmt IPs auch wirklich im VLAN 11 sind !!
So siehts aus:
* Der RasPi der im VLAN 12 ist, kann der die VLAN 12 IP Adresse des MT pingen ? Wenn ja, zeigt das das dort wenigstens das 12er Tagging an Port 8 auf ether 5 funkltioniert !
Ja, kann ich alles mit ja beantworten, wie gesagt nur zu den Switches gibts keine Verbindung. Alles andere klappt.- Gilt das auch für den DHCP ? Bekommt der RasPi seine IP vom VLAN 12 DHCP Server des MT ?
Damit kann der RasPi natürlich auch die VLAN 11 IP und auch die von 13 und 14 pingen, denn diese IPs liegen ja direkt auf dem MT selber. Ping Antworten laufen dann über den VLAN 12 Tag zurück der ja funktioniert.
Ja, so ist es.Pingst du aber vom RasPi die Switch IPs dann muss der MT routen und die Frames über VLAN 11 mit einem ID 11er Tag aussenden an Port 8, klar.
Genau DAS scheitert aber irgendwie bei dir, deshalb kann vermutlich keiner aus den anderen Netzen die Switches erreichen und umgekehrt und es ist dann auch klar das von den VLAN 11 Mgmt Interfaces der Switches nichts anderes erreicht werden kann.
Genau das ist mein Problem.Genau DAS scheitert aber irgendwie bei dir, deshalb kann vermutlich keiner aus den anderen Netzen die Switches erreichen und umgekehrt und es ist dann auch klar das von den VLAN 11 Mgmt Interfaces der Switches nichts anderes erreicht werden kann.
Es kann also nur noch 3 Gründe geben:
Habe nach deinen Vorgaben umgestellt.- 1.) Das Tagging in VLAN 11 funktioniert nicht oder nicht richtig (Mögl. Lösung oben)
* 2.) Die Mgmt IP Adressen der Switches sind nicht wirklich in VLAN 11 (Screenshot)
Das kann ich mit den oben gemachten Screenshots ausschliessen.- 3.) Die Mgmt IP Adressen der Switches haben kein Default Gateway auf die VLAN 11 IP des MT eingestellt.
2 und 3 kann man ja (fast) ausschliessen wenn du alles richtig gemacht hast und nicht irgendwo noch ein Konfig Fehler lauert ?!
Nur wo? Nach den gemachten Änderungen habe ich immer noch das gleiche Problem.Machst du irgendwie Spanning Tree wie RSTP oder sowas aktiv auf den Switches ??
Nicht das ich wüsste, in den Switches ist nur LoopDetection enabeld.Hast du ggf. irgendwo bewusst oder unbewusst einen Loop gesteckt ?
Denke nicht. Verkabelung geht- von FB in MT (P5)
- Von MT (P1) an SW1 (P8)
- Von SW1 (P1) an SW2 (P5)
Wenn nicht dann sendest du eine Teamviewer ID via PM
Danke für das Angebot, werde ich sicher nutzen, wenn ich die empfohlenen Schritte alle (switch2 abklemmen usw.) durchgeführt habe und dennoch kein Erfolg in Sicht ist. Mittlerweile habe ich wirklich den Gedanken das Projekt aufzugeben und den MT wieder zurückzuschicken.So siehts aus:
Ist aber nirgendwo zu sehen das diese Management IP Adressen jetzt im VLAN 11 angehängt sind ! Sieh dir den Screenshot vom Cisco oben an dort steht ganz klar das das Management im VLAN 11 ist.
Das ist hier bei den NGs nicht zu sehen....! Man muss ja misstrauisch sein bei den Gurken
Nebenbei: Firmwares der Switches auf dem aktuellsten Satnd ??
Nach den gemachten Änderungen habe ich immer noch das gleiche Problem.
Da gibts dann nur ein Fazit:Schmeiss diese schei... NG Teile wech ! Ich habe das hier im Labor eben nochmal mit Cisco SG, TP-Link, D-Link 1210 und Cisco Catlysten probiert.
Bei allen funktioniert das Setup fehlerfrei.
Immer sind es diese %$§"//( NG Teile....!!!
Das mit dem Einzelswitch hast du auch probiert ?? OK, das kommt noch...
OK, die Hoffnung stirbt zuletzt...
Wenn du dann mit dem Rechner und dem "WinBox" (Mikrotik) Tool im VLAN 11 bist, dann solltest du den MT sehen dort. Der MT sendet zyklisch Layer 2 Broadcasts aus um sich dem WinBox Tool bekannt zu machen.
Nein, leider klappt auch diese Verbindung nicht, auch mit manuell konfigurierter IP nicht.
Der MT wird in Winbox nicht über seine MAC gefunden. Natürlich gibts auch keine Adresse vom DHCP .
Das Verhalten sieht irgendwie etwas nach einen Ethernet oder STP Loop aus.
Hab mal in diesem Zustand (PC im VLAN 11 ohne zweiten Switch) Wireshark gestartet, da taucht STP auf, allerdings kann ich mit diesen Infos nicht anfangen. Vielleicht du:
Dann Connectivity testen, WinBox Sichtbarkeit, DHCP in VLAN 11, Pings usw.
Leider klappt gar nichts ich kann nur den Switch (151.5) an dem der PC hängt pingen. Kein Winbox, kein DHCP in V11.Ist aber nirgendwo zu sehen das diese Management IP Adressen jetzt im VLAN 11 angehängt sind !
Im NG habe ich diese Konfiguratiosmöglichkeit leider nicht.Nebenbei: Firmwares der Switches auf dem aktuellsten Satnd ??
Gerade upgedatet erstmal erster Switch und keine Änderung.Der MT wird in Winbox nicht über seine MAC gefunden. Natürlich gibts auch keine Adresse vom DHCP .
Zeigt dann klar des es keine aktive Layer 2 Verbindung gibt bzw. keine Pakete im layer 2 (Mac Basis) transportiert werden.kann ich mit diesen Infos nicht anfangen. Vielleicht du:
Wie vermutet sind das Spanning Tree BPDU Frames. Auch noch das uralte Standard STP .1s und noch nichtmal modernes RSTP mit .1wNormal stört das nicht aber da die doofen NGs nur ein steinzeitliches Single Span Verfahren können besteht die Gefahr das diese BPDUs irgendwo in irgendwelche VLANs geforwardet werden und dann Ports blocken.
Das toggelnde Verhalten bei dir mal gehts und mal nicht ist oft ein untrügliches Indiz dafür.
Wenn du also den Single Switch Test machst dann schalte jegliches STP erstmal global ab auf den Switches.
Wenn du schon snifferst mit dem Wireshark klemm den doch mal an VLAN 11 an und steck irgendwas mal ins VLAN 11 was was aussendet. Ein Windows Rechner reicht, der bläst schon viele Broad- und Multicasts ins Netz, die du dann auch am Port 8 siehst.
Wichtig wäre hier mal zu sehen ob der Switch diese VLAN 11 Pakete taggt am Port 8.
Achtung ggf. musst du deinem Wireshark Rechner noch etwas in der Registry mitgeben damit der Tags anzeigt.
https://wiki.wireshark.org/CaptureSetup/VLAN
Für den RasPi kannst du auch Wireshark mit sudo apt-get wireshark installieren, dann kannst du mit dem auch sniffen. Der zeigt übrigens VLAN Tags out of the Box an im Gegensatz zu Winblows.
Im NG habe ich diese Konfiguratiosmöglichkeit leider nicht.
Oooops !!Sorry aber dann ist es doch logisch das nichts geht !!
Dann hängen deine Management IP Adressen doch weiterhin in VLAN 1 !!
Wie sollen die denn jemals ins VLAN 11 kommen ?? Das ist doch dann klar, dann kann das doch nicht gehen, denn die VLAN Doamins sind physisch ja vollkommen getrennt untereinander.
Grrrr....dann hätten wir uns diese Eierei doch komplett ersparen können...
Wenn du das Management VLAN der Switches NICHT umstellen kannst wie im Cisco oben, dann bleiben die Management IPs doch immer fest im VLAN 1.
Dein VLAN 1 wird ja nun gar nicht übertragen und logischerweise wirst du so die Switches niemals erreichen können dann. Nachdenken...!!!
Dann bleibt dir doch nur die Option wieder alles auf VLAN 1 umzuschwenken und das VLAN 1 zu taggen.
Ob die doofen NGs das dann können, also das VLAN 1 taggen, solltest du besser vorher mit dem Wioreshark an Port 8 messen sonst eiern wir hier ggf. wieder sinnfrei im Kreis rum.
Sollten sie das auch nicht können, dann bleiben die ne isolierte Insel managementmäßig gesehen.
Die Teile sind echt Müll....aber egal.
Auf den nächsten Thread mit NG Gurken antworte ich nicht mehr...
So, da mir das keine Ruhe gelassen hat hier mal ein Feedback mit einem TP-Link statt des Cisco SG-200 am Mikrotik ether 5 Port:
Hier sieht man schon das Drama bzw. Dilemma bei den Billigswitches und deren eingeschränkten Optionen die sich bei sowas rächen:
Du erkennst hier jetzt vermutlich auch die böse Zwickmühle bei dieser Art von limitierten Switches:
Lösung eins geht nicht weil das Feature fehlt. Lösung 2 auch nicht weil auch das Feature fehlt. Da ist man dann vollends gekniffen und kann die Switches nur isoliert managen.
Ich vermute das du mit den billigen Netgears im gleichen Dilemma hängst. Leider kann ich das in Ermangelung von NetGear Switchhardware nicht testen
Für einen letzten Test solltest du aber unbedingt mal am NG checken ob der das VLAN 1 wirklich tagged am Port 8 oder nicht.
Dazu wie gesagt einen Wireshark dort anklemmen und mit irgendeinem Rechner im VLAN 1 (eins) dann ins Nirwana pingen o.ä. (VLAN 1 taggen an Port 8 nicht vergessen !)
Die dafür erforderlichen Broadcasts sollten am Port 8 mit einem 802.1q Tag auftauchen (ID 1) wie er oben im Sniffer Screenshot zu sehen ist.
Tut er das nicht, dann tagged der NG das VLAN 1 nicht analog zum TP-Link und dann kannst du das Management nicht erreichen.
Ggf. mal mit beiden Switches testen, da du ja unterschiedliche Modelle hast.
Noch ein wichtiger Punkt der am TP-Link und auch am NetGear auffällig ist. Ich habe das bei NetGear GS-10xE Modellen gesehen:
Beide supporten ein proprietäres "Port based VLAN" Verfahren ! Dieses ist NICHT kompatibel zu dem standardtisierten 802.1q VLAN Verfahren !!!
Du darfst also keinesfalls dieses Verfahren auf dem NG wählen sondern das MUSS immer auf Disabled bleiben !!
Du darfst ausschliesslich einzig nur das 802.1q VLAN Verfahren dort aktivieren !
Siehe dazu auch hier:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Nur nochmal zur Erinnerung damit du nicht in diese böse Falle tappst !
Hier sieht man schon das Drama bzw. Dilemma bei den Billigswitches und deren eingeschränkten Optionen die sich bei sowas rächen:
- Der TP-Link kann das VLAN 1 NICHT taggen !
- Das Management Interfaces dieses Switches kann NICHT in ein anderes VLAN verlegt werden. Es ist hier immer fest an VLAN 1 gebunden.
Du erkennst hier jetzt vermutlich auch die böse Zwickmühle bei dieser Art von limitierten Switches:
- 1.) Dadurch das man beim TP-Link das VLAN 1 am Switchport 8 (Verbindung auf den MT) nicht taggen kann, entfällt die Option den MT über das VLAN 1 anzubinden. Beim MT muss das VLAN 1 zwingend mit einem Tag verwendet werden.
- 2.) Der Workaround über das VLAN 11 wäre wieder machbar aber leider supportet auch dieser Switch NICHT das Management IP Interface in ein anderes VLAN zu legen. Man kann so zwar den Mikrotik über VLAN 11 erreichbar machen nur nützt das wenig, denn das VLAN 1 mit der Management IP bleibt dann isoliert.
Lösung eins geht nicht weil das Feature fehlt. Lösung 2 auch nicht weil auch das Feature fehlt. Da ist man dann vollends gekniffen und kann die Switches nur isoliert managen.
Ich vermute das du mit den billigen Netgears im gleichen Dilemma hängst. Leider kann ich das in Ermangelung von NetGear Switchhardware nicht testen
Für einen letzten Test solltest du aber unbedingt mal am NG checken ob der das VLAN 1 wirklich tagged am Port 8 oder nicht.
Dazu wie gesagt einen Wireshark dort anklemmen und mit irgendeinem Rechner im VLAN 1 (eins) dann ins Nirwana pingen o.ä. (VLAN 1 taggen an Port 8 nicht vergessen !)
Die dafür erforderlichen Broadcasts sollten am Port 8 mit einem 802.1q Tag auftauchen (ID 1) wie er oben im Sniffer Screenshot zu sehen ist.
Tut er das nicht, dann tagged der NG das VLAN 1 nicht analog zum TP-Link und dann kannst du das Management nicht erreichen.
Ggf. mal mit beiden Switches testen, da du ja unterschiedliche Modelle hast.
Noch ein wichtiger Punkt der am TP-Link und auch am NetGear auffällig ist. Ich habe das bei NetGear GS-10xE Modellen gesehen:
Beide supporten ein proprietäres "Port based VLAN" Verfahren ! Dieses ist NICHT kompatibel zu dem standardtisierten 802.1q VLAN Verfahren !!!
Du darfst also keinesfalls dieses Verfahren auf dem NG wählen sondern das MUSS immer auf Disabled bleiben !!
Du darfst ausschliesslich einzig nur das 802.1q VLAN Verfahren dort aktivieren !
Siehe dazu auch hier:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Nur nochmal zur Erinnerung damit du nicht in diese böse Falle tappst !
1Wichtig wäre hier mal zu sehen ob der Switch diese VLAN 11 Pakete taggt am Port 8.
Leider hab ich das nciht hinbekommen. zumindest zeigt mir Wireshark unter Windows keine Vlans an. Laut dem Link sollte Realtek (PCIe GBE Familiy Controller) die Vlans übertragen. Und auf dem raspi habe ich WS installiert, allerdings startet der nicht und gibt ne Fehlermmeldung aus.dann bleiben die ne isolierte Insel managementmäßig gesehen.
Da kaufst du dir das, weil es mit VLAN beworben wird, aber richtig nutzen kannst es nicht.Und die irreführende konfiguratiosnmöglichkeiten geben dir den Rest, voll die Verarschung
Ohne deiner Analyse hätte ich das bis jetzt nicht verstanden.
Für einen letzten Test solltest du aber unbedingt mal am NG checken ob der das VLAN 1 wirklich tagged am Port 8 oder nicht.
Habs versucht, aber nicht hinbekommen, dazu fehlt mir das Wissen.Hier mein Testversuch:
Ich habe an port 1 einen WinPC, Port 1 hat PVID 1 und ist in V1 untagged
An port 8 habe ich den MT abgeklemmt und dafür mein Notebook angeschlossen. Also es besteht keinerlei Verbindung mehr zum MT. Port 8 am Switch hat PVID 1 und ist im Vlan 1 getagged. Und an diesem Rechner snifft WS, richtig?
Ggf. mal mit beiden Switches testen, da du ja unterschiedliche Modelle hast.
Switch2 wird über PoE von Switch 1 mit Strom versorgt, hab versucht den vom MT (port5) mit Strom zu versorgen, hat aber anscheinend nicht genug Saft, der Switch blieb dunkel.Du darfst ausschliesslich einzig nur das 802.1q VLAN Verfahren dort aktivieren
Ja, das ist aktiv. Ich kann mich nur für eins entscheiden, das andere ist dann deaktiviert.Leider hab ich das nciht hinbekommen. zumindest zeigt mir Wireshark unter Windows keine Vlans an.
Das ist generell SCHLECHT ! Dafür kann es 2 Gründe geben:
1.)
Der Switch tagged überhaupt nicht !
Das wäre dann natürlich fatal und weist auf einen gravierenden generellen Konfig Fehler im Switch hin. Dann wäre es auch klar das nichts klappt.
2.)
Der Wireshark Rechner kann die 802.1q VLAN Tags nicht anzeigen !
Dazu eine Anschlussfrage wenn das ein Windows Rechner ist:
Hast du, sofern du eine Intel basierete NIC Karte im Rechner hast, die entsprechende Registry Anpassung unter Windows gemacht ?? (HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\00nn)
Siehe auch HIER !
Du musst dort mit Neu -> DWord eine neues DWORD setzen mit dem Namen "MonitorModeEnabled" (Schreibweise exakt so !) und dem Wert 1.
In der Windows Registry sieht das dann so aus:
Wenn du dir das ersparen willst nimmst du deinen Raspberry Pi. Da gibst du ein
sudo apt-get update
sudo apt-get install wireshark
und installierst so Wireshark auf dem RasPi was eh nie schaden kann. Linux hat keine Probleme mit dem Tag wie Winblows und zeigt die immer an.
Hier kann es dann nur sein das Wireshark nicht als User "pi" startet. Dann machst du einfach ein Terminal auf und gibst dort sudo su ein und dann wireshark oder direkt sudo wireshark dann startet Wireshark mit Root Rechten. Der zeigt dir dann in jedem Falle die Tags !
Das wäre sehr wichtig das nochmal rauszubekommen !
Habs versucht, aber nicht hinbekommen, dazu fehlt mir das Wissen.
Mit dem obigen solltest du das Wissen ja jetzt haben !!! Und an diesem Rechner snifft WS, richtig?
Yepp, das ist genau richtig so !hat aber anscheinend nicht genug Saft, der Switch blieb dunkel.
Der MT kann keine standardkonforme PoE Versorgung nach 802.3af oder at !!! Das geht also logischerweise in die Hose. Die MTs supporten nur eine passive PoE Variante die proprietär ist ! Das kannst also vergessen.Es gibt natürlich eine gruselige Frickellösung:
Alle VLANs überträgst du wie oben mit einem tagged Port (ether 5, Port 8) an den MT. Für das Management VLAN 1 ziehst du eine extra Strippe aus einem untagged VLAN 1 Port am Switch an den MT auf einen ether Port wo nur eine VLAN 1 IP Adresse konfiguriert ist.
Gruselig und nicht schön, würde aber das Problem dann quick and dirty lösen.
Trotzdem solltest du aber auch mal mit dem Kabelhai messen ob der NG an Port 8 vorschriftsmässig tagged. Ggf. gibts doch noch eine elegante Lösung. Die Hoffnung stirbt zuletzt...
Mit anderer Switch HW wärst du längst schon produktiv....
Hallo aqui,
habe jetzt einen letzten Versuch gemacht und wie von dir beschrieben bzw. hier die Änderungen gemacht. Leider sehe ich keine 802.1q Pakete.
Hab alles durchprobiert: Einstellungen in der Realtek geändert, mit und ohne Registry Eintrag, Neustart, aber trotzdem sehe ich keine Vlan ID.
Jetzt habe ich definitiv keine Lust mehr
Aber jetzt reicht mir das erstmal mit dem testen.
Auf jeden Fall danke ich dir für deine vielen Tipps, Erläuterungen sowie deine Geduld mit mir und wünsche dir ein paar schöne Feiertage.
habe jetzt einen letzten Versuch gemacht und wie von dir beschrieben bzw. hier die Änderungen gemacht. Leider sehe ich keine 802.1q Pakete.
Hab alles durchprobiert: Einstellungen in der Realtek geändert, mit und ohne Registry Eintrag, Neustart, aber trotzdem sehe ich keine Vlan ID.
Jetzt habe ich definitiv keine Lust mehr
Für das Management VLAN 1 ziehst du eine extra Strippe aus einem untagged VLAN 1 Port am Switch an den MT auf einen ether Port wo nur eine VLAN 1 IP Adresse konfiguriert ist.
Ich denke das wird nichts, da MT und Switch räumlich getrennt sind und nur ein Kabel 8 (unterm Putz) verlegt ist.Mit anderer Switch HW wärst du längst schon produktiv....
Ich bin am überlegen, ob ich die NG's bei ebay reinstelle und mir dafür noch einen MT hole, damit sollte es ja klappen.Aber jetzt reicht mir das erstmal mit dem testen.
Auf jeden Fall danke ich dir für deine vielen Tipps, Erläuterungen sowie deine Geduld mit mir und wünsche dir ein paar schöne Feiertage.
Einstellungen in der Realtek geändert,
Einige der neuen Realtek basierten Karten können keine 802.1q Tags anzeigen im Gegensatz zu den älteren z.B. Realtek RTL 8139 wo es vollkommen ohne irgendwelche Einstellungen geht !Bei denen wo es geht musst du ebenfalls einen Eingriff in die Windows Registry machen mit ein paar mehr Settings als Intel:
https://www.dafit.ch/blog/wireshark-vlan-tag-sichtbar-machen/
Das gar keine Tags angezeigt werden ist eher ein Indiz das die Tags in der NIC blockiert werden, denn das wäre sonst sehr ungewöhnlich.
Traffic aus dem VLAN 12, 13 oder 14 was ja definitiv getaggt wird am Switch sollte in jedem Falle einen Tag im Wireshark anzeigen.
Um auf Nummer sicher zu gehen nimm deinen RasPi, der zeigt die Tags an.
Worst Case wäre natürlich das der Switch wirklich nicht tagged. Aber dann müsste ganz grundsätzlich was falsch in der Konfig sein was erstmal nach den o.a. Screenshots nicht so aussieht, obwohl man bei NG ja nie weiss...?!?
Teste sonst nochmal mit den 3 anderen VLANs. Wie die Tags im Wireshark aussehen müssen siehst du ja am obigen Screenshot.
und Switch räumlich getrennt sind und nur ein Kabel 8 (unterm Putz) verlegt ist.
Das kann man mit zwei Modularverteiler auf 2 Leitungen splitten:https://www.reichelt.de/?ACTION=3;ARTICLE=37328;SEARCH=modularverteil
Nachteil ist dann das du pro Leitung nur max. 100Mbit da nur noch 4 Adern vorhanden. Aber eben 2 Leitungen..
Ich bin am überlegen, ob ich die NG's bei ebay reinstelle
Das wäre am sinnigsten. Oder einen D-Link 1210 oder Cisco SG200 dafür beschaffen. Damit klappt alles wenigstens ganz sicher....Hast ja jetzt etwas Zeit über die Feiertage einen neuen Plan zu machen...
Dir auch frohe Weihnachten.
hallo aqui,
hab hier noch eine lesslinux live CD rumliegen gehabt, da ist auch WS drauf, davon gebootet und gesnifft.
Sowohl am MT als auch am NG werden jetzt tags mitgegeben
1. Am MT Win-Client an Port 3 und WS an Port 5
und hier ein V14 paket
IP aus dem V1 enthaelt kein Tag
2. Am NG der WinClient an P1 und WS an Port 8
das gleiche wobei der Win Client jetzt am P2 haengt
das gleiche, der Win Client jetzt am P2 und WS an Port 5 wobei P5 getagged
jetzt die Konstellation Win Client an P2, WS an Port 5 und Port 8 mit MT verbunden, so wie es eigentlich sein soll, hier ist wohl kein Tag dabei
jetzt habe ich den NG-P8 mit dem MT verbunden und WS am NG-P5, wobei der der P5 als Mirror von P8 im NG konfiguriert ist.
So, nur sehr schlau werde ich nicht daraus. Ich sehe nur dass eben die Tags mitgegeben werden, so wie es sein soll.
Bestaetigt das jetzt deine Annahme, dass der NG mit dem V1 irgenwie nicht klarkommt oder ist irgendwas anderes im Argen. Hoffe du kannst mit den Infos was anfangen.
hab hier noch eine lesslinux live CD rumliegen gehabt, da ist auch WS drauf, davon gebootet und gesnifft.
Sowohl am MT als auch am NG werden jetzt tags mitgegeben
1. Am MT Win-Client an Port 3 und WS an Port 5
IP aus dem V1 enthaelt kein Tag
2. Am NG der WinClient an P1 und WS an Port 8
das gleiche wobei der Win Client jetzt am P2 haengt
das gleiche, der Win Client jetzt am P2 und WS an Port 5 wobei P5 getagged
jetzt die Konstellation Win Client an P2, WS an Port 5 und Port 8 mit MT verbunden, so wie es eigentlich sein soll, hier ist wohl kein Tag dabei
jetzt habe ich den NG-P8 mit dem MT verbunden und WS am NG-P5, wobei der der P5 als Mirror von P8 im NG konfiguriert ist.
So, nur sehr schlau werde ich nicht daraus. Ich sehe nur dass eben die Tags mitgegeben werden, so wie es sein soll.
Bestaetigt das jetzt deine Annahme, dass der NG mit dem V1 irgenwie nicht klarkommt oder ist irgendwas anderes im Argen. Hoffe du kannst mit den Infos was anfangen.
IP aus dem V1 enthaelt kein Tag
Ooops ?!!Das ist aber NICHT die MT Seite, oder ??
Beim MT dürfte das NICHT sein wenn du ihn genau so konfiguriert hast wie oben besprochen. Ich hatte das auch gesiffert und du kannst hier EINDEUTIG den VLAN 1 Tag auf der Mikrotik Seite sehen.
Leider hast du ein CDP Paket gesniffert, was keine gute Idee ist, denn Das Infrastruktur Protokoll wird ummer nur auf der Physisk gesendet nicht auf Tagged Ports.
Besser also nochmal einen Ping am MT anschieben und dann nochmal messen. Der MT müsste für den Ping ARPen bzw. ICMPs senden und die haben dann ganz sicher einen VLAN 1 Tag !
Wenn nicht ist nochwas an der MT Konfig falsch, das ist dann sicher.
Analog musst du das dann auch auf der NG Seite machen. Wenn du nachweisen kannst das der Switch in der Lage ist VLAN 1 Pakete zu taggen, dann hast du gewonnen ! Dann kann man es umsetzen das es klappt.
Dein Trace zeigt es ja auch eindeutig das der Switch es absolut richtig macht.
Folglich ist also der MT hier der böse Buhmann und dort hast du noch irgendwas falsach gemacht in dessen Konfig !!!
Switch Seite ist also safe !
Die VLAN Tags 12, 13 usw sind ja erstmal irrelevant. Es geht hier rein um das VLAN 1. Das muss tagged am MT ether 5 Port rauskommen und auch am Port 8 des Switches.
Ist das der Fall dann MUSS eine Verbindung klappen, sprich ein Ping von den Management IPs auf die MT VLAN 1 IP und umgekehrt muss möglich sein.
Hilfreich wäre es wenn du KEINE CDP Pakete snifferst sondern z.B. Ping Versuche. Das sind ARP oder ICMP Pakete aus dem VLAN 1. Es kann z.B. auch ein Ping auf eine der IP Adressen des VLAN 1 sein. Auch wenn diese Adresse nicht erreichbar sein sollte, sendet der Ping Client einen ARP Broadcast aus um die Mac Adresse diese IP rauszubekommen. Der Brocast MUSS den VLAN 1 Tag haben. Sowohl von Switchseite als auch MT Seite.
Eigentlich sieht es ja so aus als ob beide Seiten es richtig machen. Etwas verwirrend wie gesagt deine VLAN 12 usw. Traces die ja erstmal egal sind. Es geht hier ja nur um die Management Connec tivity in VLAN 1.
Der Rest funktioniert ja.
Hallo aqui,
erstmal ein gutes neues Jahr.
Hatte die letzten Tage, keine Zeit mich damit zu beschäftigen.
Heute abend hab ich mich wieder hingesetzt und getestet.
Meine neuen Mitschnitte bestätigen das. Als erstes habe ich Port 2 ins VLAN 1 umkonfiguriert und einen WinRechner dort angeschlossen. Am Port 5 des MT habe ich dann folgendes gesnifft:
Auch in den ARP werden keine V1 Tags mitgegeben.
Als nächstes habe habe ich den WinRechner in Port 3 angeschlossen der im VLAN 13 liegt und ebenfalls am Port 5 gesnifft (zuvor Port 2 wieder in V12 zugewiesen). Vom WinRechner dann Pings auf die Adresse des MT 151.1 abgesetzt, sowie auf den Adresse des Linux Rechners 151.250 am Port 5. Auch hier keine Tags im Vlan 1.
In den LLDP Paketen werden jeweils die IDs für 12,13,14 mitgegeben, jedoch nicht bei den beiden Einträgen mit ether5 und vlan1.
Ich glaube an der MT Konfig (port5) stimmt tatschlich was nicht, der verteilt auch keine DHCP adressen.
Leider kann ich keinen Fehler finden, hab eigentlich alles so wie von dir beschrieben konfiguriert.
Evtl. wäre jetzt wirklich eine Teamviewer Sitzung notwendig.
erstmal ein gutes neues Jahr.
Hatte die letzten Tage, keine Zeit mich damit zu beschäftigen.
Heute abend hab ich mich wieder hingesetzt und getestet.
Das ist aber NICHT die MT Seite, oder ??
Eigentlich schon, hab ja drüber geschrieben "am MT Win-Client an Port 3 und WS an Port 5"Meine neuen Mitschnitte bestätigen das. Als erstes habe ich Port 2 ins VLAN 1 umkonfiguriert und einen WinRechner dort angeschlossen. Am Port 5 des MT habe ich dann folgendes gesnifft:
Auch in den ARP werden keine V1 Tags mitgegeben.
Als nächstes habe habe ich den WinRechner in Port 3 angeschlossen der im VLAN 13 liegt und ebenfalls am Port 5 gesnifft (zuvor Port 2 wieder in V12 zugewiesen). Vom WinRechner dann Pings auf die Adresse des MT 151.1 abgesetzt, sowie auf den Adresse des Linux Rechners 151.250 am Port 5. Auch hier keine Tags im Vlan 1.
In den LLDP Paketen werden jeweils die IDs für 12,13,14 mitgegeben, jedoch nicht bei den beiden Einträgen mit ether5 und vlan1.
Switch Seite ist also safe !
Das muss tagged am MT ether 5 Port rauskommen
Das muss tagged am MT ether 5 Port rauskommen
Ich glaube an der MT Konfig (port5) stimmt tatschlich was nicht, der verteilt auch keine DHCP adressen.
Leider kann ich keinen Fehler finden, hab eigentlich alles so wie von dir beschrieben konfiguriert.
Evtl. wäre jetzt wirklich eine Teamviewer Sitzung notwendig.
Am Port 5 des MT habe ich dann folgendes gesnifft:
Bitte mal den Screen Capture auf WEISS umstellen. Mit diesem dunklen graublau kann man wahrlich nix erkennen Auch in den ARP werden keine V1 Tags mitgegeben.
Das wäre besser zu sehen wenn du das Ethernet II Framing mit einem Klick auf "+" mal aufgeklappt hättest aber egal...Frage hierzu:
Hast du hier den "Trick" angewendet und Port 5 mit dem Dummy VLAN 99 als PVID eingerichtet ?
Sprich also PVID auf 99 und dann VLAN 1 auf Tagged ?
Klar ist aber das wenn dort kein VLAN 1 Tag mitgesendet wird der MT diese Pakete natürlich dann niemals dem VLAN 1 zuordnen kann
Der VLAN 1 Tag vom Switch ist hier also zwingend.
Das der Wireshark .1q Tags mitsniffert hast du hoffentlich vorher verifiziert, oder ??
WinRechner in Port 3 angeschlossen der im VLAN 13 liegt und ebenfalls am Port 5 gesnifft
Dann sollten alle ARPs usw. die von diesem WinRechner kommen einen VLAN 13 Tag an Port 5 haben !!!Leider sieht man das NICHT an deinem Trace
Auch hier ist das Framing nicht aufgeklappt (klick auf +) so das man den 802.1q Tagg NICHT sehen kann !
Hier nochmals die eindringliche Frage: Das der Wireshark .1q Tags mitsniffert hast du hoffentlich vorher verifiziert, oder ??
Alle Frames die der Win Rechner in VLAN 13 aussendet müssen am Port 5 den VLAN 13 Tag haben
Liegt der Rechner an VLAN 12 Port haben sie einen VLAN 12 Tag dort, ind VLAN 14 einen VLAN 14 Tag...alles logisch, denn der Port 5 ist ja immer Tagged für die VLAN 12, 13 und 14 !
Auch für VLAN 1 sollte er es sein damit der MT diesen Tag 1 lesen kann und ihm dann seinem VLAN 1 Interface zuordnen kann. Das Prinzip ist ja nun hinreichend klar....
Ich glaube an der MT Konfig (port5) stimmt tatschlich was nicht, der verteilt auch keine DHCP adressen.
Mmmhhh...hattest du jetzt am Switchport gesniffert oder am MT Port ???Möglich das ich da jetzt was missverstanden habe
Wenn du da am MT Port gesniffert hast, dann hast du in der Tat ein Problem mit der MT Konfig, denn wenn dann die Traces stimmen und der Wireshark auch verifiziert die Tags zeigt, dann wird da ja GAR NIX getagged !!
Dann hast du wirklich ein Konfig Problem auf dem MT und dort de facto was falsch gemacht !!
Das in den VLANs 12, 13 und 14 keine DHCP Adressen verteilt werden spricht dann zusätzlich dafür !
Dann musst du also an den MT nochmal ran !!
Achtung wenn du hier die neue Firmware 6.41 aufgespielt hast !!!
Dort gibt es keine Master Ports mehr und die VLAN Konfig geht etwas anders als zuvor über eine Bridge !!!
Hier musst du also zwingend deine VLAN Konfig anpassen solltest du die 6.41 verwenden !
Hast du hier den "Trick" angewendet und Port 5 mit dem Dummy VLAN 99 als PVID eingerichtet ?
Sprich also PVID auf 99 und dann VLAN 1 auf Tagged ?
Nein, hier gibts kein VLAN 99 mehr.Sprich also PVID auf 99 und dann VLAN 1 auf Tagged ?
Das der Wireshark .1q Tags mitsniffert hast du hoffentlich vorher verifiziert, oder ??
In den LLDP Paketen wird die ID für VLAN 12,13,14 ausgegeben, also denke ich dass das grundsätzlich funtkioniert. Oder was meinst Du mit "verifiziert"?Dann sollten alle ARPs usw. die von diesem WinRechner kommen einen VLAN 13 Tag an Port 5 haben !!!
In den ARP Paketen war keine Vlan ID ersichtlich, auch in dem Ethernet II Framing nichtMmmhhh...hattest du jetzt am Switchport gesniffert oder am MT Port ???
Nur am MT Port 5, der Switch ist für den Test gar nicht angeschlossen.Das in den VLANs 12, 13 und 14 keine DHCP Adressen verteilt werden spricht dann zusätzlich dafür !
Das war missverständlich ausgedrückt, das gilt nur für VLAN 1, in den anderen VLANs funktioniert DHCP.Achtung wenn du hier die neue Firmware 6.41 aufgespielt hast !!!
Nein, Firmware ist 6.40.5, da habe ich kein Update.Hmm, wie komme ich hier bloß weiter?
Nein, hier gibts kein VLAN 99 mehr.
Das war auch nur auf die Frage bezogen ob du am Switchport snifferst. Nur da würde es Sinn machen.Auf dem MT gäbe es ja so oder so kein VLAN 99 Workaround, der kann VLAN 1 ja problemlos taggen
In den LLDP Paketen wird die ID für VLAN 12,13,14 ausgegeben
OK, wenn du die siehst nachdem du + aufgeklappt hast dann ja.Kommt das vom MT Port oder vom Switchport ?
In den ARP Paketen war keine Vlan ID ersichtlich, auch in dem Ethernet II Framing nicht
Das darf NICHT und kann auch nicht sein !!Ist ja auch logisch, denn die ARP Broadcast Pakete müssen ja transparent im jeweiligen VLAN geforwardet werden.
Diese Broadcasts MUSST du also zwangsweise sowohl am MT Uplink Port als auch am Switch Uplink Port IMMER zwingend mit dem jeweiligen Tag des entsprechenden VLAN sehen !
Dort an diesen Ports werden die Pakete ja explizit getaggt. Müssen sie ja auch damit die jeweils gegenüberliegende Seite anahnd der Tags erkennen kann welchem VLAN sie diese Pakete wieder zuordnen müssen.
Ohne Tags werden die verworfen bzw. ins native VLAN geforwardet (PVID VLAN) und verschwinden da dann.
Da wäre es dann klar das nix geht.
Die Tags müssen zwingend auf beiden Seiten der Uplink Verbindung zu sehen sein !
Das war missverständlich ausgedrückt, das gilt nur für VLAN 1, in den anderen VLANs funktioniert DHCP.
Ahh OK. Gut dann ist ja ein Routing zw. den VLANs 12, 13 und 14 problemlos möglich, richtig ?Du steckst dann natürlich in einem Dilemma denn es gibt fürs VLAN 1 mit dem MT nur 2 Lösungs Optionen:
1.)
VLAN 1 taggen auf beiden Seiten. Das scheitert bei dir am NG Switch der das ja vermutlich nicht supportet
2.)
Management VLAN in ein anderes VLAN als 1 hieven um die Switches Management seitig erreichbar zu machen.
Auch das scheitert bei dir weil die NGs das vermutlich nicht supporten.
Wie willst du das dann also lösen...geht nicht
Also entweder auf das Switch Management verzichten oder neue HW.
Kann mann mit einem kleinen Zwischenswitch machen ist aber Frickelei. Du solltest dann besser einen der NGs tauschen in einen HW die 1 und/oder 2 kann und an den dann den MT anbinden.
Daran kannst du dann wieder die NGs anschliessen.
Ein kleiner Cisco SG-200-8 würde das Problem lösen
Oder einen der NGs ersetzen.
Das darf NICHT und kann auch nicht sein !!
Das ist aber so. Es deutet alles daraufhin, dass der MT am Port 5 kein Tag für das Vlan1 mitgibt, für V12-V14 jedoch schon.Ich habe den MT wieder zurückgesetzt und wieder alles erneut konfiguriert und gesniffert, jedoch mit dem gleichen Problem.
Am Port 5 des MT kommen keine ARP Pakete mit V1 an.
Also entweder auf das Switch Management verzichten oder neue HW
Auf Mangement verzichten ist blöd und auf neue HW habe ich auch keine Lust mehr.Zumal ich ja mittelerweile, wie oben geschrieben, der Meinung bin, dass das Problem am Port 5 des MT's hängt.
Ggf. habe ich bei deinen Anleitungen etwas missverstanden, jedoch hast du ja die Screenshots für korrekt bewertet, also weiß ich nicht weiter.
Nachdem ich heute wieder mal mehrere Stunden hiermit vergeudet habe, werde ich nochmal eine Nacht darüber schlafen und vermutlich dann mein "Projekt" abblasen
Das darf NICHT und kann auch nicht sein !!
Das ist aber so.
Das habe ich vermutlich missverstanden. Du meintest das nur für VLAN 1, richtig ??Das ist aber so.
Ich hatte das so verstanden das das auch für alle anderen VLANs gilt und das das am Switchport gemessen wurde.
Wenn ich das jetzt richtig verstehe hast du aber direkt am Mikrotik Port 5 gemessen, oder ??
Das ist dann schon komisch, denn hier auf meinem MT ist eindeutig ein VLAN 1 Tag zu sehen ! Der oben gepostete Sniffer Trace belegt das ja auch eindeutig.
Es gibt jetzt 2 Möglichkeiten dazu:
- Das Verhalten an Port 5 ist anders als an Port 1 (Ich nutze Port 1)
- Du hast irgendwas falsch gemacht in deiner Konfig !
Was aber noch viel komischer ist, ist die Tatsache das es eigentlich so dann funktionieren müsste.
Auf deinem Switchport wo der MT angeschlossen ist, ist ja switchseitig die PVID 1 konfiguriert und alle anderen VLANs tagged.
Sprich also: Alle UNtagged Pakete an diesem Switch Port werden auf dem Switch in sein VLAN 1 geforwardet.
Wenn du nun vom Mikrotik (der ja VLAN 1 untagged sendet wie du sagst) über die Ping Funktion die Management IP Adressen der Switches im VLAN 1 pingst müssten die ja antworten...?!
Da wäre es mal ganz spannend wenn du ins VLAN 1 am ersten Switch der direkt am MT ist einen Wireshark PC ins VLAN 1 hängst, testweise die Mgmt IPs der Switches pingst was ja gehen müsste und dann vom MT mal die IP des Wireshark Test PCs pingst.
Dort müssten dann ARP und nachfolgend die ICMP Pings eingehen. Ein Indiz damit es dann geht.
Du kannst auch zusätzlich mal den Wireshark Test PC direkt mit einer VLAN 1 IP an den MT Port hängen wo sonst der Switch hängt. Auch hier müsstest du dann vom MT die Test PC IP im VLAN 1 pingen können und auch hier wäre es sehr interessant mal den Wireshark mitlaufen zu lassen. Auch hier müsstest du VLAN 1 ARP und dann ICMP Echos sehen (Ping).
Wenn das so klappt wäre das ja eine bzw. die Lösung.
Ich habe auf meinem Test MT jetzt die neue Firmware 6.41 mit dem geänderten VLAN Handling drauf. Ich mache dafür nochmal einen Testsetup mit deinem Szenario und verifiziere dort mal das Ping Verhalten über Port 5 und Port 1 um da ggf. Unterschiede auszuschliessen.
Ich versuche auch mal einen MT hier zu finden der noch eine alte FW Version hat um das obige Setup nichmal zu verifizieren.
Blas mal bitte noch nicht ab....!! Diese letzten Tests sollten wir noch machen !!
Du siehst ja das es generell klappt und das werden wir auch mit deinen NG Gurken hinbekommen !
Du meintest das nur für VLAN 1, richtig ??
Korrekt.Wenn ich das jetzt richtig verstehe hast du aber direkt am Mikrotik Port 5 gemessen, oder ??
Korrekt. NG Switche habe ich abgeklemmt und sind für den Test gar nicht im Netz vorhanden.Das Verhalten an Port 5 ist anders als an Port 1 (Ich nutze Port 1)
Möglich, das wäre ja fatal. Kann es sein, das wir unterschiedliche MT-Modelle verwenden? Ich habe hier den "MT hap ac" mit gigabit und Wlan, vielleicht tickt der ja anders?Du hast irgendwas falsch gemacht in deiner Konfig !
Wie schon gesagt, hab alles geprüft und neu konfiguriert, wenn du das gleiche Modell verwendest, könnte ich dir ja ein Backup der konfig mailen, was du dann bei dir restorest. Vorraussetzung ist natürlich gleiches du hast das gleiche Modell.Wenn du nun vom Mikrotik (der ja VLAN 1 untagged sendet wie du sagst) über die Ping Funktion die Management IP Adressen der Switches im VLAN 1 pingst müssten die ja antworten...?!
Ja, so sollte es sein, aber das ist ja mein Problem, das es so nicht ist. Auch die von dir empfohlenen Tests habe ich bereits gemacht (siehe bspw. Eintrag vom 3.1.) Ist nicht so wie es sein soll.Ich hänge gerade mit meinem Notebook dirket am port 5 des MT (NG's sind abgeklemmt).
1. Problem der DHCP vergibt keine Adresse, also habe ich meinem Notebook die 192.168.151.7 manuell konfiguriert
2. ich versuche die MT konfigseite 151.1 über den Browser abzurufen -> die hängen im gleichen Netz und der MT ist nicht erreichbar !
3. Im Vlan 1 sollte ja die ID 1 mitgegeben werden
4. im Vlan 4 wird die ID 14 korrekt mitgegeben
So, Testaufbau erledigt !
Um's gleich vorwegzunehmen: Es rennt ! Und zwar auch mit dem VLAN 1 untagged an Port 5.
Damit sollten dann auch deine NetGears vollständig integrierbar sein.
Die Mikrotik Konfigs findest du HIER zum Download:
https://www.sendspace.com/file/bke6hm
Die Konfig Datei mit "noencr" ist die nicht encryptete Version der Konfig. Habs zur Sicherheit einmal so und einmal so gesichert.
Die Konfig im Detail:
Der Mikrotik ist ein hAP genau wie bei dir und rennt in diesem Setup mit der derzeit aktuellen Version 6.41:
Port 5 = Tagged Uplink auf den VLAN Switch (Testswitch hier Cisco SG-200)
Port 4 = Untagged Port in VLAN 14 (IP Netz 192.168.14.0 /24)
Port 3 = Untagged Port in VLAN 13 (IP Netz 192.168.13.0 /24)
Port 2 = Untagged Port in VLAN 12 (IP Netz 192.168.12.0 /24)
Port 1 = Point to Point Port auf den Internet Router im IP Netz 192.168.150.0 /24
DHCP Server läuft auf dem MT in allen IP Netzen außer dem Koppelnetz zum Internet Router Port ether 1
VLAN Switchkonfig:
Mehr oder minder selbsterklärend. (U=Untagged, T=Tagged)
Port 8 = Tagged Uplink auf den Mikrotik, Port 5
Port 7 = Endgeräteport in VLAN 14
Port 6 = Endgeräteport in VLAN 13
Port 5 = Endgeräteport in VLAN 12
Hier sieht man das der Switch schon via untagged VLAN 1 an Port 5 (MT) eine IP vom MT DHCP Server über seinen Uplink an Port 8 bekommt:
Ein Zeichen das der untagged VLAN 1Traffic des MT sauber im VLAN 1 des Switches landet.
WinBox Verbindung funktioniert auch auf Anhieb. (Der Konfig PC steckte an Port 1 des LAN Switches.)
Mikrotik Interface und DHCP Konfig:
Fortsetzung der Interface und DHCP Konfig
Mikrotik Switchkonfig des internen L2 Switches:
Diese Konfig ist mit die wichtigste, denn sie bestimmt welcher Traffic untagged und tagged ist am internen Switch.
VLAN Portzuweisung des int. Switches
ether1 istnicht dabei da diese IP direkt dem Port zugewiesen ist und NICHT einem VLAN. Das ist die Punkt zu Punkt Verbindung auf den Internet Router 192.168.150.254.
Wenn das nun nicht klappt bei deinem hAP, dann liegt der Fehler zwischen den Kopfhörern
Um's gleich vorwegzunehmen: Es rennt ! Und zwar auch mit dem VLAN 1 untagged an Port 5.
Damit sollten dann auch deine NetGears vollständig integrierbar sein.
Die Mikrotik Konfigs findest du HIER zum Download:
https://www.sendspace.com/file/bke6hm
Die Konfig Datei mit "noencr" ist die nicht encryptete Version der Konfig. Habs zur Sicherheit einmal so und einmal so gesichert.
Die Konfig im Detail:
Der Mikrotik ist ein hAP genau wie bei dir und rennt in diesem Setup mit der derzeit aktuellen Version 6.41:
Port 5 = Tagged Uplink auf den VLAN Switch (Testswitch hier Cisco SG-200)
Port 4 = Untagged Port in VLAN 14 (IP Netz 192.168.14.0 /24)
Port 3 = Untagged Port in VLAN 13 (IP Netz 192.168.13.0 /24)
Port 2 = Untagged Port in VLAN 12 (IP Netz 192.168.12.0 /24)
Port 1 = Point to Point Port auf den Internet Router im IP Netz 192.168.150.0 /24
DHCP Server läuft auf dem MT in allen IP Netzen außer dem Koppelnetz zum Internet Router Port ether 1
VLAN Switchkonfig:
Mehr oder minder selbsterklärend. (U=Untagged, T=Tagged)
Port 8 = Tagged Uplink auf den Mikrotik, Port 5
Port 7 = Endgeräteport in VLAN 14
Port 6 = Endgeräteport in VLAN 13
Port 5 = Endgeräteport in VLAN 12
Hier sieht man das der Switch schon via untagged VLAN 1 an Port 5 (MT) eine IP vom MT DHCP Server über seinen Uplink an Port 8 bekommt:
WinBox Verbindung funktioniert auch auf Anhieb. (Der Konfig PC steckte an Port 1 des LAN Switches.)
Mikrotik Interface und DHCP Konfig:
Fortsetzung der Interface und DHCP Konfig
Mikrotik Switchkonfig des internen L2 Switches:
Diese Konfig ist mit die wichtigste, denn sie bestimmt welcher Traffic untagged und tagged ist am internen Switch.
VLAN Portzuweisung des int. Switches
ether1 ist
- PCs und Endgeräte bekamen an den Switchports 5 (Vlan 12), 6 (Vlan 13) und 7 (Vlan 14) sauber IPs des jeweiligen VLANs ebenso direkt an den Mikrotik Port 2, 3 und 4.
- Pingen aus allen VLANs auf die Management IP 192.168.151.150 des Switches klappt problemlos, ebenso auf die .150.1 und die Internet Router IP .150.254.
- Die Konfig kam auch nach mehreren Reboots problemlos wieder hoch, ist also wasserdicht.
Wenn das nun nicht klappt bei deinem hAP, dann liegt der Fehler zwischen den Kopfhörern
1Wenn das nun nicht klappt bei deinem hAP, dann liegt der Fehler zwischen den Kopfhörern
Das wird's wohl sein Mein Routerboard sieht so aus, nur um sicherzugehen, dass die Konfigs untereinander verwendbar sind:
Die von dir oben beschriebene Konfig entspricht meiner, bis auf folgende Abweichungen, von den abweichenden Adresspools sehe ich ab, da diese irrelevant sind:
In der Switch Port Zusweisung:
Die IP am ether1 hat bei mir die 150.254, da die FB die 150.1 hat, das ist das einzige was ich an deiner Konfig für meine Umgebung angepasst habe.
Habe also zunächst deine Konfiguration eingespielt, ohne jegliche Änderung (MT version 6.40), leider kein Erfolg.
Nachdem ich dann in der Adress List die IP am ether1 wie oben beschrieben angepasst habe -> trotzdem kein Erfolg.
Also habe ich als nächstes auf Version 6.41 upgedatet und deine Konfig erneut wiederhergestellt, sowie ether1 IP angepasst. Auch das brachte keinen Erfolg. Um ehrlich zu sein, ist das Verhalten mit deiner Konfig noch schlimmer, da in den VLANs 12-14 jetzt auch keine DHCP Adresssen verteilt werden, was mit meiner konfig funktionierte. Das gilt unabhängig von dem Upgrade. Selbst die Adressvergabe am MT in den Vlans 12-14 funktioniert jetzt auch nicht mehr.
Hier ist noch nicht mal der NG im Spiel, d.h. der MT alleine verhält sich schon nicht wie bei dir.
Ich verstehe nicht, wie mit der gleichen Konfiguration, bei dir alles funktioniert und bei mir eben nicht. Hat mein MT einen defekt? Ich glaube das war der letzte Stoss den ich benötigt habe um das ganze abzublasen.
Habe dir meine konfig hochgeladen. Würde mich nur noch interessieren, ob das bei dir funktioniert oder nicht.
Mein Routerboard sieht so aus,
Du hast das Firmware Upgrade NICHT durchgeführt !!! Grrr..Vergleich mal die Eintrage unter "Current Firmware" !!! Fällt dir da was auf ??!!
Du bist in der Firmware immer noch auf einem antiken uralt Stand mit der die Kiste mal ausgeliefert wurde.
Das solltest du DRINGENST ändern !
Also einmal den "Upgrade" Button dort klicken und die Kiste rebooten !
Unter "Upgrade" und "Current" Firmware MUSS die gleiche Version stehen !!
Unsere Routerboard Hardware (hAP) ist vollkommen identisch !
- Mache also einen Werksreset OHNE Default Konfig und OHNE Backup.
- Ugrade die Firmware und reboote den MT
- Checke ob Current und Upgraded GLEICH ist
- Spiele die Konfig ein
Wenn nicht schick das Teil her dann konfigurier ich ihn dir.
Ich werde das jetzt hier nochaml überprüfen und meinen ebenfalls resetten und die Konfig neu einspielen und checken ob er dann so sauber wieder hochkommt.
Stay tuned....
1
OK, Korrektur !
Ich hatte einen Fehler gemacht und die onboard Ports auf dem MT nicht beachtet. Shame on me.
Die obige Konfig hat zwar so funktioniert aber einzig nur in den Switch VLANs über MT Port 5
Die Ports 2-4 mit den VLAN Endgeräteports auf dem MT funktionieren so natürlich nicht und waren blockiert....sorry.
Hier kommt die nun wasserdicht getestete Korrektur.
Die final funktionierende Konfig findest du hier zum Download:
https://www.sendspace.com/file/e031zk
Die Korrekturen im Detail:
Zuerst musst du global eine Bridge anlegen (bridge1) um die 4 Ports zu koppeln damit ether2 bis 4 lokal genutzt werden können.
Dieser Bridge dann die Ports hinzufügen:
(Beispiel hier immer für ether5 und ether2 (vlan12). Analog für die anderen VLANs anpassen. Die Einstellungen sind mehr oder minder selbsterklärend wenn man auf das Tagging und nicht Tagging sieht.)
VLAN Einstellungen der Ports:
VLAN Definitionen der Bridge:
Korrektur der VLAN Zuweisung der internen Switchports
Mapping der VLAN Interfaces jetzt auf den Bridge Port (bridge1):
Damit rennt das nun alles fehlerfrei. Ich habe das mit Clients in allen 3 VLANs sowohl am MT Endgeräteport als auch am angeschlossenen Switch in den dortigen VLAN Ports getestet = Alles OK
MT rebootet = Connectivity OK
MT gelöscht und Konfig neu eingespielt, rebootet = Auch OK.
Mehr kann man jetzt nicht machen.
Sollte das wider Erwarten bei dir nicht funkltionieren, dann ist dein MT defekt !
Sorry nochmal für den Fehler oben und die etwas halbherzige Zwischenkonfig !
Ich hatte einen Fehler gemacht und die onboard Ports auf dem MT nicht beachtet. Shame on me.
Die obige Konfig hat zwar so funktioniert aber einzig nur in den Switch VLANs über MT Port 5
Die Ports 2-4 mit den VLAN Endgeräteports auf dem MT funktionieren so natürlich nicht und waren blockiert....sorry.
Hier kommt die nun wasserdicht getestete Korrektur.
Die final funktionierende Konfig findest du hier zum Download:
https://www.sendspace.com/file/e031zk
Die Korrekturen im Detail:
Zuerst musst du global eine Bridge anlegen (bridge1) um die 4 Ports zu koppeln damit ether2 bis 4 lokal genutzt werden können.
Dieser Bridge dann die Ports hinzufügen:
(Beispiel hier immer für ether5 und ether2 (vlan12). Analog für die anderen VLANs anpassen. Die Einstellungen sind mehr oder minder selbsterklärend wenn man auf das Tagging und nicht Tagging sieht.)
VLAN Einstellungen der Ports:
VLAN Definitionen der Bridge:
Korrektur der VLAN Zuweisung der internen Switchports
Mapping der VLAN Interfaces jetzt auf den Bridge Port (bridge1):
Damit rennt das nun alles fehlerfrei. Ich habe das mit Clients in allen 3 VLANs sowohl am MT Endgeräteport als auch am angeschlossenen Switch in den dortigen VLAN Ports getestet = Alles OK
MT rebootet = Connectivity OK
MT gelöscht und Konfig neu eingespielt, rebootet = Auch OK.
Mehr kann man jetzt nicht machen.
Sollte das wider Erwarten bei dir nicht funkltionieren, dann ist dein MT defekt !
Sorry nochmal für den Fehler oben und die etwas halbherzige Zwischenkonfig !
Du hast das Firmware Upgrade NICHT durchgeführt
Bin davon ausgegangen, wenn ich in den Packages auf Download und Install klicke, dass kein weiteren Schritte notwendig sind.
Hab jetzt upgrade durchgeführt und vorher Resetet, danach config eingespielt.
Jetzt sehe ich was du meinst, dass in 6.41 VLAN über bridge konfiguriert wird.
Allerdings scheint mir dass, die Ports 2-4 alle jetzt im VLAN 1 sind.
Muss hier in der bridge auf dem Reiter VLANs bzw. auf dem Bridge Ports noch angepasst werden?
Einen Test kann ich momentan nicht durchführen. Nur soviel, die pings auf dem MT Terminal erreichen alle Adressen, bis auf die 2 IP's der NG's. (151.4 und 151.4)
Allerdings scheint mir dass, die Ports 2-4 alle jetzt im VLAN 1 sind.
Ja, das war wie du oben sehen kannst ein Fehler meinerseits ! Sorry das ich dich damit im Eifer des Gefechts in die Wüste geschickt hatte. Die Konfig ging zwar so aber einzig nur auf den Switches und eben NICHT am MT !
wenn ich in den Packages auf Download und Install klicke
Nein ! Besser niemals so machen, denn das erfordert immer einen Internet Zugang !Mache das Update immer manuell wenn immer möglich !
- Firmware hier runterladen (MIBSBE): https://mikrotik.com/download
- Dann Firmware Datei via WinBox Tool per Drag and Drop einfach in das geöffnete Files Window fallen lassen. Dann kopiert sich die Firmware selber aufs System.
- Nach dem Kopieren Router rebooten
- Danach unter System -> Routerboard auf "Upgrade" klicken um die interne Firmware upzudaten
- Rebooten und vergleichen das "Upgrade" und "Current" Firmware GLEICH sind !
- Fertisch
Hat sich wohl überschnitten, danke für die Konfig, werde nochmal testen.
Dann drücken wir uns mal die Daumen...
Sollte aber sehr verwunderlich sein wenn da jetzt was anderes rauskommt als eine funktionierende Konfig !!!
Sollte aber sehr verwunderlich sein wenn da jetzt was anderes rauskommt als eine funktionierende Konfig !!!
So...großes Finale nach 78 Thread Einträgen mit dem "alles geht" Test !
Es funktioniert nun absolut wasserdicht getestet alles in diesem Design und das auch so das es problemlos in eine Standard VLAN Konfig wie mit den NetGears integriert werden kann.
Als Testswitch hier wieder bewusst der TP-Link von oben, da der von der VLAN Konfig Prozedur ja identisch zu deinen NetGears ist.
Als 2ter Switch kaskadiert am TP-Link der Cisco SG-200 mit der identischen Konfig von oben. Also genau dein Design.
Das es mit dem TP-Link fehlerfrei klappt zeigt auch klar, das es so auch mit den NGs so klappen muss !
Eine kleine aber wichtige Korrektur gab es noch an der MT Konfig, denn das ether 1 Interface ins Internet brauchte noch eine wichtige Anpassung im internen Switch damit auch das noch klappte. (VLAN ID entfernen)
Damit gibt es auch wieder eine neue, nochmal überarbeitete Konfig Datei für den Mikrotik Router. (Download Link am Ende dieses Threads)
Finaler Testaufbau:
Konfig Korrektur des MT internen Switches ether 1:
Default Route und Pingtest auf dem Mikrotik Router:
Ping auf Internet IP 8.8.8.8 klappt.
(In den Ping Advanced Settings kann man hier zusätzlich das Ping Source Interface abwechselnd auf ether2, 3 und 4 setzen und so verifizieren das auch der Internet Ping aus den VLAN Subnetzen ins Internet klappt !)
Switchkonfig TP-Link VLAN Switch:
VLAN Port Setting.
Switchport 1 hier der Tagged Uplink auf den Mikrotik (Port 5). Die Switchports 6 (VLAN 12), 7 (VLAN 13) und 8 (VLAN 14 ) untagged als Endgerätepoprts in den VLANs.
PVID Setting pro Port.
Switchports 6 (VLAN 12), 7 (VLAN 13) und 8 (VLAN 14 ) entsprechend ihrer VLAN Zugehörigkeit gesetzt.
IP Adresse Management. (Ist bewusst testweise auf DHCP gelassen um die Verbindung via VLAN 1 zum MT zu verifizieren)
Hier kam genau wie beim Cisco Switch die Management IP schon gleich vom DHCP Server des Mikrotik.. VLAN 1 Connectivity also auch gegeben.
(Sollte man später aber besser auf eine statische IP ändern !)
Getestet mit Router OS 6.41. Die finale Konfig Datei zum Einspielen auf den MT findest du hier:
https://www.sendspace.com/file/oeu4t0
Case closed !
Es funktioniert nun absolut wasserdicht getestet alles in diesem Design und das auch so das es problemlos in eine Standard VLAN Konfig wie mit den NetGears integriert werden kann.
- Management Zugriff aus allen Netzen
- VLAN Kommunikation aller VLANs
- Internet Zugang aus allen VLANs
Als Testswitch hier wieder bewusst der TP-Link von oben, da der von der VLAN Konfig Prozedur ja identisch zu deinen NetGears ist.
Als 2ter Switch kaskadiert am TP-Link der Cisco SG-200 mit der identischen Konfig von oben. Also genau dein Design.
Das es mit dem TP-Link fehlerfrei klappt zeigt auch klar, das es so auch mit den NGs so klappen muss !
Eine kleine aber wichtige Korrektur gab es noch an der MT Konfig, denn das ether 1 Interface ins Internet brauchte noch eine wichtige Anpassung im internen Switch damit auch das noch klappte. (VLAN ID entfernen)
Damit gibt es auch wieder eine neue, nochmal überarbeitete Konfig Datei für den Mikrotik Router. (Download Link am Ende dieses Threads)
Finaler Testaufbau:
Konfig Korrektur des MT internen Switches ether 1:
Default Route und Pingtest auf dem Mikrotik Router:
Ping auf Internet IP 8.8.8.8 klappt.
Switchkonfig TP-Link VLAN Switch:
VLAN Port Setting.
Switchport 1 hier der Tagged Uplink auf den Mikrotik (Port 5). Die Switchports 6 (VLAN 12), 7 (VLAN 13) und 8 (VLAN 14 ) untagged als Endgerätepoprts in den VLANs.
Switchports 6 (VLAN 12), 7 (VLAN 13) und 8 (VLAN 14 ) entsprechend ihrer VLAN Zugehörigkeit gesetzt.
Hier kam genau wie beim Cisco Switch die Management IP schon gleich vom DHCP Server des Mikrotik.. VLAN 1 Connectivity also auch gegeben.
- DHCP Adressen werden in allen VLANs fehlerfrei verteilt.
- Ping mit den Endgeräten aus allen VLANs 12 bis 14 klappte untereinander und auch auf die Internet IP 8.8.8.8 fehlerlos.
- Ebenso der Management Zugriff auf die Switches aus allen Netzen.
- DNS Server im MT DHCP ist die 192.168.150.254 und damit klappte dann auch die DNS Auflösung fehlerlos.
- Löschen auf Werksreset des MT und Wiedereinspielen der Konfig brachte das Szenario nach 15 Sek. wieder zum Spielen. Die kurze Wartezeit ist normal, da die Endgeräte ihre DHCP Adressen verifizieren müssen und die Spanning Tree Prozesse der Switches den Learning Mode abschliessen müssen.
Getestet mit Router OS 6.41. Die finale Konfig Datei zum Einspielen auf den MT findest du hier:
https://www.sendspace.com/file/oeu4t0
Case closed !
1
Und ?? Wie siehts aus ? Rennt alles ?
Spann uns nicht so lange auf die Folter !
Spann uns nicht so lange auf die Folter !
Und ?? Wie siehts aus ? Rennt alles ?
Spann uns nicht so lange auf die Folter !
Spann uns nicht so lange auf die Folter !
Nee, das hab ich nicht vor, aber ich habe ein echtes Zeitproblem. Du siehst ich lege ständig Nachtschichten ein.
Also, habe auf Werkseinstellungen resetet anschliessend deine Finale Konfiguration eingespielt... ich traue mich fast gar nicht mehr einen Misserfolg zu melden ... leider hat's nicht funktioniert.
Wie oben schon geschrieben, habe ich die IP's für meine Umgebung nach dem Restore angepasst. Also IP am ether1 auf 150.254 gesetzt und damit verbunden die Default Route auf 150.1 gesetzt. Zunächst habe ich nur am MT getestet aber der hat noch nicht mal DHCP Adressen an den einzelnen Ports vergeben.
Habe also alles gelöscht und von vorne begonnen, d.h. den MT nach deiner Anleitung neu konfiguriert, dummerweise hatte ich plötzlich während der internen Switch Konfiguration keinen Zugriff auf den MT, so dass ich den mit dem Resetbutton mehrfach reseten musste. Jetzt habe ich die Konfig endlich fertig. Leider funktioniert das trotzdem nicht.
Der momentane Zustand ist im Grunde so wie vor dem Update auf 6.41, nur dass jetzt zusätzlich die Verbindung zur FB nicht geht:
- Der MT vergibt Adressen im V12, 13 u. 14, nur im V1 geht es nicht
- Auch der NG Switch vergibt die Adressen im v12-14, in V1 habe ich auch keinen Zugriff
- Der MT selbst findet kann die Fritzbox (150.1) nicht anpingen, obwohl mit ether1 (150.254) verbunden
Nur um auch das auszuschliessen hier meine Verkabelung:
Grau geht von FB an MT Port 1
Orange geht von MT Port 5 an NG Port 8 (tagged Link, IP : 151.5)
grün vom NG Port 1 gehts an den zweiten NG (tagged Link)
Ich werde aus der Geschichte nicht schlau
Hab hier meine aktuelle Konfig hochgeladen, vielleicht kannst Du prüfen ob diese bei dir geht, dann würde ich sagen hat der MT einen defekt, andernfalls habe ich Tomaten auf den Augen oder bin einfach nur blöd.
Sorry, dass ich keinen Erfolg melden kann.
dummerweise hatte ich plötzlich während der internen Switch Konfiguration keinen Zugriff auf den MT,
Das kann hie und da mal passieren.Du musst beim WinBox Tool dann immer zwingend darauf achten das du auf die Mac Adresse klickst und dann auf Connect !
So verbindet sich die WinBox dann immer auf dem Layer 2 und NICHT auf dem Layer 3 über die IP.
Das ist sicherer und stabiler.
nur dass jetzt zusätzlich die Verbindung zur FB nicht geht:
Das war bei mir auch so und der Grund war das im internen Switch der Port ether 1 ind den VLAN secure Mode gesetzt werden musste und auf "always strip". Danach funktionierte das sofort.hier meine Verkabelung:
Ist exakt so wie meine hier im Testaufbau.Du hast aber doch ein anderes MT Modell als ich ! Bist du dir ganz sicher das das ein hAP ist ?
Ich teste jetzt mal deine Konfig Datei. Das wird spannend...
So verbindet sich die WinBox dann immer auf dem Layer 2 und NICHT auf dem Layer 3 über die IP.
Ja, hatte ich versucht aber selbst das ging nicht mehr, der war total Weg, so das ich nur den Resetbutton zur Auswahl hatte.Danach funktionierte das sofort.
Nee, bei mir leider gar nicht oder zumindest war die Verbindung so wie oben beschrieben weg, dass ich gar nich tmehr draufkam.Du hast aber doch ein anderes MT Modell als ich ! Bist du dir ganz sicher das das ein hAP ist ?
So wie ich sehe hast du das Lite Model mit 100Mbit, meiner hat 1 gibgabit, also der hAP ac.Das wäre zumindest ein Grund wieso deine Konfig bei mir nicht geht.
Also die Einstellungen werden zwar alle übernommen und sieht auch so wie bei deiner Beschreibung aus, allerdings funktioniet hats nicht.
Bin gespannt. Beachte, dass ich andere IP Adressen verwende.
OK, ich spiel das mal auf beiden Kisten ein...stay tuned....
Beachte, dass ich andere IP Adressen verwende.
Kein Thema für einen IP Wizzard
So, leider keine guten Nachrichten...
Die folgenden Erkenntnisse waren aber auch für mich neu, da ich bis dato von einer homogenen Funktion über die MT Modelle ausgegangen bin, was aber sehr wahrscheinlich NICHT der Fall ist. Jedenfalls nicht was Funktionen des internen Switch Chips anbetrifft. Das trübt leider den ansonsten sehr guten Eindruck von Mikrotik.
Aber wieder was gelernt...
Ich habe nach deinem Feedback die identische Konfig in folgende Modelle konfiguriert:
Es ist also reproduzierbar.
Am schlimmsten war der RB 750GL den ich auch nur mit dem Reset Knopf wieder auf die Füße bekommen habe. Genau wie bei dir.
Ich habe mit 2 nebeneinander liegenden Fenstern die Konfigs akribisch verglichen mit der funktionierenden um jeden Konfig seitigen Fehler ganz sicher ausschliessen zu können.
Es scheint de facto am internen Switch Chip zu liegen. Die oben genannten Modelle haben folgende Hardware:
Übrigens auch wenn man den MT 2011er auf dem 2ten Gigabit Switchchip 8227 also der 2ten Gig Portgruppe konfiguriert. Damit rennt die Konfig auch dort fehlerfrei.
Nimmt man beim MT 2011 die erste 5er Portgruppe auf dem 8237 geht es ebenfalls nicht.
Ein starkes Indiz das es de facto an der Switch Hardware liegt. Es spricht vieles dafür das in deiner Box auch ein 8237 ist. Das kannst du im "Switch" Konfig Menü sehen.
Die finale Frage ist jetzt ob das in einer der kommenden Releases gefixt wird. Auf der MT Download Seite gibt es schon eine Beta der 6.42 Firmware.
Ich werde die morgen mal in einen der 8327er Hardware einspielen und mal checken ob es damit ggf. funktioniert.
Eigentlich ist das ein glasklarer Fall für den Mikrotik Engineering Support denn das ist de facto ein Firmware Bug !!!
Hilfreich wäre hier ggf. auch mal ein Feedback der hiesigen Forums Community der Kollegen die Mikrotik im Einsatz haben und das ggf. auf ihrer MT Hardware verifizieren könnten.
Die folgenden Erkenntnisse waren aber auch für mich neu, da ich bis dato von einer homogenen Funktion über die MT Modelle ausgegangen bin, was aber sehr wahrscheinlich NICHT der Fall ist. Jedenfalls nicht was Funktionen des internen Switch Chips anbetrifft. Das trübt leider den ansonsten sehr guten Eindruck von Mikrotik.
Aber wieder was gelernt...
Ich habe nach deinem Feedback die identische Konfig in folgende Modelle konfiguriert:
- RB 751
- RB 750GL
- RB 2011
Es ist also reproduzierbar.Am schlimmsten war der RB 750GL den ich auch nur mit dem Reset Knopf wieder auf die Füße bekommen habe. Genau wie bei dir.
Ich habe mit 2 nebeneinander liegenden Fenstern die Konfigs akribisch verglichen mit der funktionierenden um jeden Konfig seitigen Fehler ganz sicher ausschliessen zu können.
Es scheint de facto am internen Switch Chip zu liegen. Die oben genannten Modelle haben folgende Hardware:
- RB 751 = Atheros 7240
- RB 750GL = Atheros 8327
- RB 2011 = Atheros 8327 (1. Portgruppe) und Atheros 8227 (2. Portgruppe)
- hAP = Atheros 8227
Übrigens auch wenn man den MT 2011er auf dem 2ten Gigabit Switchchip 8227 also der 2ten Gig Portgruppe konfiguriert. Damit rennt die Konfig auch dort fehlerfrei.
Nimmt man beim MT 2011 die erste 5er Portgruppe auf dem 8237 geht es ebenfalls nicht.
Ein starkes Indiz das es de facto an der Switch Hardware liegt. Es spricht vieles dafür das in deiner Box auch ein 8237 ist. Das kannst du im "Switch" Konfig Menü sehen.
Die finale Frage ist jetzt ob das in einer der kommenden Releases gefixt wird. Auf der MT Download Seite gibt es schon eine Beta der 6.42 Firmware.
Ich werde die morgen mal in einen der 8327er Hardware einspielen und mal checken ob es damit ggf. funktioniert.
Eigentlich ist das ein glasklarer Fall für den Mikrotik Engineering Support denn das ist de facto ein Firmware Bug !!!
Hilfreich wäre hier ggf. auch mal ein Feedback der hiesigen Forums Community der Kollegen die Mikrotik im Einsatz haben und das ggf. auf ihrer MT Hardware verifizieren könnten.
1In allen 3 funktioniert die Konfig genau wie bei dir NICHT Es ist also reproduzierbar.
Ich hab schon an mir selbst gezweifelt ... was für eine Erleichertung Es ist also reproduzierbar.Das kannst du im "Switch" Konfig Menü sehen.
Wenn du das meinst, dann wäre es 8337
Was bedeutet das für mich? Leider kann ich Deinen Erkenntnissen nicht ganz folgen.
Hast du meine oder deine Konfig auf den Kisten restort und es hat nicht funktioniert?
Oder hast du alles manuell auf den Kisten konfiguriert und es hat trotzdem nicht funktioniert?
Muss mein Switch mit dem Chip 8337 vielleicht anders konfiguriert werden ?
Oder liegt hier tatsächlich ein Bug vor und ich kann tun was ich will und es geht trotzdem nicht?
1
Ooopss das ist ja wieder ein ganz neuer Switch Chip ?! Aber OK, vermutlich "mag" die o.a. Konfig nur der Atheros 8227....??
Wir sollten erstmal mit ganz einfachen VLAN Tagged Konfigs anfangen.
Also klasssich eine geroutete Verbindung zur FB und dann einen .1q VLAN Trunk mit IP Interfaces auf die beiden Switches.
Das ist ein banaler Klassiker und der sollte mit dem MTs machbar sein. Bedeutet dann das du keine lokalen VLAN Ports mehr hast auf dem MT sondern nur noch auf den Switches. Aber da das eh nur ein einzelner Port ist, ist das vermutlich leicht verschmerzbar.
Ich teste das mal auf den verschiedenen Switch Chips und poste das Ergebnis hier.
Was bedeutet das für mich?
Das bedeutet das du deine Konfig etwas umstellen bzw. "abspecken" musst. Du musst dich vermutlich von der Vorgabe verabschieden die unatgged VLAN Ports auch noch auf dem MT zu realisieren.Wir sollten erstmal mit ganz einfachen VLAN Tagged Konfigs anfangen.
Also klasssich eine geroutete Verbindung zur FB und dann einen .1q VLAN Trunk mit IP Interfaces auf die beiden Switches.
Das ist ein banaler Klassiker und der sollte mit dem MTs machbar sein. Bedeutet dann das du keine lokalen VLAN Ports mehr hast auf dem MT sondern nur noch auf den Switches. Aber da das eh nur ein einzelner Port ist, ist das vermutlich leicht verschmerzbar.
Ich teste das mal auf den verschiedenen Switch Chips und poste das Ergebnis hier.
Was lange wärt nach 87 Threads. Gute Nachricht... Es FUNKTIONIERT !!! Tadaaa...
Es ist definitiv KEIN Bug sondern wie so oft ein Konfig Fehler. Allerdings ein sehr gemeiner auf den man auch als Netzwerker nicht so ohne weiteres kommt.
Aber nach seeehr vielem Handbuch lesen und Stöbern im Mikrotik Forum lag die Lösung dann auf der Hand.
Der Knackpunkt war der Haken bei "VLAN Filtering" in der zentralen Bridge VLAN Konfig, denn erst DAS aktiviert grundsätzlich das VLAN Tag Handling im Switch Chip.
Ohne diesen Haken ab der neuen 6.41 Firmware ist der Switchchip doof was VLAN Tags angeht. Bzw. er ignoriert sie schlicht.
Dann muss zudem in der VLAN Port Zuweisung der Bridge, das Bridge Interface selber als tagged Port in die Konfig.
Dieser Punkt ist leider nur sehr schwammig in der Mikrotik Doku zur 6.4.1 beschrieben und bekommt man nur durch Trial and Error raus
Aber nungut...es klappt ja nun alles.
Hier ist die nun wirklich finale Lösung !!
Ich habe das um jetzt ganz sicher zu gehen mit allen 3 Mikrotik Modellen getestet und es funktioniert jetzt auch mit allen 3en fehlerlos. Das sollte es dann auch bei dir.
Die Konfig kannst du wieder HIER runterladen !
Sie ist auf einem RB 750G gemacht. Der der am härtesten abgestürzt ist und nur mit einem HW Reset wieder auf die Füße kam nach der falschen Konfig oben.
Am besten den MT vor der neuen Konfig auf Werkseinstellungen ohne Default Konfig und Backup via WinBox resetten.
Die Schritte im Einzelnen:
Bridge und Interfaces einrichten:
ACHTUNG !!!: Den Haken bei "VLAN Filtering" erstmal noch NICHT setzen !!
Der wird erst später gesetzt wenn die statische VLAN Portzuweisung gemacht ist.
Setzt man ihn vorher gibt es eine wirre zufällige Zuordnung und es funktioniert nicht !
Und nochwas:
KEINE Konfiguration des internen Switches machen !!!
Das passiert ab der 6.41 automatisch bzw. dynamisch und darf nicht statisch verändert werden. Also im Default belassen.
Auch leider ein Fehler von den alten Konfigs oben !
VLAN Ports einrichten und an die Bridge koppeln:
Richtige VLAN ID Zuordnung beachten !
Bridge Ports hinzufügen und das VLAN Tagging einrichten:
Hier ganz wichtig:
Bridge VLANs definieren und Ports zuweisen:
Wichtig hier genau drauf zu achten was Tagged und Untagged ist.
Sorry, leider fehlt hier VLAN 1 in der Aufregung. Das hat folgende Settings:
Tagged: Bridge 1, VLAN 1 Untagged: ether 5
Übersicht der IP Adressierung:
Ether 1 ist hier testweise als DHCP Client eingerichtet weil das für den Labortest bequemer war. Musst du dann ggf. wieder auf statisch setzen. Klappt aber bei dir auch an der FB so kommt die IP und Default Route von der FB
Statische Routen der VLANs auf der FB nicht vergessen.
Die DHCP Server Einstellungen und externen Switchkonfigs haben sich natürlich nicht geändert.
Jetzt zum Schluss denn alles entscheidenden Haken an der globalen Bridge VLAN Konfig setzen:
Nun solltest du die VLAN Zuweisung auch sehen können:
Das wars !!
Jetzt sind wir mal auf deinen MT gespannt !!!
Es ist definitiv KEIN Bug sondern wie so oft ein Konfig Fehler. Allerdings ein sehr gemeiner auf den man auch als Netzwerker nicht so ohne weiteres kommt.
Aber nach seeehr vielem Handbuch lesen und Stöbern im Mikrotik Forum lag die Lösung dann auf der Hand.
Der Knackpunkt war der Haken bei "VLAN Filtering" in der zentralen Bridge VLAN Konfig, denn erst DAS aktiviert grundsätzlich das VLAN Tag Handling im Switch Chip.
Ohne diesen Haken ab der neuen 6.41 Firmware ist der Switchchip doof was VLAN Tags angeht. Bzw. er ignoriert sie schlicht.
Dann muss zudem in der VLAN Port Zuweisung der Bridge, das Bridge Interface selber als tagged Port in die Konfig.
Dieser Punkt ist leider nur sehr schwammig in der Mikrotik Doku zur 6.4.1 beschrieben und bekommt man nur durch Trial and Error raus
Aber nungut...es klappt ja nun alles.
Hier ist die nun wirklich finale Lösung !!
Ich habe das um jetzt ganz sicher zu gehen mit allen 3 Mikrotik Modellen getestet und es funktioniert jetzt auch mit allen 3en fehlerlos. Das sollte es dann auch bei dir.
Die Konfig kannst du wieder HIER runterladen !
Sie ist auf einem RB 750G gemacht. Der der am härtesten abgestürzt ist und nur mit einem HW Reset wieder auf die Füße kam nach der falschen Konfig oben.
Am besten den MT vor der neuen Konfig auf Werkseinstellungen ohne Default Konfig und Backup via WinBox resetten.
Die Schritte im Einzelnen:
Bridge und Interfaces einrichten:
Der wird erst später gesetzt wenn die statische VLAN Portzuweisung gemacht ist.
Setzt man ihn vorher gibt es eine wirre zufällige Zuordnung und es funktioniert nicht !
Und nochwas:
KEINE Konfiguration des internen Switches machen !!!
Das passiert ab der 6.41 automatisch bzw. dynamisch und darf nicht statisch verändert werden. Also im Default belassen.
Auch leider ein Fehler von den alten Konfigs oben !
VLAN Ports einrichten und an die Bridge koppeln:
Bridge Ports hinzufügen und das VLAN Tagging einrichten:
- VLAN Ports mit aufnehmen
- Auf die VLANID achten
- Frame Type Zuordnung
Bridge VLANs definieren und Ports zuweisen:
Sorry, leider fehlt hier VLAN 1 in der Aufregung. Das hat folgende Settings:
Tagged: Bridge 1, VLAN 1 Untagged: ether 5
Übersicht der IP Adressierung:
Statische Routen der VLANs auf der FB nicht vergessen.
Die DHCP Server Einstellungen und externen Switchkonfigs haben sich natürlich nicht geändert.
Jetzt zum Schluss denn alles entscheidenden Haken an der globalen Bridge VLAN Konfig setzen:
Nun solltest du die VLAN Zuweisung auch sehen können:
Das wars !!
Jetzt sind wir mal auf deinen MT gespannt !!!
So melde mich zurück.
Habe deine Konfig eingespielt, was soll ich sagen ... war wieder nichts.
Habe dann festgestellt, dass die Konfiguration teilweise nicht mit deiner Doku übereingestimmt hat. Z.b. war der Haken bei VLAN Filterig nicht gesetzt, auch die VLANs waren unter Bridge / Ports nicht aufgeführt, ebenso unter Bridge/Vlans. Anscheinend können die Konfigs nicht untereinander verwendet werden. Auch nachdem ich das nachkonfiguriert habe, kein Erfolg.
Also habe wieder resetet und die Konfig manuell nach deiner Anleitung vorgenommen.
Bei meiner manuell vorgenommenen Konfiguration gab es keine automatische Anpassung, dass sieht so aus:
Und unter VLAN gibt es keine Einträge, bleibt das so?
Auf dem MT Terminal kann ich alles anpingen auch 8.8.8.8, Namensauflösung funktioniert aber nicht.
Ein am ether2 angeschlossener Rechner, kann nur 192.168.152.1 anpingen, auch den am NG in VLAN 2 angeschlossenen Rechner, sind die Rechner in unterschiedlichen VLANs funktioniert der Ping nicht. Eigentlich so wie es sein soll (ohne dass ich die Firewallregeln hinterlegt habe), allerdings komme ich aus den VLANs nicht ins Internet, d.h. weder ether1 noch die FB sind anpingbar.
DHCP geht auch auf MT und NG, allerdings wird der DNS nicht mitgegeben.
Ich denke in der Konfig passt es noch nicht ganz, obwohl es konfiguriert ist.
Die ersten Tests sehen gut aus, wenn jetzt das Internet noch geht, denke ich wars das.
Habe deine Konfig eingespielt, was soll ich sagen ... war wieder nichts.
Habe dann festgestellt, dass die Konfiguration teilweise nicht mit deiner Doku übereingestimmt hat. Z.b. war der Haken bei VLAN Filterig nicht gesetzt, auch die VLANs waren unter Bridge / Ports nicht aufgeführt, ebenso unter Bridge/Vlans. Anscheinend können die Konfigs nicht untereinander verwendet werden. Auch nachdem ich das nachkonfiguriert habe, kein Erfolg.
Also habe wieder resetet und die Konfig manuell nach deiner Anleitung vorgenommen.
KEINE Konfiguration des internen Switches machen !!!
Bei deiner Konfig fand ich die alten Einstellungen so wie hier:Bei meiner manuell vorgenommenen Konfiguration gab es keine automatische Anpassung, dass sieht so aus:
Und unter VLAN gibt es keine Einträge, bleibt das so?
Auf dem MT Terminal kann ich alles anpingen auch 8.8.8.8, Namensauflösung funktioniert aber nicht.
Ein am ether2 angeschlossener Rechner, kann nur 192.168.152.1 anpingen, auch den am NG in VLAN 2 angeschlossenen Rechner, sind die Rechner in unterschiedlichen VLANs funktioniert der Ping nicht. Eigentlich so wie es sein soll (ohne dass ich die Firewallregeln hinterlegt habe), allerdings komme ich aus den VLANs nicht ins Internet, d.h. weder ether1 noch die FB sind anpingbar.
DHCP geht auch auf MT und NG, allerdings wird der DNS nicht mitgegeben.
Ich denke in der Konfig passt es noch nicht ganz, obwohl es konfiguriert ist.
Die ersten Tests sehen gut aus, wenn jetzt das Internet noch geht, denke ich wars das.
Juhuuuu...röchel, das war ja eine schwere Geburt !
Aber ok, das waren auch die Fallen der neuen 6.41 Firmware in der das VLAN Handling komplett geändert wurde. Da bewegte ich mich auch auf dünnem Eis.
Aber nun haben wir ja alle Hürden bewältigt und klasse das es nun auch bei dir klappt wie es soll. Bestätigt das die Konfig so richtig ist.
Das Problem mit der geposteten Konfig ist ja noch das die auf einem RB750G Modell gemacht wurde.
Da kann man nicht garantieren, das das wirklich alles richtig in dein Modell übernommen wurde, da dort ja keine WLAN Interfaces usw. drin sind wie in deinem Model. Ich kann das aber auch nochmal auf einem portgleichen RB751 machen wenn du möchtest. Mittlerweile sind wir ja geübt
Möglich also das es da Probleme gibt, deshalb hatte ich das auch so von den Konfig Schritten noch mal explizit aufgeführt.
Du hast es ja dann intuitiv genau richtig gemacht und alles nochmal ganz neu auf deiner Maschine aufgesetzt. Das ist immer der richtige Weg um nicht in weitere Fallen zu tappen.
Das nur die DNS IP nicht mitkommt bei ansonsten richtiger DHCP IP Adress- und Gateway Vergabe in den VLANs ist immer ein Indiz das irgendwo ein Tippfehler ist bei der DNS IP. Hast du mal ein ipconfig -all eingegeben und das genau überprüft ?
Wenn du genau hinsiehst dann springt es dir bei deinen obigen Screenshot auch sofort ins Auge
Bei deinen DHCP Netzwerk IP Adressen steht überall 19.168.151.x statt 192. !!! Das musst du korrigieren. Tippfehler !
Der Rest mit dem Internet ist jetzt ein Kinderspiel !!!
Aber ok, das waren auch die Fallen der neuen 6.41 Firmware in der das VLAN Handling komplett geändert wurde. Da bewegte ich mich auch auf dünnem Eis.
Aber nun haben wir ja alle Hürden bewältigt und klasse das es nun auch bei dir klappt wie es soll. Bestätigt das die Konfig so richtig ist.
Das Problem mit der geposteten Konfig ist ja noch das die auf einem RB750G Modell gemacht wurde.
Da kann man nicht garantieren, das das wirklich alles richtig in dein Modell übernommen wurde, da dort ja keine WLAN Interfaces usw. drin sind wie in deinem Model. Ich kann das aber auch nochmal auf einem portgleichen RB751 machen wenn du möchtest. Mittlerweile sind wir ja geübt
Möglich also das es da Probleme gibt, deshalb hatte ich das auch so von den Konfig Schritten noch mal explizit aufgeführt.
Du hast es ja dann intuitiv genau richtig gemacht und alles nochmal ganz neu auf deiner Maschine aufgesetzt. Das ist immer der richtige Weg um nicht in weitere Fallen zu tappen.
Das nur die DNS IP nicht mitkommt bei ansonsten richtiger DHCP IP Adress- und Gateway Vergabe in den VLANs ist immer ein Indiz das irgendwo ein Tippfehler ist bei der DNS IP. Hast du mal ein ipconfig -all eingegeben und das genau überprüft ?
Wenn du genau hinsiehst dann springt es dir bei deinen obigen Screenshot auch sofort ins Auge
Bei deinen DHCP Netzwerk IP Adressen steht überall 19.168.151.x statt 192. !!! Das musst du korrigieren. Tippfehler !
Der Rest mit dem Internet ist jetzt ein Kinderspiel !!!
Das waren aber zwei große Tomaten auf meinen Augen
Nach der Korrektur funktioniert jetzt auch die Internetverbindung.
Die Änderung hat auch bewirkt, dass sich die Rechner in den verschiedenen VLANs wieder sehen, jetzt muss die Firewall doch noch aktiviert werden, korrekt ?
Komisch ist nur, dass ich vom Windows 192.168.153.194 den raspi 192.168.152.194 erreiche, allerdings nicht umgekehrt!!! Der Raspi findet den Windows Rechner nicht!
Da du auf meine Frage der Switch Konfig nicht eingegangen bist und das tagging funktioniert, gehe ich davon aus, dass am Switch nichts mehr konfiguiert werden muss, korrekt?
Mich wundert nur, dass Mikrotik die VLAN-Konfiguration von FW 6.40 auf 6.41 grundlegend geändert hat.
Ich wäre niemals alleine klargekommen, danke für Deine Hilfe.
Das nächste Schritt wird sein, jetzt auch noch das WLAN mit ins VLAN reinzunehmen, mal schauen was daraus wird....
Nach der Korrektur funktioniert jetzt auch die Internetverbindung.
Die Änderung hat auch bewirkt, dass sich die Rechner in den verschiedenen VLANs wieder sehen, jetzt muss die Firewall doch noch aktiviert werden, korrekt ?
Komisch ist nur, dass ich vom Windows 192.168.153.194 den raspi 192.168.152.194 erreiche, allerdings nicht umgekehrt!!! Der Raspi findet den Windows Rechner nicht!
Da du auf meine Frage der Switch Konfig nicht eingegangen bist und das tagging funktioniert, gehe ich davon aus, dass am Switch nichts mehr konfiguiert werden muss, korrekt?
Ich kann das aber auch nochmal auf einem portgleichen RB751 machen wenn du möchtest
Ich denke den Aufwand kannst du Dir sparen, deine Anleitung ist super und hat jetzt bei mir gegeht.Mich wundert nur, dass Mikrotik die VLAN-Konfiguration von FW 6.40 auf 6.41 grundlegend geändert hat.
Ich wäre niemals alleine klargekommen, danke für Deine Hilfe.
Das nächste Schritt wird sein, jetzt auch noch das WLAN mit ins VLAN reinzunehmen, mal schauen was daraus wird....
Nach der Korrektur funktioniert jetzt auch die Internetverbindung.
Klasse ! So sollte es sein !jetzt muss die Firewall doch noch aktiviert werden, korrekt ?
Nein, eigentlich nicht, denn die ist ja auf der FritzBüx. Ees sei denn...Du willst zwischen den VLANs den Zugriff regeln also ala VLAN 12 darf nicht ins VLAN 13 aber beide dürfen ins Internet.
Dann brauchst du ein Regelwerk in der MT Firewall aber auch nur dann.
Komisch ist nur, dass ich vom Windows 192.168.153.194 den raspi 192.168.152.194 erreiche, allerdings nicht umgekehrt!!!
Hast du die IPs umgestellt oder sind das wieder Tippfehler ?Was genau meinst du mit erreichen und was soll bei dir findet nicht bedeuten ??
Da kann man jetzt nur wild raten.
Erreichen ist das Ping ??
Ping ist ICMP und seit Windows 7 ist ICMP geblockt in Windows Rechnern:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Das musst du also erst freischalten in der lokalen Firewall des Windows Rechners !!
Außerdem blockt die Windows Firewall alle eingehenden IP Pakete die NICHT aus dem lokalen Netzwerk .153.0 /24 kommen !!
Sie lässt im Default generell nur Pakete aus dem eigenen IP Segment passieren, keine fremden. Auch das müsstest du ggf. anpassen and die Dienste wie Drucker- Filesharing, RDP usw.
Findet nicht.. Meinst du damit ggf. die Netzwerkumgebung ??
Da die ohne lokalen DNS Server auf Broadcasts beruht kommt das dann Prinzipien bedingt nicht über Routing Interfaces. Hier trägst du die Namen dann einfach statisch in die hosts oder lmhosts Datei ein um das zu fixen.
Oder noch besser, da du einen Raspberry Pi da am Fliegen hast...einen eigenen DNS Server:
https://www.heise.de/ct/ausgabe/2017-21-Privater-Nameserver-und-Adblocke ...
https://www.heise.de/ct/ausgabe/2017-12-Namensaufloesung-inklusive-Daten ...
Steigert also noch die Sicherheit und befreit dich von lästiger Werbung.
Nebenbei kannst du dein Netzwerk damit auch etwas überwachen:
Netzwerk Management Server mit Raspberry Pi
Fazit also: Windows Firewall tunen !
Da du auf meine Frage der Switch Konfig nicht eingegangen bist
Oooops...sorry hab ich im Eifer des Gefechts übersehen ?! Wo war die denn ?gehe ich davon aus, dass am Switch nichts mehr konfiguiert werden muss, korrekt?
Wenn du den MT abziehst und du kannst VLAN 1, 12, 13 und 14 nicht mehr erreichen. Dann sehr wahrscheinlich ja. Das würde dann zeigen das die VLANs vollkommen getrennt sind und das wäre ja dann richtig.dass Mikrotik die VLAN-Konfiguration von FW 6.40 auf 6.41 grundlegend geändert hat.
Das war lange angekündigt !Macht auch Sinn, denn die Konfig Krücke mit den Master Ports usw. war gelinde gesagt Bullshit.
Jetzt ist es eine Konfig die mehr oder minder logisch an Layer 2 Switches universal mit Tagging nicht Tagging usw. angepasst ist so wie es andere Hersteller auch machen. Es macht also Sinn das das so gemacht wurde.
danke für Deine Hilfe.
Immer gerne wieder ! Hauptsache ist das funktioniert jetzt alles bei dir. War ja auch etwas erhellend für mich was die neue Firmware anbetrifft also win win. Und die nächste VLAN Konfig beim nächsten Mikrotik machst du dann in 5 Minuten
noch das WLAN mit ins VLAN reinzunehmen, mal schauen was daraus wird....
Das ist jetzt auch wieder ein Kinderspiel.Wenn eins der VLANs ein WLAN ist oder werden soll einfach den WLAN Port an die Bridge anhängen an der auch das VLAN hängt... Port Konfig in der Bridge nicht vergessen wie bei den LAN Ports, fertig.
Du willst zwischen den VLANs den Zugriff regeln also ala VLAN 12 darf nicht ins VLAN 13 aber beide dürfen ins Internet.
Dann brauchst du ein Regelwerk in der MT Firewall aber auch nur dann.
Ja, genau das will ich. Sonst machen doch VLANs keinen wirklichen Sinn, oder ?Dann brauchst du ein Regelwerk in der MT Firewall aber auch nur dann.
Zwischen V12,13,14 soll keinen Verbindung zu einander bestehen, V1 soll für V12,13,14 erreichbar sein. Hoffe die Firewallkonfiguration stimmt so:
Erreichen ist das Ping ??
Ja.Außerdem blockt die Windows Firewall alle eingehenden IP Pakete die NICHT aus dem lokalen Netzwerk .153.0 /24 kommen !!
Ja, das hatte ich nicht bedacht, dass muss es gewesen sein. Ein Ping an einen Linuxrechner hatte dann funktioniert.Wenn du den MT abziehst und du kannst VLAN 1, 12, 13 und 14 nicht mehr erreichen. Dann sehr wahrscheinlich ja.
Hiermit meinte ich nicht den NG Switch, sondern den internen MT Switch, der sieht so aus, gehe davon aus, dass hier mit Firmware 6.41 nichts mehr konfiguriert werden muss:
Zum Thema WLAN gehe ich davon aus, dass ich dem eingebauten WLAN Chip für jedes VLAN ein Virtual Interface zuordnen kann und somit mit einem WLAN Chip gleichzeitg für jedes VLAN ein eigenen AP bereitstellen kann, ist das möglich?
Habe also folgende Konfiguration vorgenommen:
Virtual IF erzeugt:
Bridge Port konfiguriert
Bridge-VLAN Anpassung
Ich kann mich mit allen SSID verbinden, allerdings funktioniert nur V1, d.h. DHCP und Verbindung ins Internet.
Bei V12,13,14 kann ich mich mit den WLANs verbinden, aber bekomme vom DHCP keine IP. Auch nach manueller IP Zuweisung funktioniert die Verbindung weder ins Internet noch ins entspr. VLAN. Eine funktionierde Verbindung, bekomme ich immer nur in dem VLAN der dem physischen WLAN Chip zugewiesen ist, hier V1.
Ist mein Vorgehen / Annahme mit den Virtuellen Wlans falsch?
Sonst machen doch VLANs keinen wirklichen Sinn, oder ?
Doch, natürlich. Brodcast Last reduzieren, logische Trennung von Geräten usw. usw. Eine Segmentierung mit oder ohne Zugriffsregelung ist immer sinnvoll ab einer bestimmten Größe. Zwingend natürlich wenn man den Zugriff steuern will, das ist richtig.Hoffe die Firewallkonfiguration stimmt so:
Ja, wenn du nur TCP und UDP filtern willst. ICMP filterst du nicht also Ping wird dann nicht unterdrückt.Thema WLAN:
Wenn du mit MSSIDs arbeitest musst du taggen, vergiss das nicht ! In der Konfig macht man eine SSID zu VLAN ID Zuweisung.
Ich check das und poste ne Testkonfig.
Habe jetzt für V12,13, und 14 im IF den Schalter "use Tag" gesetzt
sowie in der bridge die VLANS 12-14 auf tagged gesetzt:
jetzt scheint es zu funktionieren
sowie in der bridge die VLANS 12-14 auf tagged gesetzt:
jetzt scheint es zu funktionieren
Leider funktioniert die Firewall nicht
Bekomme zwischen den Vlans eine Verbindung hin, bspw. von Win 192.168.153.x nach Linux 192.168.152.x per SSH.
Firewall sieht so aus:
Bekomme zwischen den Vlans eine Verbindung hin, bspw. von Win 192.168.153.x nach Linux 192.168.152.x per SSH.
Firewall sieht so aus:
Da fehlt die Maskenangabe bei Src und dst. Und das innerhalb von Bridges Firewall Regeln angewendet werden muss dies noch noch aktiviert werden.
/interface bridge settings use-ip-firewall=yes
Wo muss was eingestellt werden ?
Steht doch oben.
Bei SRC und DST die Maske an das Netz anhängen, 192.168.153.0/24
Für die Einstellung s. Befehl oben.
Bei SRC und DST die Maske an das Netz anhängen, 192.168.153.0/24
Für die Einstellung s. Befehl oben.
Hallo Voiper2,
danke für den Hinweis, hab jetzt nur die Maske ergänzt und es funktioniert, ohne das ich den Befehl
/interface bridge settings use-ip-firewall=yes
abgesetzt habe.
Momentan steht der Wert auf no, muss der trotzdem auf yes gesetzt werden?
Eigentlich funktioniert es schon so.
danke für den Hinweis, hab jetzt nur die Maske ergänzt und es funktioniert
, ohne das ich den Befehl/interface bridge settings use-ip-firewall=yes
abgesetzt habe.
Momentan steht der Wert auf no, muss der trotzdem auf yes gesetzt werden?
Eigentlich funktioniert es schon so.
Ach nee du hast ja vlans (übersehen) da braucht es das Setting nicht. Das braucht es nur wenn man Traffic aus der selben Layer2 Domain durch den Filter jagen möchte.
1
Die WLAN Konfig ist leider komplett falsch.
Auch das geht mit der 6.41 Version anders und auch besser
So gehst du vor:
1.) Unter WiFi Interfaces fügst du "Virtuelle" hinzu für deine VLANs 12, 13 und 12:
VLAN Mode = Use Tag, VLAN ID entsprechend deinem VLAN
(Hier entsprechender Testaufbau mit dem VLANs 1, 10 und 11)
2.) Das Source- bzw. physische WLAN Interface mappst du auf VLAN 1:
3.) WLAN Interfaces der Bridge hinzufügen:
4.) Den VLAN Interfaces die VLAN ID zuweisen:
5.) Bridgeports pro VLAN definieren:
Sorry, hier fehlen im Screenshot die wlanx Interface Zuweisungen pro VLAN !
Die Schritte 3, 4 und 5 sind identisch zu denen die du oben schon in der Bridge Zuweisung gemacht hast. Im Grunde ist das genau die VLAN ID Zuweisung wie man es auch bei den LAN Ports macht.
Wenn du dann dem AP auch das richtige Land (Germany) zugewiesen hast, dann zeigt dir der WLAN Client auch deine entsprechenden MSSID WLANs an auf dem Mikrotik:
Auch das geht mit der 6.41 Version anders und auch besser
So gehst du vor:
1.) Unter WiFi Interfaces fügst du "Virtuelle" hinzu für deine VLANs 12, 13 und 12:
VLAN Mode = Use Tag, VLAN ID entsprechend deinem VLAN
(Hier entsprechender Testaufbau mit dem VLANs 1, 10 und 11)
2.) Das Source- bzw. physische WLAN Interface mappst du auf VLAN 1:
3.) WLAN Interfaces der Bridge hinzufügen:
4.) Den VLAN Interfaces die VLAN ID zuweisen:
5.) Bridgeports pro VLAN definieren:
Sorry, hier fehlen im Screenshot die wlanx Interface Zuweisungen pro VLAN !
Die Schritte 3, 4 und 5 sind identisch zu denen die du oben schon in der Bridge Zuweisung gemacht hast. Im Grunde ist das genau die VLAN ID Zuweisung wie man es auch bei den LAN Ports macht.
Wenn du dann dem AP auch das richtige Land (Germany) zugewiesen hast, dann zeigt dir der WLAN Client auch deine entsprechenden MSSID WLANs an auf dem Mikrotik:
Die WLAN Konfig ist leider komplett falsch.
Die einzigsten Unterschiede, die ich zu meiner nachgebesserten Version vom 25.1. (hier hatte ich das "use tag" verwendet sowie VLANS getagged, danach funktionierte es) feststelle sind:- Punkt 2) Das Source- bzw. physische WLAN Interface steht bei mir auf "no tag", bei dir auf "use tag"
- Punkt 4) Den VLAN Interfaces die VLAN ID zuweisen: FrameTypes stehen bei mir für V12,13 und 14 auf " "admit only VLAN tagged" und für V1 auf "admit all", bei dir bei allen auf "admit all". Welche Auswirkungen hat das?
Wenn ich meine zur Zeit funktionierende Konfiguration in den beiden Punkten deiner Konfig entsprechend anpasse, dann komme ich über WLAN bspw. im VLAN14 (gilt auch für die anderen Vlans) nicht ins Internet, ein Ping zu 192.168.150.1 (fritzbox) geht nicht. Auch Pings zwischen den VLANs gehen bei deaktivierter Firewall nicht mehr. Was bewirken diese beiden Änderungen?
Punkt 1, 3 und 5 sind identisch mit deinen Einstellungen.
Ich gehe davon aus, dass die Profile sowie die SSID Bezeichnung für den Konfigurationsvergleich egal sind, also in deinem Fall VLAN1 bei mir V1, sowie default zu profil*.
Wenn du dann dem AP auch das richtige Land (Germany) zugewiesen hast, dann zeigt dir der WLAN Client auch deine entsprechenden MSSID WLANs an auf dem Mikrotik
Wo wird das Land hinterlegt? Ich habe nichts hinterlegt, die MSSID werden trotzdem angezeigt.Punkt 2) Das Source- bzw. physische WLAN Interface steht bei mir auf "no tag", bei dir auf "use tag"
Das kann man so machen, es kommt dann halt darauf an für welches VLAN das ist.Ich habe mich auf die letzte Konfig bezogen wo wir Switchseitig ja das VLAN 1 eingezogen haben und auch das VLAN 1 Interface tagged ist so das der internen MT Switch / Bridge das entsprechend zuordenen kann.
Das müsste man ja dann auch vom WLAN Port erwarten.
Da das ja nur eine Physisk ist muss der über Tags klar machen zu welchem VLAN das Datenpaket gehört.
Punkt 4) Den VLAN Interfaces die VLAN ID zuweisen:
Deine Konfig ist besser, da sicherer. Bitte so belassen wenn es klappt.Meine war ein quick and dirty Laboraufbau
in den beiden Punkten deiner Konfig entsprechend anpasse,
Nein lass das so wenn es klappt. Das ist reine Kosmetik.Allerdings hattest du oben ja eine Konfig gepoistet mit zig überflüssigen Bridges was nicht der Fall sein muss.
Daher die entsprechenden Screenshots oben.
Ich gehe davon aus, dass die Profile sowie die SSID Bezeichnung für den Konfigurationsvergleich egal sind,
Ja !Wo wird das Land hinterlegt?
Wenn du in der WinBox Hauptseite auf Quick Setup klickst, dann kannst du un den WLAN Settings sehen das du dort ein Land definieren musst.Ohne das sendet der MT logischerweise nicht.
Zudem sollte man den Mode noch auch 802.11g/n only setzen im 2,4Ghz Bereich.
Wenn du Dual Mode mit 5 Ghz hast dort 40Mhz Bandbreite und a/n only
Das kann man so machen, es kommt dann halt darauf an für welches VLAN das ist.
Ich habe mich auf die letzte Konfig bezogen wo wir Switchseitig ja das VLAN 1 eingezogen haben und auch das VLAN 1 Interface tagged ist so das der internen MT Switch / Bridge das entsprechend zuordenen kann.
Das müsste man ja dann auch vom WLAN Port erwarten.
Da das ja nur eine Physisk ist muss der über Tags klar machen zu welchem VLAN das Datenpaket gehört.
Sorry, hab ich nicht verstanden. Was mache ich jetzt "no tag" oder "use tag" am Source wlan1?Ich habe mich auf die letzte Konfig bezogen wo wir Switchseitig ja das VLAN 1 eingezogen haben und auch das VLAN 1 Interface tagged ist so das der internen MT Switch / Bridge das entsprechend zuordenen kann.
Das müsste man ja dann auch vom WLAN Port erwarten.
Da das ja nur eine Physisk ist muss der über Tags klar machen zu welchem VLAN das Datenpaket gehört.
Wenn du in der WinBox Hauptseite auf Quick Setup klickst, dann kannst du un den WLAN Settings sehen das du dort ein Land definieren musst.
Leider kann ich die Änderung hier nicht speichern ohne das ich IP adress und Wifi Password hinterlege.
Die sind ja über die VLANs bzw. Profile hinterlegt, zieht das hier nicht?
Welche Adresse muss ich an Port eth1 hinterlegen, unter Local Network ist ja 192.168.150.254 hinterlegt, wird die oben auch hinterlegt?
Soll ich das Wifi Password von WLAN-V1 hinterlegen?
Was mache ich jetzt "no tag" oder "use tag" am Source wlan1?
Das womit es funktioniert bei dir. Logisch wäre mit Tag !Leider kann ich die Änderung hier nicht speichern
Klick es auf Open und Bridge dann klappt es auch ohne Als IP nimmst du das was du vorher eingestellt hast.
Sowohl unter "PTP Bridge AP" als auch unter "PTP Bridge CPE" kann ich nur für das 5Ghz Netz das Land einstellen. Das 2GHz taucht nur im "Home AP Dual" auf. Reicht es dann, wenn ich nur das 5 Ghz auf germany setze?
Hab jetzt wieder resetet und neu konfiguriert, jetzt wird unter QuickSetup das vorher vorhandene "Home AP Dual" nicht mehr aufgeführt ????
Merkwürzig.... Das ist Hardware direkt und kann eigentlich unmöglich verschwinden.
Habs eben auf dem hAP hier mehrfach gemacht (Reset Konfig und Haken bei NO Default und NO Backup) und ist nicht reproduzierbar. Home AP Dual ist immer da !
Habs eben auf dem hAP hier mehrfach gemacht (Reset Konfig und Haken bei NO Default und NO Backup) und ist nicht reproduzierbar. Home AP Dual ist immer da !
Melde mich wieder zurück. Nachdem ich alles wieder platt gemacht habe und neu konfiguriert habe, konnte ich auch die letzen beiden Einstellungen (use tag im wlan1 und das Land) auch setzen
Scheint, dass sich die Masken im QuickSetup entsprechend der wlan Konfiguration ändern, aber egal.
Das ganze läuft jetzt auch seit ein paar Tagen stabil, so dass dieses Thema erledigt ist.
Der nächste Schritt ist jetzt, meine bestehende KNX-Haussteuerung in ein eigenes VLAN12 zu packen, sprich den GIRA IP Router den GIRA Homeserver und dann über mein Smartphone im WLAN13 (VLAN13) das Licht ein und auszuschalten.
Habe hier gelesen, dass das ganze wohl über Multicast (224.0.23.12) läuft und für die Kommunikation zwischen zwei VLANs im Mikrotik geroutet werden muss. Hat jemand eine Ahnung wo und wie das gemacht wird?
Scheint, dass sich die Masken im QuickSetup entsprechend der wlan Konfiguration ändern, aber egal.
Das ganze läuft jetzt auch seit ein paar Tagen stabil, so dass dieses Thema erledigt ist.
Der nächste Schritt ist jetzt, meine bestehende KNX-Haussteuerung in ein eigenes VLAN12 zu packen, sprich den GIRA IP Router den GIRA Homeserver und dann über mein Smartphone im WLAN13 (VLAN13) das Licht ein und auszuschalten.
Habe hier gelesen, dass das ganze wohl über Multicast (224.0.23.12) läuft und für die Kommunikation zwischen zwei VLANs im Mikrotik geroutet werden muss. Hat jemand eine Ahnung wo und wie das gemacht wird?
Das ganze läuft jetzt auch seit ein paar Tagen stabil, so dass dieses Thema erledigt ist.
Das ist doch mal ne gute Nachricht !!! Klasse und Glückwunsch !Der nächste Schritt ist jetzt, meine bestehende KNX-Haussteuerung in ein eigenes VLAN12 zu packen
Na das ist ja jetzt für dich nach der obigen Feuertaufe eine Lachnummer, oder ?? Habe hier gelesen, dass das ganze wohl über Multicast (224.0.23.12) läuft
Kann man nur hoffen das das kein Local Multicast ist mit TTL=1 ?!Der MT supportet aber PIM Routing und damit kannst du auch Multicast problemlos routen
UPNP mit Mikrotik Routerboard hEX PoE und D-Link DGS-1210-24 Switch
Danke für den Hinweis.
Habe jetzt das multicast package installiert und wie ich aus deinem Beitrag entnommen habe entsprechend konfiguriert:
Testen ob es funktioniert kann ich erst später, oder erkennst du schon einen Fehler in der Konfiguration?
Habe jetzt das multicast package installiert und wie ich aus deinem Beitrag entnommen habe entsprechend konfiguriert:
Testen ob es funktioniert kann ich erst später, oder erkennst du schon einen Fehler in der Konfiguration?
Sieht soweit gut aus.
IGMP solltest du aber zur Sicherheit besser überall auf v2 setzen. Viele Switches und Endgeräte können mit v3 nicht richtig umgehen.
IGMP solltest du aber zur Sicherheit besser überall auf v2 setzen. Viele Switches und Endgeräte können mit v3 nicht richtig umgehen.
Leider war das nicht erfolgreich, vorher auf IMGPv2 umgestellt und die Firewall deaktiviert, da ich ja den Traffic aus Vlan12 und Vlan13 geblockt habe. In den beiden Netgear Swichtes habe ich auch IMGP aktiviert für VLAN 12.
Habe dann folgendes gesnifft:
Der Gira Homeserver (IP 152.11) sendet wohl mit TTL 16, das sollte dann eigentlich funktionieren.
Auf meinem Raspi (IP 152.199) läuft zusätzlich Homebridge zur Steuerung mit Siri, hier ist wohl tatsächlich TTL 1. Das muss aber aus dem Vlan13 nicht unbedingt erreichbar sein, es reicht wenn der Gira HS in Vlan 13 erreichbar ist.
Habe dann hier im Kommentar von dog gelesen, dass IMGP Proxy auch ein Weg ist und entsprechend getestet.
Gehe mal davon aus, dass Vlan13 den Upstream bekommt, da ich aus Vlan13 in Vlan12 kommen möchte, aber leider auch erfolglos.
Habe dann folgendes gesnifft:
Der Gira Homeserver (IP 152.11) sendet wohl mit TTL 16, das sollte dann eigentlich funktionieren.
Auf meinem Raspi (IP 152.199) läuft zusätzlich Homebridge zur Steuerung mit Siri, hier ist wohl tatsächlich TTL 1. Das muss aber aus dem Vlan13 nicht unbedingt erreichbar sein, es reicht wenn der Gira HS in Vlan 13 erreichbar ist.
Habe dann hier im Kommentar von dog gelesen, dass IMGP Proxy auch ein Weg ist und entsprechend getestet.
Gehe mal davon aus, dass Vlan13 den Upstream bekommt, da ich aus Vlan13 in Vlan12 kommen möchte, aber leider auch erfolglos.
Der Gira Homeserver (IP 152.11) sendet wohl mit TTL 16
"wohl" oder ganz sicher ?! Besser du verifizierst das mit dem Kabelhai !Das ist wichtig zu wissen und auch die Multiucast gruppenadressen um sicher sagen zu können ob es routebar ist oder nicht.
Du kannst testweise mit sudo apt-get install vlc auf dem RasPi, PC usw. mal den Klassiker VLC installieren und einen lokalen Multicast Test machen indem du mal einen Film per Multicast ins Netz streamst.
Wenn das über die IP Segmente die du PIM routest erreichbar ist, dann funktioniert das generell.
Hier steht wie es geht:
Fehlersuche im lokalem Netzwerk (RSTP, MRP, Multicast)
Also habe nochmal mit Wireshark gesnifft und es ist tatsächlich so, Homeserver sendet mit TTL 16
und die homebrige sendet mit TTL 1
Multicastgruppenadresse ist 224.0.23.12
Habe dann nach deiner Anleitung auch den Test mit VLC gemacht.
Da VLC standardmäßig mit TTL 1 sendet habe ich über die GUI den Wert nach dieser Anleitung hochgesetzt, trotzdem wurde mit TTL 1 gesendet. Erst nach dieser Anleitung hat das funktioniert, also einfach der generierten Befehlszeile -ttl 12 angehängt:
:sout=#rtp{dst=239.255.1.2,port=5004,mux=ts} :no-sout-all :sout-keep –ttl 12
Die Änderung mit TTL 12 konnte ich auch mit Wireshark feststellen.
Also habe ich im VLAN12 ein Video gestreamt und mit obigen Einstellungen am MT versucht im VLAN 13 zu empfangen.
Sowohl mit den Einstellungen im PIM als auch im IGMP Proxy konnte ich im VLAN13 nichts empfangen.
Im VLAN12 selbst hing das Video und stotterte.
Den Test habe ich nur über die Ports 2 und 3 des MT gemacht und zuvor die NG Swichte abgeklemmt um auszuschliessen, das diese irgendwas nicht routen.
und die homebrige sendet mit TTL 1
Multicastgruppenadresse ist 224.0.23.12
Habe dann nach deiner Anleitung auch den Test mit VLC gemacht.
Da VLC standardmäßig mit TTL 1 sendet habe ich über die GUI den Wert nach dieser Anleitung hochgesetzt, trotzdem wurde mit TTL 1 gesendet. Erst nach dieser Anleitung hat das funktioniert, also einfach der generierten Befehlszeile -ttl 12 angehängt:
:sout=#rtp{dst=239.255.1.2,port=5004,mux=ts} :no-sout-all :sout-keep –ttl 12
Die Änderung mit TTL 12 konnte ich auch mit Wireshark feststellen.
Also habe ich im VLAN12 ein Video gestreamt und mit obigen Einstellungen am MT versucht im VLAN 13 zu empfangen.
Sowohl mit den Einstellungen im PIM als auch im IGMP Proxy konnte ich im VLAN13 nichts empfangen.
Im VLAN12 selbst hing das Video und stotterte.
Den Test habe ich nur über die Ports 2 und 3 des MT gemacht und zuvor die NG Swichte abgeklemmt um auszuschliessen, das diese irgendwas nicht routen.
Die Multicast Adresse ist wenigstens keine Local Link MC Adresse die von 224.0.0.0 bis 224.0.0.255 spezifiziert ist.
https://www.iana.org/assignments/multicast-addresses/multicast-addresses ...
Sieht man ja daran das der Home Server es auch richtig macht.
Problem ist also die Homebridge. Durch das TTL von 1 ist das Paket dann nicht mehr Routing fähig
Das ist definitiv ein Bug in der Home Bridge bzw. dessen IP Stack.
Hast du da mal nach gegoogelt obs da einen Fix, neue Firmware oder sowas gibt ? Ggf. kann man das ja im Setup auch verändern ?!
Deshalb auch der Hinweis in der Anleitung IMMER unbedingt RTP zu nehmen als Format !!!
Damit ist der TTL Wert immer konfigurierbar. Warum VLC das so macht ist unklar.
Dann darf es eigentlich niemals ruckeln !!! Es sei denn du hast ein Problem in der LAN Verkabelung oder Autonegotiation Probleme oder auch IGMP Probleme auf dem Switch !
In einem WLAN mag das passieren. Meist in WLANs mit älteren Komponenten die KEINE Wandlung von Multicast zu Unicast im WLAN supporten. Dort müssen die APs dann MC Pakete an alle WLAN Teilnehmer fluten und billiges Blödmarkt Consumer Equipment legt sich dann sofort die Karten.
Das wäre dann ein mögliches Problem. LAN basierend können sogar uralte PCs und Laptops sowas flüssig darstellen. Hier sogar noch ein ATOM Methusalem MSI Wind U100.
Hier klappt das mit PIM Routing auf einem MT RB750 und hexLite fehlerlos.
https://www.iana.org/assignments/multicast-addresses/multicast-addresses ...
Sieht man ja daran das der Home Server es auch richtig macht.
Problem ist also die Homebridge. Durch das TTL von 1 ist das Paket dann nicht mehr Routing fähig
Das ist definitiv ein Bug in der Home Bridge bzw. dessen IP Stack.
Hast du da mal nach gegoogelt obs da einen Fix, neue Firmware oder sowas gibt ? Ggf. kann man das ja im Setup auch verändern ?!
trotzdem wurde mit TTL 1 gesendet.
Das macht VLC immer wenn UDP als Format gewählt wird. Das ist dann auch nicht änderbar, bzw. auch wenn man es ändert belässt es VLC trotzdem auf 1.Deshalb auch der Hinweis in der Anleitung IMMER unbedingt RTP zu nehmen als Format !!!
Damit ist der TTL Wert immer konfigurierbar. Warum VLC das so macht ist unklar.
Im VLAN12 selbst hing das Video und stotterte.
Dast du Sender und Empfänger kabelbasierend angeschlossen ???Dann darf es eigentlich niemals ruckeln !!! Es sei denn du hast ein Problem in der LAN Verkabelung oder Autonegotiation Probleme oder auch IGMP Probleme auf dem Switch !
In einem WLAN mag das passieren. Meist in WLANs mit älteren Komponenten die KEINE Wandlung von Multicast zu Unicast im WLAN supporten. Dort müssen die APs dann MC Pakete an alle WLAN Teilnehmer fluten und billiges Blödmarkt Consumer Equipment legt sich dann sofort die Karten.
Das wäre dann ein mögliches Problem. LAN basierend können sogar uralte PCs und Laptops sowas flüssig darstellen. Hier sogar noch ein ATOM Methusalem MSI Wind U100.
Den Test habe ich nur über die Ports 2 und 3 des MT gemacht
Hast du am MT in den Interface Settings IGMP Snooping mit V2 aktiviert ?Hier klappt das mit PIM Routing auf einem MT RB750 und hexLite fehlerlos.
Problem ist also die Homebridge.
Mir geht es in erster Linie um den Homeserver, auf homebridge kann ich verzichten.Dann darf es eigentlich niemals ruckeln !!!
Habe den Test nochmal gemacht und dafür den MT Standalone betrieben, d.h. keine Verbindung mehr zu fritzbox sowie keine Verbindung zu den NG Swichtes. Am ether2 (vlan12) den Rechner angeschlossen der den den Stream bereitstellt und am ether4 den Rechner angeschlossen der den Stream empfängt und abspielt.Den Port 4 habe ich dafür umkonfiguriert und dem Vlan12 zugewiesen => alles läuft auch flüssig.
D.h. im gleichen Subnetz funktioniert das.
Wenn ich jedoch den Rechner, der das Video abspielt an Port 3 (vlan13) anschliessen, dann geht es leider nicht.
Der VLC sendet mit TTL 12:
Hast du am MT in den Interface Settings IGMP Snooping mit V2 aktiviert ?
So sieht PIM aus, wenn du die Haken meinst, dann ja, oder muss eine weitere Einstellung vorgenommen werden? Wenn ja, wo?
Stimmt hier die Gruppenadresse?
Mmmhhh, da ist dann irgendwo noch der Wurm drin in deiner PIM Konfig auf dem MT !
Hier mal ein schneller Test auf einem hAP Mikrotik:
Hier die Details:
VLC Einstellung Streaming Host:
MT Interface Setup:
Wireshark Trace am VLC Client:
Hier sieht man deutlich das der JOIN Request vom Client 10.4.4.150 auf die MC Gruppe 239.254.1.2 kommt und der MT dann den VLC Streaming Host 10.99.1.149 forwardet. PIM Routing klappt hier also !
MC Gruppen am Mikrotik:
Entsprechend dann die am MT registrierten MC Gruppen
Fazit: Works as designed !
Hier mal ein schneller Test auf einem hAP Mikrotik:
- Routing aktiviert auf ether1 (10.99.1.148 /24) und ether 4 (10.4.4.1 /24)
- PIM aktiviert auf beiden Routerports
- Rendezvous Point auf die 10.99.1.148 gelegt
- VLC Streaming auf Host im 10.99.1er Netz mit RTP Transport Stream, TTL=10 und Port 5004 gestartet
- VLC Client im 10.4.4er Netz emfängt sofort den RTP Stream mit rtp://@239.254.1.2:5004
- MT Firmware 6.41.2
Hier die Details:
VLC Einstellung Streaming Host:
MT Interface Setup:
Wireshark Trace am VLC Client:
MC Gruppen am Mikrotik:
Entsprechend dann die am MT registrierten MC Gruppen
Fazit: Works as designed !
Durch meine Unwissenheit habe ich nur VLAN12 mit in den PIM Interfaces aufgenommen, dank Deiner Screenshots habe ich gesehen, dass auch VLAN13 angelegt werden muss. Danach habe ich getestet und siehe da, in kann zwischen beiden VLANs hin und her streamen, wohlgemerkt kabelgebunden. Kabelgebunden hat das VLC Streaming auch im Zusammenspiel mit den NG Swichtes funktioniert.
Leider hat das Streamen über WLAN weder im gleichen VLAN12 noch im VLAN13 funktioniert. Das es an Überlastung scheiterte kann ich mir nicht vorstellen, da nur ein Client (iPhone X) im Wlan direkt mit dem MT verbunden war und der Stream am iphone mit der VLC-App nicht angekommen ist.
Da das Routing grundsätzlich funktionierte war jetzt der nächste Schritt das eigentlich Ziel, den Homeserver aus beiden VLANs zu erreichen. Aber leider kam keine Verbindung aus dem VLAN13 ins VLAN12 zustande. Hier kann ich die Verbindung nur per WLan testen, kabelgebunden kann ich das nicht prüfen. Gibt es ein generelles Problem mit dem WLAN?
Eine Verständnisfrage noch: Wenn ich ether1 (Ansschluß zu Fritzbox) auch mit im PIM aufnehme, kann ich dann auch aus dem Fritz Netz den Homeserver errreichen oder geht das grundsätzlich nicht, weil ...? Der (kabelgebundene) Test mit dem VLC war nähmlich nicht erfolgreich.
Konfig sieht jetzt so aus:
Leider hat das Streamen über WLAN weder im gleichen VLAN12 noch im VLAN13 funktioniert. Das es an Überlastung scheiterte kann ich mir nicht vorstellen, da nur ein Client (iPhone X) im Wlan direkt mit dem MT verbunden war und der Stream am iphone mit der VLC-App nicht angekommen ist.
Da das Routing grundsätzlich funktionierte war jetzt der nächste Schritt das eigentlich Ziel, den Homeserver aus beiden VLANs zu erreichen. Aber leider kam keine Verbindung aus dem VLAN13 ins VLAN12 zustande. Hier kann ich die Verbindung nur per WLan testen, kabelgebunden kann ich das nicht prüfen. Gibt es ein generelles Problem mit dem WLAN?
Eine Verständnisfrage noch: Wenn ich ether1 (Ansschluß zu Fritzbox) auch mit im PIM aufnehme, kann ich dann auch aus dem Fritz Netz den Homeserver errreichen oder geht das grundsätzlich nicht, weil ...? Der (kabelgebundene) Test mit dem VLC war nähmlich nicht erfolgreich.
Konfig sieht jetzt so aus:
Hab hier einen Beitrag dazu gefunden, scheint das es tatsächlich Probleme mit Multicast über Wlan beim MT gibt, aber so richtig verstanden hab ich das nicht.
Wenn ich ether1 (Ansschluß zu Fritzbox) auch mit im PIM aufnehme
Ja, dann kannst du auch von da Multicast routen. Das ist ja nicht anders als mit den anderen Interfaces auch.Thema WLAN und Multicast.
Das WLAN Interface ist ja nicht dediziert, oder ? Ich meine mich zu erinnern das das in einer Bridge liegt und somit dann auch die IP Adresse des WLAN Segments auf dem Bridge Interface.
Folglich musst du die PIM Konfig dann immer auf dem Bridge Interface machen niemals auf der Physik die Teil der Bridge ist. Das gilt für die IP und logischerweise dann auch fürs PIM.
Ggf. ist das das Problem ?!
Auch wenn das WLAN kein Multicast zu Unicast Conversion macht sollte es mit nur einem WLAN Client dann problemlos funktionieren.
Möglich das es vermehrt zu Artefakten und Hängern kommt (bei fehlender Conversion) es sollte aber funktionieren.
Die zitierte Liste von MT besagt dann eher das der AP keine Conversion macht, was dann natürlich massiv auf die Performance geht bei mehreren WLAN Clients.
Was unverständlich ist warum er es in die andere Richtung konvertiert. Dort ist es technisch gesehen eigentlich nutzlos. Würde ich jetzt auch nicht verstehen.
Weitere Infos dazu findet man auch hier:
https://www.heise.de/ct/ausgabe/2014-14-Probleme-bei-Multicast-im-W-LAN- ...
Folglich musst du die PIM Konfig dann immer auf dem Bridge Interface machen niemals auf der Physik die Teil der Bridge ist. Das gilt für die IP und logischerweise dann auch fürs PIM.
Ja, das Wlan liegt in der Bridge.
Ich habe im PIM kein WLAN IF reingenommen nur die VLANs 12 und 13. Ich gehe davon aus, dass durch die Zuordnung der Virtual IF Wlan12 und Wlan13 zu den Vlans 12 und 13, diese schon durch das Vlan bedient werden. Also im obigen Fall, dass durch die Aufnahme von Vlan13, die IF ether5, wlan13 und ether3 im PIM automatisch berücksichtigt werden. Liege ich falsch?
Habe hier was vom multicast-helper gelesen, muss das vielleicht von default auf full gesetzt werden?
Habe jetzt ether1 mit im PIM aufgenommen, unter MFC finde ich die Multicastadresse des Homeservers, aber es sind keine Incoming und outgoing IF zugewiesen, kann ich da was zuweisen?
Der Helper hat was mit der MC zu Unicast Konvertierung zu tun. Ab release 5.15 ist das wohl supportet.
Siehe hier:
https://wiki.mikrotik.com/wiki/Manual:Multicast_detailed_example
Kapitel Multicast Wireless. Würde also Sinn machen das zu aktivieren sofern es was bringt.
Incoming und outgoing siehst du nur wenn MC per PIM geroutet wird, es also auch einen Empfänger irgendwo gibt. Wenn die Gruppe keiner Requested oder es Local Link MCs sind wird da nix angezeigt.
Siehe hier:
https://wiki.mikrotik.com/wiki/Manual:Multicast_detailed_example
Kapitel Multicast Wireless. Würde also Sinn machen das zu aktivieren sofern es was bringt.
Incoming und outgoing siehst du nur wenn MC per PIM geroutet wird, es also auch einen Empfänger irgendwo gibt. Wenn die Gruppe keiner Requested oder es Local Link MCs sind wird da nix angezeigt.
Habe den multicast-helper aktiviert und streaming funktioniert jetzt auch VLAN übergreifend über das WLAN
Auch der Homeserver funktioniert VLAN übergreifend, das Problem war hier, dass ich kein default gateway (im HS Experten) hinterlegt hatte.
Vielen Dank an alle, die zur Problemlösung beigetragen haben, allen voran aqui. Ohne Dich wäre ich nie soweit gekommen.
Danke für Deine Zeit und unermüdliche Hilfe, habe durch Dich viel dazugelernt.
Auch der Homeserver funktioniert VLAN übergreifend, das Problem war hier, dass ich kein default gateway (im HS Experten) hinterlegt hatte.
Vielen Dank an alle, die zur Problemlösung beigetragen haben, allen voran aqui. Ohne Dich wäre ich nie soweit gekommen.
Danke für Deine Zeit und unermüdliche Hilfe, habe durch Dich viel dazugelernt.
Habe den multicast-helper aktiviert und streaming funktioniert jetzt auch VLAN übergreifend über das WLAN
Sehr cool ! Wir posten hier in Kürze ein überarbeitetes Tutorial für den Mikrotik im VLAN Routing Bereich ab der Router OS Version 6.41. So müssen nicht alle den "Monsterthread" hier komplett lesen
Wäre gut wenn du da ggf. nochmal ein technisches Feedback und Screenshots beisteuern könntest. Speziell zum MC Helper ! Da können wir von dir noch lernen....
Und....danke für die Blumen. Das Wissen und die Erfahrung kann dir keiner mehr nehmen
Neues MT Tutorial:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
HI
Danke aqui, war sehr spannend mitzulesen, wie Ihr beide das Problem gelöst habt!
Danke
Holli
Vielen Dank an alle, die zur Problemlösung beigetragen haben, allen voran aqui
Danke aqui, war sehr spannend mitzulesen, wie Ihr beide das Problem gelöst habt!
Danke
Holli
Danke für die Blumen
Hallo aqui,
leider kann ich der pm kein screenshot anhängen, daher pack ich das hier rein.
Ich habe nur zusätzlich auf den Virtual IF den multicast-helper auf full gesetzt, zuvor muss rechts auf den button advanced mode umgestellt werden, damit der Eintrag erscheint. Ansonsten habe ich wie von dir geschrieben einfach die vlans ins Pim eingefügt:
Viele grüße
sonyandi
leider kann ich der pm kein screenshot anhängen, daher pack ich das hier rein.
Ich habe nur zusätzlich auf den Virtual IF den multicast-helper auf full gesetzt, zuvor muss rechts auf den button advanced mode umgestellt werden, damit der Eintrag erscheint. Ansonsten habe ich wie von dir geschrieben einfach die vlans ins Pim eingefügt:
Viele grüße
sonyandi
leider kann ich der pm kein screenshot anhängen, daher pack ich das hier rein.
Das geht auch nicht im Forum. Muss @Frank nochmal implementieren die Funktion Danke für den Screenshot. Ich teste das und bastel das dann ins Tutorial !
