02.04.2022, aktualisiert am 03.04.2022

9575

DHCP Wahnsinn TPLink Switche VLANs

Hallo zusammen,

ich habe das Mikrotik VLAN Tutorial durchgearbeitet und betreibe einen Mikrotik HEX mit 6 VLANs und 2 TP-Link Switchen sowie einen TP-Link AP mit MSSID.
Im Grunde funktioniert alles wir erwartet: Netzte sind getrennt, werden entsprechend vom Mikrotik geroutet, etc...

Ich habe folgendes Problem:
Die TP-Link Sachen sollen per DHCP vom Mikrotik-Router festgelegte IPs bekommen.
Dies hat anfänglich auch funktioniert. Mittlerweile (nach dem Clients in den VLANs 30 und 40 hinzugekommen sind) bekommen sie willkürlich aus VLAN1, VLAN30 oder VLAN40 eine IP. Einzig der AccessPoint bekommt immer seine richtige IP. Die anderen VLANs beherbergen aktuell noch keine Clients.

Einmal hab ich einen DHCP-Request von einem WLAN Gerät im VLAN40 gesehen der eine IP aus dem VLAN1 Netz angefordert hat und die auch bekommen hat. Aktuell ist das aber nicht mehr der Fall. Irgendwas scheint also in meinem VLAN1 schief zu laufen.

Ich bin aktuell etwas Ratlos an welcher Stelle ich suchen soll.

Danke für Eure Hilfe.
Grüße Felix

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 2381602375

Url: https://administrator.de/forum/dhcp-wahnsinn-tplink-switche-vlans-2381602375.html

Ausgedruckt am: 25.12.2024 um 03:12 Uhr

35 Kommentare

Neuester Kommentar

Hallo Felix,

ich habe die Kombination auch in einem Fall und es war ähnlich. Die Clients selbst bekamen IPs aus den korrekten VLANs, nur der Switch von TP-Link holte sich willkürlich die Adressen aus verschiedenen VLANs. Nicht einmal die kleinen schrottigen Zyxel-GS-Switche hatten damit Probleme, Mikrotik und Cisco natürlich auch nicht.

Ich denke, es ist ein TP-Link Bug, mit dem man leben muss. IP fest zuweisen und fertig.
Wenn Du den EAP mit OpenWRT betreibst, ist zumindest dieser Fall erledigt. Ja, ist nicht so schön, aber wo ist IT schon perfekt? Sonst kauf halt nen CSS/CRS326 oder nen Cisco CBS. Ist nicht teuer und kann das dann richtig.

Viele Grüße, commodity

bekommen sie willkürlich aus VLAN1, VLAN30 oder VLAN40 eine IP

Zeigt klar das du das Tutorial NICHT sauber abgearbeitet hast. Jedermann weiss das VLANs vollkommen getrennte L2 Domains sind. Es ist technisch vollkommen unmöglich das dort Broadcasts aus anderen VLAN Netzen enden können. Es sei denn du hast etwas falsch konfiguriert.
Entscheidend ist immer die gesetzte PVID an den Anschlussports der TP-Link Komponenten.
Die PVID bestimmt in welches VLAN die DHCP Broadcasts der angeschlossenen Komponenten geforwardet werden.
Und genau da hast du etwas falsch konfiguriert.
Außerdem ist es zwingend nötig bei einem TP-Link Switch das Port Based VLAN zu deaktivieren und immer die 802.1Q VLAN Funktion zu aktivieren !!

Hallo,

Die TP-Link Sachen sollen per DHCP vom Mikrotik-Router festgelegte IPs bekommen.

Switche Drucker, Server, WLAN APs, usw... sollten immer alle eine fixe (statische) IP Adresse
erhalten, ebenso die beiden Router!!!

Dies hat anfänglich auch funktioniert. Mittlerweile (nach dem Clients in den VLANs 30 und
40 hinzugekommen sind) bekommen sie willkürlich aus VLAN1, VLAN30 oder VLAN40 eine IP.

Das kann auch organisieren. Der MikroTik hat doch einen User Manager.

Einzig der AccessPoint bekommt immer seine richtige IP. Die anderen VLANs beherbergen
aktuell noch keine Clients.

Der sollte eine fixe (statische) IP Adresse haben!

Einmal hab ich einen DHCP-Request von einem WLAN Gerät im VLAN40 gesehen der eine IP
aus dem VLAN1 Netz angefordert hat und die auch bekommen hat. Aktuell ist das aber nicht
mehr der Fall. Irgendwas scheint also in meinem VLAN1 schief zu laufen.

VLAN1 ist immer so eine Sache das ist in der Regel das so genannte "default VLAN" und dort sind
eigentlich immer alle Geräte Mitglied (außer die WLAN Klienten), das wird auch oft als Admin VLAN
bezeichnet da es dafür natürlich gut eignet. Muss aber nicht sein.

Dobby

Zitat von @aqui:
Zeigt klar das du das Tutorial NICHT sauber abgearbeitet hast. Jedermann weiss das VLANs vollkommen getrennte L2 Domains sind. Es ist technisch vollkommen unmöglich das dort Broadcasts aus anderen VLAN Netzen enden können.

Nein, Du hast das Problem falsch verstanden.

Nur die TP-Link-Netzwerkgeräte ziehen sich die willkürlichen IPs. Und die bekommen sie (meine Vermutung) aus dem angebundenen Trunk. Der TP-Link bedient sich offenbar einfach am nächstbesten DHCP-ACK, das ihn erreicht, statt artig die auf seinem Management VLAN (1) zu nehmen, wie andere das tun.
Vielleicht liege ich ja falsch, das wäre schön.

Viele Grüße, commodity

Zitat von @108012:
Switche Drucker, Server, WLAN APs, usw... sollten immer alle eine fixe (statische) IP Adresse
erhalten, ebenso die beiden Router!!!

Sorry Dobby, wir leben nicht mehr im Netzwerk-Mittelalter. Der TO vergibt fixe IP-Adressen, aber über DHCP. Das ist heute Standard (oder sollte es sein).

Viele Grüße, commodity

Zitat von @commodity:
Ich denke, es ist ein TP-Link Bug, mit dem man leben muss. IP fest zuweisen und fertig.

Hallo commodity,
schön zu wissen, das man nicht alleine ist mit dem Problem. Den Gedanken hatte ich auch schon, ich hab schon Stunden mit der Suche vebracht und mit Wireshark geschnüffelt und es scheint tatsächlich ein Fehler der TP-Link Switche zu sein. Das würde auch dazu passen das er sich aktuell nur IPs aus den VLANs 30 und 40 holt, weil eben nur da Traffic läuft.

Der AccessPoint bekommt es gebacken sich aus dem VLAN1 die richtige IP zu holen, aber der hat auch schon mal einen Client in das VLAN1 geschickt.

Auf lange Sicht werde ich wohl auf den CRS326 umsteigen.
Danke für deine Hilfe.
Grüße Felix

Dann gibst du als Workaround zum Bug der TP-Link Gurke halt eine statische IP und das "Problem" ist erledigt !

Nebenbei: Habs hier gerade mal mit je einem TP-Link SG105 und SG108 und aktuellster Firmware nachgestellt und die zogen sich immer brav die nach ihrer Mac Adresse statisch vorgegeben IPs im Mikrotik DHCP Server (RouterOS 7.1.5)
Zumindestens mit den Modellen lies sich dein Fehler de facto nicht reproduzieren !

Zitat von @aqui:

Dann gibst du als Workaround zum Bug der TP-Link Gurke halt eine statische IP und das "Problem" ist erledigt !

Das haben die bei mir auch gemacht, während der Einrichtung war alles super.
Nur seit Clients in dem Netz sind, bedienen Sie sich auch in den Netzen in denen sich Clients tummeln.

bedienen Sie sich auch in den Netzen in denen sich Clients tummeln.

OK, das checke ich nochmal.
Wäre ja böse, denn das bedeutet das die VLAN L2 Domains nicht vollständig getrennt sind in den TP-Link Switches was gegen den .1q Standard verstößt.

Deren proprietäre "Port Based VLAN" Funktion hast du aber im Setup deaktiviert und die 802.1Q VLAN Funktion aktiviert, oder ?
Ansonsten entsorgen und Zyxel GS1200er o.ä. nehmen.

Zitat von @aqui:
Deren proprietäre "Port Based VLAN" Funktion hast du aber im Setup deaktiviert und die 802.1Q VLAN Funktion aktiviert, oder ?

Ja, das ist korrekt konfiguriert.

Ich hab es jetzt noch einmal nachgestellt. Alles aus, Clients weg. Netzwerk gestartet. Alle Switche holen sich die richtige IP. Clients wieder an. Dann versucht der SG105PE über VLAN40 seine IP zu renewn, das schlägt fehl und dann holt der sich ne ganz neue aus VLAN40.

Interresanterweise holen sich die Switche ihre neue IP auch nicht mit der Quelladresse 0.0.0.0 sondern 192.168.0.1 (wo auch immer die herkommt).

wenn Ihr so fleißig dran seid, mache ich mich vielleicht auch nochmal ran. Bislang habe ich es mit dem vom Kollegen @aqui vorgeschlagenen Workaround gelöst.

das bedeutet das die VLAN L2 Domains nicht vollständig getrennt sind in den TP-Link Switches

Mein Eindruck ist, dass der Switch sein DHCP "zufällig" aus einem der angeschlossenen VLANs bezieht, wahrscheinlich first comes, first serves.
Kann es sein, dass das DHCP-Client-Modul auf jedemInterface, das eine individuelle PVID hat, die Anfrage raus schickt und dann eben mal vom einen VLAN, mal vom anderen VLAN eine Antwort bekommt? Ich hatte seinerzeit getestet, ob vielleicht die PVID von Port1 des Switches als quasi "Master" funktioniert, war aber nicht so.
Das heißt ja noch nicht, dass die VLANs als solche nicht sauber getrennt sind, sondern nur der DHCP-Client nicht genau weiß, woher er die Adresse beziehen soll. Woher soll er das auch wissen, bei den DHCP-Einstellungen gibt es keine Interface-Angabe. Beim Mikrotik kann ich das Interface für den DHCP-Client wählen. Beim Zyxel GS z.B. geht es nur fix über VLAN 1.

Edit: Hab gerade mal gegoogelt, wir sind nicht allein:

https://forum.chip.de/discussion/1894844/vlan-mit-tp-link-und-telekom

Im Beitrag vom 21. Apr 2020, 07:25 heißt es:

Die einfachen smart-managed Switches von TP-Link verfügen über keine solche Einstellung. Der DHCP-Discover wird über alle VLANs gesendet und der erste DHCP-Offer welcher empfangen wird angenommen und von diesem DHCP-Server wird die IP-Adresse bezogen.

Der Kollege lässt zwar im Dunkeln, wo er diese Erkenntnis her hat, das passt aber zu den bisherigen Feststellungen.

Viele Grüße, commodity

Edit 2: same here: https://community.tp-link.com/en/business/forum/topic/108631
also here: https://www.reddit.com/r/HomeNetworking/comments/7yiu55/issues_with_mana ...

Edit 3: Felix, vielleicht magst Du noch den Titel des Threads in 'DHCP Wahnsinn TP-Link VLANs' o.ä. ändern ? Der arme Mikrotik kann ja nun gar nichts dafür...

sondern 192.168.0.1 (wo auch immer die herkommt).

Das ist die Fallback IP auf die er zurückfällt wenn er keine DHCP IP vom DHCP Server bekommt bzw. für ihn damit der DHCP nicht vorhanden ist.

Der Wireshark Trace ist schon etwas kurios...
Die Source Mac Adresse, ist das wirklich die des Switch Management Interfaces was der Switch dir auf seiner Status Page anzeigt ???
TP-Link supportet gar kein VLAN spezifisches Binden seines Management Interfaces an ein VLAN insofern wäre es sehr kurios das der DHCP Request dann mit einem 802.1q VLAN Tag daher kommt. Und vor allem: Warum gerade VLAN 40 und nicht VLAN 39 oder 5 oder was auch immer ?
Es sieht eher so aus als ob der Request von einem anderen Endgerät kommt und gar nicht vom Switch ?!

Der Wireshark Trace ist schon etwas kurios...

da ist er wohl in der Zeile verrutscht. Die 1.11 ist sicher nicht der Switch.
Die Zeilen im blauen Teil zeigen den Ablauf aber doch:

Viele Grüße, commodity

Richtig ! Aber genau DER Trace wäre von den Details wichtig und interessant...

Zitat von @commodity:
Edit 3: Felix, vielleicht magst Du noch den Titel des Threads in 'DHCP Wahnsinn TP-Link VLANs' o.ä. ändern ? Der arme Mikrotik kann ja nun gar nichts dafür...

Das hast du recht.

Zitat von @aqui:

sondern 192.168.0.1 (wo auch immer die herkommt).

Das ist die Fallback IP auf die er zurückfällt wenn er keine DHCP IP vom DHCP Server bekommt bzw. für ihn damit der DHCP nicht vorhanden ist.

Das ist aber auch merkwürdig, mMn müsste der Discover von 0.0.0.0 kommen. 192.168.0.1 ist ja jetzt nicht unüblich das kann ja auch mal schnell eine Kollision geben, wenn der TP-Link aus Lust und Laune damit rumbrüllt.

Zitat von @aqui:
Es sieht eher so aus als ob der Request von einem anderen Endgerät kommt und gar nicht vom Switch ?!

Der kommt definitiv vom Switch. Dieser hat sich vorher die richtige IP 192.168.1.11 geholt.

Hier das pcap:

https://we.tl/t-HyiWidjea2

Edit:
Spannend ist auch das ich direkt am Trunk geschnüffelt habe und Request nur auf 40 kam. Er sendet also nur einen Request in einem beliebigen VLAN. Aber in welchem ist dann mehr oder weniger beliebig. Eben genau deswegen, weil er gar nicht weiß in welchem er die Anfrage stellen soll.

Der kommt definitiv vom Switch. Dieser hat sich vorher die richtige IP 192.168.1.11 geholt.

d.h. er ist mit 192.168.0.1 gestartet, hat dann die 1.11 bekommen und danach eine IP aus dem VLAN40?

Der Link führt nicht zum Download des Trace.

Viele Grüße, commodity

Ne der startet tatsächlich mit 0.0.0.0 (nicht im trace).
Deswegen ist es ja auch so fragwürdig das er dann irgendwann mit der 192.168.0.1 fragt.

Bei mir funktioniert der Link. Die WT Seite ist aber nicht sehr übersichtlich.

Hier einmal ein Wireshark Trace von einem TP-Link SG Switch DHCP Bootvorgang der mit einem Trunk Port (Port 5) auf einem Mikrotik im klassischen Layer 3 Switchsetup (ebenfalls Port 5, RouterOS 7.1.5) verbunden ist.
3 VLANs = 1, 10 und 20

TP-Link Switch

Management IP und Mac Adresse in VLAN 1:

Port 5 ==> Uplink zum Mikrotik:

Mikrotik

Port 5 ==> Uplink TP-Link Switch, VLAN Setup:

Port 5 ==> PVID Setting:

DHCP Leases Mikrotik:

Wireshark Traces

DHCP Requests des TP-Link Switches:

DHCP Offer vom Mikrotik:

LLDP Broadcasts am Trunkport TP-Link-Mikrotik:

Im Grunde ist das alles klassisches und Standard konformes Verhalten:

TP-Link sendet einen initialen DHCP Requests mit 0.0.0.0 als Absender
Dananch wiederholt er diese Requests mit seiner Fallback IP
Mikrotik antwortet mit einem Offer und weist die Hostaddresse .28 zu
Anhand der LLDP Frames auf dem Trunkport kann man sehen das auch das Tagging für die einzelnen VLAN sauber rennt wie es sein soll.

Alle VLAN spezifischen Frames landen gem ihres 801.1q Tags sauber in ihren jeweiligen VLANs. Es gibt keinerlei Ausreisser, weder bei Broad- und Multicastcast Frames noch bei Unicast Frames !
Der TP-Link Switch wurde ca. 15mal rebootet mit einem Kaltstart. Davon 5mal indem auch der Lease Cache des DHCP Servers vorher gelöscht wurde. On Top auch 3mal mit einem Reboot des Mikrotik.
Fazit:
Works as designed !! 😉
In keinem einzigen Falle konnte das Verhalten vom TO oben in der Kombination mit dem TP-Link Switch reproduziert werden !
Sowohl TP-Link als auch Mikrotik verhielten sich absolut Standard konform, es kam zu keiner Zeit zu Paket Leaks in andere VLANs.
War aber eigentlich auch irgendwie zu erwarten, denn auch billige Chinesen Switches sollten diese einfachen und grundlegenden Ethernet Standards fehlerfrei beherrschen.

Wow, Du bist einfach Klasse!

Das Ergebnis irritiert aber:

Du hattest DHCP-Server auf VLAN 1, 10 und 20 eingerichtet? Und Endgeräte in diesen VLANs? Der TO beschreibt ja, dass das erst passiert, wenn Endgeräte in den VLANs aktiv sind. Ich habe es immer nur mit aktiven Endgeräten in den VLANs probiert und hatte das gleiche Verhalten wie der TO.

HW-Rev. & FW des TP-Link?

Wenn es also eine Fehlkonfiguration sein könnte, wo könnte die Deiner Meinung nach liegen? Das bei mir betroffene Netz läuft tadellos, inkl. einiger Access-Switche auf DHCP VLAN1. Nur der TP-Link bekommt als DHCP-Client IPs aus unterschiedlichen VLANs. Und wie meine Links oben zeigen, ist das Verhalten ja auch anderswo (und ohne Mikrotik-Einfluss) festgestellt worden.

Viele Grüße, commodity

Du hattest DHCP-Server auf VLAN 1, 10 und 20 eingerichtet?

Ja, der Mikrotik arbeitet als Core L3 Switch mit Spanning Tree Priority 8192 (hex 0x2000 im MT) und macht auch DHCP für die VLANs.
Die Switchports 3 und 4 sind UNtagged Endgeräte Ports in den VLANs 10 und 20. Dortige Endgeräte bekammen auch bei den Reboots immer eine entsprechend richtige, dem VLAN 10 oder 20 zugehörige IP Adresse. Ich hatte die nur aus den Leases Screenshot der Übersicht halber gelöscht.
Kann das aber nochmal eingehender testen, da ich diese Clients jetzt nicht immer auch rebootet hatte. Nur den Switch selber und 3mal dazu auch den MT.

HW-Rev. & FW des TP-Link?

Siehe Switch Status Screenshot im Kapitel "TP-Link" oben !

Wenn es also eine Fehlkonfiguration sein könnte, wo könnte die Deiner Meinung nach liegen?

Ich vermute mal eher nicht am Switch selber obwohl man das nicht 100% ausschliessen kann. Paket Leaks innerhalb der VLANs sind auch bei den billigsten Chinesen Switches aber eher sehr sehr selten. Dort kommen billige Realtek ASICs zum Einsatz die auch in dem Bereich von anderen Herstellern verwendet werden. Würde das ein genereller Fehler im Silizium sein wäre das schon längst aufgefallen bei solchen Grundfunktionen.
Sehr wahrscheinlich ist das ein Fehler der Mikrotik VLAN Bridge Einrichtung. Die VLAN Zuweisung in der Bridge des TO sieht soweit gut aus, allerdings fehlen da die Details welcher Port Mode, PVID usw. um das sicher sagen zu können.
Es werden auch gerne mal so typische Fehler gemacht die Bridge selber als Memberport zu definieren, VLAN Interfaces oder IPs auf die Bridge selber zu mappen was dann ggf. solche Side Effects bewirken kann. Das kann man aber in Unkenntniss der genauen Konfig jetzt nur vermuten.
Um das zu verifizieren könnte man den Switch mal testweise an einen Raspberry Pi mit VLAN Trunk Port oder einen anderen VLAN Router oder L3 Switch hängen, also eine andere L3 HW verwenden um die eine oder andere Komponente sicher ausschliessen zu können.

Paket Leaks ...

Es sind IMHO keine Paketleaks, sondern eine Schwäche des DHCP-Clients des TP-Link. Dieser hat keine Festlegung des Management-Interface und nimmt die nächste angebotene IP.
Das wird auch hier nochmal klar beschrieben (leider wieder ohne Quelle).

Switch Status

In meinem Fall ist es HW Rev. 2.0, vielleicht ist das da noch anders
@Felix: Welche HW Rev. hast Du?

Mikrotik VLAN Bridge Einrichtung

Ist natürlich nie ganz auszuschließen. Ich meine aber, das zu können...
(Daran bist Du nicht ganz unschuldig

)

Um das zu verifizieren...

gute Idee!
Hier hat einer das gleiche Problem mit einer PfSense

Viele Grüße, commodity

Oha, ja da hast du Recht. Das ist dann in der Tat dann eher nicht der Mikrotik.
The switch is discoverable by the easy smart software from any vlan
You cannot control via setup which vlan it asks for an ip address from.
Bedeutet dann das das Management Interface transparent an allen VLANs hängt. Das kommt dann zu einer Race Condition und ist keine gute Implementation du dann bei Broadcasts zu sowas führt.
Da ist dann wohl in der Tat doch eher der Switch der böse Buhmann.

Ist aber scheinbar wohl wirklich abhängig von der Hardware Revision. Die Revision 4 hier ist ja deutlich moderner als Rev. 2. Vermutlich gibts dann auch Änderungen im Verhalten, denn mit der Rev. 4 hier ist das, wie gesagt, nicht reproduzierbar.
Für TP-Link im VLAN Umfeld ist das dann eher ein NoGo, denn das darf eigentlich nicht passieren.

The switch is discoverable by the easy smart software from any vlan

Das sahen die wohl als Feature. So kann man sich nicht aussperren.
Na ja, für den Hausgebrauch kann man die Adresse ja auch statisch vergeben.

Um das zu verifizieren...

Ich greife das nochmal auf. Muss nur auf einen geeigneten Zeitpunkt gucken, an dem ich das Netz lahmlege

Viele Grüße, commodity

Info am Rande:

Hatte heute zufällig einen TL-SG2424 2.0 unter den Fingern.
Bei den größeren TP-Links kann man offenbar das Management-VLAN wählen:

Der läuft allerdings ohne DHCP und (noch) ohne VLANs. Denke aber, da gäbe es das Problem nicht. Ich bleibe dran.

Viele Grüße, commodity

Bei den größeren TP-Links kann man offenbar das Management-VLAN wählen:

Das ist ja schonmal ein deutlicher Fortschritt bei den Kisten und dürfte das Problem dann auch dauerhaft lösen ! 👍

Das ist der Unterschied zwischen "easy smart" und "smart". Easy smart ist immerhin ein nettes Synonym für kognitiv begrenzt. Ob ich verklagt werde, wenn ich zukünftig gewisse Äußerungen als "easy smart" bezeichne?

Viele Grüße, commodity

Nee, politisch absolut korrekt beschrieben ! 🤣

Zitat von @commodity:
In meinem Fall ist es HW Rev. 2.0, vielleicht ist das da noch anders
@Felix: Welche HW Rev. hast Du?

Der SG1024 HW Rev. 4.0
Der SG105PE HW Rev. 2.0

Verhalten sich beide gleich.

Der 1024 fliegt erstmal raus und dafür dann nen CRS326.
Und der 105PE bekommt ne statische IP.

Danke für eure Hilfe!

Gerne! Hat mir auch sehr geholfen, hatte das Thema schon ausgeblendet

Ich habe für einen Kunden gestern einen SG108 bestellt. Wenn ich den habe, teste ich nochmal.

Kannst aber ruhig schon zu machen. Ist ja wohl gelöst. Und weiter schreiben geht dann auch noch.

Viele Grüße, commodity

Ich habe für einen Kunden gestern einen SG108 bestellt. Wenn ich den habe, teste ich nochmal.

Den hatte ich hier auch am Wickel und konnte das Phänomen damit glücklicherweise nicht reproduzieren.

Moin,

mein erster comment - tada!!!

Also, ich hab bei einem Kunden ca. 25 dieser preiswertern TP-Link-Switche in vielen Varianten im Einsatz. Aus den mir bekannten Unzulänglichkeiten jedoch NUR noch in Kleinstnetzen ohne irgendwelche Sicherheitsanforderungen. Gerne als PoE-Lieferant für IP-Telefone...
Da ich grundsätzlich alle Switche manuell mit einer festen IP ausstatte, ist mir das mit dem DHCP noch nie aufgefallen. ABER: die Teile sind eben nicht nur per Managementsoftware, sondern auch das Webinterface oder per ping auf der konfigurierten IP-Adresse aus JEDEM VLAN erreichbar. M.E. ein Unding!
Das betrifft alle mir bekannten Modelle SG105/108 E/PE in allen HW-Revisionen in jeder FW!

mein erster comment - tada!!!

Welcome to the club ! 🤝

auf der konfigurierten IP-Adresse aus JEDEM VLAN erreichbar. M.E. ein Unding!

In der Tat !
Interessant zu lesen ist auch dieser Thread der einen auch bei der Firmware Qualität doch erheblich zweifeln lässt. Alles heisse Nadel...

In verlässlichen Netzen sollte man ggf. auf andere Hardware ausweichen.

Zitat von @fmosbk:
mein erster comment - tada!!!

Und gleich ein sehr wertvoller! Erfahrungswerte aus der realen Praxis sind immer prima. In diesem Sinne: Willkommen!

Zum Thread:
Ich habe jetzt den nagelneuen SG108E angedockt und er verhält sich exakt wie der alte. Zu weiteren Tests habe ich ihn dann hinter den alten SG108PE gehangen, mit Konfig wie folgt:

Am SG108PE hängt er an einem Trunkport mit PVID 1, der tagged die VLAN 20,30,40 durchleitet.
Zuerst bekam das Ding artig eine IP aus VLAN1. Dann hab ich an Port 2 einen PC rangehangen, der sich die IP aus VLAN20 zog. Dann den SG108E vom Strom getrennt. Nach Hochfahren bekam er eine IP aus dem VLAN20.

Das Spielchen konnte man beliebig wiederholen. Mal kam ein paar Mal hintereinander die IP aus VLAN20, dann wieder aus VLAN1, ebenfalls ein paar Mal, dann wieder VLAN20. Nehme ich den PC von Port 2 ab, bekommt der durchweg die IP aus dem VLAN1 (4x hintereinander versucht).

Leases hatte ich zwischendurch natürlich immer gelöscht.

Ich bleibe bei der These: Bug bzw. buggy Feature. Was mich nur irritiert sind die Tests oben vom Kollegen @aqui, die ja etwas anderes aussagen. Was aber sollte vom Mikrotik da falsches kommen, wenn sonst alle IPs in den Netzen korrekt vergeben werden?

Viele Grüße, commodity

Mein 108er ist eine Ver. 2.0 Hardware mit aktuellster Firmware:

Habe das der Vollständigkeit halber auch nochmal mit dem o.a. 108E (Ver. 2.0) nachgestellt und auch damit lässt sich das o.a. geschilderte Verhalten trotz mehrfachen Reboots und Nutzung unterschiedlicher Endgeräte an den VLAN Ports nicht reproduzieren!