6
VLAN Problem - Pakete kommen trotz VLAN Abgrenzung von VLAN1 zu VLAN2
Ich Nutze und Administriere ein Netzwerk zur Lichtsteuerung in Fernsehstudios.
Aufbau:
Wir haben neun Switche von HP (2626 und 2510 und 2610)
Es sind 4 Portbasierte VLANs eingerichtet.
Problem:
Nun kam es zu Problemen in der Lichtsteuerung. Der Hersteller behauptet, dass an unserem Netzwerk liegt.
Daraufhin haben wir uns mit Wireshark das LAN mal angeschaut.
Tatsächlich werden Pakete von einem VLAN sichtbar die da nicht sein dürfen.
Beschreibung:
Die Software WinDFB von Transtechnik fragt über VLAN1 den Status von Dimmerprozessoren ab.
WinDFB läuft auf einem Windows XP PC.
In diesem werden 3 NICs eingesetzt.
NIC1 für VLAN1 (Lichtsteuerung der Transtechnik Welt)
NiC2 für VLAN2 (Lichtsteuerung der MAlighting Welt)
NIC3 für den Backbone zur Konfiguration der Switche
Der Software WinDFB ist die NIC1 zugeordnet.
Die Software arbeitet auch super. Im VLAN1 sind auch nur Pakete des IP-Adressraums 192.9.200.x
Es kommen aber auch diese Pakete im VLAN2 an! Wieso?
Schalte ich NIC2 aus ist alles OK. Oder schalte ich WinDFB aus ist auch alles OK.
Warum blagt die Sotware in zwei Netzwerkarten obwohl sie nur einer zugeordnet ist?
Habe ich da Hardwaremäßig einen Fehler gemacht?
Alle Geräte haben eine feste IP. Es gibt auch keine Brücke die gesteckt wurde.
Ein Ping von VLAN1 zu 2 kommt auch nicht an.
Ich sollte doch 3 NICs in einem PC mit verschiedennen IP-Adressräumen betreiben können.
Zumindest lief die Anlage über 1,5 Jahre Problemlos.
Hoffe meine Ausführungen waren verständlich. Danke für eure Zeit und Geduld.
Matzemalzier
Aufbau:
Wir haben neun Switche von HP (2626 und 2510 und 2610)
Es sind 4 Portbasierte VLANs eingerichtet.
Problem:
Nun kam es zu Problemen in der Lichtsteuerung. Der Hersteller behauptet, dass an unserem Netzwerk liegt.
Daraufhin haben wir uns mit Wireshark das LAN mal angeschaut.
Tatsächlich werden Pakete von einem VLAN sichtbar die da nicht sein dürfen.
Beschreibung:
Die Software WinDFB von Transtechnik fragt über VLAN1 den Status von Dimmerprozessoren ab.
WinDFB läuft auf einem Windows XP PC.
In diesem werden 3 NICs eingesetzt.
NIC1 für VLAN1 (Lichtsteuerung der Transtechnik Welt)
NiC2 für VLAN2 (Lichtsteuerung der MAlighting Welt)
NIC3 für den Backbone zur Konfiguration der Switche
Der Software WinDFB ist die NIC1 zugeordnet.
Die Software arbeitet auch super. Im VLAN1 sind auch nur Pakete des IP-Adressraums 192.9.200.x
Es kommen aber auch diese Pakete im VLAN2 an! Wieso?
Schalte ich NIC2 aus ist alles OK. Oder schalte ich WinDFB aus ist auch alles OK.
Warum blagt die Sotware in zwei Netzwerkarten obwohl sie nur einer zugeordnet ist?
Habe ich da Hardwaremäßig einen Fehler gemacht?
Alle Geräte haben eine feste IP. Es gibt auch keine Brücke die gesteckt wurde.
Ein Ping von VLAN1 zu 2 kommt auch nicht an.
Ich sollte doch 3 NICs in einem PC mit verschiedennen IP-Adressräumen betreiben können.
Zumindest lief die Anlage über 1,5 Jahre Problemlos.
Hoffe meine Ausführungen waren verständlich. Danke für eure Zeit und Geduld.
Matzemalzier
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 149331
Url: https://administrator.de/contentid/149331
Ausgedruckt am: 26.11.2024 um 11:11 Uhr
6 Kommentare
Neuester Kommentar
Sendest du den ping wenn nur eine NIC eingeschaltet ist?
Wie sind die IPs der unterschiedlichen VLANs?
von welchem punkt hast du Wireshark angesetzt?
Ich weis die Frage ist eigentlich selbstverständlich, aber, Config gespeichert, switch neu gestartet?
Ich könnte höchstens eine Vermutung anstellen, das es zwar möglich ist, dem Programm eine abhörende Netzwerkkarte zuzuordnen, aber die sendende sind dann alle 3 .
Bei uns im Server laufen 2 Netzwerkkarten gleichzeitig, aber diese werden mittels VMs unterschiedlich getrennt voneinander angesprochen.
Wie sind die IPs der unterschiedlichen VLANs?
von welchem punkt hast du Wireshark angesetzt?
Ich weis die Frage ist eigentlich selbstverständlich, aber, Config gespeichert, switch neu gestartet?
Ich könnte höchstens eine Vermutung anstellen, das es zwar möglich ist, dem Programm eine abhörende Netzwerkkarte zuzuordnen, aber die sendende sind dann alle 3 .
Bei uns im Server laufen 2 Netzwerkkarten gleichzeitig, aber diese werden mittels VMs unterschiedlich getrennt voneinander angesprochen.
Tag,
interessante Kombination! Ein PC, 2 Anwendungen die auf 2 jeweils zugeordnete NICs arbeiten sollen.
Nimm mal das Portbasierte VLAN raus und konfigurier stattdessen deine NICs auf das jeweilige VLAN.
Dann bekommt nämlich das Datenpaket schon von der NIC das entsprechende Tag injiziert und kann an den richtigen Endport weitergeroutet werden.
Alternativ kannst du deine NICs in unterschiedlichen Subnetzen betreiben. Der PC, auf dem deine Anwendungen laufen,
sieht und hört natürlich trotzdem alles...
Wenns garned anders geht mußt halt noch an PC hinstellen oder eine App in ner VM laufen lassen.
interessante Kombination! Ein PC, 2 Anwendungen die auf 2 jeweils zugeordnete NICs arbeiten sollen.
Nimm mal das Portbasierte VLAN raus und konfigurier stattdessen deine NICs auf das jeweilige VLAN.
Dann bekommt nämlich das Datenpaket schon von der NIC das entsprechende Tag injiziert und kann an den richtigen Endport weitergeroutet werden.
Alternativ kannst du deine NICs in unterschiedlichen Subnetzen betreiben. Der PC, auf dem deine Anwendungen laufen,
sieht und hört natürlich trotzdem alles...
Wenns garned anders geht mußt halt noch an PC hinstellen oder eine App in ner VM laufen lassen.
Danke für die Vorschläge.
Dieser PC hat eigentlich noch mehr Funktionen:
- Dimmerstatus der Transtechnik Dimmer
- Konfigurtions PC für die HP Switche per Webinterface oder TelNet
- Backupziel für Showfiles von einen FTP-Server
- Per Ping werden sämtliche Netzwerkteinehmer überwacht
Die NICs sind billige Realtek Dinger. Da ist nix mit VLAN schon am PC losschicken.
Hatte auch meine Bedenken ob das alles miteinander läuft. Ging aber über Eineinhalb Jahre gut.
Nun haben wir vor einem Monat ein Firmwareupdates der MAlighting Geräte eingespielt und nun kommt es unregelmäßig zu Fehlern.
Zunächst sah es so aus als wäre das Update schuld weil die Fehler nech dem Update aufgetreten sind.
Also lerne ich daraus, es kann mit drei NICs in einem PC in drei VLANs funktionieren, muss aber nicht.
Zur Zeit haben wir zwei PCs eingerichtet und haben eine saubere Trennung.
Wir werden in den nächsten Wochen sehen ob der Fehler wieder auftritt.
Wäre über VMs eine saubere Trennung auf einem PC möglich?
Vielen Dank, Matzmalzbier.
Dieser PC hat eigentlich noch mehr Funktionen:
- Dimmerstatus der Transtechnik Dimmer
- Konfigurtions PC für die HP Switche per Webinterface oder TelNet
- Backupziel für Showfiles von einen FTP-Server
- Per Ping werden sämtliche Netzwerkteinehmer überwacht
Die NICs sind billige Realtek Dinger. Da ist nix mit VLAN schon am PC losschicken.
Hatte auch meine Bedenken ob das alles miteinander läuft. Ging aber über Eineinhalb Jahre gut.
Nun haben wir vor einem Monat ein Firmwareupdates der MAlighting Geräte eingespielt und nun kommt es unregelmäßig zu Fehlern.
Zunächst sah es so aus als wäre das Update schuld weil die Fehler nech dem Update aufgetreten sind.
Also lerne ich daraus, es kann mit drei NICs in einem PC in drei VLANs funktionieren, muss aber nicht.
Zur Zeit haben wir zwei PCs eingerichtet und haben eine saubere Trennung.
Wir werden in den nächsten Wochen sehen ob der Fehler wieder auftritt.
Wäre über VMs eine saubere Trennung auf einem PC möglich?
Vielen Dank, Matzmalzbier.
Es sind alle an
Wie sind die IPs der unterschiedlichen VLANs?
Backbone = 192.1.1.x
MA-Net = 192.168.0.x
TT-Net = 192.9.200.x
e:cue = 192.16.123.x ist im Switch eingerichtet aber wird z.Z. nicht in Verwendet
ART-Net = 2.2.2.x ist im Switch eingerichtet aber wird z.Z. nicht in Verwendet
von welchem Punkt hast du Wireshark angesetzt?
von dem PC mit den drei NICs. Als Gegentest auch in der Regie auf dem MA-Net
Ich weis die Frage ist eigentlich selbstverständlich, aber, Config gespeichert, switch neu gestartet?
da im Moment der PC mit der WinDFB im Verdacht steht, ist es unwahrscheinlich das ein Switch Schuld hat.
Kann man zur Sicherheit aber mal neu starten...
Ich könnte höchstens eine Vermutung anstellen, das es zwar möglich ist, dem Programm eine abhörende
Netzwerkkarte zuzuordnen, aber die sendende sind dann alle 3 .
Warum sehe ich dann ein Ping nicht mit Wireshark wenn alle frei NICs den Ping senden?
Ich sollte doch durch die verschieden IPs schon eine saubere Trennung haben?
Bei uns im Server laufen 2 Netzwerkkarten gleichzeitig, aber diese werden mittels VMs unterschiedlich getrennt voneinander
angesprochen.
vielen Dank, Matzemalzbier.
Wie sind die IPs der unterschiedlichen VLANs?
MA-Net = 192.168.0.x
TT-Net = 192.9.200.x
e:cue = 192.16.123.x ist im Switch eingerichtet aber wird z.Z. nicht in Verwendet
ART-Net = 2.2.2.x ist im Switch eingerichtet aber wird z.Z. nicht in Verwendet
von welchem Punkt hast du Wireshark angesetzt?
Ich weis die Frage ist eigentlich selbstverständlich, aber, Config gespeichert, switch neu gestartet?
Kann man zur Sicherheit aber mal neu starten...
Ich könnte höchstens eine Vermutung anstellen, das es zwar möglich ist, dem Programm eine abhörende
Netzwerkkarte zuzuordnen, aber die sendende sind dann alle 3 .
Ich sollte doch durch die verschieden IPs schon eine saubere Trennung haben?
Bei uns im Server laufen 2 Netzwerkkarten gleichzeitig, aber diese werden mittels VMs unterschiedlich getrennt voneinander
angesprochen.
vielen Dank, Matzemalzbier.
Die fremden Pakete können eigentlich nur über ein Backdoor Bridge kommen indem 2 Ports falsch gesteckt worden sind oder z.B. über einen 5 Port Billigswitch verbunden sind.
Eigentlich kannst du das aber ganz einfach rausbekommen mit dem Wireshark, denn du musst ja bei diesem Paket ja einfach und simpel nur auf die Absender IP Adresse sehen !
Damit hast du den bösen Buhmann ja der dieses Paket ins falsche VLAN sendet und kannst den Weg weiterverfolgen.
Du kannst sogar die Absender MAC Adresse sehen und über die Mac Database des Switches herausbekommen zu welchem Port und welchem VLAN das gehört. Damit kannst du diesen Port überprüfen ob der korrekt gesteckt ist und nicht gebridged.
Intern forwarden die Switches niemals Pakete zwischen den VLANs, die sind vollständig isoliert.
Was auch sein kann ist das du ggf. Routing aktiviert hast auf dem Server mit den 3 NICs. Das wäre natürlich fatal, denn dann ist eine Routing Verbindung über diesen Server möglich und dann vollkommen logisch das du diese Pakete aus anderen VLANs siehst.
Generell ist die Lösung mit 3 NICs nicht besonders intelligent. Besser wäre es gewesen dem Server eine tagging fähige Karte zu verpassen und den Uplink vom Server mit einem tagged Link zu machen.
Damit hast du nur einen Draht, sprich Kabel, auf den Switch, bedienst aber alle deine VLANs. Von der Verkabelung ist das erheblich sicherer.
Wie man das ganz einfach macht siehst du mit einem HP Switch Beispiel in diesem Tutorial:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Das Routing darfst du natürlich niemals in der Registry oder im Setup aktivieren um eine Kommunikation über den Server sicher zu unterbinden !
Eigentlich kannst du das aber ganz einfach rausbekommen mit dem Wireshark, denn du musst ja bei diesem Paket ja einfach und simpel nur auf die Absender IP Adresse sehen !
Damit hast du den bösen Buhmann ja der dieses Paket ins falsche VLAN sendet und kannst den Weg weiterverfolgen.
Du kannst sogar die Absender MAC Adresse sehen und über die Mac Database des Switches herausbekommen zu welchem Port und welchem VLAN das gehört. Damit kannst du diesen Port überprüfen ob der korrekt gesteckt ist und nicht gebridged.
Intern forwarden die Switches niemals Pakete zwischen den VLANs, die sind vollständig isoliert.
Was auch sein kann ist das du ggf. Routing aktiviert hast auf dem Server mit den 3 NICs. Das wäre natürlich fatal, denn dann ist eine Routing Verbindung über diesen Server möglich und dann vollkommen logisch das du diese Pakete aus anderen VLANs siehst.
Generell ist die Lösung mit 3 NICs nicht besonders intelligent. Besser wäre es gewesen dem Server eine tagging fähige Karte zu verpassen und den Uplink vom Server mit einem tagged Link zu machen.
Damit hast du nur einen Draht, sprich Kabel, auf den Switch, bedienst aber alle deine VLANs. Von der Verkabelung ist das erheblich sicherer.
Wie man das ganz einfach macht siehst du mit einem HP Switch Beispiel in diesem Tutorial:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Das Routing darfst du natürlich niemals in der Registry oder im Setup aktivieren um eine Kommunikation über den Server sicher zu unterbinden !
Die Lösung!
Die Software WinDFB von Transtechnik war die Ursache.
Die Brücke in der Software wurde von Transtechnik geschlossen.
Die 3 NIC wurden durch eine VLAN-NIC ersetzt. Ist sauberer
Die Ursache des vermeintlichen Netzwerkfehlers:
MALighting hat ab der Version 6.500 die Macke das nach jeden 12 Upload einer Session sich der NSP „aufhängt“ Hoch in den Dimmerraum und von Hand neustarten, hat man wieder 12 mal Ruhe.
Der Hersteller war vor Ort und hat diesen Fehler aufgespürt. Leider bis heute noch nicht behoben!!!
Der Fehler von MA hat zum aufdecken eines Fehlers von Transtechnik geführt und bewiesen das unser Netzwerk sauber ist!
Tschüs
Die Software WinDFB von Transtechnik war die Ursache.
Die Brücke in der Software wurde von Transtechnik geschlossen.
Die 3 NIC wurden durch eine VLAN-NIC ersetzt. Ist sauberer
Die Ursache des vermeintlichen Netzwerkfehlers:
MALighting hat ab der Version 6.500 die Macke das nach jeden 12 Upload einer Session sich der NSP „aufhängt“ Hoch in den Dimmerraum und von Hand neustarten, hat man wieder 12 mal Ruhe.
Der Hersteller war vor Ort und hat diesen Fehler aufgespürt. Leider bis heute noch nicht behoben!!!
Der Fehler von MA hat zum aufdecken eines Fehlers von Transtechnik geführt und bewiesen das unser Netzwerk sauber ist!
Tschüs
