felix94
Goto Top

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
screenshot1
switch
topologie_tplink

Content-ID: 2381602375

Url: https://administrator.de/contentid/2381602375

Ausgedruckt am: 14.11.2024 um 19:11 Uhr

commodity
Lösung commodity 02.04.2022 um 19:55:43 Uhr
Goto Top
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
aqui
aqui 02.04.2022 aktualisiert um 20:05:23 Uhr
Goto Top
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 !!
108012
108012 02.04.2022 um 20:06:02 Uhr
Goto Top
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
commodity
commodity 02.04.2022 um 20:09:05 Uhr
Goto Top
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
commodity
commodity 02.04.2022 um 20:13:31 Uhr
Goto Top
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
felix94
felix94 03.04.2022 um 13:45:28 Uhr
Goto Top
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
aqui
aqui 03.04.2022 aktualisiert um 14:57:20 Uhr
Goto Top
Dann gibst du als Workaround zum Bug der TP-Link Gurke halt eine statische IP und das "Problem" ist erledigt ! face-wink
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 !
felix94
felix94 03.04.2022 um 15:05:19 Uhr
Goto Top
Zitat von @aqui:

Dann gibst du als Workaround zum Bug der TP-Link Gurke halt eine statische IP und das "Problem" ist erledigt ! face-wink
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 !

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.
aqui
aqui 03.04.2022 aktualisiert um 15:36:58 Uhr
Goto Top
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. face-sad
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. face-wink
felix94
felix94 03.04.2022 um 15:44:28 Uhr
Goto Top
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).
details
uebersicht
commodity
commodity 03.04.2022 aktualisiert um 18:16:42 Uhr
Goto Top
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...
aqui
aqui 03.04.2022 um 18:17:30 Uhr
Goto Top
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 ?!
commodity
commodity 03.04.2022 um 18:28:36 Uhr
Goto Top
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:
screenshot 2022-04-03 182737

Viele Grüße, commodity
aqui
aqui 03.04.2022 um 18:33:36 Uhr
Goto Top
Richtig ! Aber genau DER Trace wäre von den Details wichtig und interessant...
felix94
felix94 03.04.2022 aktualisiert um 20:51:58 Uhr
Goto Top
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.
dhcp_eintrag
commodity
commodity 03.04.2022 um 21:41:03 Uhr
Goto Top
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
felix94
felix94 03.04.2022 um 22:27:24 Uhr
Goto Top
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.
aqui
aqui 04.04.2022 aktualisiert um 12:26:32 Uhr
Goto Top
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

back-to-topTP-Link Switch

Management IP und Mac Adresse in VLAN 1:
dhcp3
Port 5 ==> Uplink zum Mikrotik:
dhcp4

back-to-topMikrotik

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

Port 5 ==> PVID Setting:
pvid

DHCP Leases Mikrotik:
dhcp7

back-to-topWireshark Traces

DHCP Requests des TP-Link Switches:
dhcp1

DHCP Offer vom Mikrotik:
dhcp2

LLDP Broadcasts am Trunkport TP-Link-Mikrotik:
dhcp5

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.
commodity
commodity 04.04.2022 um 14:00:59 Uhr
Goto Top
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
aqui
aqui 04.04.2022 aktualisiert um 15:20:40 Uhr
Goto Top
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 ! face-wink
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.
commodity
commodity 04.04.2022 um 19:33:05 Uhr
Goto Top
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 face-smile )
Um das zu verifizieren...
gute Idee!
Hier hat einer das gleiche Problem mit einer PfSense

Viele Grüße, commodity
aqui
Lösung aqui 04.04.2022 aktualisiert um 20:17:15 Uhr
Goto Top
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. face-sad
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.
commodity
commodity 04.04.2022 um 20:53:08 Uhr
Goto Top
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 face-wink

Viele Grüße, commodity
commodity
commodity 05.04.2022 aktualisiert um 16:00:32 Uhr
Goto Top
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:

screenshot 2022-04-05 155810

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
aqui
aqui 05.04.2022 um 17:25:37 Uhr
Goto Top
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 ! 👍
commodity
commodity 05.04.2022 aktualisiert um 18:26:57 Uhr
Goto Top
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? face-monkey

Viele Grüße, commodity
aqui
aqui 05.04.2022 um 19:20:41 Uhr
Goto Top
Nee, politisch absolut korrekt beschrieben ! 🤣
felix94
felix94 07.04.2022 um 18:49:30 Uhr
Goto Top
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!
commodity
commodity 07.04.2022 um 19:04:57 Uhr
Goto Top
Gerne! Hat mir auch sehr geholfen, hatte das Thema schon ausgeblendet face-smile

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
aqui
aqui 08.04.2022 um 11:47:30 Uhr
Goto Top
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.
fmosbk
fmosbk 09.04.2022 um 02:47:07 Uhr
Goto Top
Moin,

mein erster comment - tada!!! face-smile

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!
aqui
aqui 09.04.2022 um 10:12:18 Uhr
Goto Top
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... face-sad
In verlässlichen Netzen sollte man ggf. auf andere Hardware ausweichen.
commodity
commodity 09.04.2022 aktualisiert um 18:59:44 Uhr
Goto Top
Zitat von @fmosbk:
mein erster comment - tada!!! face-smile
Und gleich ein sehr wertvoller! Erfahrungswerte aus der realen Praxis sind immer prima. In diesem Sinne: Willkommen! face-smile

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:
screenshot 2022-04-09 174706
screenshot 2022-04-09 174836
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. face-confused
screenshot 2022-04-09 174651
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).
screenshot 2022-04-09 185112
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
aqui
aqui 10.04.2022 um 14:26:29 Uhr
Goto Top
Mein 108er ist eine Ver. 2.0 Hardware mit aktuellster Firmware:
tp-sys
aqui
aqui 01.05.2022 aktualisiert um 17:33:10 Uhr
Goto Top
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!
  • Port 8 = Tagged Uplink auf den MT
  • Port 5, 6 und 7 = UNtagged Testports Endgeräte

back-to-topSetup TP-Link 108E

tp-test4

back-to-topSetup Mikrotik Router

tp-test1

back-to-topAdressvergabe in VLAN 1

tp-test2

back-to-topAdressvergabe in VLAN 10

tp-test10

back-to-topAdressvergabe in VLAN 20

tp-test20
Fazit:
Zumindestens gilt mit dieser HW Version: Works as designed ! face-wink
Es kann dann eigentlich nur an den verschiedenen HW Releases liegen.