Questions[keepalived](server)

I'm using keepalived to switch a floating IP between two VMs.

/etc/keepalived/keepalived.conf on VM 1:

vrrp_instance VI_1 {
    state MASTER
    interface ens160
    virtual_router_id 101
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret
    }
    virtual_ipaddress {
        1.2.3.4
    }
}

/etc/keepalived/keepalived.conf on VM 2:

vrrp_instance VI_1 {
    state MASTER
    interface ens160
    virtual_router_id 101
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret
    }
    virtual_ipaddress {
        1.2.3.4
    }
}

This basically works fine, with one exception: Everytime systemd gets updated (it's running Ubuntu 18.04) it reloads it's network component, resulting in dropping the floating IP because it's not configured in the system. Since both keepalived instances still can ping each other, none of them sees anything wrong and none of them reacts on this, resulting in the floating IP staying down.

I found that you can check for the IP with a simple script like this:

vrrp_script chk_proxyip {
    script "/sbin/ip addr |/bin/grep 1.2.3.4"
}

vrrp_instance VI_1 {
    # [...]
    track_script {
        chk_proxyip
    }
}

But I'm not sure if this is a working approach.

If I understand it correctly the following would happen, if I configure this script on VM1:

1. VM1 loses the IP due to a systemd restart
2. keepalived on VM1 detects the loss of the IP
3. keepalived switches to FAULT state and stops broadcasting vrrp packages
4. keepalived on VM2 detects the loss of keepalived on VM1 and puts the floating IP up

At this point the IP is working again on VM2, but VM1 would stay in this state because the IP never comes up again on VM1. If VM2 goes down (for whatever reason) VM1 wouldn't take it over, because it is still in FAULT state.

How can I ensure that the floating IP is always up on one of the VMs?

Further tests:

I tried to ping the floating IP instead of checking if it is active on a specific host in a check_script:

vrrp_script chk_proxyip {
    script "/bin/ping -c 1 -w 1 1.2.3.4"
    interval 2
}

Configuring this script on node 2 resulted in the following:

1. removed the IP on node 1 for testing
2. node 2 detected the IP loss and changed from BACKUP to FAULT
3. node 1 ignored the state change and stayed MASTER

The result: the IP stayed down.

Configuring the script on node 1 resulted in the following:

1. removed the IP on node 1
2. node 1 detected the IP loss and changed from MASTER to FAULT
3. node 2 detected the state change on node 1 and changed from BACKUP to MASTER, configuring the floating IP on node 2

Well, and then ...

Feb 13 10:11:26 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:27 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:29 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:29 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:32 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:33 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:36 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:36 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:38 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:39 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:41 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:41 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:44 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:45 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:47 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
...

I had to restart keepalived on node1 to stop the ping pong game between the nodes.

Is there a way for a keepalived to send gratuitous ARP periodically?

We had following situation:

1. switch failure (VLAN setup)
2. keepalived failovered to backup instance
3. backup instance sent gratuitous ARP but Cisco ASA device didn't got it (because of switch failure)
4. when switch was recovered (few minutes later) VIPs were unaccessible cause ASA did not refresh the ARP table (ARP table expiry is set to 4h)
5. as ASA already had the MACs from previously active node it didn't sent ARP request
6. VIP were unaccessible until we restarted the keepalived instance what initiated new GARP

So, we think that we could avoid this situation with periodical GARPs. Is this a good approach and is there a way to do it within keepalived?

Any other suggestions to avoid this kind of issues?

Keepalived config:

global_defs {
   notification_email {
     [email protected]
   }

   notification_email_from SERVER_1
   smtp_server smtp.server.local
   smtp_connect_timeout 30
   router_id SERVER_1
}

vrrp_instance V1 {
    state BACKUP
    nopreempt
    interface eth0
    lvs_sync_daemon_interface eth0
    virtual_router_id 150
    priority 120
    advert_int 1
    persistence_timeout 0
    smtp_alert

    authentication {
        auth_type PASS
        auth_pass xxx
    }

    virtual_ipaddress {
    10.xxx.xxx.xxx
    }
}

I want to use nopreempt option with keepalived vrrp setting to run backup node as master when master goes down and again reback into network.

I setup nopreempt option in both servers and set state as backup in both servers but due to high priority nopreempt is not working.

Please guide to resolve it?

  Master Machine: 
  ! Configuration File for keepalived
   vrrp_instance VI_1 {
   state BACKUP
   nopreempt
   interface eth0
   virtual_router_id 1
   priority 250
   advert_int 1
   virtual_ipaddress {
    192.168.1.2/24
    } 
  }

  Backup Machine :
  ! Configuration File for keepalived
   vrrp_instance VI_1 {
   state BACKUP
   nopreempt
   interface eth0
   virtual_router_id 1
   priority 200
   advert_int 1
   virtual_ipaddress {
     192.168.1.2/24
   }

}

Regards, Ben

I have set up keepalived on two Debian machines for high availability, but I've run into the maximum number of virtual IP's I can assign to my vrrp_instance. How would I go about configuring and failing over 20+ virtual IP's?

This is the, very simple, setup:

LB01: 10.200.85.1
LB02: 10.200.85.2
Virtual IPs: 10.200.85.100 -  10.200.85.200

Each machine is also running Apache (later Nginx) binding on the virtual IPs for SSL client certificate termination and proxying to backend webservers. The reason I need so many VIP's is the inability to use VirtualHost on HTTPS.

This is my keepalived.conf:

vrrp_script chk_apache2 {
        script "killall -0 apache2"
        interval 2
        weight 2
}

vrrp_instance VI_1 {
        interface eth0
        state MASTER
        virtual_router_id 51
        priority 101
        virtual_ipaddress {
            10.200.85.100
            .
            . all the way to
            .
            10.200.85.200
}

An identical configuration is on the BACKUP machine, and it's working fine, but only up to the 20th IP.

I have found a HOWTO discussing this problem. Basically, they suggest having just one VIP and routing all traffic "via" this one IP, and "all will be well". Is this a good approach? I'm running pfSense firewalls in front of the machines.

Quote from the above link:

ip route add $VNET/N via $VIP

or

route add $VNET netmask w.x.y.z gw $VIP

Thanks in advance.

EDIT:

@David Schwartz said it would make sense to add a route, so I tried adding a static route to the pfSense firewall, but that didn't work as I expected it would.

pfSense route:

Interface:            LAN
Destination network:  10.200.85.200/32 (virtual IP)
Gateway:              10.200.85.100    (floating virtual IP)
Description:          Route to VIP .100

I also made sure I had packet forwarding enabled on my hosts:

$ cat /etc/sysctl.conf
net.ipv4.ip_forward=1
net.ipv4.ip_nonlocal_bind=1

Am I doing this wrong? I also removed all VIPs from the keepalived.conf so it only fails over 10.200.85.100.

I have two machines (A and B, A is Master) running VRPP (from keepalived) for a Virtual IP.

How can I prevent A from becoming Master again if it has failed and come back up (for whatever reason)?

I'm doing this so that we have a single fail-over to the second box, and going back to normal would require manual intervention.