12
Mikrotik DHCP-Server kein Gastnetzwerk
Hallo zusammen,
ich benötige mal Hilfe von Profis. Ich habe mir einen Mikrotik RB4011 zugelegt und nach diesem Tutorial konfiguriert. Nach 4-maligen resetten habe ich dann auch alles zum Laufen gebracht. Dachte ich. Als der 1. Besucher sich in das Gastnetzwerk einwählen wollte, war er für einen Moment verbunden und wurde dann wieder rausgeschmissen. Das ganze ging dann mehrmals so, bis der Verbindungsaufbau entgültig abgebrochen wurde. Ich hatte das Gastnetzwerk dummerwiese nur in meinem Bastelkeller getestet. Bei einer direkt Verbindung mit dem MT oder 1. Switch (Cisco SG350, LAN + WLAN über AP) bekömme ich eine IP-Adresse und komme ins Internet. Ab dem 2. Switch werden keine Verbindunegn für das Gastnetzwerk aufgebaut und somit keine Ineternetverbindung (blöd). Mit Dr. Google bin ich auf DHCP relay gekommen und habe mir einige Beiträge und Videos angesehen. Bin aber nicht richtig weiter gekommen (hier fehlt mir wohl Grundwissen). Ist das überhaupt der richtige Lösungsweg? Oder habe ich in den Einstellungen im MT/Switch was falsch gemacht? Hier mein Netzaufbau und einige Einstellungen vom MT, wo ich denke, das ich ein Fehler gemacht haben könnte.
VLAN 11 - Management
VLAN 12 - Telefon
VLAN 13 - Gastnetzwerk (DHCP-Server MT)
VLAN 14 - Radios, Reiver, TV und alles was sonst so Internet benötigt (DHCP-Server Cisco SG350)
VLAN 15 - Computer, Laptops, Smartphones (DHCP-Server Cisco SG350)
VLAN 16 - Drucker, NAS
VLAN 17 - Koppelnetz MT - Cisco (DHCP-Server MT nur zum Testen)
VLAN 999 - native/default
MT RB4011
Vile Grüße
Aule
ich benötige mal Hilfe von Profis. Ich habe mir einen Mikrotik RB4011 zugelegt und nach diesem Tutorial konfiguriert. Nach 4-maligen resetten habe ich dann auch alles zum Laufen gebracht. Dachte ich. Als der 1. Besucher sich in das Gastnetzwerk einwählen wollte, war er für einen Moment verbunden und wurde dann wieder rausgeschmissen. Das ganze ging dann mehrmals so, bis der Verbindungsaufbau entgültig abgebrochen wurde. Ich hatte das Gastnetzwerk dummerwiese nur in meinem Bastelkeller getestet. Bei einer direkt Verbindung mit dem MT oder 1. Switch (Cisco SG350, LAN + WLAN über AP) bekömme ich eine IP-Adresse und komme ins Internet. Ab dem 2. Switch werden keine Verbindunegn für das Gastnetzwerk aufgebaut und somit keine Ineternetverbindung (blöd). Mit Dr. Google bin ich auf DHCP relay gekommen und habe mir einige Beiträge und Videos angesehen. Bin aber nicht richtig weiter gekommen (hier fehlt mir wohl Grundwissen). Ist das überhaupt der richtige Lösungsweg? Oder habe ich in den Einstellungen im MT/Switch was falsch gemacht? Hier mein Netzaufbau und einige Einstellungen vom MT, wo ich denke, das ich ein Fehler gemacht haben könnte.
VLAN 11 - Management
VLAN 12 - Telefon
VLAN 13 - Gastnetzwerk (DHCP-Server MT)
VLAN 14 - Radios, Reiver, TV und alles was sonst so Internet benötigt (DHCP-Server Cisco SG350)
VLAN 15 - Computer, Laptops, Smartphones (DHCP-Server Cisco SG350)
VLAN 16 - Drucker, NAS
VLAN 17 - Koppelnetz MT - Cisco (DHCP-Server MT nur zum Testen)
VLAN 999 - native/default
MT RB4011
Vile Grüße
Aule
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: 671218
Url: https://administrator.de/forum/mikrotik-dhcp-server-kein-gastnetzwerk-671218.html
Ausgedruckt am: 12.03.2025 um 04:03 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
wäre es nicht einfacher, den RB4011 als einzigen DHCP Server für alle deine VLANs arbeiten zu lassen?
SG
wäre es nicht einfacher, den RB4011 als einzigen DHCP Server für alle deine VLANs arbeiten zu lassen?
SG
wäre es nicht einfacher, den RB4011 als einzigen DHCP Server für alle deine VLANs arbeiten zu lassen?
Ich wollte aber das Gastnetzwerk vom den anderen VLAN´s trennen. Macht man das nicht so? Abgesehen davon hätte ich dann mit den anderen WLAN´s das gleiche Problem wie beim Gastnetzwerk.
Zitat von @Aule1996:
Ich wollte aber das Gastnetzwerk vom den anderen VLAN´s trennen. Macht man das nicht so?
Ich wollte aber das Gastnetzwerk vom den anderen VLAN´s trennen. Macht man das nicht so?
Moin,
Nee. Man haz üblicherweise einen zentralen DHCP-Server mit mehreren Svopes, der das ganze Netz versorgt, bei sehr großen Netzen dann vielleicht mehrere.
Die einzelnen VLANs werden dann mit per DHCP-Proxy aus dem jeweiligen Scope versorgt. Das vereinfacht die Verwaltung
lks
PS: Das Gastnetzwerk ist natürlich auch ein eigenes VLAN, in dem nur die Gäste drin sind.
Ich wollte aber das Gastnetzwerk vom den anderen VLAN´s trennen. Macht man das nicht so?
Ja das ist absolut richtig und auch korrekt.Bei einem L3 Switchdesign wie bei dir wo der zentrale L3 Switch die lokalen VLANs routet dürfen diese nicht parallel auch an der davor kaskadierten Router/Firewall liegen. Das gilt ganz besonders für offene Gastnetze die keinerlei IPs auf dem L3 Switch haben dürfen.
Dieses Gast VLAN darf also keinesfalls mit einer IP Adresse auf dem L3 Cisco Switch liegen. Der darf dieses Gast VLAN ausschliesslich nur im Layer 2 an den Mikrotik durchreichen! Das Gast VLAN darf, wie gesagt, keinerlei IP Connectivity (L3) auf dem Cisco Switch haben. Ist das so umgesetzt?
Grundsätzlich ist das Setup also richtig.
Wichtig ist hier das du dem Cisco Switch als Core zwingend eine höhere Spanning Tree Priority vorgibst z.B. 8192 damit dieser immer die Root Bridge aus Layer 2 Sicht ist und die Root Ports entsprechend erzwingt. Das dient dazu eindeutiges L2 Forwarding zu definieren. Ganz besonders wenn man mit LACP LAGs arbeitet. Ist das entsprechend so konfiguriert??
Die einzelnen VLANs werden dann mit per DHCP-Proxy aus dem jeweiligen Scope versorgt
Der MT DHCP Server ist nicht Relay fähig weil er keine multiplen Scopes supportet! Ist aber so oder so für das Setup des TOs NICHT relevant.
Moin,
wenn das im Keller direkt per LAN-Port im VLAN13 am SG350 bzw. per WLAN über den am SG350 angeschlossen AP1 noch funktioniert, hinter den weiteren Switches aber nicht mehr, liegt Dein Fehler mit ziemlicher Sicherheit im Layer 2. Auf gut deutsch, Dein VLAN13 wird nicht korrekt über die weiteren Switche und APs an die Gast-SSID geleitet.
Kontrolliere nochmal genau Deine Trunk-Ports zwischen den Switches und den APs.
VG,
Torsten
wenn das im Keller direkt per LAN-Port im VLAN13 am SG350 bzw. per WLAN über den am SG350 angeschlossen AP1 noch funktioniert, hinter den weiteren Switches aber nicht mehr, liegt Dein Fehler mit ziemlicher Sicherheit im Layer 2. Auf gut deutsch, Dein VLAN13 wird nicht korrekt über die weiteren Switche und APs an die Gast-SSID geleitet.
Kontrolliere nochmal genau Deine Trunk-Ports zwischen den Switches und den APs.
VG,
Torsten
1Wichtig ist hier das du dem Cisco Switch als Core zwingend eine höhere Spanning Tree Priority vorgibst z.B. 8192 damit dieser immer die Root Bridge aus Layer 2 Sicht ist und die Root Ports entsprechend erzwingt. Das dient dazu eindeutiges L2 Forwarding zu definieren. Ganz besonders wenn man mit LACP LAGs arbeitet. Ist das entsprechend so konfiguriert?
Rapid STP hatte ich schon aktiviert und die Priority hatte ich auf 4096 gesetzt. Habe es auf 8192 geändert. Priority 4096 ist aber doch höher wie 8192 oder liege ich da falsch? Dem 2. Switch Prio 16384 und der 3. Switch Prio 32768.
Dieses Gast VLAN darf also keinesfalls mit einer IP Adresse auf dem L3 Cisco Switch liegen. Der darf dieses Gast VLAN ausschliesslich nur im Layer 2 an den Mikrotik durchreichen! Das Gast VLAN darf, wie gesagt, keinerlei IP Connectivity (L3) auf dem Cisco Switch haben. Ist das so umgesetzt?
Dem Gastnetzwerk habe ich auf dem L3 Switch keine IP vergeben und bin davon ausgegangen, dass er im L2 Modus für dieses Vlan läuft. Oder muss ich noch eine andere Einstellung machen?
wenn das im Keller direkt per LAN-Port im VLAN13 am SG350 bzw. per WLAN über den am SG350 angeschlossen AP1 noch funktioniert, hinter den weiteren Switches aber nicht mehr, liegt Dein Fehler mit ziemlicher Sicherheit im Layer 2. Auf gut deutsch, Dein VLAN13 wird nicht korrekt über die weiteren Switche und APs an die Gast-SSID geleitet.
Kontrolliere nochmal genau Deine Trunk-Ports zwischen den Switches und den APs.
Kontrolliere nochmal genau Deine Trunk-Ports zwischen den Switches und den APs.
Habe alles schon mehrmals kontrolliert aber keinen Fehler gefunden. Switch 2 + 3 sind im L2 Modus.
Switch 2
Switch 3
Switch 1 L3
Leg' Dir als ersten Testpunkt mal bitte einen freien Port (Access) auf Switch 2 in das VLAN 13.
Wenn Du hier ein Gerät anschliesst, dann bekommst Du schon keine IP vom DHCP-Server mehr?
Dann dem Gerät mal bitte testweise eine IP aus dem VLAN 13 fest vergeben. Klappt dann ein Ping auf das Gateway?
Falls nein: Der Fehler muss in der VLAN-Konfiguration zwischen Switch 1 und 2 sein.
Blöde Frage: Das VLAN 13 ist auf Switch 2 und 3 in den VLAN-Settings aber schon auch überhaupt angelegt?
Wenn Du hier ein Gerät anschliesst, dann bekommst Du schon keine IP vom DHCP-Server mehr?
Dann dem Gerät mal bitte testweise eine IP aus dem VLAN 13 fest vergeben. Klappt dann ein Ping auf das Gateway?
Falls nein: Der Fehler muss in der VLAN-Konfiguration zwischen Switch 1 und 2 sein.
Blöde Frage: Das VLAN 13 ist auf Switch 2 und 3 in den VLAN-Settings aber schon auch überhaupt angelegt?
Hallo,
Gastnetzwerk läuft. Danke an alle. @aqui: es lag wohl an der Priority. In den Tutorials von Sebastian Philippi habe ich zwar gelernt, dass der Root Switch die niedrigste Prio haben muß. Aber wie ich auf die 4096 komme, keine Ahnung.
wahrscheinlich nicht richtig aufgepasst. Oder kannst Du mir das nochmal erklären?
Grüße
Aule
Gastnetzwerk läuft. Danke an alle. @aqui: es lag wohl an der Priority. In den Tutorials von Sebastian Philippi habe ich zwar gelernt, dass der Root Switch die niedrigste Prio haben muß. Aber wie ich auf die 4096 komme, keine Ahnung.
wahrscheinlich nicht richtig aufgepasst. Oder kannst Du mir das nochmal erklären?
Grüße
Aule
4096 ist ein absolut gültiger und üblicher Wert für die Root-Bridge. Je niedriger der Wert, umso höher die Priorität.
Ich kann nicht glauben, dass es daran gelegen hat.
Hier geht es ja um Spanning-Tree. Die Bridge-Priority und somit die Wahl der Root-Bridge spielt also erst dann eine Rolle, wenn es multiple Verbindungen zwischen Switches gibt und es somit zu einer Schleife kommen würde.
Die Gefahr besteht bei Deinem Setup ja nur bei den LAGs zwischen den Switches. Sobald LACP hier für funktionale LAGs gesorgt hat, sind diese doppelten Verbindungen aus Sicht von STP nur noch eine.
Hier kann es also höchstens während der Aufbauphase der LAG oder bei LACP-Fehlkonfiguration (beide Seiten passen nicht zueinander) zu Schleifen kommen. Dann aber rennt STP los und am Ende wird eine Verbindung geblockt. Dann könnte allerdings die VLAN-Konfiguration der einzelnen dem LAG zugeordneten Schnittstelle greifen, weshalb ich immer dafür Sorge, dass die VLAN-Konfiguration nicht nur auf der LAG, sondern auch auf den beteiligten Schnittstellen passt.
Durch sinnvolle Wahl der Root-Bridge verhinderst Du in einer Topologie mit redundanten Verbindungen zwischen den Switches einfach ausgedrückt, dass Dein Traffic ungünstige Wege geht.
Ich kann nicht glauben, dass es daran gelegen hat.
Hier geht es ja um Spanning-Tree. Die Bridge-Priority und somit die Wahl der Root-Bridge spielt also erst dann eine Rolle, wenn es multiple Verbindungen zwischen Switches gibt und es somit zu einer Schleife kommen würde.
Die Gefahr besteht bei Deinem Setup ja nur bei den LAGs zwischen den Switches. Sobald LACP hier für funktionale LAGs gesorgt hat, sind diese doppelten Verbindungen aus Sicht von STP nur noch eine.
Hier kann es also höchstens während der Aufbauphase der LAG oder bei LACP-Fehlkonfiguration (beide Seiten passen nicht zueinander) zu Schleifen kommen. Dann aber rennt STP los und am Ende wird eine Verbindung geblockt. Dann könnte allerdings die VLAN-Konfiguration der einzelnen dem LAG zugeordneten Schnittstelle greifen, weshalb ich immer dafür Sorge, dass die VLAN-Konfiguration nicht nur auf der LAG, sondern auch auf den beteiligten Schnittstellen passt.
Durch sinnvolle Wahl der Root-Bridge verhinderst Du in einer Topologie mit redundanten Verbindungen zwischen den Switches einfach ausgedrückt, dass Dein Traffic ungünstige Wege geht.
Sorge, dass die VLAN-Konfiguration nicht nur auf der LAG, sondern auch auf den beteiligten Schnittstellen passt.
Die Ports hatte ich auch immer wie die LAG´s konfiguriert.
Aber ich glaube mein Fehler liegt in der LAG Einstellung. LACP muss eingeschaltet sein oder?
Ich habe die LAG´s bei allen gleich konfiguriert.
Habe es auf 8192 geändert.
Das wäre nicht nötig gewesen wenn es schonn richtig mit einer höheren Prio versehen wurde.Priority 4096 ist aber doch höher wie 8192 oder liege ich da falsch?
Nope, da liegst du genau richtig! 4096 ist die höchste zu konfigurierende Bridge Priority. Kollege @papabaer2002 hat ja schon gesagt das das ein durchaus legitimer Wert ist!Schwer zu glauben das das der Fehler ist solange alle anderen Komponenten wie die 2 L2 Switches und der MT im Default 32768 belassen wurden?! Diese 3 Komponenten sollten in ihrer Bridge Übersicht immer den L3 Switch bzw. dessen BPDU Adresse (Mac) als Root Switch anzeigen.
Dem Gastnetzwerk 13 habe ich auf dem L3 Switch keine IP vergeben und bin davon ausgegangen, dass er im L2 Modus für dieses Vlan läuft.
Alles richtig gemacht! 👍Die Ports hatte ich auch immer wie die LAG´s konfiguriert.
Das darf man auf gar keinen Fall machen. Die Memberports eines LAGs müssen immer "nackt" sein, sprich in der Default Konfig wenn sie als LAG Member eingebunden werden.ALLE weiteren Konfigs werden dann ausschliesslich nur noch über das virtuelle LAG Interface gemacht!
Das verhindert das es zu einem Konfig Mismatch der Memberinterfaces in einer LAG Gruppe kommt denn der resultiert immer in einer LAG Fehlfunktion. Sowie nur ein einziger Parameter der Memberinterfaces unterschiedliche ist scheitert der LAG!!
Die Verwendung des LAG Interfaces sorgt dafür das der Switch IMMER die Konfig sicher und synchron auf alle Memberinterfaces distribuiert. Wie gesagt: So wird sicher ein Mismatch verhindert!
Da hast du es sicher zu gut gemeint und damit in Bezug auf LAGs kontraproduktiv gehandelt.
Wir hatten dieses "LAG Drama" hier kürzlich in diesem langen Thread wo der TO dies auch aus Unwissenheit falsch gemacht hat!
Aber ich glaube mein Fehler liegt in der LAG Einstellung.
Zu 98% wird das der Fall gewesen sein.LACP muss eingeschaltet sein oder?
Ja, denn LACP ist zwingend. Ohne den Standard LACP kommt kein dynamischer 802.1ax LAG zustande den beide Seite aktiv aushandeln. Siehe dazu auch hier:Link Aggregation (LAG) im Netzwerk
