Keepalived、Junos 和 ARP 緩存

Question

我正在嘗試stunnel在 Keepalived 的幫助下為我們公司資料中心的公共 IP 位址配置主動-被動設定。我想知道在以下情況下是否建議重新設定路由器或交換器。

目前，我在兩個 CentOS 6 機器上都安裝了已確認工作的stunnel，它代理到另一台（內部）伺服器上的測試頁面的連接。我的配置是基於本教程。 （我已經編輯了裝置上存在的外部虛擬IP eth1，以保護無辜者。）

# 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，系統日誌指示輔助設備開始發送免費 ARP 封包（如預期），但測試網頁不會進行故障轉移，而是變得不可用。一段時間後（至少幾個小時），第二個盒子終於接管了。

對我來說，這聽起來像是至少在我們的一台 Juniper 設備（面向公眾的路由器和單獨的交換器）上進行 ARP 快取。我不想覆蓋預設超時（我認為是六個小時），而是更願意讓免費 ARP 以其應有的方式工作（我認為？）並觸發路由表更新。

我相信gratuitous-arp-reply設定在這裡可能很有用。在對我們的系統進行此更改之前，我希望有人會知道：

• 我是否忽略了作為故障轉移失敗根源的更可能的罪魁禍首？
• 如果 ARP 快取是問題所在，那麼此變更聽起來是否是實現我想要做的事情的「標準」方法？
• 假設公司網路邊界相當安全，更改此設定是否會帶來不合理的安全風險？
• 還有其他我應該知道的「陷阱」嗎？

謝謝。