Armazenamento em cache com keepalive, junos e ARP

Question

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

Atualmente tenho em cada uma das duas caixas CentOS 6 uma instalação de trabalho confirmado de stunnel , que faz o proxy da conexão para uma página de teste em outro servidor (interno). Eu baseei a configuração em este tutorial . (Eu editei o IP virtual externo, que existe no dispositivo eth1 , 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 eu derrubar a instância primária de stunnel , 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 fica indisponível. Depois de algum tempo (várias horas pelo menos), a segunda caixa finalmente assume o controle.

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

Acredito que as gratuitous-arp-reply A configuração pode ser útil aqui. Antes de fazer essa alteração em nosso sistema, espero que alguém saiba:

• Eu ignorei uma causa mais provável como a origem da falha de failover?
• Se o cache do ARP é o problema, essa alteração soa como uma maneira "padrão" de fazer o que eu estou tentando fazer?
• Assumindo um perímetro de rede corporativa razoavelmente seguro, a alteração dessa configuração representa um risco de segurança irracional?
• Existem outras "dicas" que eu deveria saber?

Obrigado.