Keepalived, Junos und ARP-Caching

Question

Ich versuche, stunnelmithilfe von Keepalived ein Aktiv-Passiv-Setup für eine öffentliche IP-Adresse in unserem Unternehmensrechenzentrum zu konfigurieren. Ich möchte wissen, ob im folgenden Szenario eine Neukonfiguration des Routers oder Switches empfohlen wird.

Ich habe derzeit auf beiden CentOS 6-Rechnern jeweils eine nachweislich funktionierende Installation von stunnel, die die Verbindung zu einer Testseite auf einem anderen (internen) Server überträgt. Die Konfiguration basiert aufdieses Tutorial. (Ich habe die externe virtuelle IP, die auf dem eth1Gerät vorhanden ist, redigiert, um die Unschuldigen zu schützen.)

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

Wenn ich die primäre Instanz von herunterfahre stunnel, zeigen die Syslogs an, dass die sekundäre Box anfängt, unaufgefordert ARP-Pakete zu senden (wie erwartet), aber die Test-Webseite wird nicht umgeschaltet, sondern ist nicht mehr verfügbar. Nach einiger Zeit (mindestens mehrere Stunden) übernimmt schließlich die zweite Box.

Für mich klingt das nach ARP-Caching auf mindestens einem unserer Juniper-Geräte (einem öffentlich zugänglichen Router und einem separaten Switch). Anstatt das Standard-Timeout (das meines Wissens sechs Stunden beträgt) zu überschreiben, würde ich es vorziehen, wenn das Gratuous ARP so funktionieren würde, wie es (glaube ich?) funktionieren soll, und eine Aktualisierung der Routing-Tabelle auslösen würde.

Ich glaube, dass diegratuitous-arp-replyEinstellung kann sich hier als nützlich erweisen. Bevor ich diese Änderung an unserem System vornehme, hoffe ich, dass jemand Folgendes weiß:

• Habe ich einen wahrscheinlicheren Grund für den Failover-Fehler übersehen?
• Wenn das ARP-Caching das Problem ist, klingt diese Änderung dann wie eine „Standard“-Methode für das, was ich versuche?
• Stellt eine Änderung dieser Einstellung ein unangemessenes Sicherheitsrisiko dar, wenn man von einem ausreichend gesicherten Unternehmensnetzwerkperimeter ausgeht?
• Gibt es noch andere Fallstricke, die ich kennen sollte?

Danke schön.