TP-Link VLAN: Kommunikation verschiedener VLANs im General mode?

[ascer]

Hallo Community,

es ist schon einige Zeit her, dass ich VLANs eingerichtet habe...und heute hatte ich beim Rumspielen mit einem TP-Link SG5428 kein Glück ^^

Grundsätzlich wollte ich Folgendes konfigurieren:

VLAN 1: Port 1, 2 (Switch ist nur hier zum konfigurieren erreichbar: man kann beim TPLINK einstellen, von welchen VLANs das Webinterface zugänglich ist)

VLAN 2: Port 3-16 (Netz A zum dranstöpseln von Clients)

VLAN 3: Port 17-22 (Netz B zum dranstöpseln von Clients)

VLAN 4: Port 23, 24 (Raspberry Pi)

Mit dieses Absichten/Constraints:
- VLAN 1 soll mit nichts kommunizieren, nur zum Konfigurieren genutzt
- VLAN 2 und VLAN 3 sollen nicht miteinander kommunizieren können.
- VLAN 4 (Raspberry Pi) soll mit VLAN 2 und VLAN 3 kommunizieren können (auf dem Raspberry läuft z.B. DHCP, Proxy und Anderes).

---

Als Erstes habe ich diese Konfiguration ausprobiert:

Port 1, 2: PVID 1, Access mode

Port 3-16: PVID 2, General mode

Port 17-22: PVID 3, General mode

Port 23, 24: PVID 4, General mode

...und dann hatte ich als zusätzliche Member von VLAN 2 und 3 (damit die den Raspberry erreichen können) die Ports 23, 24 dazugehängt.

Also VLAN 2 Port 3-16 (+ Port 23, 24 als Member) und VLAN 3 Port 17-22 (+ 23, 24 als Member).

Zusätzlich hatte ich bei VLAN 4 mit Port 23, 24 alle Ports aus VLAN 2/3 als zusätzliche Member hinzugefügt. Also VLAN 4 Port 23, 24 (+ 3-22 als Member).

Hatte mich dabei an dieser Anleitung von TP-Link orientiert: How to configure 802.1Q tag VLAN on L2 Managed Switches.

Leider hatte ich damit keinen Erfolg, jeder Member konnte immer nur innerhalb seiner eigenen PVID kommunizeren. Port 3-16 konnte also z.B. nicht mit 23/24 kommunizeren, obwohl die als weitere, alternative Member ja hinzugefügt wurden (zu VLAN 2).

---

Eine weitere Konfiguration, die ich noch ausprobiert hatte, war nur 3 VLANs zu bauen, sodass ich 23, 24 einfach mit auf PVID 2 gepackt habe und die dann nur als weitere Member zu VLAN 3 hinzugefügt hatte - also kein eigenes VLAN / PVID für Port 23, 24 (Raspberry Pi).

Das hat aber auch nicht funktioniert. Da ihre PVID dann 2 war, konnte VLAN 2 natürlich mit denen kommunizeren, aber VLAN 3 immer noch nicht.


Was übersehe ich da?

Grundsätzlich ist doch der Access mode nur für Ports, die ausschließlich aus einem einzigen VLAN erreichbar sein sollen. Sobald ich Ports haben möchte, die aus verschiedenen VLANs erreichbar sein sollen, ist doch genau dafür der General mode da?!

Und Trunken macht man doch nur, wenn man die VLANs taggt und mit den Trunk Ports dann mehrere Switches untereinander verbindet, sodass die anderen Switches die Tags auslesen können und anhand der Tags dann die gleichen VLANs auch bei sich aufbauen können. Also quasi die gleichen VLANs / PVIDs über mehrere Switches "syncen".

 

[lakekeman]

Was übersehe ich da?

Du übersiehst, dass du mit VLANs dein physisches Netz in Broadcast Domänen trennen kannst. Damit IP Netze innerhalb von VLANs miteinander kommunizieren können brauchst du einen Router.

 

[ascer]

@lakekeman: das verstehe ich ehrlich gesagt nicht ganz.
Grundsätzlich kann man einen Port zwar nur an eine PVID binden, aber wenn ich für den Port nicht den Access Mode einstelle (Mitgliedschaft auf ein 1 VLAN beschränkt), sondern den Port eben als weiteren, zusätzlichen Member in mehrere VLANs reinpacke, dann müsste das doch auch ohne Router gehen? (die Clients haben alle dasselbe /24er Netz).

Wo wäre denn sonst der Sinn darin, dass man außerhalb des Access Mode Ports auch in mehreren VLANs Member sein können? (zusätzlich zu ihrer primären PVID).

Wenn ich die TP-Link Anleitung "How to configure 802.1Q tag VLAN on L2 Managed Switches" jetzt nicht falsch verstanden habe, machen die dort doch auch genau das, ohne zusätzlichen Router?

An einen Router hätte ich jetzt ehrlich gesagt nur gedacht, wenn ich zusätzlich zu den VLANs auch noch z.B. zwischen verschiedenen /24er Netzen routen möchte?!

Ganz unabhängig davon steht unter den TP-Link SG5428 Switch Features auch explizit "Statisches Routing ermöglicht VLAN-Routing". Sollte/muss ich also doch noch statische Routen extra anlegen? Im Webinterface gibt es leider keinen Punkt "Routing" o.Ä.

 

[lakekeman]

Wenn du nur ein /24 Netz hast ist das eine Broadcast Domäne - und gehört auch nur in genau 1 VLAN.
Das kannst du nicht irgendwie zerstückeln, so funktioniert das nicht

Wenn dein Switch VLAN Routing beherrscht brauchst du freilich keinen extra Router. In diesem Fall ist der Switch ja der Router.

Trotzdem gehört auch dann ein /24 in ein VLAN. Du brauchst mehrere IP Netze um auch routen zu können.

 

[up.whatever]

Ein L3 Netz über mehrere VLANs zu verteilen macht überhaupt keinen Sinn. Einen Port in mehrere VLANs zu packen impliziert, dass alle VLANs (außer ggf. dem primären) getagged rausgegeben werden. D.h. das ist eher ein Feature um Kabel zwischen zwei Geräten sparen und die Gegenstelle muss entsprechend konfiguriert werden, die VLANs über Auswertung des Tags wieder auseinander zu frickeln.

tl;dr:
Ein VLAN mit mehreren IP Netzen: OK
Ein IP Netz mit mehreren VLANs: Blöde Idee

 

[ascer]

Vielen Dank für die Antworten

Eine Frage hätte ich dann aber noch mal: wozu hat man denn dann überhaupt die Möglichkeit, einen Port in mehrere VLANs als Member zu hängen? Wenn (1) die trotzdem ohnehin nicht kommunizieren können ohne Routing und (2) es eine "blöde Idee" ist, ein IP Netz mit mehreren VLANs zu haben?

Habe ich die TP-Link Anleitung "http://www.tp-link.com/us/faq-328.html" dann falsch verstanden? Wenn ich da nichts übersehen habe, machen die doch genau das: Clients aus verschiedenen VLANs miteinander kommunizieren lassen, indem sie die in mehrere VLANs reinhängen und (da Client) auf 'untagged' schalten.

 

[CptHirni]

Die Anleitung da ist schlichtweg falsch und wird so nicht funktionieren (außer "102" ist das default VLAN, was ich aber für höchst unwahrscheinlich halte- auch bei TP-Link).
Für deine Anwendung müsstest du:
Ports 1+2 VLAN 101 (oder irgendeine andere Nummer außer 1) nur Managenment
Ports 3-16 +23+24 VLAN 102 (oder irgendeine andere Nummer außer 1) ClientsA
Ports 17-22 +23+24 [bzw.17-24] VLAN 103 (oder irgendeine andere Nummer außer 1) ClientsB
Ports 3-24 VLAN 1 (default VLAN, frisst Pakete von allen anderen VLANs) Raspberry

Falls das default VLAN bei deinem Switch nicht 1 sondern 100 o.ä. ist, dann natürlich die entsprechende Nummer für Port 23+24 nehmen.

Resultiert in:
VLAN101 kann nur mit VLAN101 Membern (und dem Management, falls du das entsprechend konfigurierst) kommunizieren
VLAN102 kann nur mit VLAN102 Membern und Port 23+24 kommunizieren
VLAN103 kann nur mit VLAN103 Membern und Port 23+24 kommunizieren
VLAN1 frisst alles von VLAN 1, 102 und 103
VLANs 101, 102, 103 können ohne weiteres untereinander NICHT kommunizieren

Ports 3-24 "General" und "untagged". Port 1+2 kannst du auf Access stehen lassen, da die ja nur in einem VLAN sind.

IPs können auch alle im selben Bereich liegen. Für ClientsA und ClientsB existieren ja nur die jeweiligen Partner in ihrem VLAN. Ob A und B nu das selbe Subnet haben oder nicht, ist in dem Fall egal, da Broadcasts und jegliche Kommunikation nur auf den explizit VLAN zugewiesenen Switchports möglich ist.
Auf dem Raspberry musst du sicherstellen, dass dort keine Kommunikation zwischen ClientsA und ClientsB möglich ist (falls die Kiste das default Gateway o.ä. ist), ansonsten hebelst du dadurch die VLANs aus.

Falls du doch willst, dass (einzelne oder alle) Clients aus A und B kommunizieren können, müsstest du entweder statische Routen setzen, oder einen zusätzlichen Router in VLAN102+103 einsetzen, oder auf dem Raspberry ein Routing/Firewalling einrichten.

 

[ascer]

Frohes Neues & vielen Dank für die Antwort!

 

[lakekeman]

Keine Ahnung was "frisst alles von VLAN xyz" heißen soll, aber so wie "CptHirni" es beschrieben hat funktioniert es halt nicht.
Darüber wurde eigentlich schon alles gesagt.

Ansonsten einfach nochmal etwas dazu lesen:
https://www.thomas-krenn.com/de/wiki/VLAN_Grundlagen

 

[ascer]

Liest sich gut und hört sich nachvollziehbar an, vielen Dank.

Allerdings bleibt dann eine Frage bei mir nach wie vor offen: wozu kann man denn dann überhaupt Ports in mehrere VLANs gleichzeitig als Member eintragen? (untagged; bei einem getaggten Port wäre es ja klar: VLANs über mehrere Switches propagieren)
Wenn die unter keinen Umständen ohne Router untereinander kommunizieren können, wäre das doch sinnfrei?!

 

[lakekeman]

Mehrere untagged VLANs auf einem Port sind nicht möglich.
Bei manchen Switchen kann man das wohl so einstellen aber es wird nichts bewirken.
Es gibt dann den Punkt PVID welcher bestimmt welches untagged VLAN verwendet wird.

 

[ascer]

Ok, Dankeschön

Dann werde ich mich mal durch das Webinterface vom Switch kämpfen. Obwohl der ja mit "Statisches Routing ermöglicht VLAN-Routing" beworben wird, gibt es da nicht direkt einen Punkt "Routing" o.Ä. Muss ich wohl mal das 250-Seiten-Manual durchlesen, unter welchem Menüpunkt sich das Routing verstecken soll.

Brauche ich für die Clients eigentlich nur eine "Hin"-Route zum Raspberry Pi? Oder muss man auch eine "Rück"-Route anlegen?
Grundsätzlich muss der Pi nur auf requests von den Clients reagieren.

 

[lakekeman]

Dein Client muss wissen, wo das Paket hin soll. Und dein Pi muss wissen, wohin es zurückgegeben wird.

 

[ascer]

Klar, ich dachte nur, dass der Pi (sobald er einen request bekommt) ohnehin weiß, von wo der request kam und dementsprechend antworten kann.

Wenn aber auch schon für eine Antwort auf eine Anfrage eine Rückroute benötigt wird, dann benötige ich natürlich in der Tat den Hin- und Rückweg als feste, statische Route.

 

[CptHirni]

Dir natürlich auch ein frohes neues Jahr

@lakekeman: Das von mir beschriebene Szenario funktioniert durchaus. Schimpft sich je nach Hersteller "asymmetric vlan" "shared vlan" "access vlan" o.ä.
Wir haben dieses System an einigen Standorten am laufen:
Port 1-46 +jeweils Port 47 in einem eigenen VLAN 101-146, mit PVID 101-146, Port 1-47 zusätzlich in VLAN1 und Port 47 mit PVID1. Resultiert in: jeder Port (Client) kann mit Port 47 (Router) kommunizieren, untereinander aber nicht.

Für die Config des TEs:
Ports 1+2 VLAN 101 nur Managenment
Ports 3-16 +23+24 VLAN 102 ClientsA
Ports 17-22 +23+24 [bzw.17-24] VLAN 103 ClientsB
Ports 3-24 VLAN 1 Raspberry
Ports 3-16 PVID102
Ports 17-22 PVID103
Ports 23+24 PVID1

Du kannst auch versuchen VLAN/PVID104 o.ä. statt VLAN1 zu setzen. Ich kenne dein Switchmodell nicht, bei den älteren/einfacheren TP-Links ist nur das default-VLAN/PVID als shared möglich.

Edit: Hier die Erklärung von TP-Link zu asymetrischen VLANs:
dlink-manuals.org/dlink-des-1228-1228p-1252-user-manual/33/

Edit 2:
Wuuups, das ist D-Link, nicht TP-Link
Funzt bei TP-Link aber genauso...

 

[lakekeman]

Je nach Hersteller? Ich hab tatsächlich noch nie davon gehört geschweige denn es im Einsatz gesehen.
Es widerspricht doch auch allem wofür VLANs eigentlich stehen.
Wie dem auch sei, dann muss ich meine Aussage natürlich zurücknehmen. Wobei ich das nie freiwillig so konfigurieren würde.

 

[CptHirni]

Sorry, ich hätte eher "je nach chinesischem Hersteller" schreiben sollen
Die günstigen Fernost-Switche (D-Link, TP-Link, Trendnet etc) nennen das System so...zumindest D-Link und Trendnet nennen es "asymmetric VLAN". Bei Whitebox Ware direkt von OEMs aus Fernost, kommt einem je nach Firmware auch "Shared VLAN", "access VLAN" oder "common vlan" entgegen.

Das ganze funktioniert aber auch mit einigen HP Procurves (min. die 1700er) , Netgear FS/GS, Dell und Cisco (umgelabelte Linksys SG3xx/5xx) Switchen. Da hat die ganze Kram nur keinen eigenen Namen (soweit ich weiß).
Bei HP/Dell auf die selbe Art wie bei TP-Link mit den 802.1Q PVIDs.
Bei Netgear gehts zusätzlich auch über ihr ganz eigenes Port-Based-VLAN Verständnis (Appendix C):
http://www.downloads.netgear.com/files/FSxxxT_GSxxxT_smartswitch_UserManual.pdf
Wird eben dazu genutzt gemeinsame Drucker, Router o.ä. mehreren VLANs zur Verfügung zu stellen ohne Routen zu brauchen.

In Zeiten von bezahlbaren Level3 Switchen mit Routingoptionen wird das auch nicht mehr wirklich gebraucht, außer man will es sich "einfach" machen, oder für sehr spezielle Anwendungsfälle.

Eingesetzt wird das z.B. für IP-TV Systeme, in denen jeder Transmitter (Cam) sein eigenes VLAN hat und der/die Receiver im "shared VLAN" sitzen. Geswitcht werden die Streams dann, indem man dem Receiver-Port ein CAM-VLAN zuweist (sehr vereinfacht ausgedrückt).
Eine andere Anwendung dafür ist im Einsatz, wo ein Standort ein großes Subnetz zugewiesen bekommt. Jedes System am Standort hat sein eigenes VLAN und kann nur über den "shared Port" per VPN-Router mit der Zentrale kommunizieren, nicht untereinander. Das sind zugegebenermaßen sehr spezielle Anwendungsfälle die einem so in der freien Wildbahn eher nicht unterkommen.

Und glaub mir, freiwillig hätten wir das auch nie so konfiguriert (und haben es außer für die speziellen Anwendungen auch noch nie getan). Der E-Mail Verkehr mit den Herstellern der Systeme und Zeitaufwand um die Chose zum Laufen zu kriegen war gigantisch...

 

[lakekeman]

Hey noch was gelernt hier, wenn auch mit fraglichem Einsatzzweck. Danke

 

[satfee]

hallo. bin mit meinem selbigen probkem auf dieses forum gestossen. ich habe selbigrs problem wie TE, habe selbige beispiele von Tp-link erfolglis getestet, bin am verzweifeln. werde aber die config von cpthirni checken, klingt pausibel. gruss

 

[satfee]

CptHirni hatte recht!
Ich versuchte jetzt seine Config, und es klappte wunderbar. Was mich aber weiters stutzig macht, ist , das ich 2 Switches verbunden über je port1 nicht im tagged mode laufen lassen darf, sondern untagged. im tagged mode auf beiden seiten kann keiner im eigenen vlan miteinenader kommunizieren.

Irgendwas ist bei den TP-Link switsches falsch geschalten. Auch die beispiele arbeiten nicht wie angegeben.