WOL on serval catalyst 2960 in the same VLAN

[MDupont09300]

Hello,

I have 2 classrooms A and B. A and B are connected to 2 different SW Catalyst 2960-X SWA and SWB. I don't manage those SW.

Before A was in another VLAN V1 (DHCP) and B in VLAN V2 (fixed IP). I could wake up with WOL the A and B classroom from a PC in VLAN 1 et another in VLAN2 because there is no WOL routing accepted.

Now, the 2 classrooms are in the same VLAN V1 (DHCP). I can wake up the A classroom but not the B classroom.

The LED of the network card is blinking orange each second in classroom A and each 10-12 seconds in classroom B. If I put my own SW (default configuration) in classroom B, the LED is blinking orange each second and I can wake up the PC when they are power off.

I check with wireshark and all the magic packets are correct.

What's happening?

- 2 different firmwares on SWA and SWB.
- I known that the SWB doesn't give an DHCP address if I put my own SW. So is there a special configuration of the SWB which disable the port when a PC is power off. So the LED is blinking less and the magic packet doesn't get to the PC???
- I also read https://community.cisco.com/t5/switching/configure-wol-for-catalyst-2960-x/td-p/2989984 but I'm not a network administrator. I don't known what means a SVI????

Thank you in advance.

Best regards

[Georg Pauwen]

Hello,

how are the two classrooms connected, and what WOL utility are you using ? WOL often uses multicast, make sure IGMP snooping is disabled on the classroom B switch...

Better yet, post the full running configurations of both switches...

[MDupont09300]

Hello,

I always use the wakeonlan command on linux.

My network scheme is:

The IGMP snooping has to be disabled because I get the magic packet on the PC when it's turn on (analyse by wireshark).

Is it possible to put down a port of the SWB when the PC is power off?
Why the LED is clincking slower on SWB than the SWA? It's weird.

I don't have the configuration because I don't work in the network team.

Thanks.

Best regards,

MD

[Georg Pauwen]

Hello,

judging from your topology drawing, both switches are connected to the router directly ? I guess we are stuck without seeing the actual configurations of the three devices. How can we get the network team involved ?

[paul driver]

Helllo
Not so sure what your asking here, are you saying when the two WOL clients were on different subnets then it worked for both clients and now they are the same vlan both clients dont recive the magic packet?

FYI -My understanding is WOL magic packets are broadcasted, You dont require mulicast for WOL packets be forwarded to clients as @Georg Pauwen  stated.

If your WOL server is on the same vlan as a WOL client then you shouldnt really need to do anything, the udp packet should reach any WOL devices.

However if you have WOL clients are on different vlans to the WOL server then the broadcast needs to traverse these other broadcast domains, which by default is denied, But what you can do is enable forwarding of udp and direct broadcast (tied down with acl) on the vlan that requires to recieve this WOL majic packet, this then should allow all WOL clients to recieve the udp magic packet.

[Georg Pauwen]

FYI -My understanding is WOL magic packets are broadcasted, You dont require mulicast for WOL packets be forwarded to clients as @Georg Pauwen  stated.

--> Just to be sure: I said 'often' not always. IBM WOL and EMCO WakeOnLan have the option to use multicast in addition to directed broadcast and unicast...

Broadcast should indeed work...since something doesn't, my thought was it could be multicast (and subsequently IGMP snooping on the switch(es)...

I guess we need to see the configs, and get more information on what is involved...

[MDupont09300 · Accepted solution]

Hello,

Thank you for your concern.

I've got the answer:

When a PC turn off or in hibernation, it makes a down link. So the port becomes "closed". The port stays in this state until the PC identifies itself again. During this period, the magic pack is blocked by the "closed" port.

To solve this problem, you have to authorize the WOL crossing the "closed" port.

Best regards,

MD

[Georg Pauwen]

Hello,

out of curiosity, amd for future reference, how do you 'authorize' WOL to access the closed port ?