5
HP Procurve und Cisco Wake on LAN Problem nach Firmware Update
Hallo miteinandern,
Ich habe ein Problem mit Wake On lan bei uns in der Netzwerkumgebung die sich wie folgt darstellt
Cisco 4500 als Core Switch , IP-routing, VLAN Database ect ----> Trunk(802.1Q) zum nächsten Cisco 3750-X ---> Etherchannel( Link aggregation 2x1GB) weiter zu einem HP 6200-yl [J8992A] ----> [Link aggregation 2x1GB] weiter zu einem HP 2910al [J9147A] ---> und von dahin dann an ca 20 Clients in einem Raum.
Bis zuletzt lief alles wie es sollte , nur habe ich nach einem Firmware update des letesten switches (HP2910al) das Problem dass WOL nicht mehr funktioniert, ich habe auf einem Monitor Port
mitgelesen und das UDP Paket (7) kommt nicht einmal auf dem Switch an
auf dem LWL switch also dem HP 6200yl sind noch mehrer Cisco switche angeschlossen an denen wieder ca 20 clients hänger, da funktioniert das WOL ohne Probleme
auch wenn ich am Core switch mir das VLAN spiegele sehe ich dass das von mir gesendete UDP Paket ( 7 ) auch in dem VLAN ankommt.
Somit muss es ja am letzten switch liegen, ich verstehe aber nicht woran?! In den Release Notes stand dass die WOL funktion verbesser wurde .......( eher nicht)
ich möchte ungern auf einer ältere Firmware version wechseln müssen , glaube aber nur dass ich den Wald vor lauter Bäumen schon nicht mehr sehe
auf dem core switch ( der auch inter VLAN routing macht ) ist ip-directed broadcas aktiv und wol funktioniert an sich , nur eben nicht bei dem einen switch
HP 6200yl version ----> K.15.17.0008, ROM K.15.30
HP 2910al version ----> W.15.14.0012, ROM W.14.06
Etherchannel(Hp sagt trunk dazu ) stehen auf Group: Trk1 Type: Trunk
bin für jede Hilfe, jeden Kommentar dankbar
gruß
Wolle
Ich habe ein Problem mit Wake On lan bei uns in der Netzwerkumgebung die sich wie folgt darstellt
Cisco 4500 als Core Switch , IP-routing, VLAN Database ect ----> Trunk(802.1Q) zum nächsten Cisco 3750-X ---> Etherchannel( Link aggregation 2x1GB) weiter zu einem HP 6200-yl [J8992A] ----> [Link aggregation 2x1GB] weiter zu einem HP 2910al [J9147A] ---> und von dahin dann an ca 20 Clients in einem Raum.
Bis zuletzt lief alles wie es sollte , nur habe ich nach einem Firmware update des letesten switches (HP2910al) das Problem dass WOL nicht mehr funktioniert, ich habe auf einem Monitor Port
mitgelesen und das UDP Paket (7) kommt nicht einmal auf dem Switch an
auf dem LWL switch also dem HP 6200yl sind noch mehrer Cisco switche angeschlossen an denen wieder ca 20 clients hänger, da funktioniert das WOL ohne Probleme
auch wenn ich am Core switch mir das VLAN spiegele sehe ich dass das von mir gesendete UDP Paket ( 7 ) auch in dem VLAN ankommt.
Somit muss es ja am letzten switch liegen, ich verstehe aber nicht woran?! In den Release Notes stand dass die WOL funktion verbesser wurde .......( eher nicht)
ich möchte ungern auf einer ältere Firmware version wechseln müssen , glaube aber nur dass ich den Wald vor lauter Bäumen schon nicht mehr sehe
auf dem core switch ( der auch inter VLAN routing macht ) ist ip-directed broadcas aktiv und wol funktioniert an sich , nur eben nicht bei dem einen switch
HP 6200yl version ----> K.15.17.0008, ROM K.15.30
HP 2910al version ----> W.15.14.0012, ROM W.14.06
Etherchannel(Hp sagt trunk dazu ) stehen auf Group: Trk1 Type: Trunk
bin für jede Hilfe, jeden Kommentar dankbar
gruß
Wolle
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: 288406
Url: https://administrator.de/contentid/288406
Ausgedruckt am: 22.11.2024 um 08:11 Uhr
5 Kommentare
Neuester Kommentar
Es ist sehr außergewöhnlich das dein WoL UDP Port 7 (Echo) benutzt ?! In der Regel nutzen alle WoL Programme durch die Bank UDP Port 9 (Discard) auf das auch alle Endgeräte entsprechend reagieren.
Das solltest du auf alle Fälle nochmal genauer checken.
Wenn allerdings schon erst gar kein WoL Paket vom Sender mehr am Switch ankommt, dann kann es ja logischerweise niemals am Switch selber liegen, denn wie sollte der Switch auch was forwarden wenn schon gar nichts bei ihm ankommt ?! Das wäre ja dann ein Wunder...
Hier musst du also mal sehen was der WoL Sender da macht wenn der gar keine WoL Pakete sendet !!
Wireshark ist hier wie immer dein Freund !
Cisco macht im Default PVSTP+ eine Spanning Tree Variante die Billigheimer HP nicht versteht und nicht supportet !!!
Wenn du also ein redundantes Netz hast, solltest du den Cisco bzw. ALLE Ciscos und auch deinen HP Gurken in jedem Falle auf MSTP umschalten. Das verstehen dann auch beide Seiten !
HP kann nur den billigen Single Span Prozess den die Ciscos wiederum nicht können !
MSTP ist hier also das kleinste gemeinsame Vielfache. Ansonsten kann es zu zufälligen Blockings im STP kommen, da beide Switche inkompatible Spanning Tree protokolle sprechen mit genau solchen Effekten die du siehst !
Hast du das bedacht bei der Konfig deiner Komponenten ???
Generell ist es auch völlig egal ob WoL oder was auch immer. Der Switch entscheidet rein nach Mac Adresse wohin das Forwarding geht !
Auch ob UDP 7 oder UDP 9 oder egal welcher Port spielt keinerlei Rolle.
Für die Forwarding Entscheidung des Switches ist REIN die Destination Mac Adresse im Ethernet Paket relevant !! Das gilt für HP und auch für Cisco.
Nutzt WoL IP Pakete mit UDP Ports ist die Ziel IP immer eine ALL Net Broadcast IP 255.255.255.255 bei der dann entsprechend alle 48 Bits der Mac Adresse auf 1 gesetzt sind im Layer 2 Teil des Pakets (ff-ff-ff-ff-ff-ff)
Das wird dir auch dein Wireshark zeigen.
Solche All Net Broadcast MUSS der Switch auf alle Ports in einem VLAN fluten also parallel aussenden.
Es ist schon zeimlich zweifelhaft das ein Hersteller ein Update rausgibt das solch ein grundlegendes Ethernet Verhalten fehlerhaft macht und damit die gesamte Ethernet Kommunikation in einem Netzwerk gefährdet.
Solche Basisc Tests macht jeder Hersteller bevor er ein Firmware Release veröffentlicht.
In sofern kann man wohl zu 98% bezweifeln das deine Vermutung stimmt und das Problem ganz sicher woanders suchen. Z.B. an einer fehlerhaften Spanning Tree Konfig in Multi Vendor Netzen !
Das solltest du auf alle Fälle nochmal genauer checken.
Wenn allerdings schon erst gar kein WoL Paket vom Sender mehr am Switch ankommt, dann kann es ja logischerweise niemals am Switch selber liegen, denn wie sollte der Switch auch was forwarden wenn schon gar nichts bei ihm ankommt ?! Das wäre ja dann ein Wunder...
Hier musst du also mal sehen was der WoL Sender da macht wenn der gar keine WoL Pakete sendet !!
Wireshark ist hier wie immer dein Freund !
auf dem LWL switch also dem HP 6200yl sind noch mehrer Cisco switche angeschlossen
Oha....das ist tödlich !Cisco macht im Default PVSTP+ eine Spanning Tree Variante die Billigheimer HP nicht versteht und nicht supportet !!!
Wenn du also ein redundantes Netz hast, solltest du den Cisco bzw. ALLE Ciscos und auch deinen HP Gurken in jedem Falle auf MSTP umschalten. Das verstehen dann auch beide Seiten !
HP kann nur den billigen Single Span Prozess den die Ciscos wiederum nicht können !
MSTP ist hier also das kleinste gemeinsame Vielfache. Ansonsten kann es zu zufälligen Blockings im STP kommen, da beide Switche inkompatible Spanning Tree protokolle sprechen mit genau solchen Effekten die du siehst !
Hast du das bedacht bei der Konfig deiner Komponenten ???
Generell ist es auch völlig egal ob WoL oder was auch immer. Der Switch entscheidet rein nach Mac Adresse wohin das Forwarding geht !
Auch ob UDP 7 oder UDP 9 oder egal welcher Port spielt keinerlei Rolle.
Für die Forwarding Entscheidung des Switches ist REIN die Destination Mac Adresse im Ethernet Paket relevant !! Das gilt für HP und auch für Cisco.
Nutzt WoL IP Pakete mit UDP Ports ist die Ziel IP immer eine ALL Net Broadcast IP 255.255.255.255 bei der dann entsprechend alle 48 Bits der Mac Adresse auf 1 gesetzt sind im Layer 2 Teil des Pakets (ff-ff-ff-ff-ff-ff)
Das wird dir auch dein Wireshark zeigen.
Solche All Net Broadcast MUSS der Switch auf alle Ports in einem VLAN fluten also parallel aussenden.
Es ist schon zeimlich zweifelhaft das ein Hersteller ein Update rausgibt das solch ein grundlegendes Ethernet Verhalten fehlerhaft macht und damit die gesamte Ethernet Kommunikation in einem Netzwerk gefährdet.
Solche Basisc Tests macht jeder Hersteller bevor er ein Firmware Release veröffentlicht.
In sofern kann man wohl zu 98% bezweifeln das deine Vermutung stimmt und das Problem ganz sicher woanders suchen. Z.B. an einer fehlerhaften Spanning Tree Konfig in Multi Vendor Netzen !
Hi aqui
Vielen dank für deinen Beitrag und deine infos das mit UDP 9 werde ich auf jeden Fall nochmal checken.
Pvst+ ja ich glaub das kann der HP wirklich nicht. Der kann nur STP oder rapid STP was aber nicht pvst+ ist oder?
Evtl sollte ich da meine config nochmal checken vielleicht liegt am Spannung treue .... Wobei es bei anderen switchen und anderen vlans auch klappt ...
Vielen dank für deinen Beitrag und deine infos das mit UDP 9 werde ich auf jeden Fall nochmal checken.
Pvst+ ja ich glaub das kann der HP wirklich nicht. Der kann nur STP oder rapid STP was aber nicht pvst+ ist oder?
Evtl sollte ich da meine config nochmal checken vielleicht liegt am Spannung treue .... Wobei es bei anderen switchen und anderen vlans auch klappt ...
Pvst+ ja ich glaub das kann der HP wirklich nicht.
Glauben heisst nicht wissen....Die Billigteile von HP können das ganz sicher nicht !
Der kann nur STP oder rapid STP was aber nicht pvst+ ist oder?
Richtig.PVST heisst Per Vlan Spanning Tree. Das kann Billigheimer HP generell gar nicht, egal in welcher Ausprägung. Die + Version ist so oder so Cisco proprietär die nur wenige andere Hersteller supporten. Dazu gehört HP aber definitiv nicht !
HP beherrscht nur das steinzeitliche Single Span Verfahren. Also einen einzigen globalen Spanning Tree für alle VLANs und das ist nicht kompatibel mit dem Cisco PVSTP+ und fürht zu unkontrollierten Link Blockings usw.
Dein einziger Ausweg ist hier eine saubere MSTP Konfiguration, denn das verstehen beide Seiten.
Dazu musst du aber auch beide Seiten entsprechend konfigurieren, was aber kinderleicht ist.
Oder natürlich du verzichtest ganz auf STP irgendeiner Art und verzichtest damit auf Redundanz. In einem redundanten Netzwerk ist das aber tödlich. Wenn du keine Redundanz hast ist es egal...
Wobei es bei anderen switchen und anderen vlans auch klappt ...
Weil du es da vermutlich nicht oder auch falsch konfiguriert hast oder keine redundanz hast.Du solltest in der Tat zwingend deine Konfig checken und das glatt ziehen. Das löst mit 98%er Sicherheit auch das problem.
Guten Morgen aqui,
also MSTP auf HP und auf Cisco einrichten, dass wäre die beste lösung. So Verstanden.
Ich hab hierzu den ProCurve & Cisco Spanning Tree Interoperability Guide gefuden, kennst du den?
Ich habe nur an einzelnen Stellen in meinem Netzwerk Redundante anbindungen ( ausfallsicherheit oder Etherchannel )
Ganz Dumm gefragt, kann ich an den stellen an denen ich Spanning Tree nicht "brauche" es einfach abschalten? Macht das Sinn? ( ..... ne oder ?)
also MSTP auf HP und auf Cisco einrichten, dass wäre die beste lösung. So Verstanden.
Ich hab hierzu den ProCurve & Cisco Spanning Tree Interoperability Guide gefuden, kennst du den?
Ich habe nur an einzelnen Stellen in meinem Netzwerk Redundante anbindungen ( ausfallsicherheit oder Etherchannel )
Ganz Dumm gefragt, kann ich an den stellen an denen ich Spanning Tree nicht "brauche" es einfach abschalten? Macht das Sinn? ( ..... ne oder ?)
Ich hab hierzu den ProCurve & Cisco Spanning Tree Interoperability Guide gefuden, kennst du den?
Kenn ich noch nicht, aber der dürfte das gleiche erzählen das MSTP die gemeinsame Lingua franca zwischen beiden ist, richtig ?Ist der auf den HP Seiten zu finden ?
Ich habe nur an einzelnen Stellen in meinem Netzwerk Redundante anbindungen
Das ist egal... Sowie du nur eine einzige hast ist STP erforderlich um eine Loopbildung zu verhindern !Ganz Dumm gefragt, kann ich an den stellen an denen ich Spanning Tree nicht "brauche" es einfach abschalten? Macht das Sinn?
Dumme Fragen gibts nicht, nur dumme Antworten 
Nein, das macht keinerlei Sinn. Theoretisch ist es machbar. Diese Komponenten die kein STP machen schleifen es dann nur durch, sprich forwarden dann nur die STP Pakete.
Das ist kontraproduktiv, da sie dann aktiv am STP Prozess nicht mehr teilnehmen und das Blocking Verhalten dann unkontrollierbar wird. STP ist immer eine Point to Point Beziehung !
Fazit: Es macht keinen Sinn und sollte man nicht machen. Besser es konsequent auf allen Switches einsetzen egal ob sie Redundanzen bedienen oder nicht !
