VIP not dropping from backup keepalived

Question

I may not be understanding how this is supposed to work, but I can't figure out why the BACKUP system with this basic vrrp_instance is transitioning to master right away and never seems to honor the priority.

Why wouldn't the virtual IP address drop off the backup system when both are healthy and online?

It looks like both systems are broadcasting the vrrp advertisement. From tcpdump on the backup system:

betaproxyslc01.fakecorp.com > vrrp.mcast.net: vrrp betaproxyslc01.fakecorp.com > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 150, authtype simple, intvl 1s, length 20, >addrs: virtual-app.fakecorp.com auth "password" 15:52:24.541637 IP (tos 0xc0, ttl 255, id 1611, offset 0, flags [none], proto VRRP (112), length 40)

betaproxyslc02.fakecorp.com > vrrp.mcast.net: vrrp betaproxyslc02.fakecorp.com > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 20, >addrs: virtual-app.fakecorp.com auth "password" 15:52:25.410073 IP (tos 0xc0, ttl 255, id 1779, offset 0, flags [none], proto VRRP (112), length 40)

but the virtual IP address is showing up on both hosts with an ip addr command.

Here's the config:

global_defs {
   notification_email {
   [email protected]
   }
   notification_email_from [email protected]
   smtp_server mysmtpserver.fakecorp.com
   smtp_connect_timeout 30
   router_id BETAPROXYSLC01
}

vrrp_script chk_haproxy{
   script "killall -0 haproxy"
   interval 2 # check every 2 seconds
   weight 2   # add 2 points of prio if OK
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    notify /usr/local/bin/notify.sh
    authentication {
        auth_type PASS
        auth_pass keep0ut!
    }
    virtual_ipaddress {
        10.10.0.40
    }
    track_script{
        chk_haproxy
    }
}

On the BACKUP server the router_id is different, state is BACKUP, and priority is 100. The other settings are the same.

This is on CentOS 7 install, with Keepalived v1.2.10 (06/10,2014), a Hyper-V guest VM, with a 3.10.0-123.8.1.el7.x86_64 kernel.

Solution 1

VRRP communication between routers uses multicast IP address 224.0.0.18^[1] and IP protocol number 112^[2].

Thus, you only need to allow incoming and outgoing traffic with these specific parameters for VRRP to work correctly. The firewall rules that are usually mentioned are redundant and unnecessarily widely formulated.

I suggest you use these firewall rules:

firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --in-interface eth0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
firewall-cmd --direct --permanent --add-rule ipv4 filter OUTPUT 0 --out-interface eth0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
firewall-cmd --reload

[1] https://www.rfc-editor.org/rfc/rfc5798#section-5.1.1.2
[2] https://www.rfc-editor.org/rfc/rfc5798#section-5.1.1.4

Solution 2

Referencing the firewall information at the end of this page I was able get it working by opening the firewall with:

firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -i eth0 -d 224.0.0.0/8 -j ACCEPT
firewall-cmd --direct --perm --add-rule ipv4 filter INPUT 0 -i eth0 -d 224.0.0.0/8 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p vrrp -i eth0 -j ACCEPT
firewall-cmd --direct --perm --add-rule ipv4 filter INPUT 0 -p vrrp -i eth0 -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -p vrrp -o eth0 -j ACCEPT
firewall-cmd --direct --perm --add-rule ipv4 filter OUTPUT 0 -p vrrp -o eth0 -j ACCEPT

Only the first (two) options seemed to be necessary. Once I set the rule to accept traffic to the multicast address, the backup system noticed the vrrp traffic, reverted to backup mode, and withdrew the VIP. I suppose what confused me was that I could see the multicast traffic from both systems on both systems with tcpdump.

Comments

[Matthew Ife]

Strange request, but can you provide the last two octets from the IP of both keepalived members?

[Utegrad]

The last two octets from the IP of both members are: 0.38 and 0.39