VLAN Tagging und Untagging Problem über mehrere gemanagede Switche
Hallo Zusammen,
ich habe Probleme mit der Einrichtung von VLAN's und würde mich über eure rege Teilnahme freuen, ich habe mich bereits hier eingelesen aber habe zu meinem Problem keinen Beitrag gefunden.
Folgendes Problem hab ich beim Einrichten von einem VLAN:
verwendete Hardware:
24 Port Switche von Hirschmann (LION 24TP, GES und RS30)
24/48-Port Switche von enterasys
24/48-Port Switche von Juniper
Physikalische Topologie: (A) HIRMA SW LION 24 TP ------ (B) enterasys SW 24Port ---------------- (C) enterasys SW 24 Port ---------------- (D) Juniper SW 24Port ------------------- (E) HIRMA 24 Port RS30
Soll Virtuelle Topologie: -----------Default VLAN 1------------untagged VLAN 333 tagged -------------- tagged VLAN 333 tagged ---------------tagged VLAN 333 untagged---------------------Default VLAN 1
NIC Teilnehmer: ----------------SV1- SV2 - WS1 - WS2 -----------------Laptop 1------------------------------------------ SV3 -------------------------------------------------------------------------------------------- Laptop 2
IP-Range: 10.0.10.xxx / 24
Problem:
Ich möchte von Laptop 1 aus Teilnehmer SV1, SV2 WS1 und WS2 erreichen, funktioniert aber nicht, SV3 kann ich selbstverständlich erreichen.
Für mein Verständnis werden die Pakete z.B. an Switch B untagged, sprich VLAN-Kennung wird entfernt und somit müssten Teilnehmer an Switch A und der Switch A erreichbar sein, sind sie aber nicht.
Temporäre Lösung
Zwischen Switch A und B, und zwischen Switch D und E ist je ein unmanged 8-Port Switch geschaltet und siehe das es funktioniert.
Das ist aber nur einen Notlösung .
Hat irgendjemand eine Idee warum das so ist und wie eine Lösung aussehen könnte.
Die Switche A und E sollten auch variabel parametrierbar bleiben, sprich man sollte nicht gezwungen sein, dort das VLAN 333 einrichten zu müssen da es sich dabei um Testgerät handelt.
Vielen Dank schon einmal im Vorraus.
Gruss
Nettiman
ich habe Probleme mit der Einrichtung von VLAN's und würde mich über eure rege Teilnahme freuen, ich habe mich bereits hier eingelesen aber habe zu meinem Problem keinen Beitrag gefunden.
Folgendes Problem hab ich beim Einrichten von einem VLAN:
verwendete Hardware:
24 Port Switche von Hirschmann (LION 24TP, GES und RS30)
24/48-Port Switche von enterasys
24/48-Port Switche von Juniper
Physikalische Topologie: (A) HIRMA SW LION 24 TP ------ (B) enterasys SW 24Port ---------------- (C) enterasys SW 24 Port ---------------- (D) Juniper SW 24Port ------------------- (E) HIRMA 24 Port RS30
Soll Virtuelle Topologie: -----------Default VLAN 1------------untagged VLAN 333 tagged -------------- tagged VLAN 333 tagged ---------------tagged VLAN 333 untagged---------------------Default VLAN 1
NIC Teilnehmer: ----------------SV1- SV2 - WS1 - WS2 -----------------Laptop 1------------------------------------------ SV3 -------------------------------------------------------------------------------------------- Laptop 2
IP-Range: 10.0.10.xxx / 24
Problem:
Ich möchte von Laptop 1 aus Teilnehmer SV1, SV2 WS1 und WS2 erreichen, funktioniert aber nicht, SV3 kann ich selbstverständlich erreichen.
Für mein Verständnis werden die Pakete z.B. an Switch B untagged, sprich VLAN-Kennung wird entfernt und somit müssten Teilnehmer an Switch A und der Switch A erreichbar sein, sind sie aber nicht.
Temporäre Lösung
Zwischen Switch A und B, und zwischen Switch D und E ist je ein unmanged 8-Port Switch geschaltet und siehe das es funktioniert.
Das ist aber nur einen Notlösung .
Hat irgendjemand eine Idee warum das so ist und wie eine Lösung aussehen könnte.
Die Switche A und E sollten auch variabel parametrierbar bleiben, sprich man sollte nicht gezwungen sein, dort das VLAN 333 einrichten zu müssen da es sich dabei um Testgerät handelt.
Vielen Dank schon einmal im Vorraus.
Gruss
Nettiman
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 150128
Url: https://administrator.de/forum/vlan-tagging-und-untagging-problem-ueber-mehrere-gemanagede-switche-150128.html
Ausgedruckt am: 15.05.2025 um 00:05 Uhr
6 Kommentare
Neuester Kommentar
Hab das jetzt zwar nicht alles kapiert was du da schreibt.
Grundsätzlich gilt..
- Switches via Trunklinks (802.1Q) miteinander verbinden. Der Trunklink ist eine Art "Brücke" über die beliebige mit VLAN-ID getaggte Frames wandern können.
- das "native VLAN" sollte an beiden Enden eines Trunklinks das gleiche sein (per default ist das VLAN 1)
- weiss garnicht ob all die involvierten Switchmodelle bei Trunklinks überhaupt ein untagged vlan verwenden, bzw. kann sein dass da alle frames getaggt werden, egal zu welchem vlan sie gehören
Grundsätzlich gilt..
- Switches via Trunklinks (802.1Q) miteinander verbinden. Der Trunklink ist eine Art "Brücke" über die beliebige mit VLAN-ID getaggte Frames wandern können.
- das "native VLAN" sollte an beiden Enden eines Trunklinks das gleiche sein (per default ist das VLAN 1)
- weiss garnicht ob all die involvierten Switchmodelle bei Trunklinks überhaupt ein untagged vlan verwenden, bzw. kann sein dass da alle frames getaggt werden, egal zu welchem vlan sie gehören
Ja, diese "gewixten Strukturen" sollte man mal von den Herrschaften administrieren lassen, die denken an grundlegender Infrastruktur sparen zu müssen.
Für jeden Pappel-Heinz-Manager hat man gut und gerne 80.000€ Gehalt im jahr in petto - für die Infrastruktur will man aber nix ausgeben.
Aber ich fürchte das ist ein anderes Thema.
Für jeden Pappel-Heinz-Manager hat man gut und gerne 80.000€ Gehalt im jahr in petto - für die Infrastruktur will man aber nix ausgeben.
Aber ich fürchte das ist ein anderes Thema.
Dein "Workaround" zeigt ja ganz klar das die Hirschmann Switches ein Problem haben mit dem Trunk Link, bzw. dort der Traffic nicht übertragen wird.
Der Grund kann daran liegen das der IEEE 802.1q Standard zwar vorschreibt das Default VLAN immer untagged auf dem Trunk parallel zu übertragen aber sich nicht alle Hersteller daran halten sofern auf diesem Port auch noch VLANs tagged übertragen werden.
Vermutlich ist Hirschmann so ein Kandidat. Oder....Entensys oder Juniper auf der anderen Seite. Das gilt es herauszufinden. Hersteller die dort nicht Standard konform sind haben dann so Kommandos wie "dual-mode" usw. auf den Ports um dies wieder zu korrigieren.
Es kann aber letztlich nur einzig und allein daran liegen, denn dein Design ist zwar etwas "krumm" sollte aber so sauber funktionieren.
Hier nochmal für "spacy" zum besseren Verständnis
Besser und sauberer wären in jedem Fall aber auch tagged Links auf dem Hirschmann aufzusetzen.
Häng einen Wireshark Sniffer in den Link zwischen die Hirschmänner wo du jetzt den Workaround dranhast. Dann siehst d sofort wo das Problem ist !
Der Grund kann daran liegen das der IEEE 802.1q Standard zwar vorschreibt das Default VLAN immer untagged auf dem Trunk parallel zu übertragen aber sich nicht alle Hersteller daran halten sofern auf diesem Port auch noch VLANs tagged übertragen werden.
Vermutlich ist Hirschmann so ein Kandidat. Oder....Entensys oder Juniper auf der anderen Seite. Das gilt es herauszufinden. Hersteller die dort nicht Standard konform sind haben dann so Kommandos wie "dual-mode" usw. auf den Ports um dies wieder zu korrigieren.
Es kann aber letztlich nur einzig und allein daran liegen, denn dein Design ist zwar etwas "krumm" sollte aber so sauber funktionieren.
Hier nochmal für "spacy" zum besseren Verständnis
Besser und sauberer wären in jedem Fall aber auch tagged Links auf dem Hirschmann aufzusetzen.
Häng einen Wireshark Sniffer in den Link zwischen die Hirschmänner wo du jetzt den Workaround dranhast. Dann siehst d sofort wo das Problem ist !
Ja zwingend wenn sie das default VLAN nicht gleichzeitig untagged auf Trunks legen. Das müsste im Manual stehen wie die Switches sich da verhalten !
Vermutlich ist das das Problem. Entensys ist da auch nicht stanndardkonform !
Sprechen die Switches irgend eine Art von Spanning Tree. Entensys kann nur das Single Span Verfahren. Wenn der Hirschmann PVST macht kann das auch ein Problem sein...vermutlich kann der Hirschmann das aber auch nicht so das es eher nicht STP ist.
Wireshark bringt da sofort Licht ins Dunkel !
Vermutlich ist das das Problem. Entensys ist da auch nicht stanndardkonform !
Sprechen die Switches irgend eine Art von Spanning Tree. Entensys kann nur das Single Span Verfahren. Wenn der Hirschmann PVST macht kann das auch ein Problem sein...vermutlich kann der Hirschmann das aber auch nicht so das es eher nicht STP ist.
Wireshark bringt da sofort Licht ins Dunkel !