19
Wake On LAN Probleme im Firmenumfeld mit MAC Authentifizierung
Servus zusammen,
wir haben bei uns ein paar Tests zu Wake on LAN gemacht und ich werde nicht recht schlau daraus.
Zur Umgebung:
99% Dell Clients, leider sehr sehr viele verschiedene Modelle, 2/3 PCs und 1/3 mobile Geräte.
Brocade Switches und VLANs via MAC Authentifizierung
VLAN1 Standardnetz
VLAN4001 unauthorisiertes Fallbacknetz
Alle NICs von Intel
Ich mach bei uns die Clientverwaltung, Netzwerk macht ein Kollege und wir haben zusammen getestet
Das positive vorab:
ohne MAC Authentifizierung alles kein Problem, funktioniert wie es soll an allen Modellen
Jetzt die Realität:
mit MAC Authentifizierung funktioniert es an keinem der 4 getesteten PCs (3 Windows und 1 Linux, verschiedene Dell Modelle von relativ alt bis brandneu)
an einem Dell Notebook funktionierte es ohne Probleme
Auf den Switches sehen wir bei den PCs folgendes Verhalten:
nach dem Erreichen des Standbys fällt der Speed auf 10 Mbit (beim Notebook bleibt es bei 1 Gbit) und die Netzwerkkarte wird kurz ausgeschaltet und 2 bis 3 Sekunden später wieder aktiv:
Aug 25 15:33:32:I:STP: VLAN 1 Port 1/1/3 STP State -> DISABLED (PortDown)
Aug 25 15:33:32:I:System: Interface ethernet 1/1/3, state down
Aug 25 15:33:32:N:MACAUTH: port 1/1/3 mac e454.e8a4.1200 vlan 1: authenticated Session is Cleared[Termination-Cause: Port-Down]
Aug 25 15:33:32:N:FLEXAUTH: Port 1/1/3 is added into Auth-Default Vlan 4001 as mac-vlan member
Aug 25 15:33:32:N:FLEXAUTH: Port 1/1/3 is deleted from Dynamic Vlan 1 as mac-vlan member
Aug 25 15:33:34:I:System: Interface ethernet 1/1/3, state up
dieses Ausschalten führt dazu, dass der Port die Authentifizierung und die VLAN-Einstellung vergißt und ins VLAN 4001 zurückspringt.
Nebensatz: im VLAN4001 zu operieren (dh. dort eventuell das Aufwachen zu initiieren) ist nicht erwünscht
An den PCs ist BIOSseitig alles gemacht worden (DeepSleep deaktviert, WoL aktiviert, testweise auch mal PCIX ASPM deaktiviert)
und wie gesagt ohne MAC Authentifizierung funktioniert es ohne Probleme aber für die Verwaltung/Zuordnung brauchen wir die.
Daher scheiden als Fehlerursache Windows bzw. die Geräte selbst für mich eigentlich aus.
Hat jemand eine Idee warum die PCs das NIC kurz ausschalten aber das Notebook nicht? Kann ich das Verhalten evtl. irgendwie steuern?
mfg Sascha
wir haben bei uns ein paar Tests zu Wake on LAN gemacht und ich werde nicht recht schlau daraus.
Zur Umgebung:
99% Dell Clients, leider sehr sehr viele verschiedene Modelle, 2/3 PCs und 1/3 mobile Geräte.
Brocade Switches und VLANs via MAC Authentifizierung
VLAN1 Standardnetz
VLAN4001 unauthorisiertes Fallbacknetz
Alle NICs von Intel
Ich mach bei uns die Clientverwaltung, Netzwerk macht ein Kollege und wir haben zusammen getestet
Das positive vorab:
ohne MAC Authentifizierung alles kein Problem, funktioniert wie es soll an allen Modellen
Jetzt die Realität:
mit MAC Authentifizierung funktioniert es an keinem der 4 getesteten PCs (3 Windows und 1 Linux, verschiedene Dell Modelle von relativ alt bis brandneu)
an einem Dell Notebook funktionierte es ohne Probleme
Auf den Switches sehen wir bei den PCs folgendes Verhalten:
nach dem Erreichen des Standbys fällt der Speed auf 10 Mbit (beim Notebook bleibt es bei 1 Gbit) und die Netzwerkkarte wird kurz ausgeschaltet und 2 bis 3 Sekunden später wieder aktiv:
Aug 25 15:33:32:I:STP: VLAN 1 Port 1/1/3 STP State -> DISABLED (PortDown)
Aug 25 15:33:32:I:System: Interface ethernet 1/1/3, state down
Aug 25 15:33:32:N:MACAUTH: port 1/1/3 mac e454.e8a4.1200 vlan 1: authenticated Session is Cleared[Termination-Cause: Port-Down]
Aug 25 15:33:32:N:FLEXAUTH: Port 1/1/3 is added into Auth-Default Vlan 4001 as mac-vlan member
Aug 25 15:33:32:N:FLEXAUTH: Port 1/1/3 is deleted from Dynamic Vlan 1 as mac-vlan member
Aug 25 15:33:34:I:System: Interface ethernet 1/1/3, state up
dieses Ausschalten führt dazu, dass der Port die Authentifizierung und die VLAN-Einstellung vergißt und ins VLAN 4001 zurückspringt.
Nebensatz: im VLAN4001 zu operieren (dh. dort eventuell das Aufwachen zu initiieren) ist nicht erwünscht
An den PCs ist BIOSseitig alles gemacht worden (DeepSleep deaktviert, WoL aktiviert, testweise auch mal PCIX ASPM deaktiviert)
und wie gesagt ohne MAC Authentifizierung funktioniert es ohne Probleme aber für die Verwaltung/Zuordnung brauchen wir die.
Daher scheiden als Fehlerursache Windows bzw. die Geräte selbst für mich eigentlich aus.
Hat jemand eine Idee warum die PCs das NIC kurz ausschalten aber das Notebook nicht? Kann ich das Verhalten evtl. irgendwie steuern?
mfg Sascha
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: 3757649573
Url: https://administrator.de/forum/wake-on-lan-probleme-im-firmenumfeld-mit-mac-authentifizierung-3757649573.html
Ausgedruckt am: 22.12.2024 um 11:12 Uhr
19 Kommentare
Neuester Kommentar
Zitat von @saxe1234:
Nebensatz: im VLAN4001 zu operieren (dh. dort eventuell das Aufwachen zu initiieren) ist nicht erwünscht
Nebensatz: im VLAN4001 zu operieren (dh. dort eventuell das Aufwachen zu initiieren) ist nicht erwünscht
Moin,
dann wirst du die Sache leider an den Nagel hängen müssen.
Wenn die Geräte weiter aktiv authentifiziert bleiben würden, könntest du die MAC-Auth auch einfach weg lassen.
Was passiert bei einem Gerät im Standby, wo du kurz das Kabel ziehst und wieder steckst?
##
Hier tatsächlich ein Beitrag aus einem Netgear Forum:
Result: Unauthenticated port blocks inbound a n d outbound traffic. This is also true for broadcasts. WOL packets therefore are not forwarded to the affected client. Wake up must fail.
2 options:
-hardened network access for clients with enabled 802.1x but no WOL... or
-disable 802.1x and use of WOL is possible, when using this kind of switch model.
##
Gruß
Spirit
1
Aber warum funktioniert es dann unterbrechungsfrei am Notebook? Würde ich das Verhalten bei allen Geräten gleich sehen dann hätte ich hier gar keinen iIntrag aufgemacht aber es muss einen Unterschied zwischen den PCs und dem Notebook geben.
Den Satz habe ich vollständig überlesen.
Schalten die den Port vielleicht nicht down sobald diese in den standby gehen?
Schalten die den Port vielleicht nicht down sobald diese in den standby gehen?
Es hat sehr wahrscheinlich etwas mit der Autonegotiation der NIC bzw. dem Switchport zu tun. Generell forwardet ein Switch an Mac oder .1x hier).
Hier muss man etwas aufpassen denn es gibt 2 Arten von Magic Packets. Einmal die reinen L2 Packete allein auf Mac Adress Basis die sich nicht in andere IP Segmente forwarden lassen:
und solche die einen IP/UDP Header haben (hier /192er Prefix) und meist Port UDP 9 (Discard) nutzen:
Letztere können nur mit einem UDP Helper/Forwarder in unterschiedliche IP Netzsegmente geforwardet werden. Leider sagt die Beschreibung nicht welche Art verwendet wird.
Du kannst die beiden unterschiedlichen Versionen kinderleicht und schnell einmal testen:
Mit letzterer Option, dem Netzwerk spezifischen Boradcast, dann, wie oben schon gesagt, testen ob es auch über Routergrenzen mit einem UDP Helper geforwardet wird. 😉
Da das aber problemlos beim TO funktioniert ist es sehr wahrscheinlich nicht das Problem. Auch ist die Port Authentisierung selber sehr wahrscheinlich nicht die Ursache wie der eine funktionierende Rechner ja zeigt.
Die Problematik liegt fast immer im Standby Handling der NIC Karten der Endgeräte und deren Treiber. Viele dieser Karten signalsieren keinen Linkverlust und takten die Karten beim Standby auf 10Mbit runter womit viele Switches nicht klarkommen weil das nicht standardkonform ist und deshalb die WoL Pakete wegen des damit ausgelösten Speed und Duplex Mismatches nicht ankommen. Das passiert aber auch ohne Port Authentisierung.
Hier solltest du ggf. einmal sowohl mit statischer Speed und Duplex Zuweisung am Switchport als auch mit dem Maximum Port Speed Advertisement am Switch testen.
Damit bekommt man das in der Regel in den Griff.
Die NIC Treiber sollten keine embeddeten sein sondern direkt die von Intel sein und die Switch Firmware sollte ein 8.0.95 Release sein mit dem aktuellen Patch (derzeit g)!
Hier muss man etwas aufpassen denn es gibt 2 Arten von Magic Packets. Einmal die reinen L2 Packete allein auf Mac Adress Basis die sich nicht in andere IP Segmente forwarden lassen:
Du kannst die beiden unterschiedlichen Versionen kinderleicht und schnell einmal testen:
- Krame deinen Raspberry Pi aus der Bastelschublade und installiere die beiden Tools etherwake und wakeonlan (apt install ...)
- etherwake -b -i eth0 01:02:03:04:05:06 sendet ein nacktes Layer 2 WoL Paket im AMD Magic Packet Format.
- wakeonlan 01:02:03:04:05:06 sendet es mit einem UDP Port 9 Header und all Network Broadcast
- wakeonlan -i 192.168.178.255 01:02:03:04:05:06 sendet es mit einem spezifischen IP Netzwerk Broadcast ins 192.168.178.0/24 Segment.
Mit letzterer Option, dem Netzwerk spezifischen Boradcast, dann, wie oben schon gesagt, testen ob es auch über Routergrenzen mit einem UDP Helper geforwardet wird. 😉
Da das aber problemlos beim TO funktioniert ist es sehr wahrscheinlich nicht das Problem. Auch ist die Port Authentisierung selber sehr wahrscheinlich nicht die Ursache wie der eine funktionierende Rechner ja zeigt.
Die Problematik liegt fast immer im Standby Handling der NIC Karten der Endgeräte und deren Treiber. Viele dieser Karten signalsieren keinen Linkverlust und takten die Karten beim Standby auf 10Mbit runter womit viele Switches nicht klarkommen weil das nicht standardkonform ist und deshalb die WoL Pakete wegen des damit ausgelösten Speed und Duplex Mismatches nicht ankommen. Das passiert aber auch ohne Port Authentisierung.
Hier solltest du ggf. einmal sowohl mit statischer Speed und Duplex Zuweisung am Switchport als auch mit dem Maximum Port Speed Advertisement am Switch testen.
Damit bekommt man das in der Regel in den Griff.
Die NIC Treiber sollten keine embeddeten sein sondern direkt die von Intel sein und die Switch Firmware sollte ein 8.0.95 Release sein mit dem aktuellen Patch (derzeit g)!
Zitat von @aqui:
Die Problematik liegt fast immer im Standby Handling der NIC Karten der Endgeräte und deren Treiber. Viele dieser Karten signalsieren keinen Linkverlust und takten die Karten beim Standby auf 10Mbit runter womit viele Switches nicht klarkommen weil das nicht standardkonform ist und deshalb die WoL Pakete wegen des damit ausgelösten Speed und Duplex Mismatches nicht ankommen. Das passiert aber auch ohne Port Authentisierung.
Hier solltest du ggf. einmal sowohl mit statischer Speed und Duplex Zuweisung am Switchport als auch mit dem Maximum Port Speed Advertisement am Switch testen.
Damit bekommt man das in der Regel in den Griff.
Die NIC Treiber sollten keine embeddeten sein sondern direkt die von Intel sein und die Switch Firmware sollte ein 8.0.95 Release sein mit dem aktuellen Patch (derzeit g)!
Die Problematik liegt fast immer im Standby Handling der NIC Karten der Endgeräte und deren Treiber. Viele dieser Karten signalsieren keinen Linkverlust und takten die Karten beim Standby auf 10Mbit runter womit viele Switches nicht klarkommen weil das nicht standardkonform ist und deshalb die WoL Pakete wegen des damit ausgelösten Speed und Duplex Mismatches nicht ankommen. Das passiert aber auch ohne Port Authentisierung.
Hier solltest du ggf. einmal sowohl mit statischer Speed und Duplex Zuweisung am Switchport als auch mit dem Maximum Port Speed Advertisement am Switch testen.
Damit bekommt man das in der Regel in den Griff.
Die NIC Treiber sollten keine embeddeten sein sondern direkt die von Intel sein und die Switch Firmware sollte ein 8.0.95 Release sein mit dem aktuellen Patch (derzeit g)!
Danke, das gebe ich so mal an die Netzwerker weiter.
Mit embeddet Treiber meinst du die hier die Treiber von Dell bzw. MS?
Wir werden mal weitertesten und ich werde hier berichten.
Danke für die Unterstützung.
Mit embeddet Treiber meinst du die hier die Treiber von Dell bzw. MS?
Richtig!
Wenn es das denn nun war bitte dann nicht vergessen deinen Thread auch als erledigt zu schliessen!
Zitat von @aqui:
Wenn es das denn nun war bitte dann nicht vergessen deinen Thread auch als erledigt zu schliessen!
Wenn es das denn nun war bitte dann nicht vergessen deinen Thread auch als erledigt zu schliessen!
Werde ich tun aber noch haben wir es nicht lösen können aber mit dem Intel Treiber sehen wir schon mal Fortschritte, hat im Standby jetzt nicht mehr 10Mbit Konnektivität sondern 100Mbit
Was halt echt doof ist, dass man nicht einfach die aktuellste Version des Treibers installieren kann wenn die NIC schon älter ist, sondern die passende Version, total dämlich.
Ich bleib dran.
die aktuellste Version des Treibers installieren kann wenn die NIC schon älter ist
Das ist nicht ganz richtig. Zumindestens bei Intel. Das ist ein Universaltreiber und wenn die Karte in der supporteten HW Liste aufgeführt ist dann klappts auch mit dem latest und greatest. 
Zitat von @aqui:
die aktuellste Version des Treibers installieren kann wenn die NIC schon älter ist
Das ist nicht ganz richtig. Zumindestens bei Intel. Das ist ein Universaltreiber und wenn die Karte in der supporteten HW Liste aufgeführt ist dann klappts auch mit dem latest und greatest. kann ich nicht bestätigen, bin aber gerade nicht vor Ort, kann nächste Woche Freitag genauere Infos liefern bzgl.
verbauter NIC und der passenden Version der wired_driver_version.exe
Hallo zusammen,
Rückmeldung weil wir es intern lösen konnten, leider noch nur theoretisch aber immerhin.
Es scheint bei uns ein Problem mit den internen Switch/VLAN Konfiguration zu sein in Verbindung mit dem Verhalten der PCs. Anscheinend verlieren die PCs beim Standby/Ruhezustand kurz ihre Netzwerkverbindung dadurch verlieren sie auch ihre MAC Authentisierung und fallen dadurch in ein VLAN in welchem sie für die WOL Pakete nicht mehr erreichbar sein.
Wir haben uns eine Möglichkeit ausgedacht den WOL "Server" (also von wo die Aufweckpakete verschickt werden) in dieses VLAN zu stecken und von da aus dann aufwecken zu lassen. Nicht schön aber machbar.
Das seltsame ist nur dass mobile Geräte (zumindest die 3 die wir bisher getestet haben) das Problem mit der verlierenden Netzwerkverbindung im Standby/Ruhezustand nicht haben. Die bleiben einfach in dem VLAN dem sie zugeordnet sind.
Rückmeldung weil wir es intern lösen konnten, leider noch nur theoretisch aber immerhin.
Es scheint bei uns ein Problem mit den internen Switch/VLAN Konfiguration zu sein in Verbindung mit dem Verhalten der PCs. Anscheinend verlieren die PCs beim Standby/Ruhezustand kurz ihre Netzwerkverbindung dadurch verlieren sie auch ihre MAC Authentisierung und fallen dadurch in ein VLAN in welchem sie für die WOL Pakete nicht mehr erreichbar sein.
Wir haben uns eine Möglichkeit ausgedacht den WOL "Server" (also von wo die Aufweckpakete verschickt werden) in dieses VLAN zu stecken und von da aus dann aufwecken zu lassen. Nicht schön aber machbar.
Das seltsame ist nur dass mobile Geräte (zumindest die 3 die wir bisher getestet haben) das Problem mit der verlierenden Netzwerkverbindung im Standby/Ruhezustand nicht haben. Die bleiben einfach in dem VLAN dem sie zugeordnet sind.
Anscheinend verlieren die PCs beim Standby/Ruhezustand kurz ihre Netzwerkverbindung
Das ist bei Standby oftmals der Fall weil die NICs dann auch häufig ihre Speed runternehmen um Strom zu sparen. Das ist bei den Endgeräten immer Treiberabhängig.Einige Switches kommen damit nicht klar weil sie die Speed 10/100/1000 dann nicht mehr neu negotiaten können.
Bei den allermeisten Switches kann man das aber über ein entsprechendes Konfig Kommando lösen. Oder muss, sofern supportet, die Endgeräte NIC entsprechend customizen. Beide Wege führen häufig zum Erfolg.
den WOL "Server" (also von wo die Aufweckpakete verschickt werden) in dieses VLAN zu stecken
Das kann man so machen, muss es aber nicht unbedingt. Es kommt darauf an welche WoL Pakete bei dir versendet werden. Leider machst du dazu keine hilfreichen Angaben so das eine zielführende Hilfe schwer möglich ist. 
Wenn es UDP 9 (Discard) Broadcasts sind, kann man die auch stinknormal mit einem ip Helper Kommando global am Switch in dieses VLAN forwarden ohne Frickelei mit einem extra Server. Bei rein L2 Mac basierten WoL Pakete scheitert das aber prinzipbedingt. Hier kann man also nur raten.
Eine Wireshark Sniffer Trace würde hier, wie immer, helfen!
Zitat von @aqui:
Einige Switches kommen damit nicht klar weil sie die Speed 10/100/1000 dann nicht mehr neu negotiaten können.
Bei den allermeisten Switches kann man das aber über ein entsprechendes Konfig Kommando lösen. Oder muss, sofern supportet, die Endgeräte NIC entsprechend customizen. Beide Wege führen häufig zum Erfolg.
Anscheinend verlieren die PCs beim Standby/Ruhezustand kurz ihre Netzwerkverbindung
Das ist bei Standby oftmals der Fall weil die NICs dann auch häufig ihre Speed runternehmen um Strom zu sparen. Das ist bei den Endgeräten immer Treiberabhängig.Einige Switches kommen damit nicht klar weil sie die Speed 10/100/1000 dann nicht mehr neu negotiaten können.
Bei den allermeisten Switches kann man das aber über ein entsprechendes Konfig Kommando lösen. Oder muss, sofern supportet, die Endgeräte NIC entsprechend customizen. Beide Wege führen häufig zum Erfolg.
hast du eine Idee oder gar Erfahrungen bzgl. den von uns eingesetzten Brocade/Ruckus ICX6xxx, 7xxx Switchen?
den WOL "Server" (also von wo die Aufweckpakete verschickt werden) in dieses VLAN zu stecken
Das kann man so machen, muss es aber nicht unbedingt. Es kommt darauf an welche WoL Pakete bei dir versendet werden. Leider machst du dazu keine hilfreichen Angaben so das eine zielführende Hilfe schwer möglich ist. Wenn es UDP 9 (Discard) Broadcasts sind, kann man die auch stinknormal mit einem ip Helper Kommando global am Switch in dieses VLAN forwarden ohne Frickelei mit einem extra Server. Bei rein L2 Mac basierten WoL Pakete scheitert das aber prinzipbedingt. Hier kann man also nur raten.
mir wäre das ja erstmal egal welche Art von WoL Paket verschickt wird solange das Gerät aufgeweckt wird. Ich bin da nicht tief genug in der Materie aber ziehe mal unseren Netzwerker hinzu
Eine Wireshark Sniffer Trace würde hier, wie immer, helfen!
OK danke
hast du eine Idee oder gar Erfahrungen
Ja. Dort gibt es ein entsprechendes Konfig Kommando was das fixt! (max port speed advertise)Zitat von @aqui:
hast du eine Idee oder gar Erfahrungen
Ja. Dort gibt es ein entsprechendes Konfig Kommando was das fixt! (max port speed advertise)ich spiele mal man in the middle und zitiere den Netzwerker:
"max port speed advertise"
unsere Switche kennen diesen Befehl nicht...
Wir haben damals die Portgeschwindigkeit fest gesetzt. Das hat aber das Interface Down-Up beim Umschalten zum WoL-Modus nicht verhindert.
Unser Problem ist nicht die Autonegotiation, sondern dieses Interface Down-Up.
Ich glaube nicht, dass wir das irgendwie verhindern könnten. Im Normalbetrieb macht eine Netzwerkkarte nicht viel, sie muss nur eine Interrupt schicken, wenn ein Paket ankommt. Dann wird die CPU dieses Paket verarbeiten.
Im WoL Modus muss aber die Netzwerkkarte die Pakete (WoL Magic, ARP usw.) selbst verarbeiten, da hilft nicht, eine Interrupt zur ausgeschalteten CPU zu schicken. Das Moduswechsel zieht aber ein Interface Down-Up mit.
2 Punkte die mir noch eingefallen sind, keine Ahnung ob wichtig:
die GPO "allow network connectivity during connected-standby" hatte ich schon früher mal aktiviert
auf manchen Notebooks sehe ich die Option unter Startmenü -> Energieoptionen (via Win+X, nicht via Systemsteuerung) -> die Einstellung "Netzwerkverbindungen im Standby trennen" (ich weiß nicht ob sie genau so lautet) aber bei meinem eigenen Notebook zum Beispiel nicht und ich frage mich wie die Einstellungsoption da erscheint bzw. warum sie bei manchen Geräten eben nicht erscheint (alle Geräte bekommen dieselben Standard-GPOs gesetzt)
Zitat von @saxe1234:
auf manchen Notebooks sehe ich die Option unter Startmenü -> Energieoptionen (via Win+X, nicht via Systemsteuerung) -> die Einstellung "Netzwerkverbindungen im Standby trennen" (ich weiß nicht ob sie genau so lautet) aber bei meinem eigenen Notebook zum Beispiel nicht und ich frage mich wie die Einstellungsoption da erscheint bzw. warum sie bei manchen Geräten eben nicht erscheint (alle Geräte bekommen dieselben Standard-GPOs gesetzt)
das hatte ich falsch im Kopf, die Option heißt:
"Wenn sich mein PC im Standbymodus befindet und im Akkubetrieb ausgeführt wird, vom Netzwerk trennen"
sollte also bei PCs nicht zum Tragen kommen und gibts anscheinend nur bis 1809 (LTSC)
Siehst du eigentlich auch mal ins Handbuch??
RUCKUS FastIron Management Configuration Guide, 08.0.95
link-config gig copper autoneg-control 10m ethernet x lautet das Kommando genau.
Das ist in der Regel oft ein Treiber Problem der NICs. Im Standby wird oft runtergetaktet auf 10 Mbit um Strom zu sparen aber ohne den Link zu deaktivieren und rezuaktivieren. So hat der Switch keine Chance eine neue Autonegotiation zu machen und verharrt im zuvor per Negotiation gelernten Speed was dann einen Mismatch und einen Kommunikationsfehler ergibt.
Hier sollte man niemals embeddete Treibe rnehmen sondern immer die des NIC Herstellers direkt. Bei denen kommt es nicht zu solchen Problemen.
Testweise kannst du das max Advertisement beim Switch mal auf 10 setzen und checken ob das beim Aufwachen aus dem Standby etwas bewirkt.
RUCKUS FastIron Management Configuration Guide, 08.0.95
Unser Problem ist nicht die Autonegotiation, sondern dieses Interface Down-Up.
Da hast du Recht.Das ist in der Regel oft ein Treiber Problem der NICs. Im Standby wird oft runtergetaktet auf 10 Mbit um Strom zu sparen aber ohne den Link zu deaktivieren und rezuaktivieren. So hat der Switch keine Chance eine neue Autonegotiation zu machen und verharrt im zuvor per Negotiation gelernten Speed was dann einen Mismatch und einen Kommunikationsfehler ergibt.
Hier sollte man niemals embeddete Treibe rnehmen sondern immer die des NIC Herstellers direkt. Bei denen kommt es nicht zu solchen Problemen.
Testweise kannst du das max Advertisement beim Switch mal auf 10 setzen und checken ob das beim Aufwachen aus dem Standby etwas bewirkt.
Wir haben damals die Portgeschwindigkeit fest gesetzt.
Das ist kontraproduktiv, denn das killt sämtliche Autonegotiation. Sollte man nicht tun bzw. nur wenn man es zwingend muss.Ruhig Blut bitte, wie zvor schon geschrieben, ich habe mit dem Netzwerk nichts zu tun und gebe hier nur das netzwerktechnisch wieder was mir der Kollege vom Netzwerk schreibt!!
RUCKUS FastIron Management Configuration Guide, 08.0.95
link-config gig copper autoneg-control 10m ethernet x lautet das Kommando genau.
Das ist in der Regel oft ein Treiber Problem der NICs. Im Standby wird oft runtergetaktet auf 10 Mbit um Strom zu sparen aber ohne den Link zu deaktivieren und rezuaktivieren. So hat der Switch keine Chance eine neue Autonegotiation zu machen und verharrt im zuvor per Negotiation gelernten Speed was dann einen Mismatch und einen Kommunikationsfehler ergibt.
Hier sollte man niemals embeddete Treibe rnehmen sondern immer die des NIC Herstellers direkt. Bei denen kommt es nicht zu solchen Problemen.
Testweise kannst du das max Advertisement beim Switch mal auf 10 setzen und checken ob das beim Aufwachen aus dem Standby etwas bewirkt.
Unser Problem ist nicht die Autonegotiation, sondern dieses Interface Down-Up.
Da hast du Recht.Das ist in der Regel oft ein Treiber Problem der NICs. Im Standby wird oft runtergetaktet auf 10 Mbit um Strom zu sparen aber ohne den Link zu deaktivieren und rezuaktivieren. So hat der Switch keine Chance eine neue Autonegotiation zu machen und verharrt im zuvor per Negotiation gelernten Speed was dann einen Mismatch und einen Kommunikationsfehler ergibt.
Hier sollte man niemals embeddete Treibe rnehmen sondern immer die des NIC Herstellers direkt. Bei denen kommt es nicht zu solchen Problemen.
Testweise kannst du das max Advertisement beim Switch mal auf 10 setzen und checken ob das beim Aufwachen aus dem Standby etwas bewirkt.
Wir haben damals die Portgeschwindigkeit fest gesetzt.
Das ist kontraproduktiv, denn das killt sämtliche Autonegotiation. Sollte man nicht tun bzw. nur wenn man es zwingend muss.ich geb das weiter und melde mich
...und bitte nicht immer alles ellenlang wieder zitieren!
