Traffic not flowing after IP address move between peers

There are several potential causes for this problem, but the most likely is that a switch somewhere between your PBX’s and your default gateway is not updating its ARP table. The ARP table associates your IP address with your MAC address, so it’s still trying to send traffic for the shared IP address to the old PBX’s MAC address (which is no longer active)

When sharing an IP you should configure HAAst to issue ‘ARP Updates’ every time the shared IP address moves. This is configured in the haast.conf file in the ‘voipnic’ stanza, with the ‘arpupdate ‘ key setting (set it to true). Once set to true, HAAst will broadcast to all switches, routers, etc. that the IP address has moved and is now associated with a new MAC address.

This setting solves the problem 99% of the time; however, your switch may be ignoring the update. This might happen for one of several reasons:

1. Switch Security Lockdown: To prevent malicious ARP attacks some switches have locked ARP tables. This means that the network administrator must allow the switch to accept ARP updates for the IP in question.
2. Switch Security Limits: Some switches limit the number of ARP updates to X per minute. If you are experimenting with failover you may have reached the security limit of your switch. Again, the network administrator has to allow more frequent ARP updates for that IP/MAC.
3. Buggy Switch Firmware: Some (particularly old HP or cheap no-name) switches do not handle ARP updates properly. The only solution is to update the switch firmware or look for a new switch.

If you are running HAAst in a cloud/hosting data center, it is common for the data center to lock down ARP tables to prevent malicious/misbehaving clients from affecting their general network. In such cases you will have to notify the data center admin of why you need to permit ARP updates, and possibly for which MAC/IP addresses. Most commercial data centers understand high availability and will have no problem accommodating your request.

Assuming this is not a switch issue (which you confirmed by the arp packet missing in the packet capture), we can diagnose the problem as follows:

1. In one shell set a simple packet capture as follows:

   tcpdump -i ethX -vvv -x arp

2. ethX is the ‘physicaldevice’ setting in haast.conf which should match the ethernet adapter you are using for VoIP traffic.

[*]In another shell issue an arping from the command line (exactly as follows):

arping -U -I ethX -c 5 sharedIP
[*]ethX is the ‘physicaldevice’ key set in haast.conf which should match the ethernet adapter you are using for VoIP traffic.
[*]If ‘vlanid’ is set in haast.conf the “.haast” is appended to the ethX adapter name
[*]sharedIP is the IP address moving between peers, set in the ‘address’ key of the ‘voipnic’ stanza of haast.conf
[*]Stop the tcpdump and show the interface details using ifconfig

ifconfig
[*]Post the full output of command and response from all 3 steps above. If any of the information above is security sensitive (eg: a public IP is in the output) email the above to support@autocommander.aws2.ocg.ca , do not obfuscate the data.

If traffic did not start to flow with the above command (and assuming there were no errors reported above), can you try a variation of the arping syntax that consistently works for you? Please post what worked for you.

If the above arping command generated any errors then we can offer a workaround. Although rare, we have seen the above command syntax fail on a Linux distro that customized its arping command. What distro and arping (from what package) are you using? And what exact syntax would allow the arping command to be successful? If we see enough need for that particular arping syntax we’ll add support directly to HAAst. As well, we can offer a workaround if that’s the only arping package available for your distro.