[c-nsp] Cross-subnet wake-on-lan (directed broadcast) with 6500s

Phil Mayers p.mayers at imperial.ac.uk
Tue Dec 5 10:10:27 EST 2006


All,

We're being mandated to implement power saving by shutting down our PCs 
at night. The windows infrastructure team have run into a wall starting 
them back up, and we are being very, very heavily pushed into providing 
a way for them to emit WOL packets.

The "standard" (read: god-awful) way of doing this would be to enable 
directed broadcasts. However, on the 6500s (sup720, native IOS, 12.2 
SXF6) it's my understanding there are two mutually exclusive forwarding 
paths for such:

ip directed-broadcast NNN
mls ip directed-broadcast

I am going to argue for a different option, a switchport facing a 
dedicated WOL machine, with all client subnets as allowed vlans, and 
make the windows infrastructure people configure a host appropriately 
with the ability to emit packets - however I am expecting considerable 
push-back, and demand for the ability to send them "from anywhere" in 
the network.

The docs on directed broadcast state: http://tinyurl.com/ydssku

"""In the default mode, IP-directed broadcast packets are not forwarded 
in the hardware; they are handled at the process level by the MSFC. The 
MSFC decision to forward or not forward the packet is dependent on the 
ip directed-broadcast command configuration.

There is no interaction between the ip directed-broadcast command and 
the mls ip directed-broadcast command. The ip directed-broadcast command 
involves software forwarding, and the mls ip directed-broadcast command 
involves hardware forwarding. """

So, I read that as:

  You can either have them forwarded in hardware with no filtering, or 
you can have them forwarded in software with filtering

I have several questions:

  1. Is my understanding correct?

  2. Can people provide concrete details that I can use to argue against 
implementation of either of the directed broadcast options? Obviously 
the smurf problem has a long and nasty history, and I have already made 
the point that cisco clearly took it seriously enough to change the 
defaults (itself a major event) but this is viewed as insufficient 
weight of evidence.

  3. Are people aware of any other technical solution which might 
provide this facility? An ability to emit them from the routers via TCL 
perhaps, or some other fiendish way?


More information about the cisco-nsp mailing list