1

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 

foo1.example.com  ether   00:20:ED:1A:0C:82   C                     eth0
foo2.example.com  ether   00:1E:C9:B0:F6:FE   C                     eth0
bar1.example.com          (incomplete)                              eth0

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
2.2.2.128  *               255.255.255.192 U     0      0        0 eth0
1.1.1.0   *               255.255.255.0   U     0      0        0 eth0
default         1.1.1.1   0.0.0.0         UG    100    0        0 eth0

so I can't ARP that bar1.example.com 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 2.2.2.128/26 dev eth0
ip route add 2.2.2.128/26 dev eth0

If I trigger an ARP lookup by pinging bar1.example.com, the ARP cache will now show 

bar1.example.com  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?

Paul Dixon
  • 1,516
  • 3
  • 23
  • 37

2 Answers2

2

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.

Tim Howland
  • 4,728
  • 2
  • 27
  • 21
0

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.

Warner
  • 23,756
  • 2
  • 59
  • 69
  • 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