Switch – Why WakeOnLAN frames are sent to broadcast

This is highly dependent on the architecture of the particular switch in question. The wide price range for a 48-port "managed switch" (e.g. under $300 to well over $10,000) should tell you there's something fundamentally different going on inside. If you didn't pay very much for your switch (and I hope you didn't), it's quite likely that multicast (and other "enterprise" features) are offloaded to software (if they're supported at all).

Basic unicast forwarding has become rather inexpensive to do in hardware, so I would expect any modern Ethernet switch to perform reasonably well at basic unicast forwarding under light loads.

When you start adding more features to hardware, the cost goes up significantly. For example, forwarding unicast frames is very different than doing packet replication based on dynamic multicast state. Those are both very specialized tasks. It takes specific bits of hardware to do either one well. Most users of low end switches don't have huge multicast needs. Paying for multicast-specific hardware is a waste for these users.

But most networks use a little multicast. Consequently, it's common for manufacturers to implement multicast and other less commonly used features in software. For example, the unicast forwarding hardware would be told to forward anything with a multicast MAC address to an internal port where they are received by a CPU subsystem (or at least a microcontroller of some sort). Then a software process is able to look at the frame, consult the multicast forwarding table, replicate the frame and hand multiple copies back to the hardware, one per port to be forwarded. Obviously lots of features can be added at this point in software without affecting the cost of the switch significantly.

In such a system, the performance will never be anywhere near what it is for unicast. The performance of the CPU will obviously have some impact, but if you're sending that much "exception" traffic that can't be forwarded in hardware, you're doing it wrong. You need to buy a different switch.

In the worst case, a really low end switch won't have any resource protections so the same CPU that's being slammed with multicast traffic will forget that it's also responsible for the care and feeding of everything else in the switch. If the CPU is too busy replicating multicast traffic to keep the unicast tables updated in hardware (or whatever else the CPU is supposed to be doing), you'll have all sorts of problems.

This is a fundamental problem: WOL only works inside a subnet, because a WOL magic packet isn't a valid IP packet and therefore is not routable beyound the local LAN.

The wikipedia entry outlines a solution for this problem (subnet directed broadcasts), but I've never seen this in action. Another way around the problem might be to create a WOL proxy agent that forwards WOL packets into other subnets (i.e. as a UDP packet).