====== Резервирование Active/Backup (VRRP) ======
{{indexmenu_n>13}}

<note important>Это предварительное описание для версии 10.3 (предположительно). Его надо дополнить описанием конфигурации keepalived после тестов</note>

Поддержка [[https://ru.wikipedia.org/wiki/VRRP|VRRP]] реализована в СКАТ при помощи Linux-демона [[https://linux.die.net/man/8/keepalived|keepalived]]. 
Собственно VRRP-протокол реализует демон, в котором конфигурируются скрипты вызова CLI-команд для перевода СКАТ в режим master или backup.

В режиме master доступна вся функциональность СКАТ, в режиме backup СКАТ работает только как мост in_dev <-> out_dev, никакие пакеты сам СКАТ не эмитирует. Предполагается, что в режиме backup на СКАТ не должно приходить вообще никакого трафика. Но есть подозрение, что какие-то служебные L2 протоколы, необходимые для функционирования сети оператора, все же могут поступать на СКАТ в режиме backup, - именно поэтому режим прозрачного моста остается включенным в режиме backup.

Поддержка VRRP включается в СКАТ конфигурационным параметром ''vrrp_enable'' в fastdpi.conf:
<code>
    # [hot] Флаг включения поддержки VRRP
    # 0 - выключено (default)
    # 1 - включено
vrrp_enable=1
</code>
По умолчанию поддержка VRRP отключена.

Все СКАТ, входящие в одну 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-командами:
<code>
   # перевести СКАТ в режим master
   # эту команду должен вызывать keepalived-скрипт notify_master
fdpi_cli vrrp set master

   # перевести СКАТ в режим backup
   # эту команду должен вызывать keepalived-скрипт notify_backup
fdpi_cli vrrp set backup
</code>
СКАТ всегда стартует в режиме master. Предполагается, что сразу после старта демон keepalived увидит, что участник VRRP-группы ожил, и вызовет соответствующий скрипт. То есть сразу после старта СКАТ должен быть явно переведен в режим master или backup.
<note warning>Постоянная работа двух или более экземпляров СКАТ одновременно в режиме master является ошибкой. Master должен быть только один.</note>

При переводе СКАТ в режим 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:
<code>
    # Параметры отправки 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
</code>

Текущий режим работы СКАТ можно узнать CLI-командой
<code>
fdpi_cli vrrp stat
</code>

===== Открытые вопросы =====
<note warning>Данный раздел следует удалить после полноценного тестирования. Ответы на вопросы данного раздела в виде  рекомендаций по типовой конфигурации keepalived должны быть в теле основного раздела выше</note>

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).