Hallo zusammen,
ich bin ein bisschen ratlos. Seit einiger Zeit kann ich die Clients nicht mehr per WOL wecken. Seit wann kann ich leider auch nicht sagen. Es ist mir nur aufgefallen, dass am Wochenende viele Clients im Standby waren und nicht abends herunter gefahren sind. Dazu wecke ich sie um 17:56, damit sie um 18:00 herunterfahren.
Zunächst dachte ich, der Server sendet keine WOL-Pakete aus. Das habe ich mit tshark getestet:
Wenn ich WireShark trauen darf, ging das Paket ins Netzwerk.
Jetzt habe ich ein WOL-Paket von meinem unifi-Server (10.16.1.3) abgeschickt und geschaut, was beim Client ankommt:
In Zeile 1 sieht man, dass das WOL-Paket beim Client angekommen ist.
Dann habe ich vom server aus mit linbo-remote -i lz-r99 -w 1 nochmal ein WOL-Paket abgeschickt. Das Ergebnis beim Client sind die Zeilen 2 bis 6?
Danach habe ich mit wakeonlan 82:E6:79:17:1D:04 nochmal ein WOL-Paket abgeschickt. Da kam beim Client nichts an?!?
Server und Client sind am gleichen Switchport des Cisco SG300-28 angeschlossen. Die Server sind im VLAN 16 und der Client ist im VLAN 17.
Ich bin ein Bisschen Ratlos. Vom lmn-Server geht wohl das WOL-Paket raus. Der Switch leitet die Pakete weiter und beim Client kommen nur die vom unifi-Server an?!?
Hat mir jemand einen Tip?
Vielen Dank schon mal fürs Mitdenken.
Gruß
Mathias
Hallo Holger,
ich hatte ja kurz Hoffnung. Beim Client im 16-er Netz kommt das an:
Ist der Rechner aber im VLAN 17 erhalte ich das:
Leider WOL-Paket.
Die realen Rechner im Lehrerarbeitsraum starten auch nicht…
Hallo zusammen,
in der Zwischenzeit habe ich einen kleinen SG300 10-Portswitch ausgepackt und nur die wichtigsten Dinge konfiguriert:
Layer-3 Modus aktiviert
Die VLANs 16 (Servernetz), 17 (Lehrernetz), 18 (Schülernetz) und 19 (Netzwerkgeräte) angelegt.
VLANs mit den Ports verbunden.
Jeder VLAN eine IP vergeben (10.17.255.254) usw…
Die Default-Route festgelegt (10.16.1.254 die OpnSense).
DHCP-Relaying eingerichtet.
ALCs und ACEs erstellt (Jeder darf alles…) und mit den VLANs verbunden.Und
Und UDP-Relaying für WOL eingerichtet.
Eigentlich kein Hexenwerk.
Ergebnis: Die Computer in den Computerräumen lassen sich von Hand starten. Alles (bis aufs Internet; hab ich weg gelassen) läuft. Die Rechner bekommen per DHCP ihre IP und man kann sich anmelden.
Aber WOL klappt nicht
Naja, damit ist aber gezeigt, dass es wahrscheinlich nicht an einer Einstellung des Layer-3-Switches liegt.
Als Workaround kann ich natürlich das cron-gesteuerte Starten der Clients vom unifi-Server machen. Aber das ist halt nur ein Workaround
Falls es jemanden interessiert, habe ich hier die Konfiguration des SG300-10. cisco214_20260216.zip (6,7 KB)
.
Hatte jemand in letzter Zeit schon ähnliche Probleme? Für einen Tip wäre ich echt dankbar
Viele Grüße
Mathias
vielleicht hat es die gleiche Ursache: Wir hatten den Effekt, dass mit neuerem Kernel im Linbo wir eine Treiber-Einstellung zum Deaktivieren von energieeffizientem Ethernet als Kernelparameter setzen mussten: igb.EEE=0
Hallo Buster,
vielen Dank für deine Idee. Die werde ich morgen mal ausprobieren.
Allerdings befürchte ich, dass es daran nicht liegt. Wenn ein WOL Paket kommt, starten die Clients auch. Das Problem ist, dass das WOL-Paket gar nicht beim Client ankommt.
Irgendwie habe ich da den L3-Switch im Verdacht.
Aber schicke ich das WOL-Paket von meinem unifi-Server (10.16.1.3) ab, kommt es bei den Clients an. Der Weg von Proxmox über die Switche zum Client scheint es ncht zu sein.
Andererseits habe ich mit tshark (WireShark) gesehen, dass das WOL-Paket zumindes die Netzwerkkarte des Servers verlassen hat.
Das WOL-Paket müsste also beim Client ankommen. Tut es aber nicht?!?
Mir gehen die Ideen aus
VG
Mathias
Das habe ich tatsächlich probiert. Der Effekt war, dass das WOL-Paket nach 10.17.255.255 gebroadcastet wurde. Leider ist beim Client trotzdem nichts angekommen?!?
wo sniffst Du mit Wireshark? Direkt auf dem Server, der das Magic-Packet verschickt?
Um zu sehen, ob das Paket wirklich den Switch erreicht, müsstest Du auf dem Switch ein Port-Mirroring einrichten und mit einem separaten PC den gespiegelten Port sniffen.
Kannst auch erstmal per tcpdump auf dem Ausgangsinterface von Proxmox schauen, so filtern, dass Du auch die Zieladresse siehst. Vielleicht schickt er die WOL-Pakete direkt ans Gateway, da Zielnetz nicht in der Routingtabelle, hatte das im anderen Thread schon erwaehnt.
So in etwa: tcpdump -i vmbr0 dst port 9 -e -n
Wenn die zweite MAC die vom Gateway (ip n, arp -a) ist, dann stimmt was mit der Broadcastadresse nicht.
Ja, das war natürlich mein Problem. Kommt das WOL-Paket wirklich am Switch an? Zumal beim Unifi alles funktionieret. Als Zieladresse ist da auch 255.255.255.255. Sieht also so aus, als läge das Problem dort…
Super Tipp, das probiere ich aus. Zumal der lmn-Server und der Unifi-Server beide vmbr0 nutzen. Mal sehn, wo sich die beiden unterscheiden.
root@server:~# routel Dst Gateway Prefsrc Protocol Scope Dev Table default 10.16.1.254 static ens18 10.16.0.0/16 10.16.1.1 kernel link ens18 10.16.0.0/16 10.16.1.253 static ens18 10.17.0.0/16 10.16.1.253 static ens18 10.18.0.0/16 10.16.1.253 static ens18 10.19.0.0/16 10.16.1.253 static ens18 10.20.0.0/16 10.16.1.253 static ens18 10.16.1.1 10.16.1.1 kernel host ens18 local 10.16.255.255 10.16.1.1 kernel link ens18 local 127.0.0.0/8 127.0.0.1 kernel host lo local 127.0.0.1 127.0.0.1 kernel host lo local 127.255.255.255 127.0.0.1 kernel link lo local
Das Paket mit der Ziel IP-Geht also zur OpnSense (10.16.1.254) und nicht zum Switch (10.16.1.253).
Die Routing-Tabelle des Unifi OS Servers sieht so aus:
root@uos-server:~# routel Dst Gateway Prefsrc Protocol Scope Dev Table default 10.16.1.253 10.16.1.2 dhcp ens18 10.16.0.0/16 10.16.1.2 dhcp link ens18 10.16.1.2 10.16.1.2 kernel host ens18 local 10.16.255.255 10.16.1.2 kernel link ens18 local 127.0.0.0/8 127.0.0.1 kernel host lo local 127.0.0.1 127.0.0.1 kernel host lo local 127.255.255.255 127.0.0.1 kernel link lo local
Schade nachdem ich in /etc/netplan/01-netcfg.yaml die Default-Route auf 10.16.1.253 gesetzt habe und den Server neu gestartet habe, ist leider kein WOL-Paket aus vmbr3 gesendet worden…
Hallo Mathias,
einen Unterschied sehe ich, wenn ich den Befehl hier auf dem Server verwende und zwar sind das die Netzmasken:
Bei uns sind überall „/24er“ Netze eingetragen – bei Dir aber überall die großen „/16er“ Netze. Vielleicht ist das ein Hinweis?
Viele Grüße,
Michael
Wenn der Server 10.16.1.2 hat, dann ist die Route in Zeile 2 (meines Zitats) überflüssig, weil der Server das Paket immer direkt zustellt bzw. zustellen sollte, da das Ziel in seinem eigenen Netz liegt.
Warum sollte da überall /24 statt /16 stehen? Kennt ihr sein Netz im Detail? Wenn die Unterscheidung der Netze im 2. Oktett der IP statt im 3. Oktett vorgenommen wird, dann ist /16 durchaus korrekt. Ich gehe mit, dass /24 nicht zu haben ein Fehler wäre, wenn die Netze so aussehen würden:
10.16.0.0/16 ist das Netz, in dem nur Server, der unifi-Server, OpnSense und der L3_Switch stehen.
10.17.0.0/16 ist das Netz des Lehrerarbeitsraums. Da sind nur Geräte für Lehrer drin.
10.18.0.0/16 ist das Schülernetz. Da sind alle Geräte, mit denen die Schüler arbeiten.
10.19.0.0/16 ist das Servicenetz. Da sind Drucker, APs und Switche.
10.20.0.0/16 WLAN für Laptops.
Bis auf die Schülernetze kann man sich natürlich überlegen, ob 24-Netze nicht besser wären.
Naja, ich habe die IPs mit 10.16 bis 20.Raumnummer.Rechnernummer vergeben. So kann man schon an der IP ablesen, wo der Rechner steht und was es ist.
Ok, die schmeiß ich mal raus… Mal seh’n, was passiert…
