Что такое BGP: автономные системы, политики и два провайдера

Когда BGP нужен бизнесу, а когда можно проще

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

• Собственная сеть через нескольких операторов: сохранить управляемую адресацию и иметь согласованную политику анонсов.
• ЦОД и крупная инфраструктура: обмен маршрутами между сегментами и распределёнными площадками.
• Несколько внешних путей: управлять предпочтением и составом получаемых маршрутов.

Два обычных офисных тарифа с разными адресами, NAT и автоматическим резервом не требуют собственной публичной AS по умолчанию. Часто достаточно tracking, policy routing и проверки каналов. BGP не создаёт канал, не суммирует тарифы и не сохраняет автоматически существующие соединения при смене исходящего адреса.

AS, ASN, префикс и анонс — на понятном примере

Автономная система объединяет маршрутизирующую инфраструктуру под согласованным административным управлением и политикой. ASN — её числовой идентификатор. Префикс, например /24, описывает диапазон адресов; BGP передаёт информацию о пути к нему. Анонсировать сеть можно только при наличии соответствующих прав и согласований.

Для реального multihoming заранее выясняют выделение ASN и адресного ресурса, право использования, допустимые длины префиксов у операторов, ROA, IRR-объекты и фильтры. Покупка маршрутизатора с BGP сама по себе этих условий не обеспечивает. Публичные и частные ASN решают разные задачи.

В статье используются AS 65010, 65001 и 65002 из частного диапазона. Адреса 192.0.2.0/24 и 203.0.113.0/24 предназначены для документации. Это изолированный пример, не ресурс для публикации в глобальную сеть.

eBGP, iBGP и состояние Established

• eBGP: обмен между разными AS; в примере компания AS 65010 соединяется с AS 65001 и 65002.
• iBGP: распространение BGP-информации внутри своей AS. Для нескольких пограничных узлов отдельно проектируют связность next hop, IGP, full mesh или route reflectors.
• Address family: IPv4 unicast, IPv6 unicast и другие семейства включают явно по задаче. Пример ниже посвящён IPv4 unicast.
• Established: BGP-сессия установлена, но маршрутов может быть ноль или они могут быть отвергнуты политикой.

BGP обычно работает через TCP 179. Для соединения нужны IP-достижимость соседа, разрешения control plane и согласованные параметры. TCP и BGP — ещё два разных уровня проверки. Нельзя объявлять «Интернет работает» только потому, что сосед установился.

AS_PATH помогает выявлять петли между AS; iBGP имеет собственные правила распространения. Отключение защит от петель ради прохождения одного префикса требует понимания архитектуры, а не универсальной команды из статьи.

Почему выигрывает политика, а не короткая линия

BGP выбирает путь по набору правил реализации и заданной политике. Для сопоставимых допустимых путей повышенный LOCAL_PREF может перевесить более короткий AS_PATH. В примере 200 предпочтительнее 100. Это административное предпочтение, не Мбит/с и не миллисекунды.

Далее учитываются другие атрибуты и условия: локальное происхождение, AS_PATH, ORIGIN, MED при соответствующей сопоставимости, тип соседства, достижимость next hop и дополнительные tie-breaker. Не переносите краткий список как одинаковый полный алгоритм всех вендоров: у FRR также есть собственные настройки выбора.

Сначала сравнивают кандидатов одного префикса. Выбор более конкретного префикса при пересылке — отдельный вопрос: маршрут /24 может определять трафик вместо /0 независимо от LOCAL_PREF этих разных сетей. Таблица политической маршрутизации и VRF также меняют контекст поиска.

Исходящий и входящий трафик управляются по-разному

Исходящий выбор на своей границе задают собственной политикой: например, LOCAL_PREF 200 для путей от A и 100 для B. LOCAL_PREF предназначен для политики своей AS, а не для прямого задания предпочтения чужому провайдеру.

Входящий путь выбирают другие сети. На него можно влиять согласованными communities оператора, составом объявлений и AS_PATH prepend. Но чужой LOCAL_PREF или иной более приоритетный критерий способен перевесить prepend. Гарантированного универсального «завернуть весь входящий трафик через A» одной командой нет.

• MED применяют с учётом правил сравнения и договорённостей соседей.
• Communities имеют смысл только при документированной политике конкретного оператора.
• Более специфичные объявления зависят от разрешённых префиксов и длины; они способны изменить маршруты у множества сетей.
• Асимметрия путей может мешать stateful firewall, NAT и диагностике.

Фиксируйте обе стороны: выход из компании и вход со стороны внешних клиентов. BGP не гарантирует одинаковую трассу, отсутствие потерь или перенос NAT-состояния между шлюзами.

Default, частичная или полная таблица

• Только default: оператор сообщает путь «всё остальное через меня». Минимум маршрутов; ограниченная информация о доступности конкретных направлений.
• Частичная таблица: согласованный набор сетей плюс, при необходимости, default.
• Full view: много префиксов и атрибутов; нужны подходящие память, CPU, RIB/FIB, лимиты и эксплуатация.

Полная таблица не означает «канал стал быстрее». Ресурсы определяют по платформе, AFI/SAFI, количеству соседей, принятых путей, политикам и нагрузке обновлений. Перед покупкой проверяют именно лимиты FIB и рабочий профиль, а не только объём RAM в паспорте.

В нашем примере от каждого соседа принимается ровно /0. Если оператор продолжает его объявлять при проблеме дальше своей границы, CE может сохранять неработающий выход. Для эксплуатации нужны договорённость о генерации default и независимые проверки сервисов, а не только мониторинг соседства.

Лаборатория: компания и две имитации провайдеров

• Компания CE: AS 65010, wanA 192.0.2.2/30, wanB 192.0.2.6/30.
• ISP-A: AS 65001, customer0 192.0.2.1/30.
• ISP-B: AS 65002, customer0 192.0.2.5/30.
• Учебная сеть CE: 203.0.113.0/24, адрес 203.0.113.1/24 на lo.
• Router ID: CE 10.255.0.10, ISP-A 10.255.0.1, ISP-B 10.255.0.2.

Выделите два отдельных L2-сегмента для транзитов и отдельное управление. Имена NIC условные и должны быть заранее сопоставлены реальным интерфейсам. Адрес на lo нужен для воспроизводимого существования /24 в таблице, а не для демонстрации настоящей клиентской LAN.

Оба ISP генерируют искусственный default. У них не создан выход в Интернет. Стенд демонстрирует объявления, фильтрацию и выбор маршрута; прохождение настоящего сервиса за двумя операторами требует отдельной топологии и испытания. Конфиги сверены с FRR 10.4 на 13 ноября 2026 года, но реальный парсер, сессии и пересылка здесь не запускались.

Подготовка Linux, FRR и адресов

ip -br address
ip route show
sudo vtysh -c 'show version'
sudoedit /etc/frr/daemons
# В файле пакета: zebra=yes, bgpd=yes, vtysh_enable=yes
sudo systemctl restart frr

Первые команды читают адреса, исходные маршруты и версию FRR. Через sudoedit включают нужные процессы в файле установленного пакета. restart перезапускает FRR и может затронуть другие включённые протоколы; на рабочем узле это изменение требует окна и альтернативного управления. Пример предполагает заранее установленный FRR 10.4.

ip address add 192.0.2.2/30 dev wanA
ip link set dev wanA up
ip address add 192.0.2.6/30 dev wanB
ip link set dev wanB up
ip address add 203.0.113.1/24 dev lo
sysctl -w net.ipv4.ip_forward=1

На CE команды ip address add добавляют адреса, ip link set поднимают существующие WAN, sysctl -w включает IPv4 forwarding. Команды ISP-A и ISP-B приложены в ZIP. Это временные изменения состояния Linux, а не постоянная конфигурация: после перезагрузки их должна восстановить выбранная сетевая служба. Повторный add существующего адреса может завершиться ошибкой.

Сохраните исходные IP, FRR и firewall. Проверьте TCP 179 только между ожидаемыми соседями; доступ к управлению не должен зависеть от отключаемого WAN. Пароли A и B генерируются отдельно и согласуются попарно. В публичном ZIP остаются только маркеры, не рабочие секреты.

openssl rand -hex 16

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

Конфигурация CE: принять /0 и объявить только свою сеть

hostname CE
log syslog informational
service integrated-vtysh-config
!
ip prefix-list DEFAULT-ONLY seq 10 permit 0.0.0.0/0
ip prefix-list OUR-ONLY seq 10 permit 203.0.113.0/24
!
route-map A-IN permit 10
 match ip address prefix-list DEFAULT-ONLY
 set local-preference 200
exit
route-map B-IN permit 10
 match ip address prefix-list DEFAULT-ONLY
 set local-preference 100
exit
route-map OWN-OUT permit 10
 match ip address prefix-list OUR-ONLY
exit
!
router bgp 65010
 bgp router-id 10.255.0.10
 bgp log-neighbor-changes
 bgp ebgp-requires-policy
 bgp network import-check
 neighbor 192.0.2.1 remote-as 65001
 neighbor 192.0.2.1 description LAB-ISP-A
 neighbor 192.0.2.1 password REPLACE_A_SECRET
 neighbor 192.0.2.1 ttl-security hops 1
 neighbor 192.0.2.1 timers 30 90
 neighbor 192.0.2.5 remote-as 65002
 neighbor 192.0.2.5 description LAB-ISP-B
 neighbor 192.0.2.5 password REPLACE_B_SECRET
 neighbor 192.0.2.5 ttl-security hops 1
 neighbor 192.0.2.5 timers 30 90
 address-family ipv4 unicast
  network 203.0.113.0/24
  neighbor 192.0.2.1 activate
  neighbor 192.0.2.1 route-map A-IN in
  neighbor 192.0.2.1 route-map OWN-OUT out
  neighbor 192.0.2.1 maximum-prefix 5
  neighbor 192.0.2.5 activate
  neighbor 192.0.2.5 route-map B-IN in
  neighbor 192.0.2.5 route-map OWN-OUT out
  neighbor 192.0.2.5 maximum-prefix 5
 exit-address-family
exit

Войдите в sudo vtysh, выполните configure terminal и применяйте блок для чистого лабораторного экземпляра частями. Это CLI FRR, не Bash. При ошибке остановитесь и проверьте режим; не заменяйте рабочий frr.conf учебным файлом.

• DEFAULT-ONLY: без ge/le разрешает только точный 0.0.0.0/0. Разрешение всех IPv4-префиксов — другая политика.
• OUR-ONLY: разрешает к экспорту только 203.0.113.0/24. Не создавайте общий разрешающий хвост route-map.
• A-IN/B-IN: пропускают только default и задают LOCAL_PREF 200/100.
• OWN-OUT: блокирует экспорт чужих и служебных сетей неявным deny для несовпавших префиксов.
• ebgp-requires-policy: явно требует входную и выходную политику, независимо от профиля значений по умолчанию.
• network import-check: для локального анонса требует наличие соответствующего точного префикса в таблице; адрес /24 на lo создаёт его в этой модели.
• remote-as: определяет AS соседа; activate включает его IPv4 unicast.
• password: строка-маркер заменяется попарно согласованным секретом. Защищайте файл, историю и резервные копии.
• ttl-security hops 1: GTSM для непосредственно соединённых соседей; не сочетается с ebgp-multihop.
• timers 30 90: Keepalive/Hold в секундах; это не гарантированное время восстановления приложения.

Настройка имитаций провайдера

hostname ISP-A
log syslog informational
service integrated-vtysh-config
!
ip prefix-list CUSTOMER-ONLY seq 10 permit 203.0.113.0/24
ip prefix-list DEFAULT-ONLY seq 10 permit 0.0.0.0/0
route-map CUSTOMER-IN permit 10
 match ip address prefix-list CUSTOMER-ONLY
exit
route-map DEFAULT-OUT permit 10
 match ip address prefix-list DEFAULT-ONLY
exit
router bgp 65001
 bgp router-id 10.255.0.1
 bgp log-neighbor-changes
 bgp ebgp-requires-policy
 neighbor 192.0.2.2 remote-as 65010
 neighbor 192.0.2.2 password REPLACE_A_SECRET
 neighbor 192.0.2.2 ttl-security hops 1
 neighbor 192.0.2.2 timers 30 90
 address-family ipv4 unicast
  neighbor 192.0.2.2 activate
  neighbor 192.0.2.2 route-map CUSTOMER-IN in
  neighbor 192.0.2.2 route-map DEFAULT-OUT out
  neighbor 192.0.2.2 maximum-prefix 5
  neighbor 192.0.2.2 default-originate
 exit-address-family
exit

ISP-A принимает от компании только учебный /24. Команда default-originate создаёт объявление /0 для клиента даже без настоящей интернет-достижимости. Это намеренное упрощение лаборатории, которое нельзя выдавать за проверку канала. На реальном операторском узле происхождение default проектируют по его политике и состоянию.

Полный ISP-B лежит в ZIP: AS 65002, router-id 10.255.0.2, сосед CE 192.0.2.6 и пароль B. Его адрес customer0 — 192.0.2.5/30. Остальные фильтры согласованы с ISP-A. Перед применением замените REPLACE_A_SECRET на CE и ISP-A одинаковым секретом, а REPLACE_B_SECRET — на CE и ISP-B другим согласованным секретом.

После настройки смотрят show running-config, сообщения CLI и фактический обмен. end завершает режим настройки; write memory сохраняет FRR после приёмки, но не сохраняет адреса Linux. В эксплуатации изменение политики выполняют с планом отката и согласованным способом повторного применения маршрутов.

Фильтры и max-prefix: не стать транзитом по ошибке

Классическая ошибка — принять маршруты от A и случайно передать их B. Другие сети могут начать считать компанию транзитом: это route leak, а не полезный резерв. Проверяйте исходящие анонсы каждому соседу, не ограничиваясь наличием входных маршрутов.

maximum-prefix 5 в выбранной форме FRR ограничивает принятые префиксы. Превышение разрывает сессию и может само вызвать отказ. Это дополнительная защита, не замена prefix-list. Она не означает «мы ограничили все объявления до фильтра»: для учёта отвергнутых маршрутов существует force с отдельными требованиями к хранению received routes. Эти режимы не включены в стенд.

Значение 5 выбрано для лаборатории с одним ожидаемым /0; для full view такой лимит непригоден. Контролируйте изменение объёма маршрутов и согласовывайте лимиты с оператором. Удалять ebgp-requires-policy, чтобы исчезло сообщение (Policy), — плохой способ исправить отсутствующую политику.

Проверяем сессию, объявления, выбор и таблицу Linux

sudo vtysh -c 'show bgp ipv4 unicast summary'
sudo vtysh -c 'show bgp ipv4 unicast 0.0.0.0/0'
sudo vtysh -c 'show bgp ipv4 unicast neighbors 192.0.2.1 routes'
sudo vtysh -c 'show bgp ipv4 unicast neighbors 192.0.2.1 advertised-routes'
sudo vtysh -c 'show bgp ipv4 unicast neighbors 192.0.2.5 advertised-routes'
sudo vtysh -c 'show ip route 0.0.0.0/0'
ip route get 198.51.100.10

• summary: состояние соседей, время стабильности и число принятых префиксов. В модели ожидается по одному /0 от каждого.
• Запрос /0: два кандидата и выбранный A с LOCAL_PREF 200, если оба допустимы и next hop достижим.
• routes: маршруты соседа, прошедшие входную политику. Для B повторите с 192.0.2.5.
• advertised-routes: каждому ISP должен уходить только учебный /24. Проверьте результат и на принимающем ISP.
• show ip route: победитель в общей таблице FRR может отличаться при наличии другого источника /0.
• ip route get: показывает решение Linux для документального адреса; это просмотр выбора, не отправка пакета и не доказательство доступности цели.

До-политические received-routes и после-политические routes — разные данные. Просмотр полного полученного набора зависит от настроек хранения/возможностей реализации и может стоить памяти. Не включайте такие режимы без оценки ресурсов на большой таблице.

Защита сессии и управления

• Разрешать TCP 179 только между ожидаемыми пиринг-адресами и защищать control plane от перегрузки.
• Согласовывать секреты, GTSM или другой поддерживаемый способ защиты с оператором; не ослаблять их односторонне.
• Учитывать версию, поддержку криптографических механизмов и ограничения установленного пакета.
• Разделять доступ к управлению, изменения маршрутов и право просматривать секреты.
• Сохранять конфигурацию и её историю; уведомлять об изменении AS, политик и набора объявлений.

TCP-аутентификация в примере не шифрует пользовательский трафик. Защита BGP-сессии не доказывает законность объявленного префикса и не предотвращает все утечки маршрутов. Это несколько разных слоёв: защита обмена, фильтры, проверка происхождения и эксплуатационный контроль.

Не включайте ebgp-multihop «на всякий случай». Для loopback-пиринга нужна отдельная схема достижимости и защиты. Не публикуйте конфиги с настоящими паролями, даже если вывод консоли выглядит удобным подтверждением работы.

RPKI, ROA, ROV и route leak — чем отличаются

ROA задаёт разрешённый origin ASN и допустимые параметры объявления адресного ресурса. ROV сопоставляет маршрут с валидированными данными: Valid, Invalid либо NotFound. NotFound означает отсутствие покрывающей информации, а не доказанную атаку. Invalid требует разбирательства: причиной может быть чужой origin или несогласованный maxLength.

При слишком широком maxLength разрешается больше специфичных объявлений, чем фактически требуется. При слишком узком законный более специфичный анонс может получить Invalid. Изменения ROA согласуют с планом миграции и реальным составом анонсов; не редактируют ради зелёного статуса без проверки полномочий.

В FRR интеграция RPKI зависит от модуля, сборки и доступа к валидирующему кешу. Нужны мониторинг актуальности данных и политика при недоступности кеша. В нашем ZIP RPKI не настроена: частный изолированный пример не является проверкой публичной ROA/ROV-инфраструктуры.

Route leak может содержать корректный origin ASN. Поэтому ROV не заменяет export-фильтры, согласование ролей и другие меры. BGP Roles и OTC из RFC 9234 помогают в поддерживаемой согласованной архитектуре, но не отменяют проверку политик и совместимости обоих соседей.

Отказ основного пути: что именно испытывать

# Только CE в изолированном стенде, управление отдельно
sudo ip link set dev wanA down
# После измерений восстановить связь
sudo ip link set dev wanA up

До изменения сохраните summary, кандидатов /0 и маршрут ядра. После потери A ожидаем выбор B, если его объявление остаётся допустимым. При потере обоих BGP-default должен исчезнуть, но статический /0 или policy route могут остаться и продолжить направлять трафик. Проверяйте контекст полностью.

Локальное отключение порта — один сценарий. «Тихая» проблема дальше провайдера может не разрушить BGP-сессию и не отозвать default. BFD помогает обнаруживать определённые отказы пути между участниками, но не подтверждает доступность всех внешних сервисов. Время реакции включает обнаружение, обработку маршрутов, обновление пересылки и поведение приложения.

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

Уменьшение Hold Time не гарантирует бесшовность. Смена NAT-адреса часто требует новых соединений; у опубликованного сервиса важны разрешённая адресация, анонсы, входящая политика и состояние firewall.

Не поднимается BGP или не идут маршруты

sudo vtysh -c 'show bgp ipv4 unicast neighbors 192.0.2.1'
ip route get 192.0.2.1
ss -tnp
journalctl -u frr --since '-15 min' --no-pager
sudo tcpdump -ni wanA -c 30 'tcp port 179'

Первая команда читает параметры и состояние конкретного соседа. ip route get показывает достижимость пиринг-адреса по таблицам; ss помогает увидеть TCP-соединения. Журнал FRR сопоставляют с временем событий. Захват ограничен 30 пакетами, но при отсутствии обмена может ждать до ручной остановки; дамп содержит служебную информацию.

• Idle/Active: IP, линк, маршрут до соседа, TCP 179, служба, пароль, TTL/GTSM и настройки обеих сторон.
• OpenSent/OpenConfirm: журналы уведомлений, ASN, возможности и согласование параметров.
• Established, но ноль маршрутов: address family, import/export-политика, состояние источника анонса и наличие нужного префикса.
• (Policy): проверить отсутствующий входной или выходной фильтр, а не снимать защиту.
• Маршрут есть, но не выбран: next hop, атрибуты, другой более предпочтительный кандидат, VRF или policy routing.
• Выбран, но трафик не проходит: FIB, forwarding, firewall, обратный путь, MTU и сам сервис.

После исправления повторите проверку принятых и объявленных сетей. Жёсткий reset рвёт сессию; мягкое повторное применение политики зависит от доступного механизма и согласованного окна. Не используйте бездумный clear всех соседей как диагностику.

Эксплуатация и критерии приёмки

• Пиринг: ожидаемые IP/ASN, uptime, перезапуски, причины и длительность нестабильности.
• Политика: принятые и экспортируемые префиксы, рост таблиц, limit и появление default.
• Происхождение: состояние ROV/валидатора и соответствие ROA для публичной схемы.
• Ресурсы: память, CPU, RIB/FIB, обновления, потери и ёмкость резерва.
• Бизнес: доступность приложения из компании и со стороны внешних клиентов.

Сохраняйте историю и единое время: корреляция reset соседства, ошибок порта, изменений фильтра, нагрузки и жалоб помогает расследовать инцидент. Одного графика «сосед сейчас установлен» недостаточно.

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

Первичные источники: BGP FRR 10.4, RFC 4271, безопасность BGP, обязательные eBGP-политики, ROV и BGP Roles/OTC. Для внутренней связности см. разбор OSPF.

Скачать конфигурации и карточку проверки

Архив содержит три полных конфига, команды адресации, CSV и README. Он не содержит настоящих паролей и не подключён к Интернету. Перед применением адаптируйте интерфейсы и секреты; начинайте с отдельного стенда.

Поможем спроектировать и сопровождать связность

Вопросы и ответы