VLAN Routing mit Mikrotik und Layer 3 Switch
Guten Tag zusammen,
für unser Büronetzwerk möchten wir mehrere VLANs haben (Internes Netzwerk, Gästenetz, sowie je eins für die vier Wohnungen oben). Alle VLANs sollen jedoch Zugriff auf eine einzige Internetverbindung haben.
Dafür haben wir uns einen Layer 3 Switch von Netgear (GS748T V5) gebraucht gekauft sowie auf Empfehlung aus anderen Beiträgen hier ein Mikrotik hEX Routerboard.
Soweit so gut. Ich bin was Netzwerk angeht absoluter Anfänger. Jedoch habe ich nun dank des tollen Tutorials von aqui (Mikrotik VLAN Konfiguration ab RouterOS Version 6.41) ein funktionierendes Setup (exakt so, wie es im Tutorial unter "Einfaches VLAN Basis Setup" abgebildet ist).
Aktuell noch im Testaufbau ohne Layer 3 Switch, sondern mit einem Layer 2 Smart Switch, der jedoch auch VLANs unterstüzt.
Ursprünglich hatte ich gedacht, ich bräuchte den Mikrotik gar nicht, da der Layer 3 von Netgear auch Inter-VLAN Routing kann. Der Switch hat jedoch keinen eingebauten DHCP-Server, somit hätten wir also feste IP Adressen nehmen müssen, da der DHCP der Fritz!Box (die den Internetzugang zur Verfügung stellt) wie die gesamte Fritz!Box kein VLAN versteht und somit falsche IP Adressen verteilen würde (wenn das überhaupt funktionieren würde...)
Meine Frage ist nun: Ergibt es Sinn, den Mikrotik im Grunde nur zum DHCP-Server zu degradieren? Mein Gedanke ist, dass der Layer 3 Switch ja dedizierte Routing-Hardware an Board hat, der Mikrotik muss jedoch für's Routing durch die CPU gehen, wenn ich das richtig verstehe. Damit sollte die Performance beim Routing durch den Layer 3 Switch besser sein.
Der Aufbau, den ich mir hier vorstelle ist, dass alles am Layer 3 Switch angeschlossen ist (mit entsprechend gesetzten PVIDs und VLAN Memberships der Ports), inkl. der Fritz!Box für den Internetzugang (in einem eigenen VLAN). Der Layer 3 Switch würde dann das Routing zwischen den VLANs machen. Der Mikrotik wäre über einen Trunk-Port am Switch, der in allen VLANs ist. So kann dann der Mikrotik den DHCP-Job übernehmen.
Vielen Dank für jegliche Einsicht.
für unser Büronetzwerk möchten wir mehrere VLANs haben (Internes Netzwerk, Gästenetz, sowie je eins für die vier Wohnungen oben). Alle VLANs sollen jedoch Zugriff auf eine einzige Internetverbindung haben.
Dafür haben wir uns einen Layer 3 Switch von Netgear (GS748T V5) gebraucht gekauft sowie auf Empfehlung aus anderen Beiträgen hier ein Mikrotik hEX Routerboard.
Soweit so gut. Ich bin was Netzwerk angeht absoluter Anfänger. Jedoch habe ich nun dank des tollen Tutorials von aqui (Mikrotik VLAN Konfiguration ab RouterOS Version 6.41) ein funktionierendes Setup (exakt so, wie es im Tutorial unter "Einfaches VLAN Basis Setup" abgebildet ist).
Aktuell noch im Testaufbau ohne Layer 3 Switch, sondern mit einem Layer 2 Smart Switch, der jedoch auch VLANs unterstüzt.
Ursprünglich hatte ich gedacht, ich bräuchte den Mikrotik gar nicht, da der Layer 3 von Netgear auch Inter-VLAN Routing kann. Der Switch hat jedoch keinen eingebauten DHCP-Server, somit hätten wir also feste IP Adressen nehmen müssen, da der DHCP der Fritz!Box (die den Internetzugang zur Verfügung stellt) wie die gesamte Fritz!Box kein VLAN versteht und somit falsche IP Adressen verteilen würde (wenn das überhaupt funktionieren würde...)
Meine Frage ist nun: Ergibt es Sinn, den Mikrotik im Grunde nur zum DHCP-Server zu degradieren? Mein Gedanke ist, dass der Layer 3 Switch ja dedizierte Routing-Hardware an Board hat, der Mikrotik muss jedoch für's Routing durch die CPU gehen, wenn ich das richtig verstehe. Damit sollte die Performance beim Routing durch den Layer 3 Switch besser sein.
Der Aufbau, den ich mir hier vorstelle ist, dass alles am Layer 3 Switch angeschlossen ist (mit entsprechend gesetzten PVIDs und VLAN Memberships der Ports), inkl. der Fritz!Box für den Internetzugang (in einem eigenen VLAN). Der Layer 3 Switch würde dann das Routing zwischen den VLANs machen. Der Mikrotik wäre über einen Trunk-Port am Switch, der in allen VLANs ist. So kann dann der Mikrotik den DHCP-Job übernehmen.
Vielen Dank für jegliche Einsicht.
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2954919523
Url: https://administrator.de/forum/vlan-routing-mit-mikrotik-und-layer-3-switch-2954919523.html
Ausgedruckt am: 15.06.2025 um 22:06 Uhr
26 Kommentare
Neuester Kommentar
Hallo,
das Problem ist der DHCP-Server in der Fritz-Box, wie du richtig erkannt hast. Du brauchst einen "richtigen" DHCP-Server, der mehrere Scops verwaltet und verteilt und eine entsprechende DHCP-Relay-Konfiguration im Router/L3-Switch.
Wahrscheinlich ist das mit dem Mikrotik-Board möglich. Aber warum nimmst du nicht einfach einen RasPi und installierst dort einen DHCP-Server? (zB. Bind)
Das ist Murks! Stichword "DHCP-Relay" im L3-Switch.
Jürgen
das Problem ist der DHCP-Server in der Fritz-Box, wie du richtig erkannt hast. Du brauchst einen "richtigen" DHCP-Server, der mehrere Scops verwaltet und verteilt und eine entsprechende DHCP-Relay-Konfiguration im Router/L3-Switch.
Wahrscheinlich ist das mit dem Mikrotik-Board möglich. Aber warum nimmst du nicht einfach einen RasPi und installierst dort einen DHCP-Server? (zB. Bind)
Der Mikrotik wäre über einen Trunk-Port am Switch, der in allen VLANs ist. So kann dann der Mikrotik
den DHCP-Job übernehmen.
den DHCP-Job übernehmen.
Das ist Murks! Stichword "DHCP-Relay" im L3-Switch.
Jürgen
Zitat von @chiefteddy:
das Problem ist der DHCP-Server in der Fritz-Box, wie du richtig erkannt hast. Du brauchst einen "richtigen" DHCP-Server, der mehrere Scops verwaltet und verteilt
das Problem ist der DHCP-Server in der Fritz-Box, wie du richtig erkannt hast. Du brauchst einen "richtigen" DHCP-Server, der mehrere Scops verwaltet und verteilt
Bis hierhin bin ich bei dir. Den Job macht im Moment (nach Tutorial von aqui) der Mikrotik. Jedoch habe ich dort einen eigenen DHCP Server für jedes VLAN eingerichtet (so, wie's auch im Tutorial ist).
und eine entsprechende DHCP-Relay-Konfiguration im Router/L3-Switch.
DHCP-Relay ist für mich ein neuer Begriff. Habe mich gerade mal eingelesen und es ergibt soweit Sinn. Ein Router oder L3 Switch blockiert DHCP Requests, daher muss hier ein DHCP-Relay eingerichtet werden, damit der L3 Switch die DHCP Requests durchlässt
Wahrscheinlich ist das mit dem Mikrotik-Board möglich. Aber warum nimmst du nicht einfach einen RasPi und installierst dort einen DHCP-Server? (zB. Bind)
1. Ich hab den Mikrotik schon hier, einen RasPi nicht.
2. Ich bin wie erwähnt ziemlicher Netzwerk-Neuling und traue mir ehrlich gesagt nicht zu, einen DHCP Server von Hand vernünftig einzurichten, vor allem wenn dann auch noch VLAN dazu kommt.
3. Die Software auf dem RasPi aktuell zu halten wäre meiner Einschätzung nach mehr Aufwand.
Aber ja, natürlich ginge das.
Das ist Murks! Stichword "DHCP-Relay" im L3-Switch.
Gut, ich brauche das DHCP-Relay. Aber dennoch muss doch der tatsächliche DHCP-Server (ob nun Mikrotik, RasPi oder whatever) an einen Trunk-Port, oder nicht? Denn er muss IP-Adressen vergeben, die zum VLAN passen.
Gruß,
Take
ich bräuchte den Mikrotik gar nicht, da der Layer 3 von Netgear auch Inter-VLAN Routing kann.
Ja, dem ist auch so. Damit kannst du problemlos ein Layer 3 Switchingkonzept umsetzen wie es HIER im Detail beschrieben ist.Wäre auch die deutlich bessere Variante. Der hEX ist da so oder so die völlig falsche Hardware von Mikrotik. Das wäre dann eher ein CRS Switch.
Hallo,
ein Client fragt per Broadcast im eigenen Subnetz (VLAN) nach einer IP-Adresse. Wenn im Subnetz ein DHCP-Server vorhanden ist, empfängt er diese Anfrage und schickt dem anfragenden Client per Unicast eine IP (und noch andere Informationen). Ist der DHCP-Server nicht im eigenen Subnetz (VLAN), sondern in einem anderen VLAN, gelangt die Broadcast-Anfrage des Clients nicht zum DHCP-Server, da Broadcast nicht geroutet wird.
Ist auf dem Router/ L3-Switch nun ein DHCP-Relay konfiguriert, agiert der L3-Switch an dem Port im VLAN des anfragenden Clients als DHCP-Server, nimmt die Anfrage auf und leitet sie per Unicast an den DHCP-Server im anderen VLAN weiter. Der DHCP-Server antwortet per Unicast mit der Zuweisung einer IP und der L3-Switch routet die Antwort in das Subnetz (VLAN) des Anfragenden Clients und der bekommt nun seine IP-Adresse.
Nochmal: NEIN Das übernimmt das DHCP-Relay! Hier wird für jedes Subnetz/VLAN der zu kontaktierende DHCP-Server mit seiner IP-Adresse hinterlegt.
Der L3-Switch/Router tut so, als wäre er der DHCP-Server im jeweiligen Subnetz. Er leitet aber tatsächlich die Anfragen an den hinterlegten, zuständigen DHCP-Server weiter und schickt die Antwort des tatsächlichen DHCP-Servers an den anfragenden Client weiter.
Jürgen
https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
DHCP-Relay
DHCP-Relay ist eine Funktion, um DHCP über Netzwerkgrenzen (Broadcastdomäne) hinaus nutzen zu können. Damit wird die Notwendigkeit der Bereitstellung eines DHCP-Servers in jedem Subnetz, in dem sich DHCP-Clients befinden, vermieden. Die DHCP-Relay-Funktion wird meist durch den Router selbst erbracht. Dabei werden Client-seitig mittels Broadcast verschickte DHCP-Anfragen durch den DHCP-Relay empfangen und mittels Unicast einem oder mehreren DHCP-Servern zugestellt. Der DHCP-Relay-Agent wird funktional auf der Schnittstelle des Routers platziert.
ein Client fragt per Broadcast im eigenen Subnetz (VLAN) nach einer IP-Adresse. Wenn im Subnetz ein DHCP-Server vorhanden ist, empfängt er diese Anfrage und schickt dem anfragenden Client per Unicast eine IP (und noch andere Informationen). Ist der DHCP-Server nicht im eigenen Subnetz (VLAN), sondern in einem anderen VLAN, gelangt die Broadcast-Anfrage des Clients nicht zum DHCP-Server, da Broadcast nicht geroutet wird.
Ist auf dem Router/ L3-Switch nun ein DHCP-Relay konfiguriert, agiert der L3-Switch an dem Port im VLAN des anfragenden Clients als DHCP-Server, nimmt die Anfrage auf und leitet sie per Unicast an den DHCP-Server im anderen VLAN weiter. Der DHCP-Server antwortet per Unicast mit der Zuweisung einer IP und der L3-Switch routet die Antwort in das Subnetz (VLAN) des Anfragenden Clients und der bekommt nun seine IP-Adresse.
Aber dennoch muss doch der tatsächliche DHCP-Server (ob nun Mikrotik, RasPi oder whatever) an einen
Trunk-Port, oder nicht? Denn er muss IP-Adressen vergeben, die zum VLAN passen.
Trunk-Port, oder nicht? Denn er muss IP-Adressen vergeben, die zum VLAN passen.
Nochmal: NEIN Das übernimmt das DHCP-Relay! Hier wird für jedes Subnetz/VLAN der zu kontaktierende DHCP-Server mit seiner IP-Adresse hinterlegt.
Der L3-Switch/Router tut so, als wäre er der DHCP-Server im jeweiligen Subnetz. Er leitet aber tatsächlich die Anfragen an den hinterlegten, zuständigen DHCP-Server weiter und schickt die Antwort des tatsächlichen DHCP-Servers an den anfragenden Client weiter.
Jürgen
https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
DHCP-Relay
DHCP-Relay ist eine Funktion, um DHCP über Netzwerkgrenzen (Broadcastdomäne) hinaus nutzen zu können. Damit wird die Notwendigkeit der Bereitstellung eines DHCP-Servers in jedem Subnetz, in dem sich DHCP-Clients befinden, vermieden. Die DHCP-Relay-Funktion wird meist durch den Router selbst erbracht. Dabei werden Client-seitig mittels Broadcast verschickte DHCP-Anfragen durch den DHCP-Relay empfangen und mittels Unicast einem oder mehreren DHCP-Servern zugestellt. Der DHCP-Relay-Agent wird funktional auf der Schnittstelle des Routers platziert.
Zitat von @aqui:
ich bräuchte den Mikrotik gar nicht, da der Layer 3 von Netgear auch Inter-VLAN Routing kann.
Ja, dem ist auch so. Damit kannst du problemlos ein Layer 3 Switchingkonzept umsetzen wie es HIER im Detail beschrieben ist.Ich meine auch auf dem Thread war ich schon mal. Jedoch brauche ich auch dann ja einen VLAN-fähigen DHCP Server. Das kann mein L3 Switch nicht - daher hatte ich mir überlegt "nimm doch den hEX, den du eh schon da hast".
Wäre auch die deutlich bessere Variante. Der hEX ist da so oder so die völlig falsche Hardware von Mikrotik. Das wäre dann eher ein CRS Switch.
Einen L3 Switch hab ich ja schon, von Netgear. Den hEX habe ich angeschafft, weil er hier (Mikrotik VLAN Konfiguration ab RouterOS Version 6.41) als mögliche Variante erwähnt wird. Funktioniert ja auch alles soweit, jedoch ist halt jetzt der hEX derjenige, der alles in L3 macht, der Switch wäre dann "nur" L2.
Das funktioniert ja alles soweit, nur war mein Gedanke eben die L3 Fähigkeiten des "richtigen" Switches auch nutzen zu wollen.
Gruß,
Take
Zitat von @chiefteddy:
Danke für die ausführliche Klarstellung. Warum ich ein DHCP-Relay brauche und was es tut verstehe ich nun, glaube ich. Bis auf eine Sache:
Nochmal: NEIN Das übernimmt das DHCP-Relay! Hier wird für jedes Subnetz/VLAN der zu kontaktierende DHCP-Server mit seiner IP-Adresse hinterlegt.
Aber wie weiß der DHCP-Server, um welches VLAN es geht? Beispiel:
VLAN 10: 192.168.10.0/24
VLAN 20: 192.168.20.0/24
PC in VLAN 10 schickt DHCP Request. Der kommt am L3 Switch an, das DHCP-Relay leitet ihn an den DHCP-Server weiter. Der muss doch jetzt wissen, dass er eine 192.168.10.0/24 IP vergeben muss und keine 192.168.20.0/24 IP. Wie geht das, wenn nicht über einen Trunk-Port, sodass der DHCP-Server weiß, um welches VLAN es geht?
Weiteres Googlen und lesen hilft (wie so häufig). Habe diesen Beitrag gefunden:
VLAN und DHCP
Dort wird das (für mich) fehlende Puzzlestück erwähnt:
Ich glaube damit ist das hier erstmal geklärt:
Vielen Dank für die Antworten!
VLAN und DHCP
Dort wird das (für mich) fehlende Puzzlestück erwähnt:
Der erkennt diese DHCP Broadcasts im jeweiligen Segment, ersetzt die Absender IP mit der eigenen aus dem Segment und forwardet das an die ihm konfigurierte DHCP Server Adresse.
So erreichen den Server diese Requests und er kann dann mit dem richtigen Scope antworten.
So erreichen den Server diese Requests und er kann dann mit dem richtigen Scope antworten.
Ich glaube damit ist das hier erstmal geklärt:
- Der Netgear L3 Switch macht das Routing.
- Auf dem Netgear muss ein DHCP Relay eingerichtet werden.
- Ich muss mich schlau machen, wie ich den DHCP Server dann korrekt konfiguriere, also erstmal ab in die Mikrotik Dokumentation.
Vielen Dank für die Antworten!
Der erkennt diese DHCP Broadcasts im jeweiligen Segment, ersetzt die Absender IP mit der
eigenen aus dem Segment und forwardet das an die ihm konfigurierte DHCP Server Adresse.
eigenen aus dem Segment und forwardet das an die ihm konfigurierte DHCP Server Adresse.
Hallo,
Broadcast, Multicast und Unicast sind deine Freunde.
https://www.ionos.de/digitalguide/server/knowhow/ethernet-frame/
https://de.wikipedia.org/wiki/Ethernet
https://de.wikipedia.org/wiki/Broadcast - Einer an Alle
https://de.wikipedia.org/wiki/Multicast - Einer an Viel (zB Video-Streaming)
https://de.wikipedia.org/wiki/Unicast - Einer an Einen ("normale" Netzwerk-Kommunikation)
Netzwerk-KnowHow ist nicht nur eine Anleitung zum Klicken in eine bunte GUI sondern sehr sehr viel Theorie und Netzwerkwissen.
Jürgen
Hi Jürgen,
Ja, Broadcast, Multicast und Unicast sind mir schon ein Begriff, also die absoluten Grundlagen verstehe ich schon.
Wie gesagt, das fehlende Puzzlestück war der Fakt, dass der DHCP Server das gewünschte Netz an der Quell-IP erkennen kann. Dies hatte ich nicht verstanden, da ich im Kopf hatte, das ein DHCP Request ja keine Quell-IP haben kann (denn die IP Adresse wird ja gerade angefragt...). Aber dies wird durch das DHCP Relay ermöglicht (ersetzt die Quell-IP durch seine eigene).
Aber ich verbitte mir das "Klicken in einer buten GUI". Lieber wäre mir auch die Konfiguration auf der Kommandozeile als die furchtbare UI meines Layer 3 Switches oder die Mikrotik WinBox :D
Grüße
Ja, Broadcast, Multicast und Unicast sind mir schon ein Begriff, also die absoluten Grundlagen verstehe ich schon.
Wie gesagt, das fehlende Puzzlestück war der Fakt, dass der DHCP Server das gewünschte Netz an der Quell-IP erkennen kann. Dies hatte ich nicht verstanden, da ich im Kopf hatte, das ein DHCP Request ja keine Quell-IP haben kann (denn die IP Adresse wird ja gerade angefragt...). Aber dies wird durch das DHCP Relay ermöglicht (ersetzt die Quell-IP durch seine eigene).
Aber ich verbitte mir das "Klicken in einer buten GUI". Lieber wäre mir auch die Konfiguration auf der Kommandozeile als die furchtbare UI meines Layer 3 Switches oder die Mikrotik WinBox :D
Grüße
das ein DHCP Request ja keine Quell-IP haben kann (denn die IP Adresse wird ja gerade angefragt...).
Hallo @diesieben07,
Quell-Adresse nicht, aber Ziel-Adress: Broadcast
Im /24-Subnetz aaa.bbb.ccc.255 und damit ist das Subnetz für jeden Empfänger bestimmbar.
In meiner obigen Erklärung habe ich eindeutig geschrieben, dass der L3-Switch an seinem virtuellen Routing-Interface im jeweiligen VLAN die Broadcast-Anfrage des Clients aufnimmt und an die in der DHCP-Relay-Konfiguration hinterlegten DHCP-Server-Adresse per Unicast weiterleitet. Und Unicast enthält die Absende-Adresse (des virtuellen Routing-Interfaces) und damit die Subnetz-Information des anfragenden Clients.
Aber ich verbitte mir das "Klicken in einer buten GUI".
Wie viele Anfragende in diesem Administrator-Forum haben sich den mit dem OSI-Referenz-Modell beschäftigt, der Abbildung des nicht normkonformen TCP/IP-Protokollstacks auf des OSI-Modell, dem Aufbau eines Ethernet-Frames usw. Wer kann denn mit den Begriffen RIP, OSPF, BGP etwas anfangen?
Das "Klicken in einer buten GUI" war nur als Synonym für das Nicht-Wissen vieler Anfragender über grundlegende Zusammenhänge im Netzwerk zu verstehen.
Wenn du dir dieses Wissen aneignest, sehr gut. Es wird dir das Verständnis für die Abläufe in der Netzwerk-Kommunikation sehr erleichtern.
Jürgen
Zitat von @chiefteddy:
Quell-Adresse nicht, aber Ziel-Adress: Broadcast
Im /24-Subnetz aaa.bbb.ccc.255 und damit ist das Subnetz für jeden Empfänger bestimmbar.
Quell-Adresse nicht, aber Ziel-Adress: Broadcast
Im /24-Subnetz aaa.bbb.ccc.255 und damit ist das Subnetz für jeden Empfänger bestimmbar.
Meinem Verständnis nach werden DHCP Anfragen als Broadcast auf 255.255.255.255 versendet (wohin auch sonst, der Client hat noch keine IP Adresse, keine Subnetzmaske oder sonst irgendwas). Aus diesem Broadcast alleine ließe sich also das Quell-Netz nicht ableiten. So gesehen gibt es ja auch noch gar kein Quellnetz, weil der Client nicht weiß "wo er ist".
In meiner obigen Erklärung habe ich eindeutig geschrieben, dass der L3-Switch an seinem virtuellen Routing-Interface im jeweiligen VLAN die Broadcast-Anfrage des Clients aufnimmt und an die in der DHCP-Relay-Konfiguration hinterlegten DHCP-Server-Adresse per Unicast weiterleitet. Und Unicast enthält die Absende-Adresse (des virtuellen Routing-Interfaces) und damit die Subnetz-Information des anfragenden Clients.
Genau. Hatte ich auch so verstanden. Ich wusste nur nicht, dass ein DHCP-Server auch in der Lage ist, diese (nun vorhandene) Absenderadresse zu verwenden, um das korrekte Netz zu bestimmen.
Wie viele Anfragende in diesem Administrator-Forum haben sich den mit dem OSI-Referenz-Modell beschäftigt, der Abbildung des nicht normkonformen TCP/IP-Protokollstacks auf des OSI-Modell, dem Aufbau eines Ethernet-Frames usw. Wer kann denn mit den Begriffen RIP, OSPF, BGP etwas anfangen?
Das "Klicken in einer buten GUI" war nur als Synonym für das Nicht-Wissen vieler Anfragender über grundlegende Zusammenhänge im Netzwerk zu verstehen.
Wenn du dir dieses Wissen aneignest, sehr gut. Es wird dir das Verständnis für die Abläufe in der Netzwerk-Kommunikation sehr erleichtern.
Das "Klicken in einer buten GUI" war nur als Synonym für das Nicht-Wissen vieler Anfragender über grundlegende Zusammenhänge im Netzwerk zu verstehen.
Wenn du dir dieses Wissen aneignest, sehr gut. Es wird dir das Verständnis für die Abläufe in der Netzwerk-Kommunikation sehr erleichtern.
War auch nicht böse gemeint. Die Grundlagen kenne ich, aber wie man sieht fehlt es eben in der Praxis und im Detail.
Ich werde mich die Tage melden, ob die Umsetzung mit DHCP-Relay auf dem L3 Switch klappt. Kann ich erst am Wochenende machen, da ich dafür das Büro "vom Netz" nehmen muss, da ich den L3 Switch brauche.
Grüße,
Take
Meinem Verständnis nach werden DHCP Anfragen als Broadcast auf 255.255.255.255 versendet
Hallo @diesieben07,
das ist FALSCH!
Ein Subnetz hat n IP-Adressen. Die erste verfügbare IP-Adresse ist die Netzwerk-Adresse (und kann nicht verwendet werden), die letzt IP-Adresse im Subnetz ist die Broadcast-Adresse dieses Subnetzes (und darf auch nicht verwendet werden). Damit bleiben n-2 Adressen für Geräte übrig.
Konkret:
ein /24-Subnetz hat 256 IP-Adressen und die Subnetzmaske 255.255.255.0
ZB. 192.168.178.0 /24
Adressbereich: 192.168.178.0 bis 192.168.178.255
Maske: 255.255.255.0
Netzwerk: 192.168.178.0
Broadcast-Adr,: 192.168.178.255
erste verfügbare Adr.: 192.168.178.1
letzte verfügbare Adr.: 192.168.178.254
--> 254 verfügbare Geräte-Adressen (256 - 2 = 254)
Das Standard-Gateway legt man üblicher Weise ans Ende des freien Adressbereiches.
Hier also 192.168.178.254
2. Bsp.
ein /27-Subnetz hat 32 IP-Adressen und die Subnetzmaske 255.255.255.224
ZB. 192.168.1.32 /27
Adressbereich: 192.168.1.32 bis 192.168.1.63
Maske: 255.255.255.224
Netzwerk: 192.168.1.32
Broadcast-Adr,: 192.168.1.63
erste verfügbare Adr.: 192.168.1.33
letzte verfügbare Adr.: 192.168.1.62
--> 30 verfügbare Geräte-Adressen (32 - 2 = 30)
Das Standard-Gateway legt man üblicher Weise ans Ende des freien Adressbereiches.
Hier also 192.168.1.62
https://www.ionos.de/digitalguide/server/knowhow/broadcast-adresse/
https://www.heise.de/netze/tools/netzwerkrechner/
Jürgen
Jedoch brauche ich auch dann ja einen VLAN-fähigen DHCP Server.
Nein, das ist völliger Quatsch und zeigt das du als Admin das Thema DHCP leider nicht wirklich verstanden hast.Es gibt, abgesehen davon, auch gar keine VLAN Fähigkeit bei DHCP!
Das Schlüsselwort ist DHCP Relay wenn man einen zentralen DHCP Server betreibt. Kollege @chiefteddy hat es oben schon gesagt.
Das kann im Übrigen sogar ein popeliger Rasperry Pi mit links: 😉
Netzwerk Management Server mit Raspberry Pi
Lesen und verstehen...
Aus diesem Broadcast alleine ließe sich also das Quell-Netz nicht ableiten.
Nein, aber der Relay Host, sprich dein Switch, ersetzt diesen Broadcast mit seiner VLAN IP als Unicast Absenderadresse und forwardet das an den zentralen DHCP Server. Damit ist die IP und der daraus resultierende Scope dann wieder klar. Eben DHCP Relay.... https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP-R ...
Nimm dir lieber jemanden an die Hand der wenigstens die Grundlagen für sowas versteht. Das reduziert das Potential für graue Haare deutlich.
Zitat von @chiefteddy:
das ist FALSCH!
Ein Subnetz hat n IP-Adressen. Die erste verfügbare IP-Adresse ist die Netzwerk-Adresse (und kann nicht verwendet werden), die letzt IP-Adresse im Subnetz ist die Broadcast-Adresse dieses Subnetzes (und darf auch nicht verwendet werden). Damit bleiben n-2 Adressen für Geräte übrig.
das ist FALSCH!
Ein Subnetz hat n IP-Adressen. Die erste verfügbare IP-Adresse ist die Netzwerk-Adresse (und kann nicht verwendet werden), die letzt IP-Adresse im Subnetz ist die Broadcast-Adresse dieses Subnetzes (und darf auch nicht verwendet werden). Damit bleiben n-2 Adressen für Geräte übrig.
Wie Subnetze funktionieren weiß ich. Ich weiß auch, was eine Broadcast- und Netzadresse ist.
Jedoch hat ein Rechner am Anfang des DHCP Prozesses keine Ahnung, was sein Netzwerk ist. Daher kann er nur auf 255.255.255.255 ein DHCPDISCOVER losschicken. Steht auch hier:
https://www.ionos.de/digitalguide/server/konfiguration/dhcp-das-client-s ...
Zu Beginn versendet der Client ein DHCPDISCOVER-Paket mit der Zieladresse 255.255.255.255
Daraufhin antwortet der DHCP Server mit DHCPOFFER, erst ab dann hat der Client seine Subnetzmaske und könnte entsprechend die Broadcast-Adresse des Netzes verwenden.
Dieses DHCPOFFER kann der DHCP Server nur dann korrekt erstellen (also mit der korrekten Subnetzmaske), wenn er irgendwie den DISCOVER Request dem korrekten Quellnetz zuordnen kann. Wie diese Zuordnung in diesem Fall (mehrere VLANs mit eigenem Subnetz) stattfindet, war mir eben nicht klar. Konnte aber inzwischen durch das Verständnis des DHCP-Relay geklärt werden.
Zitat von @aqui:
Nein, das ist völliger Quatsch und zeigt das du als Admin das Thema DHCP leider nicht wirklich verstanden hast.
Ich habe nie behauptet ein Admin zu sein. Ich bin absoluter Anfänger, was Netzwerktechnik angeht, bis auf das bisschen Theorie, was damals in der Berufsschule (bin FI Anwendungsentwicklung) kam. Und das belief sich auf Subnetting-Berechnung von Hand bis der Arzt kommt und ach übrigens bei VLAN gibt es tagged und untagged.Nein, das ist völliger Quatsch und zeigt das du als Admin das Thema DHCP leider nicht wirklich verstanden hast.
Ich schreibe mir jedoch zu, zumindest die Grundlagen von DHCP verstanden zu haben.
Es gibt, abgesehen davon, auch gar keine VLAN Fähigkeit bei DHCP!
Das war zugegebenermaßen unglücklich formuliert meinerseits. Was ich damit ausdrücken wollte war die Fähigkeit des DHCP Servers, mit mehren Netzen umzugehen, wie es z.B. die Fritz!Box nicht kann. Hat natürlich mit VLAN an sich nichts zu tun.
Das Schlüsselwort ist DHCP Relay wenn man einen zentralen DHCP Server betreibt. Kollege @chiefteddy hat es oben schon gesagt.
Das kann im Übrigen sogar ein popeliger Rasperry Pi mit links: 😉
Netzwerk Management Server mit Raspberry Pi
Lesen und verstehen...
Das kann im Übrigen sogar ein popeliger Rasperry Pi mit links: 😉
Netzwerk Management Server mit Raspberry Pi
Lesen und verstehen...
Ist mir bekannt, s.o.
Aus diesem Broadcast alleine ließe sich also das Quell-Netz nicht ableiten.
Nein, aber der Relay Host, sprich dein Switch, ersetzt diesen Broadcast mit seiner VLAN IP als Unicast Absenderadresse und forwardet das an den zentralen DHCP Server. Damit ist die IP und der daraus resultierende Scope dann wieder klar. Eben DHCP Relay.... https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP-R ...
Habe ich inzwischen verstanden, ja. s.o.
Nimm dir lieber jemanden an die Hand der wenigstens die Grundlagen für sowas versteht. Das reduziert das Potential für graue Haare deutlich.
Da gibt es leider niemanden :D Die Alternative wäre, die Kollegen stöpseln wild Fritzboxen ineinander bis es irgendwie geht.Grüße
Du musst in einem Administrator Forum nicht nocheinmal die Grundlagen von DHCP erklären. Die kennt jeder Admin hier im Schlaf.
Du bist ja auf dem richtigen Weg!
Nebenbei:
Wenn du vorher einmal besser recherchiert hättest und dir statt der NetGear Gruselgurke einen Cisco SG350 oder CBS350 oder Mikrotik oder anderen Hersteller beschafft hätte der auch die DHCP Server Funktion in den VLANs im Switch realisieren können.
Richtige HW Auswahl ist eben das A und O.
wie es z.B. die Fritz!Box nicht kann.
Aber z.B. ein Cisco Router. 😉die Kollegen stöpseln wild Fritzboxen ineinander bis es irgendwie geht.
Igitt, dann die Kollegen unbedingt meiden und es selber machen...Du bist ja auf dem richtigen Weg!
Nebenbei:
Wenn du vorher einmal besser recherchiert hättest und dir statt der NetGear Gruselgurke einen Cisco SG350 oder CBS350 oder Mikrotik oder anderen Hersteller beschafft hätte der auch die DHCP Server Funktion in den VLANs im Switch realisieren können.
Richtige HW Auswahl ist eben das A und O.
Zitat von @aqui:
Du musst in einem Administrator Forum nicht nocheinmal die Grundlagen von DHCP erklären. Die kennt jeder Admin hier im Schlaf.
Du musst in einem Administrator Forum nicht nocheinmal die Grundlagen von DHCP erklären. Die kennt jeder Admin hier im Schlaf.
Glaub ich dir gern :D Ich tat dies, weil mir das "NEIN" von Jürgen merkwürdig vorkommt und irgendwie diesen Grundlagen zu widersprechen scheint...
Aber z.B. ein Cisco Router. 😉
Wenn du vorher einmal besser recherchiert hättest und dir statt der NetGear Gruselgurke einen Cisco SG350 oder CBS350 oder Mikrotik oder anderen Hersteller beschafft hätte der auch die DHCP Server Funktion in den VLANs im Switch realisieren können.
Ein "vernünftiger" Cisco Router oder Switch sprengt leider das Budget :/ Der Netgear war schon obere Grenze.
"Wenn das so teuer ist, machen wir eben kein VLAN". 🤷
Grüße
von Jürgen merkwürdig vorkommt
Auch ein Profi hat mal einen schlechten Tag! 😉Ein "vernünftiger" Cisco Router oder Switch sprengt leider das Budget
Welch ein Quatsch...die SoHo Serien sind im gleichen Preisniveau wie der NetGear Kram und Router gibts bei eBayhttps://www.ebay.de/itm/224925290919?hash=item345e9791a7:g:DdAAAOSwa9dbx ...
Für das Geld jibbet keine FritzBox...
Alternative wäre ein Mikrotik gewesen, der zudem deutclich preiswerter ist als die NG Möhre. Und das L3 Switch in CPU geht ist mit Fastpath längst Geschichte...
Zitat von @aqui:
Welch ein Quatsch...die SoHo Serien sind im gleichen Preisniveau und Router gibts bei eBay
Dann hab ich grad auf die Schnelle nicht richtig geguckt :D Aber das Kind ist eh schon im Brunnen, der Netgear hängt ja nun schon hier im Schrank...Welch ein Quatsch...die SoHo Serien sind im gleichen Preisniveau und Router gibts bei eBay
Für das Geld jibbet keine FritzBox...
Naja, die kriegt man ja vom Anbieter zugeworfen...Du hast ja recht, ist nur alles nicht meine Entscheidung :D
ist nur alles nicht meine Entscheidung
Warum bindest du dir das denn überhaupt ans Bein ?? Dann sollen die machen die das entschieden haben...Ist aber auch letztlich alles egal, denn du/ihr hast/habt ja alles an HW beisammen um das jetzt erfolgreich und problemlos umzusetzen. Du musst nur noch machen...
1
Guten Tag, ich gebe mal ein Update.
Der große Netgear Switch den ich habe ist absoluter Schrott (ja ja, schon klar, Netgear halt :D ). Aber ich frage mich wirklich, wie man dessen Layer 3 Features sinnvoll nutzen soll, denn der Switch hat weder einen eingebauten DHCP Server noch kann er ein DHCP Relay. Wie auch immer, also mache ich halt nur Layer 2 auf dem Switch, den Layer 3 Kram macht dann doch der Mikrotik. Also komplett nach Tutorial wie hier: Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Ich habe nun erstmal ein Test-Setup von Grund auf gebaut. Dabei nehme ich erstmal einen kleinen Netgear Layer 2 Switch der hier noch "rumlag" (GS 116e). Dort habe ich dann einen Trunk-Port definiert über den VLAN-Tagged Traffic zum Mikrotik geht. Alles funktioniert wunderbar, juhu.
Dann ging ich über zum "großen" Switch (GS748TV5). Ist eine olle Kiste von Ebay, macht aber laut Dokumentation IEEE802.1Q VLAN. Dort habe ich nun zunächst mal nur VLAN 10 konfiguriert. Port 2 als Tagged, der geht zum Tagged Port am Mikrotik. Port 3 als Untagged, ebenfalls in VLAN 10. Gleiche Konfiguration funktioniert am "kleinen" Switch wunderbar - beim Großen passiert nun aber nüscht. Erstmal ein paar Screenshots der Konfiguration:
Die VLANs:
VLAN Memberships:
Und die PVIDs:
Ein wenig Debugging zeigt mir, dass der die Kommunikation zwischen Mikrotik und Switch über die Tagged Ports nicht funktioniert. Wenn ich unter Switching > Address-Table mir die gelernten MAC-Adressen anschaue, so sehe ich dort die MAC Adresse meines Rechners an Port 3 - wunderbar. Hat auch die VLAN ID 10, wunderbar. Aber vom Mikrotik ist hier weit und breit keine Spur. Unter Monitoring > Port Statistics sehe ich aber auf Port 2 (zum Mikrotik) nur Pakete ohne Fehler.
Vielleicht hat ja jemand eine Idee, ob ich irgendeine Einstellung übersehen habe oder wie ich irgendwie zumindest an eine Fehlermeldung komme? Das grundsätzliche Setup funktioniert ja wunderbar, halt nur mit dem "kleinen" Switch...
Viele Grüße und Danke schonmal.
Noch ein Nachtrag: Ja, das Routing auf dem Switch ist deaktiviert (Routing > IP > Routing Mode "Disable").
Der große Netgear Switch den ich habe ist absoluter Schrott (ja ja, schon klar, Netgear halt :D ). Aber ich frage mich wirklich, wie man dessen Layer 3 Features sinnvoll nutzen soll, denn der Switch hat weder einen eingebauten DHCP Server noch kann er ein DHCP Relay. Wie auch immer, also mache ich halt nur Layer 2 auf dem Switch, den Layer 3 Kram macht dann doch der Mikrotik. Also komplett nach Tutorial wie hier: Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Ich habe nun erstmal ein Test-Setup von Grund auf gebaut. Dabei nehme ich erstmal einen kleinen Netgear Layer 2 Switch der hier noch "rumlag" (GS 116e). Dort habe ich dann einen Trunk-Port definiert über den VLAN-Tagged Traffic zum Mikrotik geht. Alles funktioniert wunderbar, juhu.
Dann ging ich über zum "großen" Switch (GS748TV5). Ist eine olle Kiste von Ebay, macht aber laut Dokumentation IEEE802.1Q VLAN. Dort habe ich nun zunächst mal nur VLAN 10 konfiguriert. Port 2 als Tagged, der geht zum Tagged Port am Mikrotik. Port 3 als Untagged, ebenfalls in VLAN 10. Gleiche Konfiguration funktioniert am "kleinen" Switch wunderbar - beim Großen passiert nun aber nüscht. Erstmal ein paar Screenshots der Konfiguration:
Die VLANs:
VLAN Memberships:
Und die PVIDs:
Ein wenig Debugging zeigt mir, dass der die Kommunikation zwischen Mikrotik und Switch über die Tagged Ports nicht funktioniert. Wenn ich unter Switching > Address-Table mir die gelernten MAC-Adressen anschaue, so sehe ich dort die MAC Adresse meines Rechners an Port 3 - wunderbar. Hat auch die VLAN ID 10, wunderbar. Aber vom Mikrotik ist hier weit und breit keine Spur. Unter Monitoring > Port Statistics sehe ich aber auf Port 2 (zum Mikrotik) nur Pakete ohne Fehler.
Vielleicht hat ja jemand eine Idee, ob ich irgendeine Einstellung übersehen habe oder wie ich irgendwie zumindest an eine Fehlermeldung komme? Das grundsätzliche Setup funktioniert ja wunderbar, halt nur mit dem "kleinen" Switch...
Viele Grüße und Danke schonmal.
Noch ein Nachtrag: Ja, das Routing auf dem Switch ist deaktiviert (Routing > IP > Routing Mode "Disable").
Für dein Vorhaben ist der NetGear die falsche Hardware, denn das ist ein "Smart layer 2+" Switch:
("The NETGEAR GS748T is Smart Switch (Layer +2 web management only) and although it does VLAN Routing it does not have an IP helper or UDP relay. You would need a NETGEAR Fully Managed Switch such as the M4300 (Full Layer 3) that does have an IP helper and UDP Relay for this to work.")
So ein Unsinn wie "2+" ist großer Marketing Bullshit und wozu das führt siehst du selber an deinem Negativbeispiel! Netgear eben...!
Zum Nachlesen wie man VLANs auf dem MT richtig einrichtet siehe HIER!!
Entsprechende Netgear Switch Konfigurationen sind dort ebenfalls zu finden.
Folge genau dem Tutorial, dann kommt das auch sofort zum Fliegen.
Übrigens kann der MT natürlich DHCP Relay.
("The NETGEAR GS748T is Smart Switch (Layer +2 web management only) and although it does VLAN Routing it does not have an IP helper or UDP relay. You would need a NETGEAR Fully Managed Switch such as the M4300 (Full Layer 3) that does have an IP helper and UDP Relay for this to work.")
So ein Unsinn wie "2+" ist großer Marketing Bullshit und wozu das führt siehst du selber an deinem Negativbeispiel! Netgear eben...!
Aber vom Mikrotik ist hier weit und breit keine Spur.
Hilfreich für alle hier wäre gewesen du hättest einen Screenshot der MT VLAN Konfig aus der WinBox mitgeschickt. Dann hätten wir dir zielführend sagen können wo dein MT Konfig Fehler ist! Aber leider hats dafür ja nicht gereicht. So können wir auch nur kristalkugeln wo die mögliche Ursache ist... Zum Nachlesen wie man VLANs auf dem MT richtig einrichtet siehe HIER!!
Entsprechende Netgear Switch Konfigurationen sind dort ebenfalls zu finden.
Folge genau dem Tutorial, dann kommt das auch sofort zum Fliegen.
Übrigens kann der MT natürlich DHCP Relay.
Zitat von @aqui:
Für dein Vorhaben ist der NetGear die falsche Hardware, denn das ist ein "Smart layer 2+" Switch: ("The NETGEAR GS748T is Smart Switch (Layer +2 web management only) and although it does VLAN Routing it does not have an IP helper or UDP relay. You would need a NETGEAR Fully Managed Switch such as the M4300 (Full Layer 3) that does have an IP helper and UDP Relay for this to work.")
So ein Unsinn wie "2+" ist großer Marketing Bullshit und wozu das führt siehst du selber an deinem Negativbeispiel! Netgear eben...!
Für dein Vorhaben ist der NetGear die falsche Hardware, denn das ist ein "Smart layer 2+" Switch: ("The NETGEAR GS748T is Smart Switch (Layer +2 web management only) and although it does VLAN Routing it does not have an IP helper or UDP relay. You would need a NETGEAR Fully Managed Switch such as the M4300 (Full Layer 3) that does have an IP helper and UDP Relay for this to work.")
So ein Unsinn wie "2+" ist großer Marketing Bullshit und wozu das führt siehst du selber an deinem Negativbeispiel! Netgear eben...!
Ja, das habe ich inzwischen auch gemerkt. War ein Fehlkauf aufgrund von gefährlichem Halbwissen. Hinterher ist man immer schlauer. Ich mache jetzt das beste draus und nutze ihn als Layer 2.
Aber vom Mikrotik ist hier weit und breit keine Spur.
Hilfreich für alle hier wäre gewesen du hättest einen Screenshot der MT VLAN Konfig aus der WinBox mitgeschickt. Dann hätten wir dir zielführend sagen können wo dein MT Konfig Fehler ist! Aber leider hats dafür ja nicht gereicht. So können wir auch nur kristalkugeln wo die mögliche Ursache ist... Klar, reiche ich gerne nach:
ether1 geht zum Internet-Router (FritzBox), von dort bekommt der Mikrotik per DHCP eine IP.
ether2 geht an den Trunk-Port zum Switch (dort auch Port 2).
Das VLAN Interface:
Die Bridge mit zugewiesenen Ports und VLANs:
Die IP-Adressen:
Zum Nachlesen wie man VLANs auf dem MT richtig einrichtet siehe HIER!!
Ja, habe ich gemacht
Entsprechende Netgear Switch Konfigurationen sind dort ebenfalls zu finden.
Korrekt. Habe ich ja auch danach eingerichtet.
Folge genau dem Tutorial, dann kommt das auch sofort zum Fliegen.
Tut es ja auch! Aber eben nur mit dem "kleinen" 16-Port Übungsswitch. Gleiche Konfiguration auf dem "großen" und es geht nicht mehr (Mikrotik bleibt dabei unverändert).
Übrigens kann der MT natürlich DHCP Relay.
Klar kann der das, hilft mir nur nicht, weil ich ja gar keinen DHCP Server außer dem Mikrotik habe (außer den in der FritzBox, aber der hilft mir bei mehreren Netzen halt überhaupt nicht). Der Mikrotik ist also DHCP Server, dann muss er ja nicht auch noch DHCP Relay spielen.Vielen Dank für die Geduld und schöne Grüße
Die Bridge mit zugewiesenen Ports und VLANs:
Ether 2 ist dein Uplink auf den Netgear?Ein grober Fehler springt einem da gleich wieder ins Auge!
VLAN 1 ist das Default oder Natvie VLAN am Netgear (und auch am MT) und ist dort, wie bei allen Herstellern üblicherweise immer ungetagged am Uplink Port der zum MT geht (PVID 1)
Du aber taggest das VLAN 1 am ether 2 Port des MTs so das zumindestens das VLAN 1 damit nicht zwischen den beiden Geräten erreichbar ist.
Logisch, wenn die eine Seite Tagged und die andere nicht dann verstehen die sich niemals...
Das VLAN 1 muss also UNgetagged an ether 2 anliegen (PVID 1, und Port Mode "accept all")
Sorry, aber solche groben Fehler sollte man doch auch als Laie sofort sehen!
Dein Kommentar "Ja, habe ich gemacht" zum Tutorial lesen war also glatt frech gelogen hier, denn dort wird mehrfach und in rot darauf hingewiesen.
Der Mikrotik ist also DHCP Server, dann muss er ja nicht auch noch DHCP Relay spielen.
Das ist natürlich zweifelsohne richtig! Zitat von @aqui:
Die Bridge mit zugewiesenen Ports und VLANs:
Ether 2 ist dein Uplink auf den Netgear?Korrekt.
Ein grober Fehler springt einem da gleich wieder ins Auge!
VLAN 1 ist das Default oder Natvie VLAN am Netgear (und auch am MT) und ist dort, wie bei allen Herstellern üblicherweise immer ungetagged am Uplink Port der zum MT geht (PVID 1)
Du aber taggest das VLAN 1 am ether 2 Port des MTs so das zumindestens das VLAN 1 damit nicht zwischen den beiden Geräten erreichbar ist.
Logisch, wenn die eine Seite Tagged und die andere nicht dann verstehen die sich niemals...
Das VLAN 1 muss also UNgetagged an ether 2 anliegen (PVID 1, und Port Mode "accept all")
VLAN 1 ist das Default oder Natvie VLAN am Netgear (und auch am MT) und ist dort, wie bei allen Herstellern üblicherweise immer ungetagged am Uplink Port der zum MT geht (PVID 1)
Du aber taggest das VLAN 1 am ether 2 Port des MTs so das zumindestens das VLAN 1 damit nicht zwischen den beiden Geräten erreichbar ist.
Logisch, wenn die eine Seite Tagged und die andere nicht dann verstehen die sich niemals...
Das VLAN 1 muss also UNgetagged an ether 2 anliegen (PVID 1, und Port Mode "accept all")
Danke für den Hinweis. Dies habe ich korrigiert:
Sorry, aber solche groben Fehler sollte man doch auch als Laie sofort sehen!
Mag sein, dass man das sofort sehen muss. Aber in der Konfiguration des Mikrotiks schaue ich aktuell gar nicht, da es ja wie gesagt mit dem einen Switch funktioniert und mit dem anderen nicht. Mein Fokus liegt also aktuell auf "was mache ich beim anderen Switch falsch".
Dein Kommentar "Ja, habe ich gemacht" zum Tutorial lesen war also glatt frech gelogen hier, denn dort wird mehrfach und in rot darauf hingewiesen.
Ein Fehler ist weder frech noch gelogen. Sondern halt einfach ein Fehler. Ohne jetzt pamping oder pedantisch werden zu wollen, weise ich darauf hin, dass die Screenshots im Tutorial diesbezüglich jedoch falsch sind, hier ist nämlich der Trunk-Port ether5 auch als "Current Tagged" bei VLAN ID 1 mit drin (im Gegensatz zu dem was darüber in Schwarz, nicht in Rot erklärt wird):
Soll keine Entschuldigung sein, nur ein Verbesserungsvorschlag für das Tutorial.
Zum weiteren Fortschritt: Ich habe nun festgestellt, dass ein Tagged Trunk-Port zwischen "großem" und "kleinem" Netgear Switch funktioniert. Ich habe nun also den "kleinen" Switch zwischen Mikrotik und "großem" Switch (jeweils über einen Trunk Port). Und siehe da - alles funktioniert! Nehme ich den "kleinen" Switch dazwischen raus und mache den Trunk Port vom großen direkt an den Mikrotik ist wieder tote Hose. Es scheint mir also irgend eine Inkompatibilität zwischen dem Mikrotik und dem großen Switch zu sein, obwohl doch alles 802.1Q sein sollte. Gibt es sowas? Kommt mir sehr komisch vor.
Heureka, Herr @aqui - es tut. Auch ohne blöden Desktop-Switch dazwischen. Das Problem war tatsächlich das Management-VLAN. Der kleine Desktop-Switch kommt damit anscheinend klar - der große (ältere) nicht.
Vielen Dank für das zweite Paar Augen, das gefehlt hat.
Ich markiere das dann mal als gelöst hier, nun geht's daran dem Unifi Access Point auch noch die VLANs bei zu bringen :D
Edit: Unifi tut's nun auch, mit separaten WLANs für Intern und Gast.
Vielen Dank für das zweite Paar Augen, das gefehlt hat.
Ich markiere das dann mal als gelöst hier, nun geht's daran dem Unifi Access Point auch noch die VLANs bei zu bringen :D
Edit: Unifi tut's nun auch, mit separaten WLANs für Intern und Gast.
nur ein Verbesserungsvorschlag für das Tutorial.
Du hast natürlich Recht. Das wird geändert! Danke fürs Feedback.Vielen Dank für das zweite Paar Augen, das gefehlt hat.
Immer gerne! 😊
