[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