[134107] in North American Network Operators' Group
Re: Wake on LAN in the enterprise
daemon@ATHENA.MIT.EDU (Joel Jaeggli)
Thu Dec 23 23:43:27 2010
Date: Thu, 23 Dec 2010 20:41:06 -0800
From: Joel Jaeggli <joelja@bogus.com>
To: Jack Bates <jbates@brightok.net>
In-Reply-To: <4D064AB4.5080706@brightok.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 12/13/10 8:32 AM, Jack Bates wrote:
> On 12/13/2010 10:20 AM, Owen DeLong wrote:
>> 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.
>
> Jack
>
