...

-----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!

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.