Четыре Linux-сервера в одной подсети, один теряет линк, и трафик продолжает идти через остальные, потому что маршруты пересчитал OSPF. Такую схему собирают на FRRouting: наборе демонов маршрутизации, который работает поверх обычного ядра Linux. Установка занимает несколько минут, а вся логика описывается через vtysh, единую командную строку для всех демонов.
Короткий ответ: установите пакет frr, включите в /etc/frr/daemons демоны zebra и ospfd, запустите systemctl enable --now frr, затем в vtysh задайте router ospf, уникальный router-id и анонсируйте подсети командой network с указанием area 0. Соседство поднимется автоматически, если узлы видят друг друга по IP, MTU на интерфейсах совпадает, а идентификатор зоны на обоих узлах одинаковый.
Дальше: устройство FRR, точные команды для Ubuntu 24.04 и Debian 12, тонкая настройка cost, hello- и dead-интервалов, чтение состояния соседей через vtysh и разбор причин, по которым соседство застревает в ExStart или Init.
Зачем заменять статические маршруты на OSPF с FRR
Статический маршрут не меняется, пока его не тронет администратор. Если интерфейс, через который он указывает, уходит в down, пакеты теряются до ручной правки конфига или до срабатывания отдельного скрипта, который подменяет запись в таблице маршрутизации. OSPF ведёт себя иначе: каждый узел рассылает hello-пакеты, собирает базу состояния связей и пересчитывает пути, когда топология меняется.
FRRouting (FRR) это форк Quagga, набор демонов маршрутизации для Linux и Unix: zebra, ospfd, bgpd, ripd, isisd и другие. Демоны работают в пространстве пользователя, а маршруты в ядро передаёт zebra. Пример: два Linux-сервера с FRR связаны двумя каналами. Пока живы оба, работает основной путь; при падении канала сосед перестаёт получать hello и через dead-интервал исключает его из расчёта, после чего трафик уходит через второй канал без участия администратора.
OSPF ошибается так же, как любая динамика: неверная маска в анонсе создаёт лишние записи, несовпадающие таймеры ломают соседство, а включение OSPF на внешнем интерфейсе без фильтров открывает сеть для чужих маршрутов. Разбор этих ситуаций идёт в разделах про диагностику и безопасность.
FRR vs статические маршруты: что выбрать в 2026 году
| Критерий | Статические маршруты | OSPF с FRR |
|---|---|---|
| Реакция на отказ канала | Ручная правка или внешний скрипт | Пересчёт топологии и смена пути автоматически |
| Добавление новой подсети | Правка конфигов на всех узлах | Анонс на одном узле, остальные получают префикс |
| Сложность старта | Минимальная, нужны только ip route | Нужны демоны, router-id, зоны, таймеры |
| Нагрузка на администратора | Растёт с числом узлов и маршрутов | Почти не меняется при росте сети |
| Отладка | Вся таблица видна целиком | Требует vtysh и понимания состояний соседства |
Практический пример: в сети появляется подсеть 192.168.20.0/24. Со статикой придётся зайти на каждый узел, который должен знать этот префикс, и добавить маршрут. С OSPF достаточно анонсировать подсеть на одном пограничном узле, и остальные получат её сами.
Для двух-трёх серверов с одним аплинком статика проще и предсказуемее. Как только узлов становится больше, появляются резервные каналы и частая смена сегментов, OSPF экономит часы ручной работы.
Архитектура FRR: демоны zebra и ospfd
zebra управляет таблицей маршрутизации ядра Linux: этот демон переносит маршруты, посчитанные протоколами, в FIB и сообщает остальным демонам о состоянии интерфейсов и адресов. ospfd реализует OSPFv2: рассылает hello, строит базу состояния связей, считает дерево кратчайших путей по алгоритму Дейкстры и отдаёт результат zebra. Общение идёт через локальные сокеты, поэтому каждый демон можно включать и выключать отдельно.
vtysh это единая CLI, которая подключается ко всем запущенным демонам и показывает их конфигурацию в стиле, привычном по Cisco IOS. Файлы лежат в /etc/frr/: daemons, vtysh.conf и frr.conf. Если отключить zebra, ospfd продолжит считать маршруты, но установить их в ядро не сможет, и таблица маршрутизации останется пустой при работающем соседстве.
Готовые примеры конфигураций для нескольких зон и сравнение FRR с BIRD собраны в руководстве по динамической маршрутизации OSPF на Linux с FRR и BIRD.
Установка FRR на Linux: пошаговая инструкция
Пакеты FRR в Debian 12 и Ubuntu 24.04 обычно отстают от актуальной ветки проекта на несколько мажорных версий. Чтобы получить последнюю стабильную версию, FRR ставят из официального apt-репозитория проекта: он поддерживает текущую стабильную ветку для Bookworm и Noble. Помимо пакета frr пригодятся frr-pythontools: Python-инструменты нужны утилитам вроде frr-reload.py, которая применяет изменения конфигурации без полного перезапуска демонов.
Подготовка системы и добавление репозитория FRR
sudo apt update sudo apt install -y curl gnupg lsb-release # 1. импортируйте GPG-ключ репозитория FRR в /usr/share/keyrings # 2. создайте /etc/apt/sources.list.d/frr.list со строкой вида: # deb [signed-by=/usr/share/keyrings/<файл ключа>] <адрес репозитория> <кодовое имя> frr-stable # 3. обновите индексы и установите пакеты sudo apt update sudo apt install -y frr frr-pythontools
Кодовое имя для Debian 12 это bookworm, для Ubuntu 24.04 это noble. Готовые строки подключения с адресом репозитория и именем файла ключа берите на официальной странице загрузки FRR: адрес и схема подписи периодически меняются, а выдуманная по памяти строка приведёт к ошибке установки. Порядок сборки и установки FRR для Ubuntu 24.04 описан в документации FRR по сборке для Ubuntu 24.04 LTS.
Проверка подписи пакетов не формальность. Если apt ругается на отсутствующий публичный ключ или на NO_PUBKEY, значит ключ импортирован в другое место или в строке источника указан неверный signed-by. Тогда apt возьмёт пакет из репозитория дистрибутива, и вы получите старую версию вместо свежей сборки.
Для RHEL 9 и совместимых сборок логика та же, отличается менеджер пакетов: репозиторий подключается файлом в /etc/yum.repos.d/, установка идёт командой dnf install frr.
Включение демонов zebra и ospfd
После установки все демоны выключены. Откройте /etc/frr/daemons и задайте нужные значения:
zebra=yes ospfd=yes bgpd=no ospf6d=no ripd=no isisd=no # остальные строки оставьте в значении no
Затем перезапустите службу: sudo systemctl restart frr. zebra обязателен: без него ospfd не запишет маршруты в ядро, и вы увидите соседей в состоянии Full при пустой таблице маршрутизации.
Запуск службы и первичная проверка
sudo systemctl enable --now frr sudo systemctl status frr sudo vtysh -c "show version" sudo vtysh -c "show daemons" journalctl -u frr -e
show daemons выводит список запущенных процессов: в строке должны быть zebra и ospfd. Если ospfd отсутствует, вернитесь к /etc/frr/daemons и проверьте журнал: частая причина это опечатка в имени демона или незакрытая кавычка в параметрах запуска.
Если Linux-сервер должен закрывать больше сетевых задач, смотрите руководство по программному маршрутизатору на Debian и Ubuntu: там разобраны готовые конфиги FRRouting, настройка параметров ядра и мониторинг.
Настройка OSPF через vtysh: соседство и анонсирование сетей
Вся настройка идёт в vtysh. Вход: sudo vtysh, дальше configure terminal и обычный режим конфигурации. Изменения применяются сразу, а для сохранения в /etc/frr/frr.conf используется write memory.
Базовая конфигурация OSPF: router-id и area 0
router-id это уникальный идентификатор узла в домене OSPF, записывается в формате IPv4-адреса. Он не обязан совпадать с адресом интерфейса, но должен быть уникальным в домене; практично использовать адрес loopback. Без ручного router-id FRR выберет его сам из адресов интерфейсов, и идентификатор может измениться при перезагрузке, что приведёт к лишнему пересчёту топологии.
configure terminal router ospf ospf router-id 10.0.0.1 network 10.0.0.0/24 area 0 exit do write memory
area 0 это backbone-зона. Для схемы из нескольких узлов в одной подсети её достаточно: все интерфейсы попадают в одну зону, и дополнительная иерархия не нужна.
Анонсирование сетей и выбор интерфейсов
Команда network делает две вещи: включает OSPF на интерфейсах, адреса которых попадают в указанный префикс, и анонсирует этот префикс соседям. Синтаксис допускает и CIDR (10.0.0.0/24), и маску с обратным порядком бит (10.0.0.0 0.0.0.255).
Ошибка с маской даёт два разных эффекта. Слишком широкая запись, например network 10.0.0.0/8 area 0, включит OSPF на интерфейсах, где соседство не нужно, и анонсирует чужие подсети. Слишком узкая не совпадёт ни с одним адресом, hello не уйдут с интерфейса, и соседство не поднимется.
Интерфейсы без соседей переводят в passive: сеть продолжает анонсироваться, но hello-пакеты наружу не отправляются.
router ospf passive-interface eth1 end
Маршрут по умолчанию в OSPF не анонсируют через network 0.0.0.0/0. Для этого есть отдельная команда default-information originate, и включают её только на пограничном узле, у которого такой маршрут действительно есть. Иначе весь трафик домена потечёт через один узел.
Тонкая настройка: cost, hello- и dead-интервалы
Метрика cost определяет выбор пути. По умолчанию FRR считает её от пропускной способности интерфейса, и на гигабитных линках значение часто задают вручную, чтобы резервный канал не перетянул трафик раньше времени.
interface eth0 ip ospf cost 10 ip ospf hello-interval 5 ip ospf dead-interval 20 exit
HelloInterval это интервал в секундах между hello-пакетами, которые маршрутизатор отправляет на интерфейсе. По RFC 2328 HelloInterval и RouterDeadInterval должны совпадать у всех маршрутизаторов, подключённых к общей сети, иначе соседство не поднимется. Конкретные штатные значения зависят от типа сети и задаются в конфигурации интерфейса; сверяйте их с RFC 2328 и документацией FRR для вашей версии, а не полагайтесь на память. Уменьшение интервалов ускоряет обнаружение сбоя, но повышает служебный трафик.
Пример для второго узла отличается одним: ospf router-id 10.0.0.2. Остальные параметры, включая таймеры и cost, должны совпадать, если сеть однородная.
Проверка состояния OSPF и диагностика проблем с соседями
Мониторинг строится на четырёх командах vtysh, которые показывают состояние с разных сторон: соседи, интерфейсы, маршруты и база состояния связей.
Команды vtysh для мониторинга OSPF
show ip ospf neighbor show ip ospf interface show ip route ospf show ip ospf database
show ip ospf neighbor выводит соседа, его router-id, состояние и интерфейс. Состояние Full означает, что базы состояния связей синхронизированы и маршруты получены. На широковещательном сегменте два роутера, не выбранные DR или BDR, остаются в 2-Way, и это штатное поведение. Проблема начинается там, где сосед застревает в ExStart или Exchange: стороны не могут договориться о размере пакетов или о параметрах аутентификации. Состояние Init говорит о том, что hello доходят в одну сторону.
show ip ospf interface отдаёт подробности по интерфейсу: зона, стоимость, интервалы hello и dead, роль DR или BDR, число соседей. show ip route ospf перечисляет полученные маршруты, помеченные O и O IA. show ip ospf database показывает записи базы состояния связей и нужен, когда маршрут не появился в таблице, хотя соседство уже поднялось.
Вывод удобно фильтровать: в vtysh работает show ip ospf neighbor | include Full.
Типовые ошибки: MTU mismatch, несовпадение area, firewall
Разный MTU. Отличительная черта: сосед застревает в ExStart, hello ходят, а обмен базами не идёт. Проверка занимает минуту:
ip link show eth0 ping -M do -s 1472 10.0.0.2 tcpdump -i eth0 -n proto 89
Значение 1472 равно 1500 минус 20 байт IP-заголовка и 8 байт ICMP. Если такой ping не проходит, а пакет меньшего размера проходит, MTU на концах линка отличается: выровняйте его на интерфейсах или настройте TCP MSS clamping.
Несовпадение area. Идентификатор зоны должен совпадать на обоих узлах. Если на одном настроено area 0, а на другом area 1, hello-пакеты отбрасываются, и соседство не поднимается даже при полной IP-связности.
Блокировка firewall. OSPF работает непосредственно поверх сетевого уровня IP и получил от IANA номер IP-протокола 89, поэтому правила, написанные только для TCP или UDP-портов, его не пропустят: нужны правила по протоколу, и в nftables, iptables и firewalld номер 89 выделяется отдельно. Поскольку OSPF не использует порты, он не проходит через NAT или PAT, поэтому соседство строят между узлами, которые видят друг друга напрямую, а трансляцию обходят через GRE или IPsec-туннель. История выбора протокола 89 описана в разборе, почему OSPF не использует TCP, а также в истории разработки OSPF.
Что делать, если соседство не поднимается
Диагностика идёт сверху вниз, от процесса к пакетам:
- Проверьте службу: systemctl status frr и vtysh -c "show daemons". В списке обязаны быть zebra и ospfd.
- Посмотрите соседей: show ip ospf neighbor. Пустой вывод означает, что hello не доходят или не отправляются.
- Проверьте IP-связность: ping между адресами интерфейсов.
- Сверьте MTU на обоих концах через ip link show.
- Сверьте зону и анонсы: show ip ospf interface и раздел router ospf в конфигурации.
- Проверьте firewall и промежуточные устройства: нужен протокол 89, а команда tcpdump -i eth0 proto 89 покажет, приходят ли пакеты вообще.
- Включите debug ospf packet hello и посмотрите журнал: в выводе видны параметры hello-пакетов и причины отбрасывания.
debug включают точечно и выключают сразу после проверки командой no debug ospf packet hello: на нагруженном узле он пишет в журнал слишком много строк.
Разбор состояний EXSTART и INIT с готовыми командами для разных вендоров есть в гайде по OSPF для корпоративных сетей.
Безопасность и предупреждение ошибок при настройке OSPF
OSPF по умолчанию доверяет любому узлу, который присылает корректные hello. Этого достаточно, чтобы посторонний маршрутизатор в том же сегменте начал анонсировать свои сети и уводить трафик через себя.
Ограничение соседства через passive-interface
Включайте passive-interface на всех интерфейсах, где соседство не нужно: внешний аплинк, management-сеть, интерфейс в сторону клиентского сегмента. Интерфейс остаётся в OSPF и его сеть анонсируется, но hello не отправляются, и посторонний узел не сможет построить соседство.
router ospf passive-interface default no passive-interface eth0 end
Схема passive-interface default удобнее в больших конфигурациях: сначала закрывают все интерфейсы, затем точечно открывают те, где соседство действительно нужно.
Аутентификация OSPF: md5 и area
Аутентификация не даёт постороннему узлу поднять соседство без знания пароля.
router ospf area 0 authentication message-digest exit interface eth0 ip ospf message-digest-key 1 md5 <пароль> exit
Пароль и номер ключа должны совпадать на всех соседях зоны, иначе состояние соседства не пойдёт дальше Init. MD5 подтверждает подлинность пакетов, но не шифрует их содержимое: топология и префиксы видны в захвате трафика.
В FRR OSPFv2 поддерживается криптографическая аутентификация с хешами MD5 и HMAC-SHA, в том числе через цепочку ключей (key chain), которая задаётся командой вида ip ospf authentication key-chain. Цепочка ключей это логический контейнер для одного или нескольких ключей аутентификации, позволяющий выполнять ротацию и управление ключами. Если в цепочке больше одного ключа, OSPF выбирает ключ с максимальным временем жизни, а ключ с бесконечным временем жизни является предпочтительным. На новых развёртываниях разумно выбирать именно этот вариант: точный синтаксис зависит от версии и приведён в документации FRR по OSPFv2.
FRR не заменяет firewall. Аутентификация защищает протокол, а фильтрация трафика, изоляция management-сети и правила по протоколу 89 остаются на сетевом экране. Анонсируйте только те подсети, которые нужны соседям: лишние записи в базе создают нагрузку и расширяют поле для ошибок.
Если кроме маршрутизации нужен резервный шлюз, посмотрите руководство по отказоустойчивой сети с VRRP, HSRP и OSPF: там собраны схемы резервирования шлюза и таймеры для быстрой сходимости.
Актуальность инструкции для 2026 года и адаптация под вашу среду
Синтаксис ospfd и vtysh в FRR стабилен годами: router ospf, network, passive-interface, ip ospf cost и таймеры выглядят одинаково в разных ветках. Меняются версии, состав поддерживаемых дистрибутивов и способ подключения репозитория.
Версии FRR и дистрибутивы Linux в 2026 году
Целевые платформы для готовых пакетов: Ubuntu 24.04 LTS, Debian 12, RHEL 9. На дистрибутивах с истекшим сроком поддержки FRR собирают из исходников, и это отдельная работа с зависимостями (libyang, protobuf, инструменты сборки).
Номера версий не фиксирую как истину: ветки выпускаются несколько раз в год, и статус пакета в репозитории дистрибутива меняется вместе с ними. Перед установкой сверьте актуальную ветку и список поддерживаемых систем в официальной документации FRR, а также посмотрите, какую версию предлагает apt policy frr в вашей системе.
Проверить сборку после установки можно командой vtysh -c "show version". Первая строка содержит номер версии; при обращении в поддержку проекта он нужен, потому что поведение отдельных команд отличается между мажорными ветками.
OSPFv2 vs OSPFv3: что выбрать для IPv6
OSPFv2 работает с IPv4, для IPv6 нужен отдельный протокол OSPFv3 и отдельный демон ospf6d. Процессы независимы: включив ospf6d, вы не получите IPv4-маршруты, а настройка ospfd ничего не сообщит о состоянии IPv6-соседей.
router ospf6 ospf6 router-id 10.0.0.1 interface eth0 area 0.0.0.0 exit
В OSPFv3 интерфейс включается в OSPFv3 и добавляется в указанную область командой в процессе, а параметры вроде стоимости и MTU задают в режиме интерфейса. Стоимость выходного интерфейса по умолчанию зависит от пропускной способности интерфейса и опорной полосы auto-cost; для OSPFv3 доступны также команды установки MTU интерфейса и игнорирования несовпадения MTU. Точный синтаксис команд смотрите в документации FRR по ospf6d: он отличается между версиями. Диагностика идёт командами show ipv6 ospf6 neighbor и show ipv6 ospf6 interface.
Итоги: когда FRR и OSPF оправданы, а когда нет
Считайте по узлам и каналам. OSPF окупается, когда в сети три и более маршрутизирующих узла, есть резервные пути и топология меняется чаще, чем раз в квартал. Для двух серверов с одним линком статические маршруты проще: их видно целиком в одном файле конфигурации, и отлаживать нечего.
Альтернативы FRR: BIRD (лёгкий, часто выбирают для BGP-фильтрации и работы с полной таблицей маршрутов), Quagga (предшественник FRR, развивается медленнее), OpenBGPD (минималистичный, ориентирован на BGP). Для связки OSPF и BGP в одной инфраструктуре FRR удобен тем, что оба протокола живут под одним vtysh и в одном файле конфигурации.
Примеры связки протоколов для крупных сетей с ускорением сходимости через BFD разобраны в руководстве по настройке OSPF и BGP для крупных сетей.
Перед выводом в продакшен пройдите чек-лист:
- Соседство во всех нужных сегментах в состоянии Full, маршруты видны в show ip route ospf.
- MTU и таймеры совпадают на концах каждого линка.
- passive-interface стоит на всех интерфейсах без соседей.
- Аутентификация включена, пароли и номера ключей совпадают.
- Firewall пропускает протокол 89 только с доверенных адресов.
- Анонсируются только рабочие подсети, маршрут по умолчанию не утекает наружу.
- Резервный путь проверен отключением основного линка на стенде.
Начинайте с тестового стенда из двух виртуальных машин: сломать соседство проще, чем кажется, а сборка стенда занимает меньше времени, чем разбор последствий на рабочем сегменте.