Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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 {
   me@fakecorp.com
   }
   notification_email_from keepalived@betaproxyslc01.fakecorp.com
   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.

share|improve this question
    
Strange request, but can you provide the last two octets from the IP of both keepalived members? –  Matthew Ife Oct 13 at 20:48
    
The last two octets from the IP of both members are: 0.38 and 0.39 –  Utegrad Oct 15 at 17:56

1 Answer 1

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.