1

How can I properly configure failover IPs in Debian 9? I tried below settings after restart

/etc/init.d/networking restart

new FO IPs are pingable but server goes down for upto 30 minutes. I think there is something missing in interface settings.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface

allow-hotplug eno1

iface eno1 inet static
address Server-IP/26
gateway 89.163.138.65

auto eno2
iface eno2 inet static
address Failover_IP_1 
netmask 255.255.255.255
broadcast Failover_IP_1 

auto eno3
iface eno3 inet static
address Failover_IP_2 
netmask 255.255.255.255
broadcast Failover_IP_2
Mark Fulghum
  • 13
  • 3
  • Netmask 255.255.255.255 suggests a point-to-point link instead of a regular network connection - are `eno2` and `eno3` direct links to an alternate host, for heartbeat and/or some sort of state synchronization? What kind of failover solution are you using, is it `keepalived` or something different? Usually failover IPs are configured through the failover solution, not the main network configuration, as the failover solution must first verify the IPs are not already up at the alternate host before setting them up on the local host. – telcoM Jun 22 '19 at 09:12
  • I need failover IPs to send requests to YouTube it needs 5-10 IPs for high availability on each server. – Mark Fulghum Jun 22 '19 at 11:38

1 Answers1

0

Because I can't know for sure now, I would test using network namespaces if it's possible to use the failover IPs without effect on the "main" IP. I can improve this answer depending on results: I suspect ARP issues caused by "ARP flux" (ie when one interface answers an ARP request on behalf of an other) because of the multiple interfaces on the same LAN.

So I'd remove the additional failover IP settings and would manually run this as root, to use those IP in network namespaces, which will isolate the host from any network issue:

Create namespaces:

ip netns add failover1
ip netns add failover2

Move additional interfaces to namespaces (and stop if this fails):

ip link set eno2 netns failover1 || echo 'No support. stop here.'
ip link set eno3 netns failover2

Configure...

ip -n failover1 link set lo up
ip -n failover2 link set lo up
ip -n failover1 link set eno2 up
ip -n failover2 link set eno3 up

ip -n failover1 address add Failover_IP_1 peer 89.163.138.65 dev eno2
ip -n failover1 route add default via 89.163.138.65
ip -n failover2 address add Failover_IP_2 peer 89.163.138.65 dev eno3
ip -n failover2 route add default via 89.163.138.65

This can work because the provider already ran settings on the gateway to have routes for those additional IPs on the same LAN.

Now the failover addresses should be pingable, without any side effect on server (But there's no service nor firewall set on the network namespaces owning those IPs).

You can run commands from them (but depending on settings, no service might mean no DNS, if the DNS server was running on the host):

ip netns exec failover1 traceroute -n 8.8.8.8

Delete namespaces (which will bring back interfaces to host, as long as nothing was left running in those namespaces):

ip netns delete failover1
ip netns delete failover2

So did it work as described for now?

A.B
  • 31,762
  • 2
  • 62
  • 101
  • @MarkFulghum Hum sorry, but I was expecting a comment before the answer was accepted. How can I know if I should proceed further now with the possible actual ARP issue? This answer is fine as is only to have the host running containers or VMs. In case an actual failover needed (ie: a part of internet is down), this won't help an application running on the host rather than the container, because it won't have direct access to the extra IPs (though it could have access to the containers/VMs). Is that fine? I guess I'll still add ARP stuff later in this answer anyway. – A.B Jun 24 '19 at 05:58
  • Trying to make a model and reproduce something, I can only conclude that it's not really possible to use those failover IPs on additional interfaces (and really have traffic through them) without relying on policy routing (ip rule). Everything should be using eno1 anyway with OP's settings, so I'm puzzled about what problem was present. Not having received any feedback didn't help. I'd delete my answer but I can't because it's accepted. – A.B Jun 25 '19 at 12:14