Keepalived、Junos 和 ARP 缓存

Question

我正在尝试stunnel在 Keepalived 的帮助下为我们公司数据中心的公共 IP 地址配置主动-被动设置。我想知道在以下情况下是否建议重新配置路由器或交换机。

我目前在两个 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，系统日志显示辅助设备开始发送无用 ARP 数据包（正如预期的那样），但测试网页并未故障转移，而是变得不可用。一段时间后（至少几个小时），第二个设备终于接管了。

在我看来，这听起来像是至少在我们的一台 Juniper 设备（面向公众的路由器和单独的交换机）上进行了 ARP 缓存。与其覆盖默认超时（我认为是 6 小时），我更愿意让免费 ARP 按照它应该的方式（我认为？）工作并触发路由表更新。

我相信gratuitous-arp-reply设置在这里可能很有用。在我对我们的系统进行此更改之前，我希望有人知道：

• 我是否忽略了更可能导致故障转移失败的罪魁祸首？
• 如果问题在于 ARP 缓存，那么这种改变听起来像是我正在尝试做的“标准”方式吗？
• 假设企业网络边界安全合理，改变此设置是否会带来不合理的安全风险？
• 还有其他我应该知道的“陷阱”吗？

谢谢。