Almacenamiento en caché Keepalived, Junos y ARP

Question

Estoy intentando configurar una stunnelconfiguración activa-pasiva, con la ayuda de Keepalived, para una dirección IP pública en el centro de datos de nuestra empresa. Me gustaría saber si se recomienda la reconfiguración de un enrutador o conmutador dado el siguiente escenario.

Actualmente tengo en cada una de las dos cajas CentOS 6 una instalación de funcionamiento confirmado de stunnel, que envía la conexión a una página de prueba en otro servidor (interno). Basé la configuración eneste tutorial. (He redactado la IP virtual externa, que existe en el eth1dispositivo, para proteger a los 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
    }
}

Cuando elimino la instancia principal de stunnel, los syslogs indican que el cuadro secundario comienza a enviar paquetes ARP gratuitos (como se anticipó), pero la página web de prueba no falla y, en cambio, deja de estar disponible. Después de un tiempo (al menos varias horas), la segunda caja finalmente toma el control.

Para mí, esto suena como almacenamiento en caché ARP en al menos uno de nuestros dispositivos Juniper (un enrutador público y un conmutador separado). En lugar de anular el tiempo de espera predeterminado (que creo que es de seis horas), preferiría que el ARP gratuito funcione de la forma (¿creo?) que se supone que debe funcionar y active una actualización de la tabla de enrutamiento.

Yo creo que elgratuitous-arp-replyLa configuración puede resultar útil aquí. Antes de realizar este cambio en nuestro sistema, espero que alguien sepa:

• ¿He pasado por alto a un culpable más probable como la fuente del error de conmutación por error?
• Si el problema es el almacenamiento en caché de ARP, ¿este cambio parece una forma "estándar" de hacer lo que estoy tratando de hacer?
• Suponiendo un perímetro de red corporativa razonablemente seguro, ¿cambiar esta configuración representa un riesgo de seguridad irrazonable?
• ¿Hay otros "errores" que debería saber?

Gracias.