VIP não está caindo do backup keepalived

Question

Eu posso não estar entendendo como isso deve funcionar, mas não consigo entender por que o sistema BACKUP com essa vrrp_instance básica está passando para dominar imediatamente e nunca parece honrar a prioridade.

Por que o endereço IP virtual não cai do sistema de backup quando os dois estão íntegros e online?

Parece que ambos os sistemas estão transmitindo o anúncio vrrp. De tcpdump no sistema de backup:

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)

mas o endereço IP virtual está aparecendo nos dois hosts com um comando ip addr .

Aqui está a configuração:

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
    }
}

No servidor BACKUP, o router_id é diferente, o estado é BACKUP e a prioridade é 100. As outras configurações são as mesmas.

Isso está na instalação do CentOS 7, com o Keepalived v1.2.10 (06 / 10,2014), uma VM guest do Hyper-V, com um kernel 3.10.0-123.8.1.el7.x86_64.

    

Answer 1

A comunicação VRRP entre roteadores usa o endereço IP multicast 224.0.0.18 ^[1] e o número do protocolo IP 112 ^[2] .

Assim, você só precisa permitir tráfego de entrada e saída com estes parâmetros específicos para o VRRP funcionar corretamente. As regras de firewall que são geralmente mencionadas são redundantes e desnecessariamente amplamente formuladas.

Sugiro que você use estas regras de firewall:

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] link
[2] link

    

Answer 2

Referenciando as informações do firewall no final de esta página Consegui que funcionasse abrindo o firewall com:

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

Apenas as primeiras (duas) opções pareciam ser necessárias. Depois de definir a regra para aceitar tráfego para o endereço multicast, o sistema de backup notou o tráfego vrrp, reverteu para o modo de backup e retirou o VIP. Suponho que o que me confundiu foi que eu pude ver o tráfego multicast de ambos os sistemas em ambos os sistemas com o tcpdump.