Some switch hardware can generate the packets directly, negating the need for a box on every VLAN. Meraki hardware can do it, but you have to go through the dashboard so automating it isn't currently possible.
Here is some documentation on forwarding WoL on catalyst 3750 switches from Cisco: https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series-swi...
yeah I am wondering if that isn't the easiest route to go though if there already is
one. I am waiting for an answer from Cisco. Cisco switches and routers can forward wol
packets sent over udp. But etherwake doesn't do that apparently.
So if I want to wake up machines from a central location, I either need to use something
else then ether-wake, or don't do it from a central location it looks like.
thanks,
Ron
On 5/18/20 9:33 AM, Rich Greenwood wrote:
Some switch hardware can generate the packets directly, negating the need for a box on every VLAN. Meraki hardware can do it, but you have to go through the dashboard so automating it isn't currently possible.
Here is some documentation on forwarding WoL on catalyst 3750 switches from Cisco: https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series-swi...
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Rich Greenwood Sent: Monday, 18 May, 2020 08:34 To: centos@centos.org Subject: Re: [CentOS] ether-wake
Some switch hardware can generate the packets directly, negating the need for a box on every VLAN. Meraki hardware can do it, but you have to go through the dashboard so automating it isn't currently possible.
Here is some documentation on forwarding WoL on catalyst 3750 switches from Cisco: https :// www. cisco. com /c/en/us/support/docs/switches/catalyst/3750/series/switches_91672/catl3/wol/vlans.html
-- Rich Greenwood Network Engineer Shasta County Office of Education
And from the other major network player(s) :-) a post from our HPE Aruba "Airheads" forum regarding how to enable the IP directed broadcast feature for wake-on-LAN (WoL). Visit the URL to see the formatted version of this forum post. (Note: because anti-malware feature in e-mail sometimes mangles the URL, the URL is separated by spaces to keep it as text)
Cheers! Simba networking
Source URL: https:// community. arubanetworks. com /t5/Security/Magic-Packets-WOL/td-p/426307/page/2
devocite Occasional Contributor I devocite Re: Magic Packets/WOL
01-31-2019 11:31 AM - edited 01-31-2019 11:33 AM
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!
Hello,
when booting using dhcp, some OS-es use their MAC addr, some, when getting an IP with DHCP use a client id, sometimes it's 01M+MAC, sometimes it is a quite long string, similar to UUIDs.
For example some Ubuntu version sends out their DHCP client id as 01+MAC, similar to windows machines.
Is there a way in Centos/RHEL, to 'configure' that? (Cisco equipment is kind of particlat about that), so that for example when requesting
an IP using DHCP, the client-id used is 01+MAC instead of just the MAC address?
(it becomes a hassle when machines are dual boot for example).
thanks,
Ron
On 5/22/20 10:04 AM, R C wrote:
Hello,
when booting using dhcp, some OS-es use their MAC addr, some, when getting an IP with DHCP use a client id, sometimes it's 01M+MAC, sometimes it is a quite long string, similar to UUIDs.
For example some Ubuntu version sends out their DHCP client id as 01+MAC, similar to windows machines.
Is there a way in Centos/RHEL, to 'configure' that? (Cisco equipment is kind of particlat about that), so that for example when requesting
an IP using DHCP, the client-id used is 01+MAC instead of just the MAC address?
(it becomes a hassle when machines are dual boot for example).
In your ifcfg file set:
DHCP_CLIENT_ID=
to whatever you want. I don't know of a way to automatically use the 01+MAC scheme.
-
Orion Poplawski -
Phoenix, Merka -
R C -
Rich Greenwood