Wenn per WOL (Wake on LAN) Geräte die über ein Bonding (LAG/Etherchannel/Teaming…) angeschlossen sind nicht oder nur unzuverlässig aufwachen, kann es damit zusammenhängen, dass das WOL-Frame über das „falsche“ Interface gesendet wird.

Jede NIC besitzt eine feste/permanente MAC-Adresse. Wird ein Bond erstellt, benötigt Dieser ebenfalls eine MAC-Adresse. Normalerweise übernimmt der Bond die MAC der ersten NIC die hinzugefügt wird (oder es wird eine synthetische MAC generiert). Ist das Gerät ausgeschalten, existiert der Bond nicht und die NICs hören nur auf ihre permanente MAC. Wird nun ein WOL-Frame an das Gerät gesendet, kann es sein, dass je nach Bonding-Treiber und Hash-Mode das WOL-Frame an irgendeine NIC des Bonds gesendet wird. Ist das nicht die erste NIC die dem Bond hinzugefügt wurde (MAC des Bonds), erkennt diese NIC das WOL-Frame richtigerweise nicht als für sie bestimmt! In diesem Fall startet das Gerät nicht. Von einem anderen Gerät kann es klappen, je nach verwendetem Bonding-Treiber und Hash-Mode.

 

So zeigt sich ein Gerät das über ein Bonding angeschlossen ist. Die MAC des Bonds ist die MAC der zuerst hinzugefügten NIC:

 

Der Bonding-Treiber überschreibt im Betrieb die MAC-Adressen der Slaves (eth0 und eth1 enden auf :72):

 

Die permanenten MACs (die „echten“) der NICs lauten jedoch :72 für eth0 und :73 für eth1:

 

Ergibt die Gleichung des XOR + L3+4-Hashes, dass das WOL-Frame über ether22 gesendet wird, komm es an eth1 (:73) an:

 

Im WOL-Frame wird jedoch die Bond-MAC (:72 des physischen eth0-Interfaces) angesprochen:

 

In diesem Fall wacht das Gerät nicht auf. Wird das WOL-Frame von einem anderen Gerät aus gesendet, kann es sein das es sofort startet. So wenn die Gleichung des XOR-Modes ergibt, dass das Frame über ether21 (zu eth0 mit der :72) gesendet wird.

Dieses Verhalten kann nicht beeinflusst werden, da es immer auf das Ergebnis der XOR-Gleichung ankommt welches Egress-Interface genutzt wird.

 

---

Lösung

Eine möglich Lösung kann sein, das zu weckende Gerät anzupingen und wenn der Ping fehlschlägt (= Gerät ist aus), das Egress-Interface das mit der „falschen“ NIC/MAC des Zielsystems verbunden ist, zu deaktivieren. Dafür würde sich die Netwatch-Funktion in Mikrotik eignen.

Im Beispiel wäre es ether22 das zu eth1 (:73) geht. Ist ether22 disabledt, zwingt man den Bonding-Treiber alles über ether21 an eth0 (:72) zu senden (ungeachtet des Ergebnisses der XOR-Gleichung). So kommt das WOL-Frame immer am Interface mit der „richtigen“ MAC des Bonds an.

 

Folgendes Script erledigt diese Aufgabe:

/tool netwatch
add down-script="/interface disable ether22" host=10.88.30.5 \
interval=30s up-script="/interface enable ether22"

Es pingt das Gerät (10.88.30.5) im Abstand von 30 Sekunden an, scheitert dies, wird ether22 disabelt. Ansonsten wird ether22 enabelt.