VRRP support is implemented in SSG using the Linux daemon keepalived. It configures scripts for calling CLI commands to put SCAT in master or backup mode.

In master mode, all SSG functionality is available. In backup mode, SSG works only as a bridge in_dev ↔ out_dev, no packets are emitted by SSG itself. It is supposed that in backup mode no traffic should come to SSG at all. But it seems that some service L2 protocols necessary for the operator's network may still arrive at the SSG in backup mode, which is why the transparent bridge mode remains enabled in backup mode.

VRRP support is enabled in SSG by configuration parameter vrrp_enable in fastdpi.conf:

    # [hot] Flag to enable VRRP support
    # 0 - disabled (default)
    # 1 - enabled
vrrp_enable=1

VRRP support is disabled by default.

Все СКАТ, входящие в одну VRRP-группу, должны иметь одинаковую конфигурацию. В частности, следующие параметры обязательно должны быть заданы и быть одинаковыми во всех СКАТ VRRP-группы, так как они задают виртуальные MAC и IP-адреса:

• bras_arp_mac - виртуальный MAC-адрес СКАТ
• bras_arp_ip - виртуальный IP-адрес СКАТ

Если включена поддержка IPv6, то также должны быть заданы и быть одинаковыми параметры bras_ipv6_link_local и bras_ipv6_address - виртуальные link-local и глобальный IPv6-адреса соответственно.

Перевод СКАТ в режим master/backup производится CLI-командами:

   # перевести СКАТ в режим master
   # эту команду должен вызывать keepalived-скрипт notify_master
fdpi_cli vrrp set master

   # перевести СКАТ в режим backup
   # эту команду должен вызывать keepalived-скрипт notify_backup
fdpi_cli vrrp set backup

СКАТ всегда стартует в режиме master. Предполагается, что сразу после старта демон keepalived увидит, что участник VRRP-группы ожил, и вызовет соответствующий скрипт. То есть сразу после старта СКАТ должен быть явно переведен в режим master или backup.

При переводе СКАТ в режим master CLI-командой fdpi_cli vrrp set master СКАТ посылает gARP (gratuitous ARP) на все свои in и out-интерфейсы, чтобы сообщить коммутаторам, что виртуальный MAC и IP адреса (bras_arp_mac и bras_arp_ip соответственно) теперь находятся на портах коммутаторов, к которым подключен данный экземпляр СКАТ. Получив такой gARP, коммутатор должен понять, что виртуальный MAC/IP-адрес СКАТ теперь находится на данном порту, и переключить весь трафик на этот СКАТ (в этот порт). Число gARP-оповещений и интервал между ними регулируются следующими параметрами fastdpi.conf:

    # Параметры отправки gratuitous ARP при переходе в master-режим
    # gratuitous ARP отправляются на все интерфейсы СКАТа
    # На каждый интерфейс отправляется vrrp_arp_count gratuitous ARP пакетов
    # с интервалом между пакетами vrrp_arp_timeout секунд
    #
    # [hot] Тайм-аут между отправками, секунд (default=1)
#vrrp_arp_timeout=1
    # [hot] Число повторных отправок, default=10
#vrrp_arp_count=10

Текущий режим работы СКАТ можно узнать CLI-командой

fdpi_cli vrrp stat

1. keepalived привязывается к конкретному интерфейсу, через который идет обмен VRRP-пакетами. Это обычный интерфейс Linux (управляющий, ctl-интерфейс), а не in/out девайс СКАТ. Собственно, именно на этот интерфейс keepalived назначает виртуальный IP-адрес при переходе в режим master. Нам же нужно, чтобы в идеале keepalived не привязывал наш виртуальный IP-адрес на этот интерфейс, а просто вызывал скрипты перевода СКАТ в режим master или backup.

2. Аналогично п.1 - при переводе в master демон keepalived шлет gARP через управляющий интерфейс. Нам также этого не нужно (быть может, это даже вредно).

3. Если п.1 и п.2 нерешаемы в рамках конфигурации keepalived, можно рассмотреть возможность работы keepalived через vlan-интерфейсы, созданные на ctl-интерфейсе. Для всех компьютеров VRRP-группы на их ctl-интерфейсах Linux создаем vlan-интерфейсы с уникальным vlan, выделенном для VRRP, и привязываем keepalived именно к этим vlan-интерфейсам. Тогда пусть keepalived назначает виртуальные IP-адреса на эти vlan-интерфейсы и рассылает gARP через них, - это не должно никому помешать. Нам важно только, чтобы keepalived вовремя вызывал скрипты master/backup.

4. Проверить, как поведут себя коммутаторы, подключенные к СКАТ к in/out девайсам, в vlan/qinq-сетях. Дело в том, что СКАТ рассылает обучающие gARP без всяких VLAN. Распознают ли в этом случае коммутаторы, что трафик нужно переключать с портов СКАТ-1 на порты СКАТ-2 в случае перевода СКАТ-2 в master-режим (а СКАТ-1, соответственно, в backup).