Полная настройка BGP на Linux с FRR: Multi-homing и отказоустойчивость в 2026

Архитектура решения: зачем вашему бизнесу multi-homing BGP

Multi-homing BGP позволяет подключить вашу сеть к двум или более интернет-провайдерам одновременно. Это дает не просто резервный канал, а полноценную отказоустойчивость, балансировку нагрузки и снижение задержек для критичных сервисов. Веб-приложения, удаленные офисы, VoIP-платформы и системы видеонаблюдения перестают зависеть от сбоя у одного оператора связи. Вы получаете контроль над маршрутизацией входящего и исходящего трафика.

Для реализации вам потребуется собственный номер автономной системы (ASN), который можно получить у регионального интернет-регистратора (RIPE NCC, ARIN и др.). В качестве маршрутизатора выступает сервер под управлением Linux, на котором работает демон FRRouting (FRR). Физические каналы связи подключаются к сетевым интерфейсам этого сервера.

Сценарии применения: от активного-резервного до балансировки трафика

Выбор стратегии зависит от бизнес-требований.

• Активный-резервный канал (primary/backup). Основной провайдер обрабатывает весь трафик, резервный включается только при отказе первого. Сценарий прост в настройке и минимизирует риски асимметричной маршрутизации. Подходит для обеспечения базовой отказоустойчивости.
• Балансировка исходящего трафика. Нагрузка распределяется между каналами, увеличивая общую доступную пропускную способность. Реализуется через настройку атрибутов BGP или разделение пулов исходящих IP-адресов.
• Влияние на входящий трафик. Управление маршрутами, по которым клиенты приходят в вашу сеть, сложнее. Оно зависит от политик удаленных провайдеров, но базовое влияние можно оказать с помощью атрибута MED.

Выбор сценария определяется требованиями к доступности сервисов и бюджетом на каналы связи.

Подготовка инфраструктуры: установка FRR и базовая конфигурация

Начните с установки актуальной версии FRR на ваш дистрибутив Linux. Это основа для всех последующих настроек BGP.

Установка FRR из официальных репозиториев

Для Ubuntu 22.04 LTS или Debian 12 используйте официальный репозиторий FRR. Версия 9.1, актуальная на 2026 год, обеспечивает стабильность и поддержку современных функций.

# Добавление репозитория FRR
curl -fsSL https://deb.frrouting.org/frr/keys.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/frr.gpg
echo "deb https://deb.frrouting.org/frr $(lsb_release -s -c) frr-9.1" | sudo tee /etc/apt/sources.list.d/frr.list

# Обновление пакетов и установка FRR
sudo apt update
sudo apt install frr frr-pythontools

# Проверка установленной версии
frr --version

Для дистрибутивов на базе RHEL (AlmaLinux 9, Rocky Linux 9) установка выполняется через репозиторий EPEL и официальный репозиторий FRR.

Настройка демонов и первый вход в vtysh

Перед запуском активируйте необходимые демоны. Zebra управляет интерфейсами и таблицей маршрутизации ядра, а bgpd отвечает за протокол BGP.

# Редактируем файл /etc/frr/daemons
sudo nano /etc/frr/daemons

В файле установите значения "yes" для zebra и bgpd:

bgpd=yes
zebra=yes

Запустите службы и добавьте их в автозагрузку:

sudo systemctl enable frr
sudo systemctl start frr

Для управления FRR используйте консоль vtysh:

sudo vtysh

Внутри vtysh перейдите в режим конфигурации и задайте пароль для доступа:

configure terminal
service password-encryption
enable password ваш_надежный_пароль
line vty
 password ваш_пароль_vty
end
write memory

Базовая конфигурация zebra включает назначение IP-адресов на интерфейсы. Предположим, у вас два uplink: eth1 к провайдеру A (203.0.113.10/30) и eth2 к провайдеру B (198.51.100.10/30). Внутренняя сеть на eth3 (10.0.0.1/24).

configure terminal
interface eth1
 ip address 203.0.113.10/30
 description Uplink-to-ISP-A
 exit
interface eth2
 ip address 198.51.100.10/30
 description Uplink-to-ISP-B
 exit
interface eth3
 ip address 10.0.0.1/24
 description LAN-Network
 exit
end
write memory

Теперь инфраструктура готова к настройке BGP. Если вам нужно превратить сервер в полноценный программный маршрутизатор для корпоративной сети, изучите практическое руководство по программному маршрутизатору на Linux.

Стратегия маршрутизации: Full-table или Default-only?

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

Full-table означает прием от провайдера полной таблицы интернет-маршрутов. Ее размер в 2026 году составляет около 1.1-1.3 миллиона префиксов IPv4. Преимущество в возможности самостоятельно выбирать оптимальный путь для исходящего трафика к любой точке сети. Вы не зависите от выбора маршрута по умолчанию вашего провайдера. Недостаток - высокие требования к оперативной памяти (1-2 ГБ для хранения таблицы) и процессору для обработки обновлений.

Default-only - прием от каждого провайдера только маршрута по умолчанию (0.0.0.0/0). Этот подход требует минимальных ресурсов (десятки килобайт памяти), прост в настройке и фильтрации. Однако он приводит к потенциально неоптимальной маршрутизации. Весь ваш исходящий трафик будет идти через того провайдера, чей маршрут по умолчанию выбран как лучший, даже если к целевой сети есть более короткий путь через другого провайдера.

Анализ нагрузки на ресурсы: память и процессор

Для работы с полной таблицей маршрутов выделите серверу не менее 2 ГБ оперативной памяти только для процесса bgpd. Процессор с 2-4 ядрами средней производительности справится с обработкой обновлений. Используйте команду в vtysh для мониторинга:

show ip bgp summary

В выводе обратите внимание на количество принятых префиксов (Received Prefixes) и использование памяти процессом. Для сценария default-only достаточно виртуальной машины с 512 МБ RAM и одним ядром CPU.

Влияние на отказоустойчивость и оптимальность пути

При стратегии default-only отказоустойчивость работает просто: если маршрут по умолчанию от основного провайдера исчезает, используется маршрут от резервного. Однако может возникнуть ситуация suboptimal routing: ваш трафик уходит через провайдера A, но ответный трафик от удаленного сервера приходит через провайдера B из-за его более предпочтительного маршрута к вашей сети. Это создает асимметричность, которая иногда вызывает проблемы с stateful-фаерволлами или некоторыми протоколами.

Full-table позволяет избежать этого, так как ваш маршрутизатор знает оптимальный путь для исходящего трафика ко всем сетям. При отказе канала к одному провайдеру трафик автоматически перераспределится через оставшиеся, используя наилучшие альтернативные пути из таблицы.

Рекомендация: используйте full-table для головных офисов, дата-центров и узлов с критичными сервисами. Выбирайте default-only для удаленных филиалов, резервных каналов с низкой пропускной способностью или при ограниченных аппаратных ресурсах.

Настройка BGP-сессий с провайдерами: готовые конфигурации FRR

Основная конфигурация BGP находится в файле /etc/frr/frr.conf или настраивается через vtysh. Приведем готовые блоки для двух провайдеров. Ваша автономная система - AS 65001. Провайдер A (ISP-A) имеет AS 64500 и IP пиринга 203.0.113.9. Провайдер B (ISP-B) - AS 64501 и IP 198.51.100.9.

Конфигурация для сценария Full-table

Этот конфиг принимает полные таблицы от обоих провайдеров и анонсирует им вашу сеть 10.0.0.0/24.

router bgp 65001
 bgp router-id 10.0.0.1
 # Настройка соседа - провайдер A
 neighbor 203.0.113.9 remote-as 64500
 neighbor 203.0.113.9 description ISP-A-Full-Table
 neighbor 203.0.113.9 timers 10 30
 # Настройка соседа - провайдер B
 neighbor 198.51.100.9 remote-as 64501
 neighbor 198.51.100.9 description ISP-B-Full-Table
 neighbor 198.51.100.9 timers 10 30
 # Объявление своей сети в интернет
 network 10.0.0.0/24
 exit

После применения конфигурации проверьте сессии:

show ip bgp summary

В колонке "State/PfxRcd" для каждого соседа должно быть число (количество принятых префиксов), а не "Idle" или "Active". Команда show ip bgp покажет всю таблицу BGP.

Конфигурация для сценария Default-only

Здесь используются route-map и prefix-list для фильтрации, чтобы принимать только маршрут 0.0.0.0/0.

router bgp 65001
 bgp router-id 10.0.0.1
 neighbor 203.0.113.9 remote-as 64500
 neighbor 203.0.113.9 description ISP-A-Default-Only
 neighbor 203.0.113.9 prefix-list DEFAULT-ONLY in
 neighbor 198.51.100.9 remote-as 64501
 neighbor 198.51.100.9 description ISP-B-Default-Only
 neighbor 198.51.100.9 prefix-list DEFAULT-ONLY in
 network 10.0.0.0/24
 exit

ip prefix-list DEFAULT-ONLY seq 5 permit 0.0.0.0/0
ip prefix-list DEFAULT-ONLY seq 10 deny 0.0.0.0/0 le 32

Prefix-list "DEFAULT-ONLY" разрешает только маршрут по умолчанию и блокирует все остальные префиксы. Это защищает вашу таблицу маршрутизации от переполнения.

Для объявления своих префиксов провайдерам в этом сценарии дополнительная фильтрация не требуется, конфигурация network 10.0.0.0/24 достаточна.

Управление трафиком: Local-preference, MED и балансировка

Атрибуты BGP позволяют гибко управлять выбором пути. Local-preference влияет на исходящий из вашей AS трафик: чем выше значение (по умолчанию 100), тем более предпочтительным считается маршрут. MED (Multi-Exit Discriminator) дает рекомендацию соседней AS о предпочтительном пути для входящего к вам трафика, но конечное решение остается за вашим провайдером.

Настройка активного-резервного канала (Primary/Backup)

Чтобы весь исходящий трафик шел через ISP-A, а ISP-B использовался только при его отказе, установите более высокий local-preference для маршрутов от основного провайдера.

router bgp 65001
 neighbor 203.0.113.9 route-map SET-HIGH-LOCAL-PREF in
 exit

route-map SET-HIGH-LOCAL-PREF permit 10
 set local-preference 200

Маршруты, полученные от соседа 203.0.113.9, получат local-preference 200 и будут выбраны как лучшие. Маршруты от ISP-B сохранят значение по умолчанию 100 и станут резервными.

Проверьте работу командой:

show ip bgp 0.0.0.0/0

В выводе для выбранного лучшего маршрута будет указан атрибут "locPrf 200". Для тестирования failover отключите интерфейс eth1 (sudo ip link set eth1 down) и убедитесь, что трафик переключился на маршрут через ISP-B, проверив таблицу маршрутизации (show ip route).

Балансировка нагрузки между каналами

Для распределения исходящего трафика можно использовать ECMP (Equal-Cost Multi-Path), если оба маршрута имеют одинаковые локальные предпочтения, вес и длину AS_PATH. При использовании full-table это часто происходит для многих префиксов. Включите многопутевую маршрутизацию в ядре Linux и zebra:

configure terminal
ip forwarding
ip nht resolve-via-default
line vty
 exit
end
write memory

Другой метод - балансировка по префиксам. Разделите пул ваших исходных IP-адресов (например, 10.0.0.0/24) на две подсети и анонсируйте одну через ISP-A, другую через ISP-B, используя route-map на исходящих объявлениях.

! Создаем prefix-list для разделения сетей
ip prefix-list NET-1 seq 5 permit 10.0.0.0/25
ip prefix-list NET-2 seq 5 permit 10.0.0.128/25

! Применяем route-map к исходящим анонсам для ISP-A
router bgp 65001
 neighbor 203.0.113.9 route-map ANNOUNCE-NET-1 out
 exit

! Применяем route-map к исходящим анонсам для ISP-B
router bgp 65001
 neighbor 198.51.100.9 route-map ANNOUNCE-NET-2 out
 exit

route-map ANNOUNCE-NET-1 permit 10
 match ip address prefix-list NET-1

route-map ANNOUNCE-NET-2 permit 10
 match ip address prefix-list NET-2

Входящий трафик от клиентов будет приходить по разным каналам в зависимости от того, какую подсеть они используют для подключения. Для комплексного управления трафиком в сложных сетях, включая игровые серверы, полезно изучить практическое руководство по маршрутизации трафика для игровых серверов.

Безопасность и фильтрация: защита от ошибочных маршрутов

Фильтрация входящих маршрутов от провайдеров обязательна. Она предотвращает принятие ошибочных или злонамеренных анонсов, которые могут изолировать вашу сеть.

Фильтрация входящих и исходящих маршрутов

Создайте prefix-list, который разрешает только ваши легитимные префиксы для исходящих анонсов. Это предотвратит случайную утечку чужих маршрутов.

ip prefix-list OUR-NETWORKS seq 5 permit 10.0.0.0/24
ip prefix-list OUR-NETWORKS seq 10 deny 0.0.0.0/0 le 32

Примените этот список как исходящий фильтр ко всем соседям:

router bgp 65001
 neighbor 203.0.113.9 prefix-list OUR-NETWORKS out
 neighbor 198.51.100.9 prefix-list OUR-NETWORKS out
 exit

Для входящих маршрутов, особенно в сценарии default-only, уже создан фильтр DEFAULT-ONLY. В сценарии full-table рекомендуется фильтровать приватные (RFC 1918) и зарезервированные префиксы:

ip prefix-list BOGONS seq 5 deny 10.0.0.0/8 le 32
ip prefix-list BOGONS seq 10 deny 172.16.0.0/12 le 32
ip prefix-list BOGONS seq 15 deny 192.168.0.0/16 le 32
ip prefix-list BOGONS seq 20 deny 0.0.0.0/8 le 32
ip prefix-list BOGONS seq 25 deny 127.0.0.0/8 le 32
ip prefix-list BOGONS seq 30 permit 0.0.0.0/0 le 24

Последняя строка разрешает все остальные префиксы с маской не более /24 (более специфичные маршруты часто являются ошибочными). Примените этот список как входящий фильтр.

Ограничение сессий и аутентификация

Директива neighbor maximum-prefix разрывает сессию BGP, если провайдер прислал больше префиксов, чем ожидалось. Это защита от сбоев на стороне провайдера.

router bgp 65001
 neighbor 203.0.113.9 maximum-prefix 1500000 80
 neighbor 198.51.100.9 maximum-prefix 1500000 80
 exit

Лимит установлен в 1.5 млн префиксов. При достижении 80% от этого значения (1.2 млн) в логи будет записано предупреждение. При превышении лимита сессия разорвется.

Включите MD5-аутентификацию для защиты от подделки сессий BGP. Пароль должен быть согласован с провайдером.

router bgp 65001
 neighbor 203.0.113.9 password ваш_общий_секретный_пароль
 neighbor 198.51.100.9 password ваш_общий_секретный_пароль
 exit

Для мониторинга состояния сессий включите логирование их изменений:

router bgp 65001
 bgp log-neighbor-changes
 exit

События установки и разрыва сессий будут записываться в syslog. Для глубокого анализа проблем с динамической маршрутизацией используйте руководство по диагностике и мониторингу BGP и OSPF.

Проверка, мониторинг и устранение неполадок

После настройки убедитесь, что все работает как задумано.

Основные команды для диагностики состояния BGP

Тестирование отказоустойчивости на стенде

1. Проверка основного пути. Выполните traceroute до внешнего адреса (например, 8.8.8.8). Убедитесь, что трафик идет через интерфейс основного провайдера (eth1).
2. Имитация отказа канала. На сервере выполните команду отключения интерфейса: sudo ip link set eth1 down.
3. Наблюдение за перестроением таблицы. В vtysh выполните show ip bgp summary и убедитесь, что сессия с провайдером A разорвана. Команда show ip route bgp должна показать, что маршрут по умолчанию теперь ведет через eth2.
4. Проверка доступности сервиса. Выполните ping до 8.8.8.8. Несколько первых пакетов могут быть потеряны, но затем соединение восстановится через резервный канал.
5. Восстановление канала. Включите интерфейс обратно: sudo ip link set eth1 up. Через 10-30 секунд сессия BGP должна восстановиться, и трафик вернется на основной канал (если local-preference выше).

Типичные проблемы и их решения:

• Сессия не устанавливается (State Idle/Active). Проверьте: IP-адреса и номера AS на обеих сторонах, доступность по сети (firewall правила на порте 179), соответствие MD5-паролей.
• Маршруты не принимаются. Убедитесь, что нет конфликтующих фильтров prefix-list или route-map, блокирующих входящие анонсы.
• Асимметричная маршрутизация. Если входящий и исходящий трафик идут разными путями, проверьте атрибуты local-preference и AS_PATH на вашей стороне. Учтите, что управление входящим трафиком ограничено политиками ваших провайдеров.

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

Интеграция BGP с FRR открывает возможности для автоматизации и управления инфраструктурой как кодом. Для сложных сценариев взаимодействия с облачными провайдерами и API можно рассмотреть использование сервисов вроде AiTunnel, который предоставляет единый интерфейс для доступа к различным моделям ИИ и может быть полезен для автоматизации сетевых задач.