Меня зовут Вася. Разберём BGP на VDS без академичности, но с упором на то, что действительно работает в проде: anycast, multihoming, routing policy и предсказуемый failover. Обычно к BGP приходят, когда DNS-failover уже слишком медленный, L7-балансировка усложняет систему, а нужно переключение «само» и как можно ниже по стеку.
Важно: поднимать BGP «просто потому что можно» — плохая идея. Ошибка в анонсах и фильтрах может затронуть не только ваш сервис, но и соседние сети. Поэтому ниже — только безопасные, типовые сценарии и практические грабли, которые встречаются на VDS.
Что такое BGP на VDS и зачем он вообще нужен
BGP (Border Gateway Protocol) — протокол обмена маршрутами между автономными системами (AS). На практике «BGP на VDS» означает, что вы поднимаете BGP-сессию с сетью провайдера, чтобы анонсировать свои префиксы и управлять маршрутами, или строите схему из нескольких площадок и хотите переключать трафик быстрее и точнее, чем через DNS.
- Failover без ожидания DNS TTL: обычно десятки секунд на сходимость, иногда быстрее при правильной схеме.
- Multihoming: два независимых пути в интернет и контроль политики маршрутизации.
- Anycast: один и тот же IP (префикс) обслуживается из нескольких точек.
- Routing policy: приоритеты, ограничения, «primary/backup» и управляемые исключения.
Если вы только выбираете площадку под сетевые эксперименты или edge-сервисы, удобнее начинать с VDS: там проще тестировать маршрутизацию, мониторинг и сценарии отказа без влияния на «железную» инфраструктуру.
Anycast простыми словами: один IP в нескольких местах
Anycast — это когда один и тот же префикс анонсируется из нескольких географически или топологически разных точек. Интернет выбирает «лучший» маршрут по своим BGP-правилам и политике сетей по пути.
- Чаще всего пользователь попадает в ближайшую точку (но «ближайшая» — это не километры, а BGP-политика и связность).
- Если точка перестаёт анонсировать префикс, трафик постепенно переезжает на оставшиеся.
Anycast не гарантирует идеальную географию и может вести разные подсети одного провайдера в разные точки. Это норма: BGP оптимизируется под политику и стоимость, а не под «карту».
Где anycast реально полезен
- DNS (авторитативный или рекурсивный): короткие ответы, хорошо кешируется, важна низкая задержка.
- Статичные фронтенды и «лёгкие» API: когда состояние минимально или клиент нормально переживает переподключение.
- Edge-терминация: например, входной слой, который умеет быстро ретраить или перекидывать запросы дальше.
Где anycast может сделать хуже
- State и sticky-сессии: при изменении маршрута пользователь внезапно попадёт на другую точку.
- Длинные TCP-сессии: при флапе маршрута сессии могут рваться.
- Запись/репликация: anycast не решает консистентность данных, это только маршрутизация.
Anycast отлично разносит входящий трафик и помогает пережить аварию на одной точке, но не заменяет продуманную работу со state и устойчивость клиента.
Если вы рассматриваете альтернативы anycast на уровне DNS, полезно сравнить подходы с GeoDNS и весами: GeoDNS и weighted routing для failover.
На практике anycast почти всегда требует наблюдаемости: метрики по точкам, алерты на withdraw/announce и проверку доступности с нескольких сетей. Без этого вы узнаете о «переезде» трафика по жалобам пользователей.
Multihoming на VDS: два пути в интернет
Multihoming — это подключение к интернету через две и более независимые сети. В мире VDS чаще всего это две площадки (или два провайдера), где ваш префикс объявляется из разных точек.
- Две локации (два дата-центра) с вашим префиксом, анонсируемым в обеих.
- Основная площадка и резервная в другом месте.
- Реже — два аплинка на одном узле (типичнее для собственного «железа»).
Ценность multihoming — устойчивость к проблемам аплинка и маршрута. Это «лечит» недоступность ниже L7: если у одного провайдера авария, вы не ждёте таймаутов приложения, а перестраиваете маршрут.
Что нужно, чтобы multihoming был «настоящим»
- Свой префикс, который можно анонсировать из разных мест.
- ASN (свой или делегированный) и возможность поднять BGP-сессии по правилам провайдеров.
- Фильтрация и лимиты: prefix-list, max-prefix и защита от утечек.
Если своего ASN/префикса нет, BGP всё равно может помочь, но обычно в ограниченных сценариях «внутри провайдера»: управляемый вход на разные узлы, резервирование в одной сети, тестирование политики.
IP и префиксы: самый частый камень преткновения
В BGP вы объявляете не «один IP», а префикс. Поэтому практически любой проект упирается в вопрос: какой префикс вы анонсируете, какого он размера, и примет ли его интернет.
- Размер префикса: минимально принимаемый префикс зависит от IPv4/IPv6 и политики аплинков. Даже если один аплинк принял анонс, это не гарантирует глобальную достижимость.
- PI и PA: переносимость адресов между провайдерами и «принадлежность» префикса.
- RPKI/ROA: без корректных ROA часть сетей отфильтрует маршрут как invalid.
Планирование стоит начинать с вопроса: какой префикс мы объявляем и где он будет считаться легитимным? Если ответа нет, anycast/multihoming превращаются в лотерею.
Мини-проверка перед запуском
- Убедитесь, что префикс действительно выделен вам и разрешён к анонсу в выбранной схеме.
- Подготовьте ROA под ваш ASN и конкретный префикс (включая maxLength там, где это осмысленно).
- Решите, где будет «источник истины» для анонса: одна точка, две точки, какие триггеры снимают анонс.
Routing policy: как управляют тем, куда поедет трафик
Routing policy — это правила принятия и выбора маршрутов: какие маршруты анонсировать, какие принимать и что предпочитать. На VDS чаще всего решают такие задачи:
- Primary/backup: основная и резервная площадка.
- Ограниченная балансировка: распределение входящего трафика (предсказуемость ограничена).
- Фильтрация: «анонсируем только свой префикс», «принимаем только дефолт» или ограниченный набор маршрутов.
Инструменты политики (в общих чертах)
- Local Preference: основной рычаг выбора исходящего маршрута внутри одной AS.
- AS-PATH prepending: сделать путь «длиннее», чтобы снизить привлекательность маршрута.
- MED: подсказка соседу, какой вход предпочтительнее (работает только при соответствующей политике соседа).
- Communities: метки, которыми аплинк может управлять распространением/предпочтением маршрута.
Практически важно не «какой атрибут красивее», а что реально поддерживает аплинк: какие communities разрешены, какие фильтры включены, какие лимиты стоят и как устроена защита от утечек.
Failover в BGP: что происходит при аварии
Правильный failover в BGP — это снятие анонса префикса с аварийной точки. Тогда интернет перестраивает маршруты и ведёт трафик на оставшиеся точки.
У failover есть два ключевых параметра: детект отказа и скорость сходимости.
Как корректно детектить отказ
- BGP-сессия down: базовый и обязательный сигнал, но не ловит ситуацию «BGP жив, приложение мертво».
- BFD (если доступно у провайдера и на вашей стороне): ускоряет детект проблем канала/соседа.
- Health приложения: если сервис не отвечает, автоматика должна уметь снять анонс (withdraw) или переключить политику.
Почему failover не бывает «мгновенным»
- маршруты расходятся по интернету не сразу;
- у разных сетей разные политики и таймеры;
- при флапе могут включаться механизмы подавления.
Поэтому «нулевой разрыв» достигается не только BGP: нужны корректные таймауты, ретраи, идемпотентность и понятная деградация. BGP уменьшает время недоступности, но не отменяет инженерную работу на уровне приложения.
Типовые схемы: anycast vs active/standby
Схема 1: Anycast на двух VDS в разных локациях
Обе VDS анонсируют один и тот же префикс. Пользователи распределяются между точками. При падении одной точки анонс прекращается, трафик уходит на вторую. Плюсы: распределение нагрузки и хороший UX. Минусы: сложнее со state, сложнее интерпретировать логи, а также важно следить за MTU и асимметрией маршрутов.
Схема 2: Active/Standby через BGP-политику
Обе точки могут анонсировать префикс, но основная делает маршрут предпочтительным, резервная — менее предпочтительным (например, через AS-PATH prepending или communities аплинка). В штатном режиме трафик идёт на primary, при аварии — на backup. Плюсы: проще со state. Минусы: резерв простаивает, а переключение заметнее.
Если у вас BGP-узел является точкой терминации TLS (например, edge-вход для API), заранее продумайте выпуск и ротацию сертификатов: это проще и безопаснее делать централизованно через SSL-сертификаты.
Операционные риски и минимальный набор защит
BGP — это не только «как поднять», но и «как не устроить инцидент». Минимальный набор защит должен быть включён сразу.
Что стоит сделать обязательно
- Prefix-фильтры на исходящие объявления: анонсируйте только то, что должны.
- Max-prefix на входящие маршруты: защита от неожиданно большой таблицы.
- Логи и мониторинг: состояние сессии, количество префиксов, события withdraw/announce.
- План отката: как быстро снять анонс и вернуть систему в предсказуемое состояние.
- RPKI: проверьте валидность до выката и после изменений.
Шаблон «безопасного мышления» при настройке
Если вы пишете конфиги, держите правило: «по умолчанию запрещено, явно разрешаем нужное». Например, сначала фильтр, который ничего не анонсирует, затем точечное разрешение вашего префикса и явный deny на всё остальное.
sudo vtysh -c "show bgp summary"
sudo vtysh -c "show bgp ipv4 unicast"
sudo vtysh -c "show bgp ipv6 unicast"Когда BGP на VDS — хорошая идея, а когда лучше выбрать другой подход
BGP оправдан, если вам нужен контроль маршрутизации и вы готовы поддерживать это как отдельный сетевой сервис: с мониторингом, политиками и регулярными проверками.
Частые «да»
- нужен anycast для DNS/edge-сервисов;
- нужен multihoming и независимость от одного провайдера;
- DNS-failover не устраивает по времени переключения или предсказуемости.
Частые «пока нет»
- непонятно, какой префикс вы анонсируете и как он будет принят в интернете;
- приложение сильно stateful, а репликация/устойчивые клиенты не готовы;
- нужен просто резервный сайт «на всякий случай» — часто достаточно L7 или DNS-стратегии.
Практический чеклист проектирования
- Цель: anycast, primary/backup или multihoming.
- Адресный план: префикс, размер, легитимность, ROA.
- Точки размещения: разные DC/провайдеры, требования к задержкам и связанности.
- Политика: приоритеты, prepending/communities, входящие и исходящие фильтры.
- Failover: что считается отказом и что снимает анонс.
- Защиты: prefix-list, max-prefix, мониторинг, алерты, план отката.
- Тест-план: падение приложения, падение канала, частичная деградация.
Итоги
BGP на VDS — это инженерный инструмент для управления доступностью и маршрутизацией: anycast, multihoming, routing policy и управляемый failover. Начинайте с адресного плана и легитимности префикса (включая RPKI), затем проектируйте модель отказов и включайте защитные механизмы. Тогда BGP будет снижать недоступность, а не увеличивать число инцидентов.
Если захотите продолжение с конкретикой по настройке демона (например, FRR) и безопасными фильтрами, удобно начать с сопутствующих тем по IPv6 и маршрутизации: SLAAC vs DHCPv6 и базовая маршрутизация IPv6.
