Cache Keepalived, Junos e ARP

Question

Estou tentando configurar uma stunnelconfiguração ativa-passiva, com o auxílio do Keepalived, para um endereço IP público no datacenter da nossa empresa. Gostaria de saber se uma reconfiguração de roteador ou switch é recomendada dado o seguinte cenário.

Atualmente, tenho em cada uma das duas caixas do CentOS 6 uma instalação de funcionamento confirmado do stunnel, que faz proxy da conexão para uma página de teste em outro servidor (interno). Baseei a configuração emeste tutorial. (Eu redigi o IP virtual externo, que existe no eth1dispositivo, para proteger os inocentes.)

# Box 1 (primary)
vrrp_script chk_stunnel {           # Requires keepalived-1.1.13
        script "killall -0 stunnel"     # cheaper than pidof
        interval 2                      # check every 2 seconds
        weight 2                        # add 2 points of prio if OK
}

vrrp_instance stunnel_cluster {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    virtual_ipaddress {
        <VIRTUAL IP>/32 dev eth1
    }
    track_script {
        chk_stunnel
    }
}

# Box 2 (secondary)
vrrp_script chk_stunnel {           # Requires keepalived-1.1.13
        script "killall -0 stunnel"     # cheaper than pidof
        interval 2                      # check every 2 seconds
        weight 2                        # add 2 points of prio if OK
}

vrrp_instance stunnel_cluster {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    virtual_ipaddress {
        <VIRTUAL IP>/32 dev eth1
    }
    track_script {
        chk_stunnel
    }
}

Quando desativo a instância primária do stunnel, os syslogs indicam que a caixa secundária começa a enviar pacotes ARP gratuitos (conforme previsto), mas a página da Web de teste não falha e, em vez disso, fica indisponível. Depois de algum tempo (várias horas pelo menos), a segunda caixa finalmente assume o controle.

Para mim, isso soa como cache ARP em pelo menos um de nossos dispositivos Juniper (um roteador público e um switch separado). Em vez de substituir o tempo limite padrão (que acredito ser de seis horas), eu preferiria que o ARP gratuito funcionasse da maneira (eu acho?) que deveria funcionar e acionar uma atualização da tabela de roteamento.

Eu acredito que ogratuitous-arp-replyconfiguração pode ser útil aqui. Antes de fazer essa alteração em nosso sistema, espero que alguém saiba:

• Ignorei um culpado mais provável como a origem da falha de failover?
• Se o problema for o cache ARP, essa alteração parece uma maneira "padrão" de fazer o que estou tentando fazer?
• Supondo um perímetro de rede corporativa razoavelmente protegido, a alteração dessa configuração representa um risco de segurança excessivo?
• Há alguma outra "pegadinha" que eu deveria saber?

Obrigado.