When I first began working on WoL, I read this post thread, much like many will read as time goes on, and yet I still could not get WoL to work, but eventually I did.
I will attempt to summarized all that has been said, and needs and some added things done to get WoL working.
Some Requirements (just stating the obvious)
Configure WoL in your computer's BIOS.
(Window) Enable Allow this device to wake the computer under the Ethernet Connection Properties, Power Management tab.
Aruba AOS aka HPE Proview/Provision switching running version 16.x or newer (I can't confirm WoL on older versions)
On the switch, you will need to configure the port for controlled-direction in
i.e. aaa port-access 1/1 controlled-direction in
This allows traffic from the switch to egress the port, so the sleeping computer NIC may process packets.
IP directed-broadcast is only required on the switch performing Layer-3 routing. For Layer-3 Distribution and Access switches, it will do nothing.
Note: ip directed-broadcast globally activates broadcast forwarding/routing between all VLANs. This feature is notorious for being exploited for LAN DOS attacks, therefore I highly recommend setting the optional access list, to only allow WoL from a trusted source.
The interface untagged must a VLAN serviced by a routing instance.
For example:
When a device is authorized, it is put in VLAN 100 services by the core routing device with a SVI of 10.0.100.1.
SVI- Service Virtual Interface (Fancy talk for a Layer-3 VLAN)
When the device goes to sleep, the port is de-authorized, the Ethernet port is change to the default untagged VLAN 1, serviced by the core routing device with a SVI of 10.0.1.1.
The WoL server is at 10.0.50.100 in VLAN 50 with a SVI of 10.0.50.1.
When the WoL packet is sent from the WoL server to 10.0.1.255, the core SVI 50 will route the packet out to SVI 1, thanks to the ip directed-broadcast command.
Here is the part that is not in the ArubaOS-Switch Guide, if you are running spanning-tree, it takes precidence and will block traffic despite the “controlled-direction in” command.
What I discovered, and shared with support, is for a port to be allowed to forward, when blocked by AAA, the port must be set to STP admin-edge.
i.e. (config)# spanning-tree 1/1 admin-edge-port
When everything is set correctly, on an unauthenticated port you should see in the log this succession of events:
00076 ports: port 16 is now on-line
00077 ports: port 16 is now off-line
00435 ports: port 16 is Blocked by AAA
00435 ports: port 16 is Blocked by STP <- STP kicks in after AAA, therefore trumping it.
00076 ports: port 16 is now on-line <- Admin Edge allowing the port to forward
In reality STP admin-edge is a good thing. It allows the port for begin forwarding a few seconds more quickly.
If you are concerned about STP protection, when STP is detected on a admin-edge port, it will fail back to full STP mode, while connected.
If a loop is created, one of the ports will begin blocking, protecting the network.
Note: The need for admin-edge in conjunction with “controlled-direction in”, if STP is enabled, is not in the command reference documentation. The engineer I worked with said he would request documentation update to mention it.
And for the example config:
## Core Switch ##
ip directed-broadcast
ip routing
VLAN 1 ip address 10.0.1.1/24
VLAN 50 ip address 10.0.50.1/24
VLAN 100 ip address 10.0.100.1/24
interface 48 tagged vlan 50,100
## Access Switch ##
…
assuming NAC is already working
...
interface 1/48 tagged vlan 50,100
aaa port-access 1/1 controlled-direction in
spanning-tree 1/1 admin-edge-port
I hope this helps!