Keepalived、Junos、ARP キャッシュ

Question

Keepalived を利用して、会社のデータセンターのパブリック IP アドレスにアクティブ/パッシブ設定を構成しようとしていますstunnel。次のシナリオでは、ルーターまたはスイッチの再構成が推奨されるかどうかを知りたいです。

現在、2台のCentOS 6ボックスにそれぞれ がインストールされておりstunnel、別の（内部）サーバーのテストページへの接続をプロキシしています。設定は以下に基づいています。このチュートリアルeth1（無実の人々を保護するために、デバイス上に存在する外部仮想 IP は編集しました。 ）

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

のプライマリ インスタンスを停止するとstunnel、セカンダリ ボックスが Gratuitous ARP パケットの送信を開始したことが syslog に記録されます (予想どおり)。ただし、テスト Web ページはフェールオーバーされず、使用できなくなります。しばらくすると (少なくとも数時間後)、2 番目のボックスがようやく引き継ぎます。

これは、少なくとも 1 つの Juniper デバイス (パブリック ルーターと別のスイッチ) で ARP キャッシュが行われているように思われます。デフォルトのタイムアウト (6 時間だと思います) をオーバーライドするのではなく、Gratuitous ARP が (私の考えでは) 想定どおりに動作し、ルーティング テーブルの更新をトリガーするようにしたいと思います。

私は、gratuitous-arp-reply設定はここで役に立つかもしれません。この変更をシステムに適用する前に、次のことを知っておいてください。

• フェイルオーバー失敗の原因として、もっと可能性の高い原因を見落としていませんか?
• ARP キャッシュが問題である場合、この変更は私が実行しようとしていることを実行する「標準的な」方法のように思えますか?
• 企業ネットワーク境界が適切に保護されていると仮定した場合、この設定を変更すると不当なセキュリティ リスクが生じますか?
• 他に知っておくべき「落とし穴」はありますか?

ありがとう。