5
Wake-On-LAN-Pakete bei Port-Mirroring eines Switches aufzeichnen
Hallo zusammen,
ich hätte eine Frage zum Port-Mirroring eines Switches. Konrekt geht es um den Switch HP 1810G-48G (Gigabit-Switch).
Ich überwache aus Diagnose-Zwecken einen einzelnen Port (Port 1, Rx und Tx) und gebe diesen auf Port 48 aus. Dort hängt ein Laptop mit Wireshark zum Aufzeichnen.
Den Datenverkehr kann ich auch soweit problemlos mitschneiden, allerdings kommen Wake-On-LAN-Pakete (WOL) nicht auf Port 48 an. WOL-Pakete sind ja bekanntlich Broadcast-Pakete auf IP-Ebene (Schicht 3 im ISO/OSI-Modell) und Ethernet-Ebene (Schicht 2 im ISO/OSI-Modell).
Werden also Broadcast-Pakete generell nicht bei einem Port-Mirroring auf dem gewünschten Port 48 ausgegeben? Oder liegt das Problem eher in der Netzwerkkarte des Laptops? Soll heißen: das Paket wird korrekt am Port 48 ausgegeben und liegt auf der Leitung, das Paket wird aber nicht vom Treiber der Netzwerkkarte an Wireshark übergeben?
Im Übrigen: der Rechner weckt problemlos auf. Das Paket muss also vorhanden sein.
Besten Dank im Voraus
ich hätte eine Frage zum Port-Mirroring eines Switches. Konrekt geht es um den Switch HP 1810G-48G (Gigabit-Switch).
Ich überwache aus Diagnose-Zwecken einen einzelnen Port (Port 1, Rx und Tx) und gebe diesen auf Port 48 aus. Dort hängt ein Laptop mit Wireshark zum Aufzeichnen.
Den Datenverkehr kann ich auch soweit problemlos mitschneiden, allerdings kommen Wake-On-LAN-Pakete (WOL) nicht auf Port 48 an. WOL-Pakete sind ja bekanntlich Broadcast-Pakete auf IP-Ebene (Schicht 3 im ISO/OSI-Modell) und Ethernet-Ebene (Schicht 2 im ISO/OSI-Modell).
Werden also Broadcast-Pakete generell nicht bei einem Port-Mirroring auf dem gewünschten Port 48 ausgegeben? Oder liegt das Problem eher in der Netzwerkkarte des Laptops? Soll heißen: das Paket wird korrekt am Port 48 ausgegeben und liegt auf der Leitung, das Paket wird aber nicht vom Treiber der Netzwerkkarte an Wireshark übergeben?
Im Übrigen: der Rechner weckt problemlos auf. Das Paket muss also vorhanden sein.
Besten Dank im Voraus
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: 204750
Url: https://administrator.de/contentid/204750
Ausgedruckt am: 22.11.2024 um 14:11 Uhr
5 Kommentare
Neuester Kommentar
Hi Willy,
Also WOL ist kein Layer 3 Protokoll!
Ein gespiegelter Port sollte es ausgeben können.
Die einzigen Pakete, die bewußt nicht weiter gegeben werden sind kaputte, also welche mit CRC-Fehler. Der Rest wird nicht überprüft, darf nur in Grenzen überprüft werden.
Aber ein WOL Paket kann man auch an jedem anderen Port messen.
Es ist aber denkbar, dass beim Portspiegeln noch andere Parameter gesetzt werden können / müssen. Bei den kleinen Procurves Handbuch 1810G sollte höchsten bei Überbuchung ein Problem am Mirrorport auftreten. Überbuchung kann auch am Eingang vom Wireshark stattfinden.
Setze mal die Zähler (auf dem Switchinterface) zurück und vergleich die Anzahl der Pakete mit denen des Wireshark. Solange die Station nicht aufgewacht ist, dürfte sich nicht viel tun, danach ...
Aber es stellt sich noch die Frage ob WOL Pakete im Betriebssystem zu sehen sind. Teste das einfach mit dem Wireshark Rechner als Ziel.
GRuß
Netman
Also WOL ist kein Layer 3 Protokoll!
Ein gespiegelter Port sollte es ausgeben können.
Die einzigen Pakete, die bewußt nicht weiter gegeben werden sind kaputte, also welche mit CRC-Fehler. Der Rest wird nicht überprüft, darf nur in Grenzen überprüft werden.
Aber ein WOL Paket kann man auch an jedem anderen Port messen.
Es ist aber denkbar, dass beim Portspiegeln noch andere Parameter gesetzt werden können / müssen. Bei den kleinen Procurves Handbuch 1810G sollte höchsten bei Überbuchung ein Problem am Mirrorport auftreten. Überbuchung kann auch am Eingang vom Wireshark stattfinden.
Setze mal die Zähler (auf dem Switchinterface) zurück und vergleich die Anzahl der Pakete mit denen des Wireshark. Solange die Station nicht aufgewacht ist, dürfte sich nicht viel tun, danach ...
Aber es stellt sich noch die Frage ob WOL Pakete im Betriebssystem zu sehen sind. Teste das einfach mit dem Wireshark Rechner als Ziel.
GRuß
Netman
Danke sehr für deine Antwort.
Mir ist schon klar, dass WOL kein Layer-3-Protokoll ist, sondern einfach nur eine magische Zahlenfolge, die in einem Ethernet-Frame enthalten sein muss. Trotzdem wird diese magische Zahlenfolge in ein IP-Paket eingebettet (encapsulation). Ziel auf Layer-3 ist 255.255.255.255 und auf Layer-2 FF:FF:FF:FF:FF:FF. Das ganze wird (mit meinem Tool hier) auch noch in ein UDP-Paket verwurstet.
Den Rest deiner Vorschläge werde ich gleich testen.
(Das eigentliche Problem ist aber eh ganz anders gelagert. Das Problem ist: wenn ich diesen Server am Switch betreibe und herunterfahre, dann geht die Kiste gleich wieder an. Die Netzwerkkarte ist aber so konfiguriert, dass dies nur bei einem Magic Packet passieren sollte. Deshalb mein Versuch, am Port zu lauschen, um zu sehen, was da passiert. Diesen Verhalten tritt aber nur auf (sogar reproduzierbar), wenn ich den Rechner zuvor per WOL aufgeweckt habe. Mach ich die Kiste mit dem Hardware-Schalter an und fahr den Rechner anschließend runter, geht der Rechner nicht wieder von alleine an. Höchst merkwürdig. NIC ist folgende: Intel Corporation 82574L Gigabit Network Connection).
Mir ist schon klar, dass WOL kein Layer-3-Protokoll ist, sondern einfach nur eine magische Zahlenfolge, die in einem Ethernet-Frame enthalten sein muss. Trotzdem wird diese magische Zahlenfolge in ein IP-Paket eingebettet (encapsulation). Ziel auf Layer-3 ist 255.255.255.255 und auf Layer-2 FF:FF:FF:FF:FF:FF. Das ganze wird (mit meinem Tool hier) auch noch in ein UDP-Paket verwurstet.
Den Rest deiner Vorschläge werde ich gleich testen.
(Das eigentliche Problem ist aber eh ganz anders gelagert. Das Problem ist: wenn ich diesen Server am Switch betreibe und herunterfahre, dann geht die Kiste gleich wieder an. Die Netzwerkkarte ist aber so konfiguriert, dass dies nur bei einem Magic Packet passieren sollte. Deshalb mein Versuch, am Port zu lauschen, um zu sehen, was da passiert. Diesen Verhalten tritt aber nur auf (sogar reproduzierbar), wenn ich den Rechner zuvor per WOL aufgeweckt habe. Mach ich die Kiste mit dem Hardware-Schalter an und fahr den Rechner anschließend runter, geht der Rechner nicht wieder von alleine an. Höchst merkwürdig. NIC ist folgende: Intel Corporation 82574L Gigabit Network Connection).
Das ist technisch nicht ganz richtig ! In der Tat nutzen WoL Pakete weitverbreitet auch UDP mit Port 9 (Discard)
Siehe: http://www.heise.de/netze/artikel/Port-Forwarding-224180.html
Damit ist das dann de facto IP !
So oder so ob IP oder nicht gehen solche Pakete (Broadcasts sowieso) IMMER an einem Mirror Port raus sofern natürlich an dem Ursprungs Port (der, der gemirrort wird) ein WoL Paket ankommt.
Es mag sein das du den Mirror falsch konfiguriert hast. Fast alle Switche lassen die Mirror Direction zu in der Konfig also ob das ein incoming oder outgoing Paket ist oder ob Bidirectional gemirrort werden soll (Both) !
Hast du das natürlich nicht auf "Both" stehen siehst du nur die Hälfte der Pakete...logo !
Kann natürlich auch sein das die HP Billiggurke einen Firmware Bug hat...
Neueste Firmware hast du auf den Switch geflasht ??
Genauso bei der NIC, da solltest du du immer die Treiber direkt von Intel nehmen !!
Siehe: http://www.heise.de/netze/artikel/Port-Forwarding-224180.html
Damit ist das dann de facto IP !
So oder so ob IP oder nicht gehen solche Pakete (Broadcasts sowieso) IMMER an einem Mirror Port raus sofern natürlich an dem Ursprungs Port (der, der gemirrort wird) ein WoL Paket ankommt.
Es mag sein das du den Mirror falsch konfiguriert hast. Fast alle Switche lassen die Mirror Direction zu in der Konfig also ob das ein incoming oder outgoing Paket ist oder ob Bidirectional gemirrort werden soll (Both) !
Hast du das natürlich nicht auf "Both" stehen siehst du nur die Hälfte der Pakete...logo !
Kann natürlich auch sein das die HP Billiggurke einen Firmware Bug hat...
Neueste Firmware hast du auf den Switch geflasht ??
Genauso bei der NIC, da solltest du du immer die Treiber direkt von Intel nehmen !!
Ich versuche mich kurz zu halten:
Mirror steht auf "Rx and Tx", sollte daher dein angesprochenes "Both" sein.
Firmware auf dem HP habe ich die aktuelleste Version laufen. Getestet auch mit einer älteren Firmware. Das Ding kann zwei Firmwares verwalten, zwischnen denen man hin- und herspringen kann. Beides keine Veränderung.
Treiber von Intel habe ich auch die neuesten probiert und einen uralten. Alle von der Intel-Website und selbst kompiliert.
Es kommt selten vor, aber hier weiß ich nicht mehr weiter.
Warum startet der Rechner sofort wieder, wenn ich den mit "shutdown -h 0" unter Linux runterfahre? Und das auch nur, wenn ich ihn zuvor per WOL aufgeweckt habe. Sehr dubios die Geschichte
Mirror steht auf "Rx and Tx", sollte daher dein angesprochenes "Both" sein.
Firmware auf dem HP habe ich die aktuelleste Version laufen. Getestet auch mit einer älteren Firmware. Das Ding kann zwei Firmwares verwalten, zwischnen denen man hin- und herspringen kann. Beides keine Veränderung.
Treiber von Intel habe ich auch die neuesten probiert und einen uralten. Alle von der Intel-Website und selbst kompiliert.
Es kommt selten vor, aber hier weiß ich nicht mehr weiter.
Warum startet der Rechner sofort wieder, wenn ich den mit "shutdown -h 0" unter Linux runterfahre? Und das auch nur, wenn ich ihn zuvor per WOL aufgeweckt habe. Sehr dubios die Geschichte
Wenn es also Linux ist, dann gibt es doch auch Log-Dateien, die man vergleichen kann.
Also WOL Start und Normalstart vergleichen.
Und WOL Pakete solltes du auch ohne Spiegelung sehen können, wenn die Station so lange aus ist, dass die MAC nicht mehr bekannt ist.
Dann hast du auch hier den Vergleich ob Wireshark dir was vorenthält oder ob es am Serverport eigenartig ist.
Ist jetzt halt eine Indiziensuche...
Also WOL Start und Normalstart vergleichen.
Und WOL Pakete solltes du auch ohne Spiegelung sehen können, wenn die Station so lange aus ist, dass die MAC nicht mehr bekannt ist.
Dann hast du auch hier den Vergleich ob Wireshark dir was vorenthält oder ob es am Serverport eigenartig ist.
Ist jetzt halt eine Indiziensuche...
