Как записать VRRP в NetBox: куда привязать общий VIP и отдельные IP двух маршрутизаторов

Один IP-адрес в NetBox нельзя одновременно назначить и группе FHRP, и интерфейсу устройства — из-за этого при заведении VRRP многие теряются: общий VIP есть, а куда девать реальные адреса двух маршрутизаторов, непонятно. Разбираю схему из трёх адресов, которая закрывает эту задачу без костылей.

Путаница: один IP не может принадлежать сразу двум объектам

Первая попытка завести VRRP в NetBox обычно выглядит так: администратор создаёт FHRP-группу, назначает ей виртуальный IP — и на этом застревает. Реальные адреса двух маршрутизаторов, которые физически стоят на портах и обмениваются VRRP-пакетами, никак не получается связать с той же самой группой напрямую, потому что при попытке назначить IP-адрес устройству форма не даёт одновременно указать, что он же относится к FHRP-группе. В NetBox это ограничение модели, а не баг: IP-адрес занимает ровно одну связь — либо assigned_object устройства/интерфейса, либо привязку к группе.

Отсюда рождается вопрос, с которым чаще всего приходят: «У меня в VRRP участвует три адреса — общий VIP и по одному на каждый роутер — как записать все три так, чтобы из карточки VIP было видно оба маршрутизатора?». Ответ на GitHub дал сам мейнтейнер проекта Джереми Стретч ещё в феврале 2023 года в обсуждении «Bind FHRP IP to a device» (#11649), и с тех пор схема не менялась — она использует не один объект, а связку из двух моделей, которые в NetBox сознательно разделены. Разбор таких моделей данных — стандартная часть внедрения NetBox, которым мы занимаемся: без понимания разницы между FHRPGroup и её привязкой к интерфейсу документация расходится с реальной сетью в первую же неделю.

Я регулярно натыкаюсь на эту путаницу у клиентов, которые сами заводят сетевую документацию в NetBox без предварительного разбора модели данных IPAM. Последний раз — у художественной школы «Кисть и холст» (33 рабочих места, разберу кейс ниже), где администратор потратил вечер на попытки «впихнуть» реальный IP роутера в форму FHRP-группы, прежде чем понял, что это в принципе не тот объект.

Две разные модели: FHRPGroup и FHRPGroupAssignment

В IPAM NetBox first-hop redundancy protocol описан двумя связанными, но разными сущностями. Первая — FHRP Group: она описывает саму избыточную конфигурацию, а не устройства. У неё есть поле Protocol (страница документации перечисляет HSRP, VRRP, CARP и GLBP, а в самом выпадающем списке VRRP разделён на VRRPv2 и VRRPv3, плюс есть Check Point ClusterXL и Other — выбирайте версию, которая реально работает на роутерах), Group ID — числовой идентификатор группы, как он настроен на самих маршрутизаторах, опциональное Name для человекочитаемой подписи, и пара полей аутентификации — Authentication Type (Plaintext или MD5) и Authentication Key. При создании группы можно сразу же создать и виртуальный IP — он автоматически назначается новой группе; можно и привязать существующий VIP позже, это не обязательно делать одним действием.

Вторая модель — FHRP Group Assignment, и это как раз то звено, которого не хватает в первой попытке. Она не хранит IP-адрес — она связывает уже существующую FHRP-группу с конкретным интерфейсом устройства или виртуальной машины. Документация формулирует это прямо: «member device and VM interfaces can be assigned to FHRP groups to indicate their participation in maintaining a common virtual IP address». То есть группа — это абстракция самого VRRP-инстанса с его VIP, а привязка группы к интерфейсам конкретных маршрутизаторов — отдельный набор записей, по одной на каждый участвующий интерфейс.

Из этого прямо следует ответ на изначальный вопрос: реальный IP маршрутизатора не привязывается к FHRP-группе вообще. Он остаётся обычным IP-адресом, назначенным напрямую интерфейсу устройства — точно так же, как любой другой адрес в IPAM. Связь с VRRP-группой у этого интерфейса появляется не через IP-адрес, а через отдельную запись FHRPGroupAssignment на этом же интерфейсе.

Правильная схема: три адреса, три разных объекта

Схема, которую предложил Джереми Стретч в обсуждении на GitHub, использует классический пример подсети 192.0.2.0/24: адрес 192.0.2.1 назначается FHRP-группе как общий VIP, 192.0.2.2 назначается напрямую интерфейсу первого маршрутизатора, 192.0.2.3 — напрямую интерфейсу второго. Ничего экзотического: два «обычных» адреса роутеров заводятся так же, как любые другие IP на интерфейсах, а VIP — единственный адрес, который относится к группе, а не к устройству.

Связка с устройством у VIP появляется не напрямую, а через интерфейс. Когда автор вопроса летом 2023-го вернулся в тред с тем же сомнением, другие участники ответили ему точно: «They're also on the same interface — that's what links them to the device», и ещё короче — адрес VRRP назначается FHRP-группе, а сама группа назначается одному или нескольким интерфейсам устройств. То есть на интерфейсе первого маршрутизатора одновременно существуют собственный IP 192.0.2.2 (обычная запись IPAM, назначенная этому интерфейсу) и запись FHRPGroupAssignment, которая привязывает этот же интерфейс к FHRP-группе с VIP 192.0.2.1. Открыв карточку группы или самого VIP-адреса, вы увидите список интерфейсов, участвующих в группе — а уже с карточки конкретного интерфейса откроются его собственные адреса.

На практике в NetBox это два раздельных действия в интерфейсе: сначала на странице интерфейса маршрутизатора назначаете ему обычный IP-адрес (192.0.2.2 или 192.0.2.3), затем на той же странице интерфейса — во вкладке FHRP-групп — добавляете назначение (assignment), выбирая уже существующую группу с VIP. Ни то, ни другое не требует правки самого VIP-адреса 192.0.2.1: он создаётся и назначается группе один раз, а маршрутизаторы просто подключаются к группе через свои интерфейсы.

VRF и глобальная таблица: где физически живут все три адреса

Отдельный момент из того же ответа мейнтейнера, который легко упустить: все три адреса — VIP и оба реальных IP маршрутизаторов — должны принадлежать одному и тому же VRF, либо все три лежать в глобальной таблице маршрутизации, если VRF в сети не используется. Смешивать нельзя: если VIP заведён в глобальной таблице, а реальный адрес одного из роутеров — в VRF, с точки зрения NetBox это разные пространства адресации, и модель перестаёт логически соответствовать тому, что физически настроено на маршрутизаторах.

Если у вас, как в примере из обсуждения на GitHub, несколько VRF на разных сегментах — по одному VRF на VLAN с отдельным транзитным VRF до аплинка, — правило простое: схема из трёх адресов повторяется отдельно для каждого VRF. Общий VIP каждого VRF получает свою собственную FHRP-группу (даже если Group ID на маршрутизаторах формально один и тот же для всех сегментов), и к каждой группе отдельно привязываются интерфейсы, которые физически обслуживают именно этот VRF. Технически NetBox не запретит повесить на одну группу VIP из разных VRF, но делать так не нужно — это разные VRRP-инстансы даже с точки зрения самого протокола, и документация перестанет отвечать на вопрос «какой шлюз у этого сегмента».

На MikroTik та же логика VRRP настраивается прямо в RouterOS — я подробно разбирал это в материале про продвинутую офисную сеть с OSPF, VRRP и QoS. NetBox здесь не подменяет конфигурацию на самих маршрутизаторах, а фиксирует её: Group ID, приоритеты и адреса в NetBox должны быть зеркалом того, что реально прописано в /interface vrrp на устройствах, а не отдельной параллельной версией правды.

Priority: кто станет master, если оба маршрутизатора живы

Поле Priority у FHRPGroupAssignment принимает значение от 0 до 255 — оно и указывает NetBox, чему соответствует роль каждого интерфейса в реальном протоколе VRRP: как сформулировано в документации, это «a value between 0 and 255 indicating the interface's priority for being elected as the master/primary node in the group». Записывайте туда именно то значение, которое реально прописано в конфигурации VRRP на маршрутизаторе (обычно 100 — умолчание, выше — предпочтительный master), а не произвольную метку «главный/резервный» — иначе документация начнёт расходиться с реальной конфигурацией уже в момент заведения.

Практический смысл в том, что при трёх и более участниках (для офисного VRRP редкость, но в кампусных сетях с HSRP или GLBP, где у группы несколько активных форвардеров, — обычная конфигурация) именно приоритет в NetBox показывает реальную иерархию выборов master, не полагаясь на порядок создания записей. Документация прямо приводит пример с тремя интерфейсами разных маршрутизаторов в одной группе: «each of these assignments would typically receive a different priority» — то есть разный приоритет у каждого участника это норма, а не редкий случай, который стоит проверять отдельно. Для более сложной отказоустойчивости — не двух пограничных маршрутизаторов, а кластера балансировщиков — схема несколько другая, я разбирал её в статье про HAProxy и Keepalived; принцип общего VIP там тот же самый, VRRP лежит в основе и Keepalived.

Authentication Key: почему не стоит держать боевой пароль VRRP в NetBox как есть

У FHRP-группы есть поля Authentication Type и Authentication Key — можно записать, каким способом аутентифицируются участники группы и сам ключ. Документация здесь даёт прямое предупреждение: «the authentication key value is stored in plaintext in NetBox's database. Do not utilize this field if you require encryption at rest for shared keys». То есть NetBox не шифрует это поле на уровне хранения — значение лежит в базе так же, как оно было введено. И ещё одна деталь, о которой забывают: аутентификация есть только в VRRPv2, в VRRPv3 (RFC 5798) её убрали из протокола, так что для группы VRRPv3 поля Authentication Type и Key в NetBox честнее оставить пустыми.

Практический вывод простой: если ваша политика ИБ требует шифрования секретов at rest (а для пароля VRRP, который по факту защищает контроль над шлюзом сегмента сети, это разумное требование), заносите в это поле не сам боевой ключ, а ссылку на запись в менеджере секретов — или используйте специализированный плагин для секретов, если он у вас уже развёрнут в NetBox, вместо штатного поля Authentication Key. Для тестовых стендов и лабораторий поле удобно использовать как есть, но переносить эту привычку на прод без учёта того, что ключ лежит открытым текстом, не стоит.

На практике я вижу два разумных сценария. Если у вас уже есть отдельное хранилище секретов (Vault, KeePass с общим доступом ИТ-команде, тот же плагин секретов внутри NetBox с собственным шифрованием) — в Authentication Key пишите не значение, а короткую пометку вида «см. секрет VRRP-gw-01» и ссылку на запись. Если отдельного хранилища нет и VRRP-пароль и так известен всем, кто имеет доступ к конфигурации маршрутизаторов (частый случай для малого офиса на 20–40 рабочих мест) — хранить открытым текстом в NetBox не хуже, чем он и так лежит открытым текстом в running-config, и большого дополнительного риска это не добавляет.

Кейс: художественная школа «Кисть и холст», 33 рабочих места

У клиента — два пограничных маршрутизатора на входе в сеть школы, настроенные в VRRP-паре для отказоустойчивости шлюза основного сегмента (компьютерный класс, административная сеть, Wi-Fi для преподавателей). NetBox школа завела сама, по тому же принципу «сначала общая документация инфраструктуры вместо Excel, детали потом», который я обычно рекомендую для старта — и это нормальная последовательность, просто FHRP-группы обычно остаются в списке «деталей на потом» дольше всего. До обращения к нам в NetBox была заведена только FHRP-группа с общим VIP — администратор школы прочитал документацию по FHRP-группам, но не дошёл до раздела про FHRP Group Assignments, и решил, что реальные адреса маршрутизаторов просто некуда девать в этой модели данных.

Мы завели оба маршрутизатора как устройства с их интерфейсами, назначили каждому реальный IP напрямую на интерфейс (адреса из подсети школы, не публикую здесь реальные — в статье используются условные 192.0.2.x по примеру из документации), а затем добавили на каждом из этих интерфейсов запись FHRPGroupAssignment с привязкой к уже существующей группе VIP шлюза: главному маршрутизатору — приоритет 150, резервному — 100, в точности как прописано в их VRRP-конфигурации на оборудовании. Все три адреса — VIP и оба реальных — лежат в глобальной таблице маршрутизации, отдельных VRF в сети школы нет, так что повторять схему было не нужно.

Работа заняла около 40 минут вместе с проверкой по интерфейсам обоих маршрутизаторов. Результат — карточка VIP-адреса в NetBox теперь одним кликом показывает оба интерфейса-участника с их приоритетами, и при следующей замене резервного маршрутизатора (школа планирует обновление оборудования в следующем учебном году) администратор будет ориентироваться на актуальную схему в NetBox, а не вспоминать по памяти, какой адрес на каком порту был прописан два года назад.

Частые вопросы