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, syslogs показывают, что вторичный ящик начинает отправлять беспричинные пакеты ARP (как и ожидалось), но тестовая веб-страница не отключается и вместо этого становится недоступной. Через некоторое время (несколько часов по крайней мере) второй ящик наконец берет управление на себя.

Мне это напоминает кэширование ARP по крайней мере на одном из наших устройств Juniper (маршрутизатор с публичным доступом и отдельный коммутатор). Вместо того, чтобы переопределять тайм-аут по умолчанию (который, как я полагаю, составляет шесть часов), я бы предпочел, чтобы безвозмездный ARP работал так, как (я думаю?) он должен работать и запускать обновление таблицы маршрутизации.

Я считаю, чтоgratuitous-arp-replyнастройка может оказаться полезной здесь. Прежде чем я внесу это изменение в нашу систему, я надеюсь, что кто-то узнает:

• Может быть, я упустил из виду более вероятную причину сбоя аварийного переключения?
• Если проблема в кэшировании ARP, можно ли считать это изменение «стандартным» способом сделать то, что я пытаюсь сделать?
• Если предположить, что периметр корпоративной сети достаточно защищен, будет ли изменение этого параметра представлять собой неоправданный риск для безопасности?
• Есть ли еще какие-то «подводные камни», о которых мне следует знать?

Спасибо.