Правильная настройка VRRP

Даже в версии v6 в руководстве рекомендовалось, чтобы IP-адрес, назначенный интерфейсу VRRP, был с маской /32. Дело в том, что в обычном случае подсеть /24 может быть одновременно активна на нескольких маршрутизаторах, и в этой подсети может быть несколько VRRP-интерфейсов, каждый из которых предпочитает свой физический маршрутизатор. Это неизбежно, причем по замыслу, приводит к несимметричной маршрутизации: запрос от хоста в LAN внутри этой /24 проходит через физический маршрутизатор, на котором сейчас поднят IP-шлюз VRRP с маской /32, а ответный пакет к этому хосту идёт через физический маршрутизатор, выбранный шлюзом для всей подсети /24. Проблемы начинаются при использовании stateful-файрволов на этих физических маршрутизаторах, потому что такие файрволы могут корректно работать с несимметричной маршрутизацией только если таблицы отслеживания соединений синхронизированы между ними. В версии v7 такая синхронизация возможна, но она привязана к VRRP и требует очень специфических настроек. С другой стороны, в v7 можно по-прежнему назначить VRRP-интерфейсу адрес с маской /24; если в подсети только один VRRP-интерфейс, то вся подсеть мигрирует между физическими маршрутизаторами вместе с этим VRRP-интерфейсом, а OSPF будет рекламировать её только на том маршрутизаторе, где она сейчас поднята. Но без синхронизации таблиц отслеживания соединений stateful-файрвол всё равно будет разрывать существующие сессии, если VRRP и вся подсеть /24 мигрируют на другой физический маршрутизатор.

Мои тестовые CHR на ROS 7 никогда не работали на ROS 6, и они без проблем принимают адрес с /24 (специально удалял и добавлял заново, чтобы убедиться):

[me@chr-7-1] > ip/address/print where interface=vrrp1
Колонки: ADDRESS, NETWORK, INTERFACE  
ADDRESS           NETWORK        INTERFACE  
15 192.168.216.1/24  192.168.216.0  vrrp1  

[me@chr-7-1] > interface/vrrp/print
Флаги: R - работает; M, F - ошибка  
Колонки: NAME, INTERFACE, MAC-ADDRESS, VRID, PRIORITY, INTERVAL, VERSION, V3-PROTOCOL, SYNC-CONNECTION-TRACKING  
NAME   INTERFACE  MAC-ADDRESS        VRID  PRIORITY  INTERVAL  VERSION  V3-PROTOCOL  SYNC-CONNECTION-TRACKING  
0 RM vrrp1  eoip1      00:00:5E:00:01:01     1       203  1s              3  ipv4         no  

[me@chr-7-2] > ip address/print where interface=vrrp1
Флаги: I, D - динамический  
Колонки: ADDRESS, NETWORK, INTERFACE  
ADDRESS           NETWORK        INTERFACE  
13 I 192.168.216.1/24  192.168.216.0  vrrp1  

[me@chr-7-2] > interface/vrrp/print
Флаги: B, F - ошибка  
Колонки: NAME, INTERFACE, MAC-ADDRESS, VRID, PRIORITY, INTERVAL, VERSION, V3-PROTOCOL, SYNC-CONNECTION-TRACKING  
NAME   INTERFACE  MAC-ADDRESS        VRID  PRIORITY  INTERVAL  VERSION  V3-PROTOCOL  SYNC-CONNECTION-TRACKING  
0 B vrrp1  eoip1      00:00:5E:00:01:01     1       100  1s              3  ipv4         no  

Я не думаю, что достаточно компетентен, чтобы дать окончательный ответ, но в RFC 5798 ничего не сказано про размер подсети, связанный с виртуальным адресом. В том же RFC указано, что может быть несколько виртуальных адресов на интерфейсе; учитывая, как работает VRRP в целом, было бы странно, если бы все они были из одной подсети. Также там не требуется, чтобы основной адрес интерфейса находился в той же подсети, что и любой из виртуальных адресов.

В нём есть буква «i», и из-за этого он считается недействительным? Этот сайт — резервный для VRRP.

Жаль вас разочаровывать, но дело в том, что CHR работают на Hyper-V, который по умолчанию (как и многие другие платформы виртуализации) фильтрует кадры с MAC-адресами источника, отличающимися от собственных виртуальных сетевых карт. Для этого быстрого теста было проще обойти это, используя EoIP-туннель между двумя устройствами, чем менять настройки Hyper-V для самих интерфейсов.