Multi-homed server with 1 static IP and 1 floating IP (like VRRP) having audio issues.

We’re transitioning a server from a static IP to a “floating” IP which we can switch over to a hot-spare should the primary server fail. This would negate the need to change settings on devices and trunk providers in the event of a failure.

For this example, lets say 172.16.0.2/24 is the old IP, and 192.168.0.2/32 is the new IP. Default GW is 172.16.0.1.

The problems I see:

P1 - the handsets fail to register on the new IP address as “reply” traffic is bound to the old IP.
A1 - I can work around this with a static route ip route add <handset ip>/32 via 172.16.0.1 dev eth0 src 192.168.0.2. This essentially forces a source IP for that specific hand-set, which then is able to register, but then I have 1-way or none audio issues.

P2 - I have the old IP defined in the SIP settings as most traffic is still live and we have some devices behind NAT - This might be what’s causing the audio failure above as RTP is trying to use the wrong IP on the server.

Any help and suggestions on how to work this out is greatly appreciated.

Regards
-Rob

These sound more like Linux questions.

Changing an IP address is always going to be disruptive as I don’t thin IP was designed for this.

One other thing you will need to do is to flush the ARP cache on every machine in the same broadcast areas, as traffic will actually be sent to MAC addresses, not to IP addresses, once the first packet has been sent. I’m not sure if destination unreachable will force an ARP cache refresh.

There is a, high numbered, RFC that addresses the ARP problem by allowing a gratuitous ARP reply.

From my debugging, the problem is specific to SIP/RTP. All other services work fine (the web-ui, tftp etc)
The problem stems from how SIP handles the incoming request, doesn’t track the src IP and replies from a default IP instead.

After extensive digging, this appears to be a “by design” issue with the SIP code.
I was not able to solve the problem and have redesigned around it.