FRR (Free Range Routing) - это современный набор демонов маршрутизации, который заменяет устаревшую Quagga и позволяет превратить обычный Linux-сервер в полноценный маршрутизатор с поддержкой BGP, OSPF, IS-IS и других протоколов. Вы получаете активное сообщество, регулярные релизы и интеграцию с systemd из коробки. Это руководство проведет вас от установки FRR до настройки BGP-пиринга в дата-центре и развертывания OSPF в mesh-сетях.
Мы разберем практические сценарии, с которыми сетевые инженеры и системные администраторы сталкиваются ежедневно. Каждый шаг проверен на практике и содержит готовые конфигурации. Материал ориентирован на работу с bare-metal серверами и виртуальными машинами под управлением Debian и Ubuntu. Вы сможете сразу применить инструкции в своей инфраструктуре.
Что такое FRR и зачем он нужен
FRRouting - это форк проекта Quagga, созданный в 2017 году группой разработчиков, недовольных темпами развития оригинала. Ключевые участники - компании Cumulus Networks (ныне часть NVIDIA), Big Switch Networks и сообщество OpenSource-разработчиков. FRR используется как основа сетевого стека в Cumulus Linux и SONiC - операционной системе для коммутаторов от Microsoft.
Архитектура FRR повторяет классическую модель: демон zebra управляет таблицей маршрутизации ядра, а протокольные демоны (bgpd, ospfd, isisd) обмениваются маршрутной информацией с соседними устройствами. Все демоны общаются через zebra, что позволяет комбинировать протоколы и настраивать перераспределение маршрутов между ними.
Типовые сценарии использования FRR:
- BGP-пиринг с провайдерами для анонсирования собственных IP-префиксов
- Организация eBGP/iBGP-сессий между серверами в дата-центре
- Внутренняя маршрутизация через OSPF в кластерах и mesh-сетях
- Построение отказоустойчивых VPN-узлов с динамическим выбором путей
- Замена аппаратных маршрутизаторов на программные решения
Если вам нужно настроить программный маршрутизатор на Linux с нуля, включая DHCP, DNS и мониторинг, обратитесь к практическому руководству по созданию enterprise-маршрутизатора на Debian/Ubuntu. Там разобран полный стек сервисов на базе FRRouting.
FRR vs Quagga: почему стоит перейти
Quagga получала обновления раз в несколько лет. FRR выпускает стабильные релизы каждые 4-6 месяцев. Это не просто косметическое различие - за ним стоят реальные изменения в поддержке протоколов.
Сравнение по ключевым критериям:
- Поддержка RFC. FRR реализует BGP FlowSpec (RFC 8955), BGP-LU, Segment Routing и EVPN. Quagga остановилась на базовом наборе RFC десятилетней давности.
- Интеграция с systemd. FRR поставляется с готовыми unit-файлами, поддержкой watchdog и корректной обработкой сигналов. Quagga требует ручного написания скриптов автозапуска.
- Производительность. FRR использует многопоточную обработку для BGP-сессий. На стенде с 1000 eBGP-пиров FRR обрабатывает обновления в 3-5 раз быстрее Quagga за счет переработанной внутренней очереди сообщений.
- Сообщество. Репозиторий FRR на GitHub имеет более 300 активных контрибьюторов. Баги исправляются в течение недель, а не месяцев.
- Инструментарий. Встроенная поддержка gRPC API для программного управления маршрутизацией и экспорт метрик в Prometheus без дополнительных агентов.
Конфигурационные файлы Quagga совместимы с FRR на 95%. Процесс миграции описан в соответствующем разделе этой статьи.
Установка FRR на Linux и интеграция с systemd
Установка выполняется из официального репозитория FRRouting. На момент написания статьи актуальная стабильная версия - 9.1. Процесс одинаков для Debian 11/12 и Ubuntu 22.04/24.04.
Добавление репозитория и установка:
# Установка зависимостей
apt update && apt install -y curl gnupg2 lsb-release
# Добавление GPG-ключа и репозитория
curl -s https://deb.frrouting.org/frr/keys.gpg | gpg --dearmor > /usr/share/keyrings/frr-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/frr-archive-keyring.gpg] https://deb.frrouting.org/frr $(lsb_release -sc) frr-stable" > /etc/apt/sources.list.d/frr.list
# Установка FRR
apt update && apt install -y frr frr-pythontoolsПосле установки необходимо указать, какие демоны будут запускаться. Файл /etc/frr/daemons содержит список всех доступных демонов с флагами yes/no. Для базовой настройки BGP и OSPF включите zebra, bgpd и ospfd:
zebra=yes
bgpd=yes
ospfd=yes
ospf6d=no
ripd=no
ripngd=no
isisd=no
pimd=no
ldpd=no
nhrpd=no
eigrpd=no
babeld=no
sharpd=no
pbrd=no
bfdd=no
fabricd=no
vrrpd=no
pathd=noПосле изменения файла /etc/frr/daemons перезапустите службу FRR:
systemctl restart frr
systemctl enable frrПроверка статуса всех демонов выполняется одной командой:
systemctl status frrВывод покажет общий статус службы и состояние каждого включенного демона. Для доступа к командной оболочке FRR используйте vtysh:
vtysh
Hello, this is FRRouting (version 9.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.Vtysh предоставляет Cisco-подобный интерфейс командной строки. Вы можете просматривать конфигурацию, состояние протоколов и вносить изменения в реальном времени.
Управление демонами FRR через systemd
FRR использует общий systemd-юнит frr.service, который запускает скрипт /usr/lib/frr/frrinit.sh. Этот скрипт читает /etc/frr/daemons и последовательно запускает каждый включенный демон как дочерний процесс.
Для управления отдельным демоном используйте синтаксис:
/usr/lib/frr/bgpd --start
/usr/lib/frr/bgpd --stop
/usr/lib/frr/bgpd --restartЛоги каждого демона можно просмотреть через journalctl с фильтрацией по идентификатору:
journalctl -u frr -f | grep bgpd
journalctl -t bgpd -fНастройка автоматического перезапуска при сбоях уже включена в стандартном unit-файле FRR. Параметры Restart=on-failure и RestartSec=5s гарантируют, что упавший демон перезапустится через 5 секунд. При необходимости можно увеличить лимит перезапусков, создав override-файл:
systemctl edit frr
[Service]
RestartSec=10s
StartLimitBurst=10
StartLimitIntervalSec=120Типовая проблема - отказ запуска демона из-за занятого порта. Если bgpd не стартует, проверьте, не запущен ли другой экземпляр или процесс, слушающий порт 179/tcp:
ss -tlnp | grep 179Базовая настройка BGP-пиринга в дата-центре
Рассмотрим типовую схему: два сервера в дата-центре, соединенных напрямую через выделенный интерфейс. Задача - организовать eBGP-сессию для обмена маршрутами между ними. Сервер A имеет AS 65001, сервер B - AS 65002.
Схема сети:
- Сервер A: интерфейс eth1 - 10.0.0.1/30, AS 65001
- Сервер B: интерфейс eth1 - 10.0.0.2/30, AS 65002
Настройка интерфейсов на сервере A:
ip addr add 10.0.0.1/30 dev eth1
ip link set eth1 upНастройка интерфейсов на сервере B:
ip addr add 10.0.0.2/30 dev eth1
ip link set eth1 upКонфигурация FRR для сервера A. Войдите в vtysh и выполните:
configure terminal
router bgp 65001
bgp router-id 10.0.0.1
neighbor 10.0.0.2 remote-as 65002
neighbor 10.0.0.2 description "BGP to Server-B"
neighbor 10.0.0.2 timers 10 30
!
address-family ipv4 unicast
network 192.168.1.0/24
neighbor 10.0.0.2 activate
exit-address-family
exit
write memoryКонфигурация FRR для сервера B:
configure terminal
router bgp 65002
bgp router-id 10.0.0.2
neighbor 10.0.0.1 remote-as 65001
neighbor 10.0.0.1 description "BGP to Server-A"
neighbor 10.0.0.1 timers 10 30
!
address-family ipv4 unicast
network 192.168.2.0/24
neighbor 10.0.0.1 activate
exit-address-family
exit
write memoryПроверка установления сессии выполняется командой:
show ip bgp summaryВывод должен показать состояние Established в столбце State/PfxRcd. Если состояние Active или Connect, сессия не установлена - проверьте IP-адреса, номера AS и доступность порта 179/tcp.
Проверка получения маршрутов:
show ip bgp
show ip route bgpДля более сложных сценариев BGP, включая multi-homing и работу с несколькими провайдерами, изучите руководство по настройке BGP на Linux с FRR для multi-homing и отказоустойчивости. Там разобраны манипуляции с local-preference, MED и фильтрация маршрутов.
Настройка аутентификации и фильтрации в BGP
В production-среде BGP-сессия без аутентификации и фильтрации недопустима. Злоумышленник, получивший доступ к сегменту сети, может установить BGP-соседство и анонсировать любые префиксы.
Настройка MD5-аутентификации на обоих концах сессии:
configure terminal
router bgp 65001
neighbor 10.0.0.2 password MySecureP@ssw0rd
exit
write memoryПароль должен совпадать на обоих устройствах. FRR хранит его в конфигурации в зашифрованном виде.
Фильтрация входящих маршрутов через prefix-list. Создайте список разрешенных префиксов и примените его к соседу:
configure terminal
ip prefix-list FROM-SERVER-B seq 5 permit 192.168.2.0/24
ip prefix-list FROM-SERVER-B seq 10 deny any
!
route-map FILTER-IN permit 10
match ip address prefix-list FROM-SERVER-B
!
router bgp 65001
neighbor 10.0.0.2 route-map FILTER-IN in
exit
write memoryЭта конфигурация гарантирует, что сервер A примет от сервера B только маршрут 192.168.2.0/24. Любые другие префиксы будут отброшены. Для исходящих маршрутов создайте аналогичный route-map с ключевым словом out.
Проверка примененных фильтров:
show ip bgp neighbors 10.0.0.2 routes
show ip bgp neighbors 10.0.0.2 advertised-routesРазвертывание OSPF в mesh-сетях
OSPF оптимален для внутренней маршрутизации в сетях с 10-100 узлами. В mesh-топологии каждый узел соединен с каждым, что создает избыточность, но требует правильной настройки OSPF для предотвращения лавинной рассылки LSA.
Рассмотрим сеть из трех серверов, соединенных в полносвязную топологию через VLAN:
- Сервер A: 10.0.1.1/24, router-id 1.1.1.1
- Сервер B: 10.0.1.2/24, router-id 2.2.2.2
- Сервер C: 10.0.1.3/24, router-id 3.3.3.3
Все узлы находятся в одной OSPF-зоне (area 0). Конфигурация сервера A:
configure terminal
router ospf
ospf router-id 1.1.1.1
network 10.0.1.0/24 area 0
passive-interface default
no passive-interface eth1
exit
write memoryКонфигурация серверов B и C аналогична, с заменой router-id на 2.2.2.2 и 3.3.3.3 соответственно. Директива passive-interface default запрещает отправку OSPF-пакетов на всех интерфейсах, кроме явно указанных - это стандартная практика безопасности.
Проверка соседства:
show ip ospf neighborКаждый сервер должен видеть двух соседей в состоянии Full. Проверка таблицы маршрутизации OSPF:
show ip route ospfДля сравнения FRR с альтернативным демоном маршрутизации и изучения особенностей интеграции с оборудованием Cisco и Juniper рекомендую руководство по настройке OSPF на Linux с FRR и BIRD. Там детально разобраны таймеры, аутентификация и multi-area топологии.
Оптимизация OSPF для mesh-сетей
В полносвязной топологии каждый узел является соседом каждого другого. По умолчанию OSPF в broadcast-сети выбирает Designated Router (DR) и Backup DR для сокращения числа LSA-обменов. В mesh-сети выбор DR не дает преимуществ, так как все узлы все равно обмениваются LSA напрямую.
Решение - перевести интерфейсы в режим point-to-point. Это отключает выбор DR/BDR и ускоряет сходимость:
configure terminal
interface eth1
ip ospf network point-to-point
exit
write memoryНастройка таймеров для быстрой сходимости. Значения по умолчанию (hello - 10 секунд, dead - 40 секунд) рассчитаны на консервативные сети. В дата-центре с управляемой задержкой можно сократить таймеры:
configure terminal
interface eth1
ip ospf hello-interval 1
ip ospf dead-interval 3
exit
write memoryПри таких настройках потеря соседа обнаруживается за 3 секунды вместо 40. Это критично для кластеров баз данных и систем с высокими требованиями к доступности.
Аутентификация OSPF-сообщений защищает от подделки LSA. Настройка MD5-аутентификации на всех узлах mesh-сети:
configure terminal
interface eth1
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 MyOspfP@ss
exit
write memoryКлюч и его номер должны совпадать на всех узлах в пределах одной сети. После включения аутентификации соседство временно разрывается до применения настроек на всех устройствах - планируйте изменения в окно обслуживания.
Диагностика и мониторинг динамической маршрутизации
Эффективная диагностика начинается с системного подхода. При проблемах с маршрутизацией проверяйте состояние в следующем порядке: физический уровень, IP-связность, состояние соседства протокола, таблицы маршрутизации, перераспределение маршрутов.
Основные диагностические команды vtysh:
show ip route # Полная таблица маршрутизации
show ip route bgp # Только BGP-маршруты
show ip route ospf # Только OSPF-маршруты
show ip bgp summary # Состояние всех BGP-сессий
show ip bgp neighbors 10.0.0.2 # Детали конкретного соседа
show ip ospf neighbor # Состояние OSPF-соседей
show ip ospf database # База данных LSDB
show ip ospf interface # Параметры OSPF на интерфейсахЛоги FRR находятся в /var/log/frr/. Каждый демон пишет в отдельный файл: bgpd.log, ospfd.log, zebra.log. Уровень логирования настраивается в /etc/frr/frr.conf:
log file /var/log/frr/frr.log
log syslog informationalДля глубокой диагностики можно включить отладку конкретных событий. Используйте debug-команды с осторожностью - на production-системах с большим количеством маршрутов они создают значительную нагрузку:
debug bgp updates in
terminal monitor
После завершения диагностики отключите отладку:
no debug all
Полный цикл настройки мониторинга FRR с Prometheus и Grafana, включая готовый docker-compose и чек-лист для поиска проблем, описан в руководстве по диагностике и мониторингу динамической маршрутизации. Там вы найдете конкретные метрики и дашборды для OSPF и BGP.
Типовые ошибки и их решение
За годы работы с FRR мы выделили повторяющиеся проблемы, с которыми сталкиваются администраторы при настройке динамической маршрутизации.
Ошибка «Connection refused» при подключении к bgpd. Демон bgpd не запущен или не слушает порт 2605/tcp (внутренний порт zebra). Проверьте статус:
systemctl status frr | grep bgpd
netstat -tlnp | grep 2605BGP-сессия не поднимается (состояние Active или Connect). Причина в 90% случаев - firewall или ACL, блокирующие порт 179/tcp. Проверьте правила iptables/nftables:
iptables -L -n -v | grep 179
nft list ruleset | grep 179Разрешающее правило для BGP:
iptables -A INPUT -p tcp --dport 179 -j ACCEPTНесовпадение AS number. BGP-сессия не установится, если номера AS на концах не соответствуют конфигурации. FRR логирует это событие:
grep "AS number" /var/log/frr/bgpd.logПроблемы с MTU. BGP-пакеты с большим количеством атрибутов могут превышать MTU интерфейса. Симптом - сессия устанавливается, но маршруты не передаются. Настройте path MTU discovery или принудительно ограничьте MSS:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuOSPF-соседство застревает в состоянии ExStart. Причина - несовпадение MTU на интерфейсах. OSPF обменивается DBD-пакетами, размер которых зависит от MTU. Проверьте MTU на обоих концах линка:
ip link show eth1 | grep mtuЗначения должны совпадать. При необходимости измените MTU:
ip link set eth1 mtu 1500Несовпадение area ID или параметров аутентификации. OSPF не формирует соседство, если эти параметры различаются. Проверьте конфигурацию на всех узлах:
show running-config | grep -A10 "router ospf"Миграция с Quagga на FRR: практические советы
Конфигурационные файлы Quagga (/etc/quagga/*.conf) совместимы с FRR. Синтаксис команд vtysh идентичен на 95%. Основные различия касаются новых возможностей FRR, которых нет в Quagga.
Процесс миграции на Debian/Ubuntu:
# Остановка Quagga
systemctl stop quagga
systemctl disable quagga
# Установка FRR (репозиторий уже должен быть добавлен)
apt update
apt install -y frr frr-pythontools
# Копирование конфигураций
cp /etc/quagga/zebra.conf /etc/frr/zebra.conf
cp /etc/quagga/bgpd.conf /etc/frr/bgpd.conf
cp /etc/quagga/ospfd.conf /etc/frr/ospfd.conf
chown frr:frr /etc/frr/*.conf
# Включение демонов в /etc/frr/daemons
sed -i 's/zebra=no/zebra=yes/' /etc/frr/daemons
sed -i 's/bgpd=no/bgpd=yes/' /etc/frr/daemons
sed -i 's/ospfd=no/ospfd=yes/' /etc/frr/daemons
# Запуск FRR
systemctl enable frr
systemctl start frrПосле запуска проверьте, что все BGP-сессии и OSPF-соседства восстановились:
vtysh -c "show ip bgp summary"
vtysh -c "show ip ospf neighbor"Специфичные настройки, требующие ручного переноса:
- Route-map с расширенными действиями (FRR поддерживает больше опций match/set)
- Параметры BGP Bestpath (новый синтаксис для некоторых опций)
- Настройки EVPN и VXLAN (отсутствуют в Quagga)
Откат в случае проблем выполняется обратной заменой пакетов. Конфигурационные файлы Quagga рекомендуется сохранить до подтверждения стабильной работы FRR:
tar czf quagga-backup.tar.gz /etc/quagga/После успешной миграции пакеты Quagga можно удалить:
apt purge quagga
apt autoremoveДля проектов, требующих географического распределения и максимальной отказоустойчивости, изучите руководство по построению отказоустойчивой инфраструктуры с BGP и Anycast. Там разобраны сценарии с несколькими дата-центрами и балансировкой нагрузки через маршрутизацию.
FRR превращает Linux-сервер в полноценный маршрутизатор с поддержкой всех современных протоколов динамической маршрутизации. Активная разработка, регулярные релизы и промышленное использование в Cumulus Linux делают его стандартом для программных сетевых решений. Начните с установки из официального репозитория, настройте BGP-пиринг или OSPF по инструкциям из этого руководства, и ваша сеть получит автоматическое перестроение маршрутов при отказах каналов.