Wake on LAN over MPLS

Alpha Rafael · ‎04-07-2017

I'm working on an issue trying to get Wake on LAN (WoL) messages to be sent across an MPLS network to remote locations. The path is from local subnet > L3 switch > Router > MPLS > Remote Router, connected to the remote (destination) subnet.

On the local L3 switch, I have the ip helper-address command set on the interface connected to the local subnet. It is set with the IP broadcast address of the remote (destination) subnet. In global config mode on the L3 switch, I also have ip forward-protocol 0 set, which is the protocol used by the program used to send the WoL packet.

On the remote router, the interface that is connected to the destination subnet has ip directed-broadcast 199 configured, and access list 199 allows udp over port 0 from the source subnet to the destination subnet.

So as I understand it, the ip helper-address and ip forward-protocol commands on the local L3 router will allow it to convert the WoL packet to a directed broadcast, which is a unicast message. The L3 switch will then send the WoL unicast to the local router, which will send it over the MPLS to the remote router. Once the remote router receives the packet, it will see that it has a destination address of the LAN subnet's broadcast address. Because the interface connected to that subnet has ip directed-broadcast configured, it should then convert/explode the directed broadcast into an L2 broadcast and all hosts on the remote LAN should receive the WoL packet. The host it is intended for should be one of the hosts that receives the packet, and should then be awoken.

However, this is not what actually is happening. I know the computers on the remote subnet can be woken properly, as they can be woken form a server on that LAN. I also know that the remote router is receiving the packet, because I have done a packet capture on a host on the remote LAN while it is powered on and is sent a WoL packet from the local LAN. When that happens, the packet that comes into the host on the remote LAN shows as "WOL" in Wireshark, and the source address is indeed from the correct IP on the local LAN. However, instead of the destination address being that of the remote LAN's broadcast address, it is the IP of the remote host.

So it seems like the remote router is failing to apply the ip directed-broadcast command correctly. I ran a debug ip packet detail on the remote router, and saw the following:

FIBipv4-packet-proc: route packet from GigabitEthernet0/0/0 src x.x.x.x dst y.y.255.255
FIBfwd-proc: Default:y.y.255.255/32 receive entry
FIBipv4-packet-proc: packet routing failed
IP: tableid=0, s=x.x.x.x (GigabitEthernet0/0/0), d=y.y.255.255 (VlanZ), routed via RIB

I don't know much about FIB/CEF/RIB, but I'm wondering why the router is saying that it failed to route the packet using information from FIB, but then routed it via RIB. And if the remote router did route the WoL via RIB, shouldn't it have done so to the stated address of y.y.255.255 (which is the remote LAN's broadcast)? I think that it should be doing this, but again, I'm not seeing that packet coming into the remote host when performing a packet capture. The only thing that stands between the remote router and the remote host is an L2 switch, so I don't think that is relevant.

Georg Pauwen · ‎04-07-2017

Hello,

try and disable CEF on the receiving router (either on the relevant interface with 'no ip route-cache cef') or globally with 'no ip cef'.

Alpha Rafael · ‎04-10-2017

If I disable CEF, what else will be affected? Will the router's performance slow down, or will CPU usage increase? This is a production router, so I want to make sure I understand what side-effects the command will have before trying it out.

Alpha Rafael · ‎06-16-2017

I wanted to post a (delayed) follow-up for anyone who faced a similar issue.

I discovered that, while the primary program I was using to try to sen WoL wasn't working, we have another program that actually was successfully waking clients on remote subnets. I looked at the difference between the packets each program was sending using Wireshark, and discovered that the primary program had port 0 as the destination, whereas this other program uses port 9. The primary program does allow the WoL port to be configured, so I changed it from 0 to 9. Voila! Now our primary program can also successfully wake clients on remote subnets.

I worked with Cisco TAC on this case, and the technician could not explain why the port made a difference. From what I can see in the configurations of the devices involved, there is no reason this should have made a difference; any relevant ACLs were allowing both ports 0 and 9.

So if you're facing a WoL issue and your destination port for WoL packets is 0, try changing it to either 7 or 9 (more common ports for WoL). I don't know why it helps, but it might.