Как BGP и Anycast решают задачу глобальной отказоустойчивости
BGP (Border Gateway Protocol) - протокол динамической маршрутизации, который связывает автономные системы (AS) в интернете. Его задача - сообщать всем участникам, через какого провайдера и какой путь доступна та или иная IP-сеть. Anycast - метод адресации, при котором один и тот же IP-адрес назначается на несколько физических серверов в разных точках присутствия. Маршрутизаторы в интернете видят несколько путей к этому адресу и выбирают ближайший по метрике BGP.
Связка BGP + Anycast решает две задачи одновременно: автоматический failover при отказе целого ЦОДа и снижение задержек за счёт маршрутизации пользователя к ближайшему узлу. Механизм работает без внешних балансировщиков и DNS-переключений. Когда сервер или канал связи в одном ЦОДе выходит из строя, BGP-маршрутизатор прекращает анонсировать префикс, и трафик перестраивается на следующий доступный узел. Время переключения - от нескольких секунд до пары минут, в зависимости от количества транзитных провайдеров и настроек таймеров BGP.
Пример: у вас три ЦОДа в Амстердаме, Франкфурте и Хельсинки. Каждый анонсирует префикс 203.0.113.0/24 через локальных провайдеров. Пользователь из Берлина получит маршрут до Франкфурта как самый короткий. При падении Франкфурта его маршрутизатор перестанет отправлять BGP-анонсы, и через 30-90 секунд трафик из Берлина пойдёт в Амстердам. Администратору не нужно менять DNS-записи или поднимать резервные серверы - всё происходит автоматически на уровне глобальной маршрутизации.
Этот подход используют корневые DNS-серверы (например, F-root), CDN-сети и крупные облачные провайдеры. Для детального знакомства с протоколами маршрутизации и их ролью в отказоустойчивости изучите руководство по BGP и OSPF, где разобраны таблицы маршрутизации и проектирование отказоустойчивых сетей.
Проектирование отказоустойчивой архитектуры: с чего начать
Минимальная конфигурация для глобальной отказоустойчивости - два географически разнесённых ЦОДа с независимыми каналами связи и разными провайдерами. Три ЦОДа дают запас прочности: при плановом обслуживании одного узла два оставшихся продолжают работать без деградации. Каждый ЦОД должен иметь минимум двух аплинков к разным магистральным операторам, чтобы исключить единую точку отказа на уровне L1-L2. Провайдеры обязаны поддерживать BGP-пиринг и согласовывать фильтрацию исходящих анонсов - без этого ваш префикс либо не уйдёт в глобальную таблицу маршрутизации, либо будет отфильтрован как некорректный.
IP-префиксы должны быть публичными и независимыми от провайдера (PI, Provider Independent). Если использовать адресное пространство провайдера, при смене оператора придётся переназначать все IP, что ломает Anycast и требует перестройки всех сервисов. Минимальный размер анонсируемого префикса в глобальной таблице - /24 для IPv4 и /48 для IPv6. Более длинные префиксы большинство операторов фильтруют.
Получение автономной системы (AS) и IP-префиксов
Номер автономной системы (ASN) получают через регионального интернет-регистратора: RIPE NCC для Европы, ARIN для Северной Америки, APNIC для Азиатско-Тихоокеанского региона. Для получения ASN нужен договор минимум с двумя аплинк-провайдерами, подтверждающий мультихоминг. Стоимость регистрации ASN в RIPE - около 50 евро, ежегодное обслуживание - 55 евро. Процесс занимает от нескольких дней до двух недель.
PI-префиксы также запрашивают через RIR. Для RIPE минимальный блок - /24, требуется обоснование использования не менее 50% адресов в течение двух лет. При дефиците IPv4 можно арендовать префикс у брокера, но это дороже и требует согласования с провайдерами. После получения префикса создайте объекты route/route6 в IRR (Internet Routing Registry) - это обязательное требование для прохождения фильтрации у большинства операторов. Без записи в IRR ваш анонс отбросят.
Выбор топологии и согласование с провайдерами
Полносвязная топология - каждый ЦОД соединён с каждым через выделенные каналы или VPN-туннели - даёт максимальную надёжность, но дорога. Частичная топология с двумя аплинками на узел и внутренней маршрутизацией через интернет-каналы дешевле и покрывает 95% сценариев. При согласовании BGP-сессий с провайдерами укажите:
- Ваш AS-номер и список префиксов для анонса
- Максимальную длину префикса (обычно /24)
- Необходимые BGP-community для управления трафиком (например, community для снижения local-preference на резервном канале)
- Поддержку RPKI для валидации анонсов
Пример письма провайдеру:
«Прошу настроить BGP-пиринг для AS65001. Префиксы для анонса: 203.0.113.0/24, 2001:db8::/48. Максимальная длина префикса /24 для IPv4, /48 для IPv6. Прошу принимать community 65001:100 для снижения local-preference на вашем маршрутизаторе. Наш маршрутизатор: 198.51.100.2/30. Ваш: 198.51.100.1/30. MD5-пароль предоставлен отдельно».
Для глубокого погружения в настройку BGP на Linux с примерами конфигураций и сравнением full-table/default-only сценариев рекомендую руководство по multi-homing BGP с FRR.
Настройка BGP на маршрутизаторах: BIRD и FRR
BIRD и FRR - два основных демона динамической маршрутизации для Linux. BIRD компактнее, потребляет меньше памяти и чаще используется на конечных серверах. FRR - форк Quagga с поддержкой множества протоколов (BGP, OSPF, IS-IS, PIM), удобен на выделенных маршрутизаторах. Выбор зависит от роли узла: для сервера с Anycast-сервисом достаточно BIRD, для полноценного граничного маршрутизатора с несколькими протоколами лучше FRR.
Пошаговая настройка BIRD для BGP-анонсов
Установка на Debian/Ubuntu:
apt update && apt install bird2
Основной конфигурационный файл - /etc/bird/bird.conf. Пример рабочей конфигурации для анонса префикса 203.0.113.0/24 через провайдера с IP 198.51.100.1:
router id 203.0.113.1;
protocol device {
scan time 10;
}
protocol direct {
interface "lo";
}
filter export_filter {
if net = 203.0.113.0/24 then accept;
reject;
}
filter import_filter {
if net = 0.0.0.0/0 then accept;
reject;
}
protocol bgp uplink1 {
local as 65001;
neighbor 198.51.100.1 as 64500;
ipv4 {
import filter import_filter;
export filter export_filter;
};
hold time 90;
keepalive time 30;
}Ключевые параметры: router id - уникальный идентификатор маршрутизатора (обычно IP на loopback), hold time - время ожидания keepalive-пакетов перед разрывом сессии, keepalive - интервал отправки проверочных пакетов. Фильтр export_filter разрешает анонсировать только ваш префикс - это критично для предотвращения утечек маршрутов. Фильтр import_filter принимает только маршрут по умолчанию, экономя память и CPU.
После сохранения конфигурации перезапустите BIRD и проверьте статус:
systemctl restart bird birdc show protocols birdc show route
Типовые ошибки: несовпадение AS-номера, неправильный IP соседа, фильтрация провайдером более длинных префиксов. Проверяйте лог /var/log/bird.log при проблемах с установлением сессии.
Настройка FRR (Free Range Routing) для BGP
Установка:
apt install frr
В файле /etc/frr/daemons включите bgpd=yes. Конфигурация через vtysh или файл /etc/frr/frr.conf:
router bgp 65001 bgp router-id 203.0.113.1 neighbor 198.51.100.1 remote-as 64500 neighbor 198.51.100.1 timers 30 90 ! address-family ipv4 unicast network 203.0.113.0/24 neighbor 198.51.100.1 prefix-list EXPORT out neighbor 198.51.100.1 route-map IMPORT in exit-address-family ! route-map IMPORT permit 10 match ip address prefix-list DEFAULT ! route-map EXPORT permit 10 match ip address prefix-list MY_PREFIX ! ip prefix-list DEFAULT seq 5 permit 0.0.0.0/0 ip prefix-list MY_PREFIX seq 5 permit 203.0.113.0/24
Проверка статуса:
vtysh -c "show ip bgp summary" vtysh -c "show ip bgp neighbors 198.51.100.1 advertised-routes"
FRR даёт более детальный контроль через route-map и prefix-list, что удобно при сложных политиках маршрутизации. Для настройки фильтрации BGP и предотвращения утечек маршрутов изучите полное руководство по фильтрации BGP с примерами prefix-list, as-path-list и route-map.
Реализация Anycast: настройка серверов и интеграция с BGP
Anycast работает так: один и тот же IP-адрес настраивается на loopback-интерфейсе всех серверов, предоставляющих сервис. BGP-маршрутизатор анонсирует префикс, включающий этот адрес. Когда пользователь отправляет запрос, интернет-маршрутизация доставляет его к ближайшему узлу, анонсирующему префикс. Сервис (DNS, HTTP, NTP) слушает на этом IP и отвечает.
Настройка loopback-интерфейса и health-check'ов
Добавление Anycast-адреса на loopback:
ip addr add 203.0.113.10/32 dev lo
Маска /32 обязательна - она предотвращает конфликты маршрутизации на локальной машине. Адрес должен быть в пределах анонсируемого префикса (например, 203.0.113.10 из 203.0.113.0/24).
Критичный компонент - health-check. Если сервис упал, а BGP продолжает анонсировать префикс, трафик пойдёт в чёрную дыру. Скрипт health-check проверяет состояние сервиса и управляет анонсом:
#!/bin/bash
SERVICE_IP="203.0.113.10"
CHECK_PORT="53"
CHECK_PROTO="udp"
if nc -z -u -w 2 localhost $CHECK_PORT > /dev/null 2>&1; then
ip addr show lo | grep -q $SERVICE_IP || ip addr add $SERVICE_IP/32 dev lo
else
ip addr show lo | grep -q $SERVICE_IP && ip addr del $SERVICE_IP/32 dev lo
fiЭтот скрипт проверяет доступность UDP-порта 53 (DNS) и добавляет или удаляет IP с loopback. BIRD отслеживает наличие IP на интерфейсе через протокол direct и автоматически добавляет или убирает маршрут из анонса. Запускайте скрипт по cron каждые 10-15 секунд.
Для сервисов, критичных к состоянию приложения (не только порт открыт, но и отвечает корректно), health-check должен выполнять полноценный запрос: DNS-резолвинг для DNS-сервера, HTTP GET с проверкой кода 200 для веб-балансировщика.
Решение проблем с Anycast: асимметричный трафик и TTL
Асимметричная маршрутизация - основная проблема Anycast. Запрос от пользователя приходит в ближайший ЦОД, а ответ может уйти через другой канал или ЦОД, если обратный маршрут отличается. Для stateless-протоколов (DNS, NTP) это некритично. Для stateful-сервисов (HTTP с сессиями, TCP-соединения) асимметрия ломает соединение.
Решения:
- Sticky-соединения на балансировщике по IP источника - работает, но снижает равномерность распределения нагрузки
- IP-туннели (GRE/IPIP) между ЦОДами для возврата трафика через тот же узел, куда пришёл запрос
- Отказ от Anycast для stateful-сервисов в пользу DNS-балансировки с коротким TTL
TTL (Time To Live) влияет на трассировку: traceroute до Anycast-адреса может показать разное количество хопов при повторных запусках, так как маршрут меняется. Это не баг, а особенность. При диагностике используйте утилиты с фиксацией исходного порта или запускайте тесты из разных географических точек через Looking Glass и RIPE Atlas.
Тестирование отказоустойчивости и мониторинг
Тестирование проводите поэтапно. Сначала отключите BGP-сессию на одном маршрутизаторе командой birdc down uplink1 или vtysh -c "conf t" -c "router bgp" -c "neighbor 198.51.100.1 shutdown". Проверьте время переключения трафика: запустите непрерывный ping с внешнего хоста и зафиксируйте потерю пакетов. При таймерах hold=90, keepalive=30 переключение занимает 90-120 секунд. Для ускорения можно уменьшить таймеры до hold=30, keepalive=10, но это повышает нагрузку на CPU и чувствительность к кратковременным проблемам с каналом.
Второй этап - симуляция падения сервиса. Остановите приложение (например, named для DNS) и убедитесь, что health-check убрал IP с loopback, а BGP прекратил анонс. Проверьте, что трафик уходит на другой ЦОД.
Для мониторинга BGP-сессий используйте bgp_exporter для Prometheus. Он собирает метрики состояния сессий, количества анонсированных и принятых префиксов. Настройте алерты:
- Состояние сессии != Established - критичный алерт
- Резкое падение числа анонсированных префиксов - возможная проблема с health-check или фильтрацией
- Рост числа принятых префиксов - возможная утечка full-table от провайдера
Пример правила алертинга Prometheus:
- alert: BGPDown
expr: bgp_session_state != 6
for: 2m
labels:
severity: critical
annotations:
summary: "BGP session to {{ $labels.peer }} is down"Для комплексного мониторинга Anycast-сервисов проверяйте доступность из разных географических зон. Подробная настройка мониторинга BGP с готовыми правилами алертинга описана в руководстве по мониторингу BGP и Prometheus.
Типовые проблемы при внедрении и их решение
Провайдер фильтрует префикс /24. Симптом: BGP-сессия Established, но ваш префикс не виден в глобальной таблице (проверить через looking glass). Решение: проверьте записи route/route6 в IRR для вашего префикса и AS-номера. Убедитесь, что провайдер настроил фильтр на приём вашего префикса. Запросите у провайдера подтверждение, что префикс пропущен в аплинки.
Неправильные BGP community. Симптом: трафик идёт не по ожидаемому пути, асимметрия. Решение: проверьте, какие community принимает и обрабатывает провайдер. Стандартные community для управления local-preference: 64500:100 (увеличить), 64500:90 (уменьшить). Не все провайдеры поддерживают произвольные community - согласуйте список заранее.
Отсутствие резервного маршрута. Симптом: при падении BGP-сессии сервер теряет связность, так как нет маршрута по умолчанию. Решение: всегда настраивайте статический маршрут с более высоким administrative distance как резервный. В BIRD добавьте protocol static с маршрутом 0.0.0.0/0 через второго провайдера и более высоким значением preference.
Проблемы с MTU из-за туннелей. Симптом: большие пакеты не проходят между ЦОДами, фрагментация ломает производительность. Решение: при использовании GRE/IPIP туннелей уменьшите MTU на туннельном интерфейсе до 1400-1450 байт. Включите TCP MSS clamping на граничных маршрутизаторах.
Чек-лист перед включением в продакшен:
- Префиксы зарегистрированы в IRR и валидируются через RPKI
- BGP-сессии Established со всеми провайдерами
- Фильтры на экспорт пропускают только свои префиксы
- Фильтры на импорт принимают только default-route или согласованный набор маршрутов
- Health-check корректно добавляет и убирает Anycast-IP при изменении состояния сервиса
- Мониторинг BGP-сессий и сервисов настроен, алерты проверены
- Проведено тестирование failover: отключение сессии, остановка сервиса, отключение канала
- Документация по архитектуре и процедурам восстановления актуальна
Для расширения отказоустойчивой архитектуры на гибридные облака и подключения AWS, GCP или Azure через BGP используйте руководство по единому сетевому пространству с облаками.