0

I'm out of idea facing a challenging situation : Wake up a server on demand.

The problem

Wake-up a physical server that listen on specific port, when an incoming packet arrives. There may be a controller/middleware between clients and the server, but it should not affect bandwidth (and transparent for users).

The main goal : saving power consumption.

What I've tried

The setup I've tried for this demonstration is applied for a Samba NAS server.

  • Firewall wake up : similar to the previous option, but acting at transport layer regarding to the requested port the firewall will wake up the server. Requires a subnet for masquerading the server.

    firewall topology

    • PROS : Generic, Transparent for users in established state
    • CONS : Bandwith affected, Requires a new subnet

  • IPVS DR : based on load-balanced environments, the goal is to take advantage of the floating IP address. I've imaginated to modify the ipvs stack (ipvsadm or keepalived) by implementing the wake-up server feature when a request arrives. That's a lot of works and searching, that's why I would prefer to see if there are another solutions ;)

    IPVS DR topology

    • PROS : Generic, Transparent for users in established state, Bandwith not affected
    • CONS : Hard to set up ?

This is an example with the NAS server, but I would prefer an elegant and generic solution to solve this problem.

Any ideas ? :)

Xavier Brassoud
  • 101
  • 2

1 Answers1

2

Possibly the easiest solution, fully transparent:

  1. select a "WoL server": that can be a tiny creditcard computer, or a service on an already present machine - anything you can run a packet capture on and that can use a (more or less) dedicated NIC for capturing; possibly you could also use a router suitable for scripting
  2. on the switch to the physical server, configure port mirroring from the physical server port to the WoL server port
  3. on the WoL server, run a packet capture with an appropriate filter - ARP for the physical server IP, SYN for HTTP socket, ...
  4. on the WoL server, run a small script monitoring the captured packets and on a hit, send a WoL packet to the physical server

Don't forget to add a static ARP entry on the upstream router if you're using a higher layer trigger frame like SYN for HTTP.

Zac67
  • 8,639
  • 2
  • 10
  • 28
  • Can't give you a +1 due to lack of reputation... I like your solution, port mirroring seems a good starting point. What's I don't really understand, that's the point 2, you say port mirroring from the physical server, but there are nothing to capture because the server is shutdown. Do you mean mirroring from network to WoL Server ? – Xavier Brassoud Mar 18 '20 at 22:14
  • Sure I will can't escape the static ARP entry on my router with this solution. If I understand, every packet captured with the MAC destination address corresponding to my physical server will triggers on the WoL server ? So there is no difference by settings WoL on ARP on the physical server `ethtool -s eth0 wol a` ? – Xavier Brassoud Mar 18 '20 at 22:33
  • The port mirroring is actually just a safeguard to make sure the WoL server catches the trigger frame - an ARP request is broadcast anyway, but a SYN request with static ARP might not be flooded when the server has just shut down and the MAC hasn't aged out yet on the switch. From the switch's perspective the server link is up, as required for WoL. – Zac67 Mar 19 '20 at 07:07