Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an LVS based load balancer which has been working just fine. It runs on two servers using heartbeat to provide failover.

I've added support for a second IP range to the system, but when the failover occurs, the server which takes over cannot ARP any IPs in this second range until I remove and re-add the route for that range.

Here's some more detail on what I see on the active load balancer right after failover:

# arp  ether   00:20:ED:1A:0C:82   C                     eth0  ether   00:1E:C9:B0:F6:FE   C                     eth0          (incomplete)                              eth0

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface  *      U     0      0        0 eth0   *        U     0      0        0 eth0
default         UG    100    0        0 eth0

so I can't ARP that which will be on the 2.2.2.* netblock

What I found is that removing and adding the route for the netblock fixes the issue

ip route del dev eth0
ip route add dev eth0

If I trigger an ARP lookup by pinging, the ARP cache will now show  ether   00:22:19:51:71:E4   C                     eth0

Does anyone know what's going on here, or know of a way I could get the heartbeat daemon to perform this route deletion and re-adding when it performs the takeover?

share|improve this question
up vote 2 down vote accepted

Sometimes the switch keeps the old ARP mapping around for too long; I've had to use "arping -U" under linux to tell the upstream switch to flush cache.

share|improve this answer

How are you specifying an IP as a resource? Are you using the IPAddr resource script? If you are not re-broadcasting the ARP on failover, equipment previously talking to the VIP will have the old physical address in the ARP table.

share|improve this answer
I'm using IPAddr2. I don't think there is an issue with equipment not finding the VIP - this is simply the RIP not being ARPable from the DIP – Paul Dixon Jul 29 '10 at 21:59
Try and use arping and other arp utilities to see if broadcasts update the table without readding the route. I still think it may have to do with the broadcast. – Warner Jul 29 '10 at 22:06

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.