FRR vs BIRD в 2026: что выбрать для BGP на Linux и как не ошибиться в политике маршрутов

Если вы поднимаете BGP на Linux (в облаке, в стойке, на пограничных серверах), то в 2026 году выбор чаще всего сводится к двум лагерям: FRR и BIRD. Оба зрелые, быстрые и широко применяются, но их сильные стороны проявляются в разных сценариях: от простого eBGP-пиринга до фабрики route reflectors и сложной route policy с communities.

Ниже — сравнение без маркетинга: как они живут в проде, где проще отлаживать политику, что учитывать в graceful restart, как строить RR и как организовать мониторинг так, чтобы ловить не только «Established», но и реальные аварийные симптомы.

Короткая карта выбора (если нужно решить быстро)

Если сильно упростить:

• FRR чаще выбирают, когда нужна «маршрутизаторная» модель управления, привычный CLI, быстрые интерактивные проверки и богатый набор сетевых сущностей (prefix-list, route-map, peer-group, VRF).
• BIRD чаще выбирают, когда важны компактные конфиги, очень читаемая фильтрация «как код», предсказуемость выкладок и лёгкая шаблонизация однотипных BGP-узлов (anycast/edge/IX).

Нормальная стратегия: понимать оба инструмента. В сетевых командах с сильной CLI-культурой FRR часто снижает трение, а в GitOps-подходе и при «политике как код» BIRD обычно проще держать в порядке.

Архитектура и модель управления: что будет удобнее в эксплуатации

FRR: набор демонов + vtysh

FRR — это несколько демонов (типично zebra и bgpd), которые общаются между собой и с ядром Linux. Операционная работа обычно идёт через vtysh — CLI, похожий на сетевое железо. Это удобно, когда нужно быстро ответить на вопросы «что происходит прямо сейчас», «почему не принялось», «какие атрибуты у маршрута».

Практическая особенность FRR — ощущение «живой системы»: можно править в CLI и сохранять. В проде это не проблема, если вы заранее договорились, как именно живёт конфиг (GitOps/шаблоны/запрет ручных правок/ревью).

BIRD: один демон + декларативные фильтры

BIRD чаще воспринимается как конфиг-ориентированный демон: вы описываете протоколы и фильтры, а фильтры выглядят как мини-язык. Это снижает риск скрытых «магических» состояний, упрощает аудит и делает конфигурацию удобной для генерации.

На практике BIRD любят команды, которые хотят держать политики максимально читаемыми и проверяемыми диффом: что импортируем, что экспортируем, где меняем local-pref, где добавляем communities, где режем длину префикса.

Route policy: где проще не ошибиться

Самый частый BGP-инцидент — не падение демона, а ошибка политики. Типовые сценарии: «выпустили лишнее», «не отфильтровали чужое», «забыли ограничить длину», «внезапно приняли слишком много (вплоть до full table)», «не проставили/не вычистили communities».

FRR: prefix-list + community-list + route-map

В FRR политика обычно строится из трёх привычных блоков:

• ip prefix-list — матчи по префиксам и длинам;
• bgp community-list — матчи по communities;
• route-map — порядок условий и действий (permit/deny, set local-pref, set community и т.д.).

Плюс — модель максимально знакома сетевикам. Минус — порядок строк в route-map действительно важен: «лестницы» из sequence легко превращаются в ловушку. Рабочий подход: дробить policy на короткие route-map, жёстко именовать и документировать, а перед выкладкой делать проверки (синтаксис, ожидаемое число префиксов, контроль «запрещено по умолчанию»).

BIRD: фильтры как код

В BIRD фильтр читается сверху вниз как логика программы: условия, модификации атрибутов, финальное accept или reject. Это обычно облегчает ревью и снижает шанс ошибиться в «порядке применений», потому что вся логика видна в одном месте и её проще структурировать функциями/макросами (в рамках возможностей используемой версии BIRD).

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

BGP communities: договорённости, управление трафиком и дисциплина

В 2026 году communities — это не «опциональная метка», а язык договорённостей: классификация источника маршрута, политика экспорта на аплинки и пиринги, аналитика, иногда управление приоритетами внутри вашей сети. Чем больше у вас соседей и площадок, тем важнее единый словарь communities.

По удобству работы:

• FRR хорош, если вы мыслите в терминах «community-list + route-map» и хотите быстро проверить фактическое состояние соседей через show-команды.
• BIRD хорош, если communities — часть читаемой логики фильтра и вы хотите, чтобы политика выглядела как код, а не как набор разрозненных списков.

Что реально снижает аварийность (независимо от демона): документированный словарь communities и автоматическая проверка конфигов на «разрешённые значения». Если словаря нет — рано или поздно появятся «65001:9999 потому что так исторически».

Graceful restart: полезно, но не вместо мониторинга

Graceful restart (GR) часто включают «чтобы не ронять маршруты при рестарте». В эксплуатации важнее детали:

• поддержка GR с обеих сторон и согласованные таймеры;
• поведение при частичных сбоях, когда сессия выглядит живой, но обновления не приходят;
• как вы детектите «застывшие» маршруты и stale-состояния.

GR уменьшает вероятность кратковременной потери маршрутов, но не гарантирует корректность. Если вы изменили политику, а сосед держит stale, трафик может некоторое время идти «по старым правилам».

Полезная практика: перед плановыми работами переводить узел в maintenance-режим вашей системы мониторинга, делать reload/restart, затем проверять не только «Established», но и количество маршрутов/атрибуты/ожидаемую сходимость.

Route reflectors: когда «пора» и что выбрать

Route reflectors обычно появляются, когда iBGP full mesh перестаёт быть управляемым (десятки/сотни внутренних сессий, несколько площадок, разные кластера). Для RR важно:

• устойчивость под большим числом peers;
• прозрачная политика импорта/экспорта между кластерами;
• диагностика: где маршрут отфильтровался, почему не отразился, какой next-hop ушёл клиенту.

FRR часто выбирают на RR из-за привычной «маршрутизаторной» диагностики и богатого набора команд. BIRD при этом отлично справляется с RR-ролью, когда вы хотите держать конфиг компактным и строго декларативным.

Практический критерий выбора для RR:

• если NetOps-операции и интерактивная диагностика в CLI — ежедневная рутина, FRR обычно проще;
• если политика живёт как код, много шаблонизации и ревью, BIRD часто проще удержать в консистентном виде.

Мониторинг BGP: что смотреть, кроме «сессия Established»

Проверка «BGP up» — это базовый healthcheck, но он не ловит большинство опасных ситуаций. Минимальный набор метрик/сигналов, который реально помогает предотвращать аварии:

• Количество принятых и отданных маршрутов по каждому соседу (в том числе по address-family). Резкие скачки — повод разбираться.
• Изменения policy: дифф конфигов, контрольная сумма, «кто/когда применил» (особенно если допускаются ручные правки).
• Сходимость: время до стабилизации после reload/restart и отклонения от нормы.
• Флапы/ресеты: частота reconnection и причины сбросов.
• Stale/GR: если включён graceful restart — отслеживайте stale-состояния и таймеры.

Если вы строите мониторинг на Linux-узлах, полезно продумать ещё и системные «обвязки»: watchdog, рестарты по healthcheck, алерты на деградации сервиса. По этой части пригодится материал про systemd watchdog и рестарты по healthcheck.

Минимальные примеры конфигурации: стиль FRR и BIRD

Примеры ниже упрощённые: они показывают стиль и «точки крепления» политики, но не заменяют вашу модель безопасности и требования аплинка/пира. Главный принцип для экспорта: по умолчанию запрещать всё и разрешать только явно нужные префиксы.

FRR: базовый eBGP, route-map и communities (упрощённо)

! /etc/frr/frr.conf
frr version 9
frr defaults traditional
hostname edge-bgp-1
log syslog informational
service integrated-vtysh-config

router bgp 65001
 bgp router-id 192.0.2.10
 no bgp ebgp-requires-policy

 neighbor 203.0.113.1 remote-as 65010
 neighbor 203.0.113.1 description TRANSIT-1
 neighbor 203.0.113.1 timers 3 9

 address-family ipv4 unicast
  network 198.51.100.0/24
  neighbor 203.0.113.1 route-map RM-IN in
  neighbor 203.0.113.1 route-map RM-OUT out
 exit-address-family

ip prefix-list PL-OUT seq 10 permit 198.51.100.0/24

bgp community-list standard CL-SET seq 10 permit 65001:100

route-map RM-OUT permit 10
 match ip address prefix-list PL-OUT
 set community 65001:100 additive

route-map RM-IN permit 10
 set local-preference 200

Что стоит обязательно добавить в реальном конфиге: max-prefix на соседа, явные inbound-фильтры (не «accept all»), а также запрет на экспорт «всего подряд» даже при ошибке в route-map.

BIRD: базовый eBGP, фильтры и communities (упрощённо)

# /etc/bird/bird.conf
router id 192.0.2.10;

define MY_ASN = 65001;

protocol device {
}

protocol direct {
  ipv4;
}

function allow_out_prefixes() {
  if net = 198.51.100.0/24 then return true;
  return false;
}

filter export_transit {
  if !allow_out_prefixes() then reject;
  bgp_community.add((MY_ASN, 100));
  accept;
}

filter import_transit {
  bgp_local_pref = 200;
  accept;
}

protocol bgp transit1 {
  local as MY_ASN;
  neighbor 203.0.113.1 as 65010;
  ipv4 {
    import filter import_transit;
    export filter export_transit;
  };
}

Для продакшена дополняйте фильтры ограничением длины префикса, базовой защитой от «мусора» (martians) и лимитами на число маршрутов от соседа (аналогично max-prefix по смыслу).

Эксплуатационные нюансы: обновления, reload и аварии

При выборе демона важна не только функциональность, но и то, как вы будете жить с ним каждый день:

• Как выкатываете изменения: через CLI, через конфиг с CI, через генерацию из шаблонов.
• Как делаете dry-run: проверка синтаксиса, тестовый стенд, контроль количества маршрутов до/после.
• Как откатываете: быстрый revert на прошлый конфиг и предсказуемое восстановление сессий.

Если BGP-роутер крутится на пограничном сервере, часто логично выносить его на отдельную виртуальную машину/инстанс, чтобы плановые работы по приложению не затрагивали маршрутизацию. Для таких задач обычно выбирают VDS с понятными ресурсами и изоляцией.

Итог: FRR vs BIRD — выбирайте то, что проще поддерживать вашей командой

В 2026 сравнение FRR и BIRD редко упирается в «потянет ли BGP». Оба потянут. Реальный выбор — это:

• как вы пишете, проверяете и ревьюите route policy;
• как используете communities и поддерживаете их консистентность;
• как переживаете рестарты и обновления (graceful restart плюс наблюдаемость);
• как строите и обслуживаете route reflectors;
• насколько зрелый у вас мониторинг (маршруты, флапы, сходимость, stale).

Если вы только начинаете: выберите инструмент, чей способ управления ближе вашей команде, и инвестируйте время в безопасность политик, проверяемость изменений и мониторинг. Это даёт больше стабильности, чем тонкая настройка таймеров.