WOL is unfortunately terribly deficient in that the spec. never envisioned the possibility
of a need for wake on WAN.
Bottom line, it's a non-routeable layer 2 protocol. Your choices boil down to the
helper address nightmare you describe or proxy servers on every subnet.
Owen
I would suspect that proxy servers being the better deal, though my experience with Cisco is that you may have to use ASR type gear to get a nicer layout (similar to service providers) where you can backend everything to a radius server (I'm still waiting to test this myself, but IOS is really weak on DHCP support).
Jack
WOL is unfortunately terribly deficient in that the spec. never envisioned the possibility
of a need for wake on WAN.
Use case I can think of: 'green' data center running VMware VI3 or vSphere with DRS and dynamically bringing blades online through WoL to handle load peaks and still stay green (when a host is empty, using the VMware API you can take it to maintenance mode and shut it down; use WoL to boot it back up when you need it).
Bottom line, it's a non-routeable layer 2 protocol. Your choices boil down to the
helper address nightmare you describe or proxy servers on every subnet.
In the use case I mention it wouldn't be a problem, since under VMware DRS (which relies on VMotion) you have to have layer 2 transparency anyway. Would this not be a use case also for something like VPLS or EoMPLS?
Jack Bates:
I would suspect that proxy servers being the better deal, though
my experience with Cisco is that you may have to use ASR type gear
to get a nicer layout (similar to service providers) where you can
backend everything to a radius server (I'm still waiting to test
this myself, but IOS is really weak on DHCP support).I hope someone will please clarify the problem statement?
My problem is lack of WOL experience and associating dhcp-helper address with DHCP; ie, speaking without knowledge. I'm bad about that. 
The only router/switch configuration required was to permit directed
broadcasts from the systems doing the waking. On by default, I
believe, but locked down in my environment.
IOS specific, I believe. Some have it on; some have it off.
Jack
Appologies to all that got a quote email from me. My phone decided to
pocket-reply to you.
Owen DeLong <owen@delong.com> writes:
WOL is unfortunately terribly deficient in that the spec. never =
envisioned the possibility
of a need for wake on WAN.Bottom line, it's a non-routeable layer 2 protocol. Your choices boil =
down to the
helper address nightmare you describe or proxy servers on every subnet.
WoL works just fine over routed networks; the magic packet format
doesn't preclude it. I send WoL over routed networks several times a
day. The only gotcha is that you need some kind of arrangement for
either directed broadcast, or hardcode ndp/arp entries.
Perl code snippet below:
my $wolhost = "wolhost.example.com";
my $wolhost_mac = "de:ad:be:ef:ca:fe";
my $mac = $wolhost_mac;
$mac =~ s/[: ]//g;
# Use socat to build a wakeonlan packet inside a udp6 datagram.
my $packed_bcast = pack("H12", "f" x 12);
my $packed_mac = pack("H12", $mac);
my $dgram = $packed_bcast . ( $packed_mac x 16);
# 9 is the discard port. For whatever reason, the wrong thing
# happens when the port is referenced by name, despite having the
# name in /etc/services.
open(SOCAT, "|-",
(qw(socat -u STDIN),
"UDP6-DATAGRAM:$wolhost:9"))
>> die "popen: $!";
print SOCAT $dgram || die "print: $!";
close(SOCAT);
WOL is unfortunately terribly deficient in that the spec. never
envisioned the possibility
of a need for wake on WAN.Bottom line, it's a non-routeable layer 2 protocol. Your choices boil
down to the
helper address nightmare you describe or proxy servers on every subnet.I would suspect that proxy servers being the better deal, though my
experience with Cisco is that you may have to use ASR type gear to get a
nicer layout (similar to service providers) where you can backend
everything to a radius server (I'm still waiting to test this myself,
but IOS is really weak on DHCP support).
assuming you don't mind burning an ip address per subnet you can do this
with a static arp entry for an ethernet multicast address even if your
l3 platform doesn't allow subnet directed multicast.
on a firewall platform basied on linux I specifically worked around the
deliberate lack of subnet directed broadcast by natting from the
broadcast address of the target subnet to an rfc 1918 address on the
subnet with a static arp entry pointing at a multicast address. it
worked fine, exploited the fact that rewrite occurs before forwarding on
linux and allowed the use of a pre-existing management tool that used
subnet directed broadcasts.