LACP Trunk not passing WOL packets

[Mark^]

I have two 2960s which are connected via an LACP trunk and I am unable to send WOL (magic packet) to machines on the other side of the trunk within the same VLAN.  I was trying to Google this, but only found reference to sending WOL between different VLAN.

Wondering what I am doing wrong.  It did work previously, and I believe this started after I restricted which VLAN allowed on the trunk.  Help/suggestions greatly appreciated.

Trunk configurations below:

**Switch A**
interface Port-channel4
 description LAG between floors
 switchport trunk allowed vlan 1-999,1001-4094
 switchport mode trunk

interface GigabitEthernet1/0/30
 description 1st Floor
 switchport trunk allowed vlan 1-999,1001-4094
 switchport mode trunk
 srr-queue bandwidth share 1 30 35 5
 priority-queue out
 mls qos trust cos
 auto qos trust
 channel-protocol lacp
 channel-group 4 mode active

interface GigabitEthernet1/0/34
 description 1st Floor
 switchport trunk allowed vlan 1-999,1001-4094
 switchport mode trunk
 srr-queue bandwidth share 1 30 35 5
 priority-queue out
 mls qos trust cos
 auto qos trust
 channel-protocol lacp
 channel-group 4 mode active

**Switch B**
interface Port-channel1
 description Trunk LAG to 2nd Floor
 switchport trunk allowed vlan 1-999,1001-4094
 switchport mode trunk
 
interface GigabitEthernet1/0/14
 description 2nd Floor
 switchport trunk allowed vlan 1-999,1001-4094
 switchport mode trunk
 srr-queue bandwidth share 1 30 35 5
 priority-queue out
 mls qos trust cos
 auto qos trust
 channel-protocol lacp
 channel-group 1 mode active

interface GigabitEthernet1/0/24
 description 2nd Floor
 switchport trunk allowed vlan 1-999,1001-4094
 switchport mode trunk
 srr-queue bandwidth share 1 30 35 5
 priority-queue out
 mls qos trust cos
 auto qos trust
 channel-protocol lacp
 channel-group 1 mode active

[Peter Paluch]

Hi Mark,

There must be something strange going on. I do not see anything unusual with your configuration. Just to be absolutely sure, check the show ether summ output and make sure that the Port-channel interfaces are flagged as SU (Switched, Up) and that each of their physical member ports is flagged as P (In Port Channel).

I suppose you do not have your stations-to-be-awakened in VLAN 1000, do you? This VLAN is the only VLAN that is disallowed on the trunk.

If nothing else helps then I'd suggest trying to follow the path of the WoL frame, first using Wireshark on the end station while it runs to see if the packet arrives to that station, and if not, following the path from the sender  and checking whether at least the sender's MAC address is being properly learned on the switches along the path.

By the way, what kind of WoL packets are you using? Broadcasted UDPs?

Best regards,
Peter

[Mark^]

I believe that I am sending multicast WoL packets -- using the free utility from matcode.com.

Since you asked, I looked it up.  I then tested sending a WoL and including the broadcast address as an option worked.

So, for some reason, I now need to include the broadcast address where I did not need that before.

Thanks for the help!

[Peter Paluch]

Mark,

I do not personally believe that the multicast option for WoL packets is a smart thing to do. Here's why:

1. Cisco Catalyst switches optimize multicast delivery by running IGMP Snooping by default. As soon as a multicast router is detected (this is done by receiving sending PIM or IGMP Membership Query packets), the IGMP Snooping kicks into action and causes multicast to be delivered only to those ports where stations explicitly joined the corresponding multicast group. This joining has to be periodically refreshed. A shut-down PC is unable to send IGMP Membership Report messages and thus does not appear as a member of any multicast group.
2. Even if IGMP Snooping is deactivated or the link-local multicast scope 224.0.0.0/24 is used, the PC's NIC must be instructed to listen to specific multicast MAC address to actually process received multicasts. Even though this can easily be done while the PC is running, I am not sure if the NICs retain this setting after the PC is shut down.

If the network card operated in promisc mode when the PC is shut down, listening to all frames and looking for the magic sequence anywhere in their contents, even multicasts could work (provided they are not affected by IGMP Snooping). However, I really do not know if NICs in shutdown PCs operate in promisc or in normal mode. Without diving into datasheets of particular NIC controllers, it would be kind of difficult to know.

So the choice of broadcast for WoL is probably the easiest course of action with least obstacles to overcome. The WoL traffic is entirely insignificant so I would not be concerned with broadcasting it across the entire VLAN.

Best regards,
Peter