Междоменная маршрутизация и BGP

В теме 9 рассматривалась маршрутизация внутри одной организационной единицы: все маршрутизаторы сети подчиняются одному администратору, знают общую карту или общие метрики и стремятся к единой цели — доставить пакет по кратчайшему пути. Протоколы RIP и OSPF решают эту задачу хорошо, но лишь до тех пор, пока сеть остаётся под единым управлением. Интернет устроен иначе. Он состоит из десятков тысяч независимых сетей — провайдеров, университетов, облачных платформ, контент-компаний, — каждая из которых самостоятельно решает, через кого передавать свой трафик, чей трафик принимать и кому сообщать о своих адресах. Эти решения определяются договорами и деньгами, а не метрикой каналов, и ни одна организация не видит и не контролирует Интернет целиком.

Отсюда вопрос, на который отвечает тема: как независимые сети договариваются о достижимости адресов так, чтобы каждая из них сохраняла контроль над своей политикой, а глобальная система при этом оставалась связной и не зацикливалась. Ответом служит протокол пограничного шлюза (англ. Border Gateway Protocol, BGP) четвёртой версии — единственный протокол междоменной маршрутизации, используемый в Интернете с середины 1990-х годов ¹.

Изложение построено так. Сначала вводится понятие автономной системы и рассматриваются экономические отношения между сетями, которые определяют, какие пути в Интернете вообще допустимы. Затем разбирается сам протокол BGP: сессия поверх TCP, конечный автомат, формат сообщений OPEN и UPDATE байт за байтом. Третий раздел посвящён атрибутам пути и процессу выбора лучшего маршрута с пошаговым примером. Далее рассматриваются политики маршрутизации, управление трафиком и BGP внутри автономной системы. Пятый раздел посвящён уязвимостям глобальной маршрутизации — перехватам и утечкам маршрутов — и механизмам защиты: реестрам IRR, RPKI и ролям BGP. Завершает тему обзор anycast и инструментов наблюдения за маршрутизацией в реальном Интернете.

Интернет как сеть автономных систем

Автономная система и её номер

Автономная система (англ. Autonomous System, AS) — совокупность маршрутизаторов и сетей под единым техническим управлением, которая для внешнего мира выглядит как целое с единой согласованной политикой маршрутизации ¹. Внутри автономной системы могут работать любые протоколы внутренней маршрутизации — OSPF, IS-IS, статические маршруты (тема 9), — но наружу она предъявляет один набор правил: какие префиксы принадлежат ей, какие она готова передавать транзитом и на каких условиях. Протоколы внутри AS называют протоколами внутреннего шлюза (англ. Interior Gateway Protocol, IGP), протокол между автономными системами — протоколом внешнего шлюза (англ. Exterior Gateway Protocol, EGP); BGP — единственный используемый сегодня протокол второго класса.

Каждой автономной системе, участвующей в глобальной маршрутизации, присваивается уникальный номер (англ. Autonomous System Number, ASN). Номера распределяет IANA между пятью региональными интернет-регистратурами (англ. Regional Internet Registry, RIR): AFRINIC, APNIC, ARIN, LACNIC и RIPE NCC, — а те выдают их организациям. Изначально номер занимал 16 бит, что давало 65 536 значений; к середине 2000-х годов стало ясно, что их не хватит, и номер расширили до 32 бит ³. Четырёхбайтовые номера записываются обычным десятичным числом, например 4200000000; встречается и устаревшая запись через точку (65536 записывается как 1.0).

Некоторые диапазоны номеров зарезервированы. Номера 64496–64511 и 65536–65551 предназначены для документации и учебных примеров (RFC 5398) — ими пользуется и настоящий курс. Номера 64512–65534 и 4200000000–4294967294 — частные (RFC 6996): их применяют внутри организаций и в центрах обработки данных, но не анонсируют в Интернет. Номер 23456 (AS_TRANS) служит заглушкой для совместимости старых двухбайтовых реализаций с четырёхбайтовыми номерами ³. По данным проекта CIDR Report, в октябре 2026 года в глобальной таблице маршрутизации видны около 80 тысяч автономных систем и около 1,08 млн префиксов IPv4.

Важно различать два понятия: префикс принадлежит организации, а автономная система его анонсирует, то есть сообщает соседям, что пакеты для этих адресов можно отправлять ей. Автономная система, которая первой анонсирует префикс, называется источником (англ. origin AS) этого префикса. Связь между префиксом и законной AS-источником — центральный вопрос безопасности маршрутизации, к которому мы вернёмся в пятом разделе.

Отношения между автономными системами: транзит и пиринг

Соединение двух автономных систем — не только техническое, но и договорное. В Интернете преобладают два типа отношений ⁷¹³.

Отношение «клиент — провайдер» (англ. customer — provider), или транзит (англ. transit): клиент платит провайдеру за доступ ко всему Интернету. Провайдер обязуется анонсировать префиксы клиента всем своим соседям и передавать клиенту маршруты ко всем известным ему сетям. Деньги текут от клиента к провайдеру, обычно пропорционально объёму трафика (например, по 95-му процентилю загрузки канала).

Отношение «равноправный обмен» (англ. peer — peer), или пиринг (англ. peering): две сети договариваются обмениваться трафиком между своими клиентами, как правило без взаимных платежей. Принципиальная особенность пиринга — его ограниченность: каждая сторона сообщает другой только свои префиксы и префиксы своих клиентов, но не маршруты, полученные от провайдеров или других пиров. Пир не продаёт пиру транзит в остальной Интернет.

Мотивация пиринга экономическая. Если провайдеры А и Б обмениваются большим объёмом трафика между своими клиентами, им выгоднее соединиться напрямую, чем платить общему вышестоящему провайдеру за доставку этого трафика.

Точки обмена трафиком и иерархия провайдеров

На вершине иерархии находятся провайдеры первого уровня (англ. Tier 1) — сети, которые достигают любого адреса Интернета без покупки транзита: со всеми остальными сетями первого уровня у них пиринг, а все прочие сети являются их прямыми или косвенными клиентами. К ним относят, например, Lumen (AS3356), Arelion (AS1299), NTT (AS2914), Cogent (AS174). Ниже располагаются региональные провайдеры, которые покупают транзит у первого уровня и одновременно продают его своим клиентам, а в самом низу — тупиковые (англ. stub) автономные системы: предприятия и университеты, которые ничего не передают транзитом. Тупиковая AS, подключённая к двум и более провайдерам ради надёжности, называется многодомной (англ. multihomed).

Иерархия на практике давно размыта. Крупные контент-провайдеры и облачные платформы (Google, Amazon, Cloudflare, Meta) построили собственные глобальные сети и обмениваются трафиком напрямую с тысячами провайдеров, минуя верхние уровни. Этому способствуют точки обмена трафиком (англ. Internet Exchange Point, IX или IXP) — площадки, где десятки и сотни сетей подключаются к общему коммутатору Ethernet и устанавливают пиринговые сессии друг с другом. Крупнейшие IX — DE-CIX во Франкфурте, AMS-IX в Амстердаме, LINX в Лондоне, MSK-IX в Москве. Чтобы не устанавливать сессию с каждым участником, на IX работают серверы маршрутов (англ. route server), собирающие маршруты всех участников и раздающие их обратно. Сама IX не участвует в пересылке на сетевом уровне: это общий сегмент второго уровня, а BGP-сессии идут между маршрутизаторами участников.

Рисунок ниже показывает типичную картину: провайдеры первого уровня связаны пирингом, региональные провайдеры покупают у них транзит и пирингуются между собой на IX, тупиковые AS подключены к одному или двум провайдерам.

Правило «долины» и экспорт маршрутов

Из договорных отношений следуют правила экспорта маршрутов, которые первыми формализовали Л. Гао и Дж. Рексфорд ⁷. Обозначим маршруты по тому, от кого они получены: от клиента, от пира или от провайдера. Тогда:

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

Последствие этих правил для путей в Интернете называют правилом «долины» (англ. valley-free). Представим путь как последовательность шагов: «вверх» — от клиента к провайдеру, «вниз» — от провайдера к клиенту, «вбок» — между пирами. Допустимый путь сначала идёт только вверх (ноль или более шагов), затем делает не более одного шага вбок и далее идёт только вниз. Путь, спускающийся к клиенту и снова поднимающийся к другому провайдеру, образует «долину»: клиент при этом бесплатно, а точнее за собственный счёт, перевозит трафик между двумя своими провайдерами. Также недопустимы два шага вбок подряд.

Рассмотрим пример по рисунку выше. Тупиковая AS 64500 подключена к провайдерам 64501 и 64502. Путь «64500 → 64501 → 64496 → 64497 → 64503 → 64510» поднимается от клиента к провайдеру первого уровня, делает шаг вбок между двумя сетями первого уровня и спускается к получателю — он допустим. Путь «64501 → 64500 → 64502» опускается к клиенту и вновь поднимается — это долина. Если бы AS 64500 анонсировала провайдеру 64502 маршруты, полученные от 64501, весь трафик между двумя провайдерами мог бы пойти через её каналы. Такая ошибка называется утечкой маршрутов и разбирается в пятом разделе.

Гао и Рексфорд показали и более сильный результат: если каждая AS предпочитает маршруты через клиентов маршрутам через пиров, а те — маршрутам через провайдеров, и соблюдает правила экспорта, а граф отношений «клиент — провайдер» не содержит циклов, то BGP гарантированно сходится к устойчивому состоянию без какой-либо глобальной координации ⁷. Именно поэтому практическая политика большинства провайдеров выглядит одинаково: клиентским маршрутам назначается наибольший приоритет, пиринговым — средний, провайдерским — наименьший. Как это делается средствами BGP, показано в третьем и четвёртом разделах.

Протокол BGP-4: сессии и сообщения

Вектор путей вместо вектора расстояний

Прежде чем разбирать формат сообщений, выясним, почему для междоменной маршрутизации не подходят протоколы из темы 9. Протокол состояния каналов (OSPF) требует, чтобы каждый маршрутизатор знал полный граф сети с метриками каналов. Для Интернета это неприемлемо по трём причинам: граф огромен, сети не желают раскрывать внутреннее устройство конкурентам, а главное — единой метрики не существует, поскольку каждая AS выбирает путь по собственным коммерческим критериям. Дистанционно-векторный протокол (RIP) раскрывает меньше, но страдает от счёта до бесконечности и тоже опирается на общую метрику.

BGP — протокол вектора путей (англ. path vector). Как и в дистанционно-векторном подходе, маршрутизатор сообщает соседям только свои лучшие маршруты, но вместо числового расстояния каждый маршрут несёт полный список автономных систем, через которые прошло объявление, — атрибут AS_PATH. Это решает две задачи сразу. Во-первых, петли обнаруживаются тривиально: AS, увидевшая собственный номер в пути, отбрасывает маршрут, поэтому счёт до бесконечности невозможен. Во-вторых, путь даёт материал для политики: AS может отвергать маршруты через нежелательные сети или предпочитать одних соседей другим, а длина пути служит лишь одним из критериев выбора.

История протокола начинается в 1989 году, когда первая версия BGP (RFC 1105) пришла на смену протоколу EGP, рассчитанному на древовидную топологию ранней NSFNET. Версия 4 опубликована в 1994–1995 годах (RFC 1771) и с поддержкой бесклассовой адресации (CIDR) стала основой коммерческого Интернета; действующая спецификация — RFC 4271 ¹. Многопротокольные расширения позволяют переносить в BGP префиксы IPv6, VPN и другие семейства адресов ⁶; их устройство кратко рассмотрено ниже.

Сессия поверх TCP и конечный автомат

Два маршрутизатора, обменивающиеся маршрутами по BGP, называются соседями (англ. neighbors) или пирами. Слово «пир» здесь имеет технический смысл — участник сессии — и не совпадает с договорным «пирингом» из предыдущего раздела; путаница этих значений — частая ошибка. Сессия между маршрутизаторами разных AS называется внешней (англ. external BGP, eBGP), между маршрутизаторами одной AS — внутренней (англ. internal BGP, iBGP).

В отличие от OSPF, который сам обнаруживает соседей рассылкой hello-пакетов, BGP соседей не ищет: администратор явно указывает адрес и номер AS каждого соседа. Сообщения передаются по TCP на порт 179 ¹. TCP обеспечивает надёжность, упорядоченность и управление потоком (подробно — в темах 12 и 13), поэтому в BGP нет ни подтверждений, ни повторной передачи, ни периодического повторения всей таблицы: однажды переданный маршрут считается известным соседу до тех пор, пока не будет явно отозван или пока не разорвётся сессия. Это ключевое отличие от RIP с его рассылкой всей таблицы каждые 30 секунд — и причина того, что BGP справляется с таблицей из миллиона префиксов.

Состояние сессии описывается конечным автоматом из шести состояний ¹:

• Idle — исходное состояние: ресурсы не выделены, соединение не устанавливается (например, после ошибки или административного отключения);
• Connect — маршрутизатор пытается установить TCP-соединение с соседом;
• Active — попытка не удалась, маршрутизатор ожидает входящего соединения от соседа и повторит попытку по истечении таймера ConnectRetry (рекомендуемое значение — 120 с);
• OpenSent — TCP-соединение установлено, отправлено сообщение OPEN, ожидается OPEN соседа;
• OpenConfirm — OPEN соседа получен и проверен, отправлен KEEPALIVE, ожидается KEEPALIVE в ответ;
• Established — сессия установлена, идёт обмен UPDATE.

Название состояния Active вводит в заблуждение: оно означает не «сессия активна», а «соединения нет, жду». Сосед, надолго застрявший в Active или колеблющийся между Active и Connect, указывает на проблему связности или настройки: неверный адрес соседа, отсутствие маршрута до него, фильтр на TCP-порт 179.

Временна́я диаграмма на рисунке ниже показывает установление сессии. После трёхэтапного рукопожатия TCP обе стороны отправляют OPEN, подтверждают параметры друг друга сообщением KEEPALIVE и переходят в Established, после чего передают свои маршруты в сообщениях UPDATE.

Живость сессии контролируют два таймера. Каждая сторона предлагает в OPEN время удержания (англ. hold time); действует меньшее из двух предложенных значений. Если в течение времени удержания от соседа не пришло ни одного сообщения, сессия разрывается, а все полученные от него маршруты удаляются. Чтобы при отсутствии изменений сессия не разорвалась, стороны периодически посылают KEEPALIVE; RFC 4271 рекомендует время удержания 90 с и интервал KEEPALIVE в треть от него ¹. FRRouting по умолчанию использует 180 и 60 с ¹². Таким образом, отказ соседа, не сопровождающийся разрывом канала, обнаруживается только через три минуты — для ускорения применяют уменьшенные таймеры или протокол BFD (тема 9). При падении непосредственно подключённого интерфейса FRR разрывает eBGP-сессию сразу, не дожидаясь таймера.

Формат сообщений: заголовок и OPEN

Каждое сообщение BGP начинается с заголовка длиной 19 байт ¹:

Тип 5 введён отдельным документом (RFC 2918) и позволяет запросить у соседа повторную передачу маршрутов без разрыва сессии — именно его использует команда «мягкого» сброса clear bgp ... soft in. Предельная длина 4096 байт позднее расширена до 65 535 байт для соседей, договорившихся об этом (RFC 8654).

Сообщение OPEN после заголовка содержит:

Наиболее важный необязательный параметр — объявление возможностей (англ. capabilities, тип параметра 2): каждая сторона перечисляет поддерживаемые расширения, и действует их пересечение. Среди них многопротокольные расширения (код 1) с указанием семейства адресов ⁶, поддержка ROUTE-REFRESH (код 2), четырёхбайтовые номера AS (код 65) ³, добавление нескольких путей ADD-PATH (код 69), плавный перезапуск (код 64), роль BGP (код 9) ¹⁰.

Разберём OPEN, который маршрутизатор AS 64500 с идентификатором 203.0.113.1 отправляет соседу. Сообщение предельно сокращено: в нём три возможности (реальный OPEN FRR содержит их около десятка и потому длиннее).

0000  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff   Marker
0010  00 31 01                                          Length = 49, Type = 1 (OPEN)
0013  04                                                Version = 4
0014  fb f4                                             My AS = 0xFBF4 = 64500
0016  00 b4                                             Hold Time = 180 с
0018  cb 00 71 01                                       BGP Identifier = 203.0.113.1
001c  14                                                Opt Parm Len = 20
001d  02 06 01 04 00 01 00 01                           Capability 1: AFI 1 (IPv4), SAFI 1 (unicast)
0025  02 02 02 00                                       Capability 2: Route Refresh
0029  02 06 41 04 00 00 fb f4                           Capability 65: 4-octet AS = 64500

Каждая возможность упакована в параметр типа 2: байт 02 — тип параметра, следующий байт — его длина, затем код возможности, её длина и значение. Проверим длину: 19 байт заголовка, 10 байт фиксированной части OPEN (1 + 2 + 2 + 4 + 1) и 20 байт параметров дают 49 = 0x31. Номер 64500 помещается в два байта, поэтому поле My AS содержит его самого; маршрутизатор с номером 4200000001 записал бы туда 23456, а настоящий номер передал бы только в возможности 65 ³.

Получатель проверяет OPEN: совпадает ли номер AS с настроенным для этого соседа, допустимо ли время удержания, не совпадает ли идентификатор с собственным. При ошибке он отправляет NOTIFICATION и закрывает соединение. Типичная ошибка настройки — неверный remote-as — проявляется именно здесь: сессия циклически проходит Connect → OpenSent → Idle, а в журнале появляется NOTIFICATION с кодом 2 (ошибка в OPEN) и подкодом 2 (неверный номер AS соседа).

Сообщения UPDATE, KEEPALIVE и NOTIFICATION

Маршрутная информация передаётся в сообщениях UPDATE. Одно сообщение может одновременно отзывать ранее анонсированные префиксы и анонсировать новые, причём все новые префиксы в одном сообщении разделяют общий набор атрибутов пути. Структура UPDATE показана на рисунке ниже.

После заголовка следуют: длина списка отзываемых маршрутов (2 байта) и сам список (англ. Withdrawn Routes); суммарная длина атрибутов пути (2 байта) и сами атрибуты (англ. Path Attributes); затем, до конца сообщения, — список анонсируемых префиксов (англ. Network Layer Reachability Information, NLRI) ¹. Префикс кодируется компактно: байт длины префикса в битах и минимальное число байт адреса, вмещающее эти биты. Префикс /24 занимает 1 + 3 = 4 байта, /25 — 1 + 4 = 5 байт, маршрут по умолчанию 0.0.0.0/0 — один байт.

Каждый атрибут закодирован по схеме «флаги — тип — длина — значение». Четыре старших бита байта флагов означают: Optional (0x80) — атрибут необязательный; Transitive (0x40) — атрибут следует передавать дальше, даже если он непонятен; Partial (0x20) — необязательный транзитивный атрибут прошёл через маршрутизатор, который его не понимал; Extended Length (0x10) — поле длины занимает два байта вместо одного.

Рассмотрим UPDATE, которым маршрутизатор AS 64500 анонсирует провайдеру свой префикс 203.0.113.0/24 через eBGP-сессию с адреса 10.1.1.2:

0000  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff   Marker
0010  00 2f 02                                          Length = 47, Type = 2 (UPDATE)
0013  00 00                                             Withdrawn Routes Length = 0
0015  00 14                                             Total Path Attribute Length = 20
0017  40 01 01 00                                       ORIGIN: flags 0x40, type 1, len 1, IGP (0)
001b  40 02 06 02 01 00 00 fb f4                        AS_PATH: type 2, len 6, AS_SEQUENCE из 1 номера: 64500
0024  40 03 04 0a 01 01 02                              NEXT_HOP: type 3, len 4, 10.1.1.2
002b  18 cb 00 71                                       NLRI: /24, 203.0.113

Атрибуты ORIGIN, AS_PATH и NEXT_HOP имеют флаг 0x40: они общеизвестные (не Optional) и транзитивные. Атрибут AS_PATH состоит из сегментов; сегмент типа 2 (AS_SEQUENCE) — упорядоченная последовательность номеров, здесь из одного четырёхбайтового номера, поскольку обе стороны объявили возможность 65. Длина сообщения: 19 + 2 + 2 + 20 + 4 = 47 байт. Реальный UPDATE от FRR обычно содержит ещё атрибут MULTI_EXIT_DISC со значением 0 для локально созданных маршрутов; в примере он опущен.

Отзыв маршрута — UPDATE с непустым списком Withdrawn Routes и без атрибутов. Отзыв того же префикса займёт 19 + 2 + 4 + 2 = 27 байт. Многопротокольные расширения переносят префиксы других семейств (IPv6, VPN) не в полях NLRI и Withdrawn Routes, а в атрибутах MP_REACH_NLRI (тип 14) и MP_UNREACH_NLRI (тип 15), которые содержат идентификаторы семейства AFI/SAFI и собственный следующий переход ⁶. Поэтому BGP для IPv6 — тот же протокол, а нередко и та же сессия поверх IPv4 (тема 11).

Сообщение KEEPALIVE состоит из одного заголовка и имеет длину 19 байт. Сообщение NOTIFICATION сообщает об ошибке и всегда сопровождается закрытием соединения; оно содержит код ошибки (1 — ошибка заголовка, 2 — ошибка в OPEN, 3 — ошибка в UPDATE, 4 — истечение времени удержания, 5 — ошибка конечного автомата, 6 — прекращение сессии, англ. Cease), подкод и диагностические данные ¹. Код 6 используется и при штатном административном отключении соседа, и при превышении допустимого числа префиксов.

Атрибуты пути и выбор лучшего маршрута

Категории атрибутов

Атрибуты пути — это свойства маршрута, на которых строятся и выбор лучшего пути, и политика. RFC 4271 делит их на четыре категории ¹:

В скобках указаны коды типов. Атрибуты сообществ определены в RFC 1997 и RFC 8092 ⁴⁵, атрибуты отражения маршрутов — в RFC 4456 ⁹, атрибут OTC — в RFC 9234 ¹⁰.

AS_PATH, NEXT_HOP и ORIGIN

Атрибут AS_PATH — список автономных систем, через которые прошло объявление, в обратном порядке: последней записана AS-источник, первой — сосед. Каждый маршрутизатор, передающий маршрут по eBGP, дописывает свой номер в начало. Если провайдер 64501 получил от клиента маршрут с путём 64500 и передал его пиру 64502, тот увидит путь 64501 64500. Помимо обнаружения петель путь используется в выборе маршрута — короче значит лучше — и в фильтрах. При агрегации маршрутов из разных путей возникает сегмент типа AS_SET — неупорядоченное множество номеров, которое при подсчёте длины учитывается как один номер.

Атрибут NEXT_HOP — адрес маршрутизатора, которому следует передать пакеты для данного префикса. При передаче по eBGP маршрутизатор обычно подставляет собственный адрес на этой сессии. При передаче по iBGP атрибут по умолчанию не меняется: маршрутизатор внутри AS получает в качестве следующего перехода адрес внешнего соседа на другой границе AS. Чтобы маршрут был пригоден, этот адрес должен быть достижим по таблице маршрутизации — через IGP или подключённую сеть. Если сеть между AS не известна внутреннему протоколу, маршрут остаётся в таблице BGP, но не используется; лекарство — команда next-hop-self на граничном маршрутизаторе либо анонс сетей стыков в IGP.

Атрибут ORIGIN указывает, как префикс попал в BGP: IGP (0) — по явной команде network, EGP (1) — из исторического протокола EGP, на практике не встречается, INCOMPLETE (2) — перераспределением из другого источника, например командой redistribute static. В выводе команд значения обозначаются символами i, e и ?.

LOCAL_PREF, MED и сообщества

Атрибут LOCAL_PREF (локальный приоритет) — главный инструмент политики выбора исходящего пути. Это число, чем больше, тем предпочтительнее маршрут; значение по умолчанию — 100. Атрибут действует только внутри одной AS: он передаётся по iBGP, чтобы все маршрутизаторы AS принимали согласованное решение, и никогда не передаётся по eBGP. Именно через LOCAL_PREF реализуется иерархия предпочтений Гао — Рексфорд: на входящих сессиях от клиентов устанавливается, например, 200, от пиров — 150, от провайдеров — 100. Поскольку сравнение LOCAL_PREF предшествует сравнению длины пути, клиентский маршрут будет выбран даже тогда, когда путь через пира короче.

Атрибут MULTI_EXIT_DISC (MED, межсистемный дискриминатор) — подсказка соседней AS о том, через какую из нескольких точек стыка лучше входить: меньшее значение предпочтительнее. Атрибут нетранзитивен — он передаётся только в соседнюю AS и дальше не распространяется — и по умолчанию сравнивается лишь между маршрутами, полученными из одной и той же соседней AS. Сосед вправе подсказку проигнорировать: LOCAL_PREF и длина пути проверяются раньше.

Атрибут COMMUNITIES (сообщества) — это набор 32-битных меток, которые маршрутизатор прикрепляет к маршруту ⁴. Метка записывается как ASN:значение, где старшие 16 бит — номер AS, определяющей смысл метки. Сообщества не влияют на выбор маршрута сами по себе: они служат для передачи намерений между сетями и между маршрутизаторами одной сети. Провайдер помечает маршруты по происхождению («получен от клиента», «получен на IX во Франкфурте») и затем фильтрует экспорт по меткам, а клиентам публикует сообщества действий: например, метка 64501:70 от клиента означает «установите этому маршруту LOCAL_PREF 70», что позволяет клиенту управлять входящим трафиком. Определены общеизвестные сообщества: NO_EXPORT (65535:65281) — не передавать маршрут за пределы AS, NO_ADVERTISE (65535:65282) — не передавать никому ⁴, а также BLACKHOLE (65535:666, RFC 7999) — просьба отбрасывать трафик к префиксу, применяемая при отражении DDoS-атак.

Шестнадцати бит для номера AS в обычном сообществе недостаточно для четырёхбайтовых номеров, поэтому введены большие сообщества (англ. large communities) — тройки 32-битных чисел вида 4200000001:1:70 ⁵.

Наконец, вес (англ. weight) — не атрибут протокола, а локальное свойство маршрута в реализациях Cisco и FRR: число, действующее на одном маршрутизаторе и проверяемое раньше всех атрибутов. Локально созданные маршруты получают вес 32768, полученные от соседей — 0.

Процесс выбора лучшего маршрута: пошаговый разбор

Маршрутизатор может получить один и тот же префикс от нескольких соседей. Все полученные варианты хранятся в таблице BGP (англ. Adj-RIB-In, затем Loc-RIB), но в таблицу маршрутизации устанавливается и соседям анонсируется только один — лучший. Сначала отбрасываются непригодные маршруты: отвергнутые входной политикой, содержащие собственный номер AS в пути, с недостижимым следующим переходом. Затем оставшиеся сравниваются по шагам; на каждом шаге отбрасываются все кандидаты, кроме лучших по данному критерию, и процесс останавливается, как только остаётся один. В FRR 10 порядок шагов следующий ¹²:

1. Больший вес (weight).
2. Больший LOCAL_PREF.
3. Локально созданный маршрут (network, агрегат, перераспределение) предпочтительнее полученного от соседа.
4. Более короткий AS_PATH.
5. Меньший ORIGIN: IGP лучше EGP, EGP лучше INCOMPLETE.
6. Меньший MED — только среди маршрутов из одной соседней AS.
7. Маршрут от eBGP-соседа предпочтительнее маршрута от iBGP-соседа.
8. Меньшая стоимость IGP до следующего перехода.
9. Проверка многопутевой маршрутизации: если она включена, оставшиеся равные маршруты используются одновременно.
10. Если оба маршрута получены по eBGP — предпочтительнее уже выбранный ранее (защита от колебаний).
11. Меньший идентификатор маршрутизатора соседа (или ORIGINATOR_ID для отражённого маршрута).
12. Более короткий CLUSTER_LIST.
13. Адрес соседа как последний критерий.

Шаги 4–8 и 11 соответствуют правилам разрешения неопределённости RFC 4271 ¹; шаги 1, 3, 9 и 10 — расширения реализаций, и их набор у разных производителей немного различается. На последнем шаге RFC 4271 предписывает предпочесть соседа с меньшим адресом; так же поступает и FRR (функция bgp_path_info_cmp), хотя его документация говорит о большем адресе. На практике до этого шага сравнение доходит крайне редко.

Разберём пример. Маршрутизатор R3 в AS 64502 получил пять маршрутов к префиксу 192.0.2.0/24. Маршруты от iBGP-соседей R1, R2 и R4 пришли с других граничных маршрутизаторов той же AS, где им уже был назначен LOCAL_PREF по типу отношения.

Шаг 1. Вес всех маршрутов равен 0 — без изменений.

Шаг 2. Наибольший LOCAL_PREF — 150. Маршрут 1 (100) отбрасывается, хотя по длине пути он не хуже остальных: политика «пир дешевле провайдера» срабатывает прежде любых технических критериев. Остаются 2, 3, 4, 5.

Шаг 3. Локальных маршрутов нет.

Шаг 4. Длина AS_PATH: у маршрутов 2, 3, 5 — 2, у маршрута 4 — 3. Маршрут 4 отбрасывается. Остаются 2, 3, 5.

Шаг 5. ORIGIN: у маршрута 5 значение INCOMPLETE — источник перераспределил префикс из другого протокола. Маршрут 5 отбрасывается. Остаются 2 и 3.

Шаг 6. Оба оставшихся маршрута получены из одной соседней AS 64501, поэтому их MED сравнимы: 10 меньше 20. AS 64501 сообщила, что предпочитает принимать трафик через петербургский стык, и выбран маршрут 3.

Итог: лучшим стал маршрут 3, полученный по iBGP, хотя рядом был маршрут 2 непосредственно от eBGP-соседа. Пример показывает важную особенность порядка: шаг «eBGP лучше iBGP» (7) проверяется после MED. Если бы MED совпадали или отсутствовали, решение принял бы шаг 7, и победил бы маршрут 2. Если бы маршрут 3 пришёл из другой AS, например 64508, сравнение MED было бы пропущено вовсе. Такой поатрибутный разбор — основной приём при объяснении любого неожиданного выбора BGP, и в лабораторной работе он выполняется как вручную, так и вспомогательным сценарием на Python.

В FRR результат выбора виден в подробном выводе для префикса: рядом с лучшим маршрутом указаны слово best и в скобках причина — шаг, на котором отсеян ближайший конкурент.

# в vtysh маршрутизатора AS 64500 из лабораторной работы
show bgp ipv4 unicast 192.0.2.0/24

BGP routing table entry for 192.0.2.0/24, version 7
Paths: (2 available, best #1, table default)
  Not advertised to any peer
  64501 64503
    10.1.1.3 from 10.1.1.3 (198.51.100.1)
      Origin IGP, valid, external, best (AS Path)
      Last update: ...
  64502 64501 64503
    10.1.2.3 from 10.1.2.3 (198.51.100.129)
      Origin IGP, valid, external
      Last update: ...

Лучший путь выбран на шаге сравнения длины AS_PATH, о чём говорит пометка best (AS Path). Строка Not advertised to any peer показывает действие выходной политики: маршрут, полученный от одного провайдера, клиент не передаёт ни одному соседу, в том числе другому провайдеру.

Политики маршрутизации, eBGP и iBGP

Политики импорта и экспорта

Политика BGP — это набор правил, применяемых к маршрутам на входе от соседа (импорт) и на выходе к соседу (экспорт). Входная политика решает, принять ли маршрут и с какими атрибутами (LOCAL_PREF, сообщества); выходная — передавать ли маршрут соседу и как его изменить (удлинить путь, добавить метки). В FRR, как и в большинстве реализаций, политики строятся из трёх элементов ¹²:

• список префиксов (ip prefix-list) — упорядоченный набор правил permit/deny по префиксу и диапазону длин, например permit 203.0.113.0/24 le 25;
• список сообществ (bgp community-list) и список путей (bgp as-path access-list, регулярные выражения над AS_PATH);
• карта маршрутов (route-map) — последовательность пронумерованных записей вида «если совпало (match ...), то разрешить или запретить и изменить атрибуты (set ...)». Маршрут, не совпавший ни с одной записью, отвергается: в конце карты подразумевается запрет.

Политика типичного провайдера по отношению к клиенту выглядит так: принимать только префиксы, которые клиент вправе анонсировать (список префиксов, составленный по реестру), назначать им высокий LOCAL_PREF и метку «клиентский», а отдавать клиенту все маршруты. По отношению к пиру: принимать его маршруты с меньшим LOCAL_PREF, отдавать только собственные и клиентские маршруты. Фрагмент такой политики в синтаксисе FRR:

ip prefix-list FROM-CUST-64500 seq 10 permit 203.0.113.0/24
bgp community-list standard C-CUSTOMER seq 10 permit 64501:100
!
route-map CUST64500-IN permit 20
 match ip address prefix-list FROM-CUST-64500
 set local-preference 200
 set community 64501:100 additive
exit
!
route-map PEER-OUT permit 10
 match community C-CUSTOMER
exit
!
router bgp 64501
 neighbor 10.1.1.2 remote-as 64500
 neighbor 10.1.3.3 remote-as 64502
 address-family ipv4 unicast
  neighbor 10.1.1.2 route-map CUST64500-IN in
  neighbor 10.1.3.3 route-map PEER-OUT out
 exit-address-family

Исторически многие реализации BGP по умолчанию принимали и анонсировали по eBGP всё подряд, и забытый фильтр приводил к утечкам. RFC 8212 потребовал противоположного поведения: без явно настроенной политики eBGP-сессия не должна ни принимать, ни передавать маршруты. В FRR это правило включено по умолчанию в профиле traditional и управляется командой bgp ebgp-requires-policy ¹². Сессия при этом устанавливается, но в выводе show bgp summary в столбцах принятых или отправленных префиксов вместо числа стоит (Policy). Отключать проверку командой no bgp ebgp-requires-policy допустимо лишь в лабораторных стендах; в рабочей сети правильный ответ — написать политику, пусть даже route-map ALL permit 10, явно выражающую намерение.

Изменение политики не применяется к уже полученным маршрутам автоматически: маршрутизатор должен повторно пропустить их через фильтры. Для этого служит «мягкий» сброс clear bgp ipv4 unicast <сосед> soft in (запрос ROUTE-REFRESH) или soft out (повторная отправка своих маршрутов), не разрывающий сессию.

Управление исходящим и входящим трафиком

Управление трафиком в BGP асимметрично. Исходящим трафиком, то есть выбором, через какого соседа отправлять пакеты, автономная система управляет полностью: решение принимают её собственные маршрутизаторы, и основной инструмент — LOCAL_PREF на входящих маршрутах. Например, многодомная AS, у которой канал к провайдеру 64501 шире, назначает его маршрутам LOCAL_PREF 200 и весь исходящий трафик направляет туда, а второй канал оставляет резервным.

Входящим трафиком AS управляет только косвенно — она может лишь повлиять на решения чужих маршрутизаторов, изменяя то, что анонсирует. Инструменты, в порядке возрастания силы:

• удлинение пути (англ. AS path prepending): AS повторяет свой номер в анонсе резервному провайдеру несколько раз (64500 64500 64500), делая путь через него длиннее. Это работает только для тех удалённых сетей, у которых выбор доходит до шага сравнения длины пути. Провайдер, для которого маршрут клиентский и имеет LOCAL_PREF 200, выберет его при любой длине — удлинение пути не может перебить локальный приоритет;
• сообщества действий: если провайдер их поддерживает, клиент меткой просит понизить LOCAL_PREF своего маршрута в сети провайдера, и тот начинает предпочитать путь через пира или другого клиента. Это действует уже на решение провайдера, а не только удалённых сетей;
• более специфичные префиксы: анонс 203.0.113.0/25 и 203.0.113.128/25 через разные каналы вместе с общим /24 гарантированно распределяет трафик, поскольку правило наибольшего совпадения префикса (тема 8) сильнее любого атрибута BGP. Цена — рост глобальной таблицы; многие провайдеры не принимают префиксы IPv4 длиннее /24.

MED также влияет на входящий трафик, но лишь между несколькими стыками с одним и тем же соседом.

iBGP, полносвязность и отражатели маршрутов

Если у автономной системы несколько граничных маршрутизаторов, маршруты, полученные одним из них по eBGP, нужно донести до остальных. Для этого служат сессии iBGP. Внутри AS путь не удлиняется — номер AS дописывается только на eBGP-границе, — поэтому AS_PATH не может защитить от петель внутри AS. RFC 4271 решает это жёстким правилом: маршрут, полученный от iBGP-соседа, не передаётся другим iBGP-соседям ¹. Следствие — каждый маршрутизатор BGP в AS должен иметь сессию с каждым: полносвязная схема (англ. full mesh) из n маршрутизаторов требует n(n − 1)/2 сессий. Для 10 маршрутизаторов это 45 сессий, для 100 — 4950, и при добавлении нового маршрутизатора приходится перенастраивать все остальные.

Отражатели маршрутов (англ. route reflectors) снимают это ограничение ⁹. Отражатель — маршрутизатор, которому разрешено передавать iBGP-маршруты дальше: маршруты от своих клиентов он отражает всем, маршруты от обычных iBGP-соседей — только клиентам. Клиенту достаточно одной-двух сессий с отражателями. Для защиты от петель вводятся атрибуты ORIGINATOR_ID (идентификатор маршрутизатора, впервые внёсшего маршрут в AS; получив маршрут со своим идентификатором, маршрутизатор его отбрасывает) и CLUSTER_LIST (список кластеров, через которые маршрут уже отражался). iBGP обычно устанавливается между адресами петлевых интерфейсов, достижимыми через IGP, чтобы сессия переживала отказ отдельного канала; сам IGP переносит только внутренние адреса, а не сотни тысяч внешних префиксов — их несёт iBGP. Применение BGP внутри центров обработки данных вместо IGP рассматривается в теме 21.

Безопасность междоменной маршрутизации

Перехваты и утечки маршрутов: разбор инцидентов

BGP создавался в среде взаимного доверия и в базовой спецификации не проверяет, вправе ли AS анонсировать префикс и вправе ли она передавать полученный маршрут дальше. Любая AS может объявить чужой префикс, и соседи, не фильтрующие анонсы, распространят его. Различают два класса инцидентов.

Перехват префикса (англ. prefix hijack) — анонс чужого префикса от имени не той AS-источника, по ошибке или умышленно. Если перехватчик анонсирует тот же префикс, часть Интернета, для которой его путь короче, направит трафик ему. Если он анонсирует более специфичный префикс, трафик пойдёт к нему отовсюду, куда дошёл анонс, — правило наибольшего совпадения префикса сильнее любых атрибутов.

Классический пример — инцидент 24 февраля 2008 года, подробно восстановленный по данным коллекторов RIPE NCC ¹¹. YouTube (AS36561) анонсировал префикс 208.65.152.0/22. Получив предписание властей заблокировать YouTube внутри страны, Pakistan Telecom (AS17557) в 18:47 UTC начал анонсировать более специфичный 208.65.153.0/24 — предполагалось, что только внутри своей сети, направляя трафик в никуда. Анонс ушёл к вышестоящему провайдеру PCCW Global (AS3491), который не фильтровал префиксы клиента и распространил его по всему миру; трафик YouTube со всего Интернета пошёл в Пакистан. В 20:07 YouTube начал анонсировать тот же /24, частично вернув трафик, в 20:18 — два ещё более специфичных /25, выигрывающих по правилу наибольшего совпадения везде, куда они дошли. В 21:01 PCCW отозвал маршруты Pakistan Telecom. Инцидент длился более двух часов и показал, что одна ошибка фильтрации у провайдера транзита превращает локальную ошибку в глобальную.

Утечка маршрутов (англ. route leak) — распространение маршрута за пределы, предусмотренные политикой, при правильной AS-источнике ⁸. Типичный случай — нарушение правила долины: многодомный клиент передаёт маршруты одного провайдера другому, и второй провайдер, назначающий клиентским маршрутам высокий LOCAL_PREF, начинает отправлять через клиента трафик к огромной части Интернета. Каналы клиента перегружаются, пакеты теряются. Так произошло 24 июня 2019 года: небольшая компания (AS396531) передала своему провайдеру Verizon (AS701) тысячи маршрутов, полученных от другого провайдера (DQE, AS33154), причём более специфичных — их сгенерировал так называемый оптимизатор BGP внутри DQE. Verizon не фильтровал префиксы клиента, и на несколько часов значительная часть трафика к Cloudflare, Amazon и другим сервисам пошла через малую сеть. Схема утечки показана на рисунке ниже; тот же сценарий воспроизводится в лабораторной работе.

Среди других известных инцидентов — анонс AS7007 в апреле 1997 года, «разрезавший» таблицу на префиксы /24 и на время сделавший небольшую AS точкой притяжения для значительной части Интернета; анонс около 37 тысяч чужих префиксов China Telecom 8 апреля 2010 года; перехват адресов DNS-сервиса Amazon Route 53 в апреле 2018 года с целью кражи криптовалюты. Отдельный случай — отказ Facebook 4 октября 2021 года: ошибочное изменение конфигурации привело к отзыву маршрутов к собственным DNS-серверам компании, и её сервисы стали недоступны примерно на шесть часов. Это не атака, но наглядная демонстрация того, что в BGP исчезнуть из Интернета можно несколькими сообщениями UPDATE.

Реестры маршрутизации IRR и фильтрация

Первая линия защиты — фильтрация анонсов клиентов на стороне провайдера: принимать от клиента только те префиксы, которые ему принадлежат. Источником сведений служат реестры маршрутизации (англ. Internet Routing Registry, IRR) — базы данных, где владельцы адресов публикуют объекты route («префикс P анонсируется AS N») и as-set («AS N передаёт маршруты таких-то клиентских AS»). Крупнейшие реестры ведут RIR (RIPE DB, ARIN IRR) и независимые операторы (RADB). Провайдер автоматически строит списки префиксов по as-set клиента инструментами вроде bgpq4. Ограничение IRR — слабая достоверность: в реестрах, не связанных с RIR, объект может зарегистрировать кто угодно, и они полны устаревших записей.

Вторая мера — ограничение числа префиксов (англ. maximum prefix): если клиент, обычно анонсирующий два префикса, внезапно прислал тысячу, сессия разрывается с NOTIFICATION «Cease». Третья — отбрасывание заведомо недопустимых анонсов: частных и документационных адресов (англ. bogons), префиксов IPv4 длиннее /24, путей с частными номерами AS. Эти практики продвигает инициатива MANRS.

RPKI и проверка источника маршрута

Инфраструктура открытых ключей для ресурсов (англ. Resource Public Key Infrastructure, RPKI) даёт криптографически проверяемую связь между префиксом и правом его анонсировать ². Её иерархия повторяет иерархию распределения адресов: корневые сертификаты (якоря доверия) принадлежат пяти RIR, которые выдают сертификаты на адресные блоки своим членам ¹⁴. Владелец блока подписывает разрешение на анонс (англ. Route Origin Authorization, ROA): «префикс 203.0.113.0/24 с длиной до /24 может анонсировать AS 64500». Параметр maxLength задаёт наибольшую длину допустимых более специфичных префиксов; щедрый maxLength облегчает перехват более специфичным префиксом с подделанным путём, поэтому рекомендуется указывать точно анонсируемые длины.

ROA публикуются в репозиториях RIR. Специальные программы-валидаторы (Routinator, rpki-client, FORT) загружают их, проверяют подписи и передают маршрутизаторам готовый список пар «префикс, длина, AS» по протоколу RPKI-to-Router. Маршрутизатор относит каждый полученный маршрут к одному из трёх состояний проверки источника (англ. Route Origin Validation, ROV) ²:

• Valid — существует ROA, покрывающий префикс, с той же AS-источником (последней в AS_PATH) и допустимой длиной;
• Invalid — префикс покрыт хотя бы одним ROA, но ни один не совпал по AS-источнику или по длине;
• NotFound — ни один ROA префикс не покрывает.

Политика большинства сетей, внедривших ROV: отбрасывать Invalid, остальные принимать. Применительно к инциденту 2008 года: если бы у YouTube был ROA на 208.65.152.0/22 с maxLength 22, анонс 208.65.153.0/24 от AS17557 получил бы статус Invalid и был бы отброшен везде, где работает ROV. В FRR проверка подключается модулем rpki и командой match rpki invalid в карте маршрутов ¹². К середине 2020-х годов ROV внедрили крупнейшие провайдеры транзита и облачные платформы, а ROA покрывают более половины префиксов IPv4 глобальной таблицы.

Важно понимать границы ROV: он проверяет только AS-источник. Перехватчик, который подделает путь, дописав законную AS-источник в конец своего AS_PATH, проверку пройдёт. Защиту всего пути даёт протокол BGPsec (RFC 8205), где каждая AS подписывает путь, но из-за вычислительной стоимости и требования поддержки на всём пути он практически не развёрнут. Промежуточную защиту от подделки пути и утечек дают проекты ASPA (англ. Autonomous System Provider Authorization), находящийся в стадии стандартизации, и роли BGP.

Защита от утечек: роли BGP и атрибут OTC

Утечка маршрутов не нарушает ни один ROA: AS-источник законна. Защититься от неё можно только зная отношения между AS. RFC 9234 вводит роли BGP: каждая сторона сессии объявляет в OPEN возможность «роль» — provider, customer, peer, rs (сервер маршрутов IX) или rs-client, — и роли сторон должны быть согласованы (провайдер с клиентом, пир с пиром) ¹⁰. Кроме того, вводится атрибут «только клиентам» (англ. Only to Customer, OTC): маршрут, полученный от провайдера или пира, помечается номером AS, после чего его нельзя передать провайдеру или пиру. А маршрут с меткой OTC, пришедший от клиента, — признак утечки, и он отбрасывается. Тем самым правило долины, прежде существовавшее лишь в головах администраторов и в их картах маршрутов, становится частью протокола. В FRR роль задаётся командой neighbor <адрес> local-role customer и т. п. ¹².

Anycast и наблюдение за глобальной маршрутизацией

Anycast

BGP позволяет нескольким географически разнесённым узлам анонсировать один и тот же префикс от одной AS. Каждая сеть Интернета выбирает ближайший по критериям BGP вариант, и пакеты к одному и тому же адресу попадают на разные серверы в зависимости от того, откуда они отправлены. Такая схема называется anycast («к любому из»). Так устроены корневые серверы DNS — 13 имён, за которыми стоят более 1900 экземпляров по всему миру, — публичные резолверы 1.1.1.1 и 8.8.8.8, сети доставки контента. Его ограничение следует из природы BGP: «ближайший» означает ближайший по политике и длине пути, а не по километрам или миллисекундам, и при изменении маршрутов TCP-соединение может переключиться на другой экземпляр, не знающий о нём. Поэтому anycast лучше всего подходит для коротких транзакций, например DNS поверх UDP. Подробнее anycast в контексте DNS рассматривается в теме 15.

Коллекторы маршрутов и инструменты наблюдения

Поскольку ни одна сеть не видит Интернет целиком, для наблюдения за глобальной маршрутизацией созданы коллекторы маршрутов (англ. route collectors) — маршрутизаторы, устанавливающие BGP-сессии с сотнями сетей по всему миру и записывающие все полученные UPDATE в архивы формата MRT. Крупнейшие проекты — RIPE RIS (RIPE NCC) и RouteViews (Университет Орегона). Архивы RIS позволили восстановить хронологию инцидента с YouTube по минутам ¹¹. Поверх этих данных построены удобные инструменты:

• RIPEstat — веб-интерфейс и открытый программный интерфейс RIPE NCC: кто анонсирует префикс, история анонсов, видимость, состояние RPKI, сведения о AS;
• bgp.tools — обзор AS, префиксов, соседей вверх и вниз по иерархии, RPKI, а также whois-интерфейс для быстрых запросов из командной строки;
• looking glass («зеркало») — веб-интерфейс к маршрутизатору провайдера, позволяющий выполнить show bgp или traceroute из его сети и увидеть Интернет с чужой стороны;
• PeeringDB — общая база сведений о сетях, точках обмена трафиком и ЦОД: какая сеть на каких IX присутствует, её политика пиринга, контакты.

Запрос к RIPEstat возвращает JSON; например, срез таблиц коллекторов для префикса публичного резолвера Cloudflare показывает, какие пути к нему видят пиры коллектора RRC01 в Лондоне:

curl -s "https://stat.ripe.net/data/looking-glass/data.json?resource=1.1.1.0/24" \
  | python3 -m json.tool | grep -E '"(as_path|peer|origin)"' | head -6

                        "as_path": "15692 13335",
                        "peer": "5.57.80.113",
                        "origin": "IGP",
                        "as_path": "8218 13335",
                        "peer": "5.57.80.210",
                        "origin": "IGP",

Пути из двух номеров — следствие того, что Cloudflare пирингуется на IX в Лондоне практически со всеми участниками. Проверка ROA для того же префикса показывает статус valid:

curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS13335&prefix=1.1.1.0/24" \
  | python3 -c "import json,sys; d=json.load(sys.stdin)['data']; print(d['status'], d['validating_roas'])"

valid [{'origin': '13335', 'prefix': '1.1.1.0/24', 'validity': 'valid', 'max_length': 24}]

По этим данным видно, кто провайдер у вашего провайдера, какие пути ведут к крупным сервисам и подписаны ли префиксы ROA; в лабораторной работе они используются в заключительной части.

Итоги темы

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

BGP-4 — протокол вектора путей, работающий поверх TCP на порту 179. Соседи задаются явно, сессия проходит состояния конечного автомата до Established, после чего маршруты передаются однократно в сообщениях UPDATE и далее лишь изменяются или отзываются; живость сессии поддерживают KEEPALIVE и время удержания. Список автономных систем в AS_PATH одновременно предотвращает петли и служит материалом для политики.

Выбор лучшего маршрута — последовательное сравнение атрибутов, где политика (weight, LOCAL_PREF) стоит раньше технических критериев (длина пути, ORIGIN, MED, тип сессии, стоимость IGP). Понимание этого порядка объясняет, почему удлинение пути не перебивает локальный приоритет провайдера, почему маршрут по iBGP может выиграть у eBGP-маршрута и почему исходящим трафиком AS управляет полностью, а входящим — лишь косвенно. Внутри AS маршруты распространяются по iBGP — полносвязно или через отражатели.

BGP изначально доверяет соседям, и ошибки фильтрации порождают перехваты и утечки, затрагивающие весь Интернет. Защита многоуровневая: фильтры префиксов по реестрам, ограничение числа префиксов, проверка источника по RPKI, роли BGP и атрибут OTC против утечек. Наблюдать результат можно публичными инструментами — RIPEstat, bgp.tools, PeeringDB и looking glass.

Темы 8–10 завершают рассмотрение маршрутизации IPv4. Следующая тема посвящена IPv6, где те же протоколы — OSPFv3 и многопротокольный BGP — переносят префиксы нового семейства адресов, а BGP в центрах обработки данных рассматривается в теме 21.

Литература

1. Rekhter Y., Li T., Hares S. A Border Gateway Protocol 4 (BGP-4). — RFC 4271, IETF, 2006. https://www.rfc-editor.org/rfc/rfc4271
2. Mohapatra P., Scudder J., Ward D., Bush R., Austein R. BGP Prefix Origin Validation. — RFC 6811, IETF, 2013. https://www.rfc-editor.org/rfc/rfc6811
3. Vohra Q., Chen E. BGP Support for Four-Octet Autonomous System (AS) Number Space. — RFC 6793, IETF, 2012. https://www.rfc-editor.org/rfc/rfc6793
4. Chandra R., Traina P., Li T. BGP Communities Attribute. — RFC 1997, IETF, 1996. https://www.rfc-editor.org/rfc/rfc1997
5. Heitz J., Snijders J., Patel K., Bagdonas I., Hilliard N. BGP Large Communities Attribute. — RFC 8092, IETF, 2017. https://www.rfc-editor.org/rfc/rfc8092
6. Bates T., Chandra R., Katz D., Rekhter Y. Multiprotocol Extensions for BGP-4. — RFC 4760, IETF, 2007. https://www.rfc-editor.org/rfc/rfc4760
7. Gao L., Rexford J. Stable Internet Routing Without Global Coordination. — IEEE/ACM Transactions on Networking, 2001, Vol. 9, No. 6, P. 681–692, DOI: 10.1109/90.974523.
8. Sriram K., Montgomery D., McPherson D., Osterweil E., Dickson B. Problem Definition and Classification of BGP Route Leaks. — RFC 7908, IETF, 2016. https://www.rfc-editor.org/rfc/rfc7908
9. Bates T., Chen E., Chandra R. BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP). — RFC 4456, IETF, 2006. https://www.rfc-editor.org/rfc/rfc4456
10. Azimov A., Bogomazov E., Bush R., Patel K., Sriram K. Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages. — RFC 9234, IETF, 2022. https://www.rfc-editor.org/rfc/rfc9234
11. RIPE NCC. YouTube Hijacking: A RIPE NCC RIS case study. — 2008. https://www.ripe.net/about-us/news/youtube-hijacking-a-ripe-ncc-ris-case-study/
12. FRRouting Project. FRR User Manual: BGP. — 2025. https://docs.frrouting.org/en/latest/bgp.html
13. Kurose J. F., Ross K. W. Computer Networking: A Top-Down Approach. 8th ed. — Pearson, 2021.
14. Lepinski M., Kent S. An Infrastructure to Support Secure Internet Routing. — RFC 6480, IETF, 2012. https://www.rfc-editor.org/rfc/rfc6480

Дополнительные материалы

Вопросы для самопроверки

1. Что такое автономная система и почему внешний мир видит её как одно целое, хотя внутри неё могут работать разные протоколы маршрутизации?
2. Чем отличаются отношения «клиент — провайдер» и пиринг с точки зрения денег и с точки зрения экспорта маршрутов?
3. Сформулируйте правило долины. Почему сеть, нарушающая его, теряет деньги или качество связи?
4. Почему BGP называют протоколом вектора путей и как атрибут AS_PATH защищает от счёта до бесконечности, свойственного протоколу RIP?
5. Перечислите состояния конечного автомата BGP. Что означает состояние Active и почему его название обманчиво?
6. Рассчитайте длину сообщения UPDATE, которое анонсирует префиксы 192.0.2.0/24 и 198.51.100.128/25 с атрибутами ORIGIN, AS_PATH из двух четырёхбайтовых номеров и NEXT_HOP.
7. Какие атрибуты являются общеизвестными обязательными и почему без каждого из них маршрут нельзя использовать?
8. Назовите по порядку шаги выбора лучшего маршрута в FRR до шага «eBGP лучше iBGP». Почему LOCAL_PREF стоит раньше длины пути?
9. Почему iBGP-маршрутизатор не передаёт маршрут, полученный от другого iBGP-соседа, и как отражатель маршрутов обходит это правило без петель?
10. Чем перехват префикса отличается от утечки маршрутов? Приведите исторический пример каждого.
11. Какие три состояния определяет проверка источника по RPKI и от какой атаки ROV не защищает?
12. Как атрибут OTC и роли BGP предотвращают утечку маршрутов через многодомного клиента?
13. Почему anycast хорошо подходит для DNS и хуже — для длительных TCP-соединений?
14. Какие из инструментов RIPEstat, bgp.tools, PeeringDB и looking glass позволят ответить на вопрос «через какие сети пойдёт трафик из сети провайдера X к префиксу Y»?

Глоссарий темы

Шпаргалка по инструментам

Управление стендом:

docker compose up -d                        # поднять топологию
docker compose exec cust vtysh              # консоль FRR
docker compose exec cust vtysh -c "show bgp summary"
docker compose logs --tail 50 ispb          # журнал FRR
docker compose down                         # удалить топологию

Просмотр состояния BGP в vtysh:

show bgp summary                                    ! соседи и счётчики префиксов
show bgp neighbors 10.1.1.3                         ! возможности, таймеры, причина последнего разрыва
show bgp ipv4 unicast                               ! таблица BGP
show bgp ipv4 unicast 192.0.2.0/24                  ! все пути к префиксу, причина выбора
show bgp ipv4 unicast neighbors 10.1.1.3 routes            ! принято от соседа
show bgp ipv4 unicast neighbors 10.1.1.3 advertised-routes ! отправлено соседу
show bgp ipv4 unicast regexp _64501_                ! пути, проходящие через AS 64501
show bgp ipv4 unicast community 64501:100           ! маршруты с меткой
show ip route bgp                                   ! маршруты BGP в RIB
show route-map                                      ! политики и счётчики срабатываний

Настройка (в режиме configure terminal):

router bgp 64500
 bgp router-id 203.0.113.1
 neighbor 10.1.1.3 remote-as 64501
 neighbor 10.1.1.3 description ISP-A
 neighbor 10.1.1.3 timers 10 30                 ! keepalive и hold time, с
 neighbor 10.1.2.3 local-role customer          ! роль RFC 9234
 address-family ipv4 unicast
  network 203.0.113.0/24                        ! анонс (префикс должен быть в RIB)
  neighbor 10.1.1.3 route-map ISPA-IN in
  neighbor 10.1.1.3 route-map UPSTREAM-OUT out
  neighbor 10.1.1.3 maximum-prefix 100          ! защита от лавины префиксов
 exit-address-family
!
ip prefix-list OWN seq 10 permit 203.0.113.0/24
ip prefix-list CUST seq 10 permit 203.0.113.0/24 le 25
bgp community-list standard C-CUST seq 10 permit 64501:100
bgp as-path access-list AP-CUST seq 10 permit ^64500(_64500)*$
!
route-map UPSTREAM-OUT permit 10
 match ip address prefix-list OWN
 set as-path prepend 64500 64500
 set community 64501:70 additive
exit

Применение изменённой политики без разрыва сессии: clear bgp ipv4 unicast 10.1.1.3 soft in (запрос ROUTE-REFRESH) и clear bgp ipv4 unicast 10.1.1.3 soft out.

Наблюдение за Интернетом:

Полезные фильтры Wireshark: bgp, bgp.type == 2, bgp.update.path_attribute.type_code == 8 (UPDATE с сообществами), bgp.open.cap (возможности в OPEN), bgp.notify.major_error (коды ошибок).

Что почитать и посмотреть

• RFC 4271. A Border Gateway Protocol 4 (BGP-4) — первоисточник: формат сообщений (раздел 4), атрибуты (раздел 5), процесс выбора (раздел 9) и конечный автомат (раздел 8). Раздел 9 полезно прочитать целиком после лабораторной работы.
• FRR User Manual: BGP — описание всех команд FRR, порядок выбора маршрута, пример полной политики провайдера с сообществами действий, роли RFC 9234 и RPKI.
• Kurose J. F., Ross K. W. Computer Networking: A Top-Down Approach, раздел 5.4 «Routing Among the ISPs: BGP» — короткое и ясное введение с экономической мотивацией; хорошо читать перед темой.
• Gao L., Rexford J. Stable Internet Routing Without Global Coordination — статья, объясняющая, почему политика «клиент лучше пира, пир лучше провайдера» гарантирует сходимость BGP.
• RIPE NCC. YouTube Hijacking: A RIPE NCC RIS case study — поминутная реконструкция инцидента 2008 года по данным коллекторов; образец расследования по публичным данным.
• Cloudflare Blog. How Verizon and a BGP Optimizer Knocked Large Parts of the Internet Offline Today — разбор утечки 24 июня 2019 года с объяснением, какие фильтры её бы остановили.
• Cloudflare Blog. Understanding How Facebook Disappeared from the Internet — отказ 4 октября 2021 года глазами внешнего наблюдателя: всплеск UPDATE с отзывами и последствия для DNS.
• Is BGP safe yet? — проект Cloudflare, проверяющий, отбрасывает ли сеть пользователя маршруты со статусом RPKI Invalid, и список провайдеров с ROV.
• RIPEstat Data API — документация программного интерфейса RIPEstat; позволяет писать собственные сценарии анализа маршрутизации на Python.
• MANRS для сетевых операторов — раздел инициативы MANRS для операторов с практическими руководствами по фильтрации, защите от подделки адресов, IRR и RPKI.
• CIDR Report — ежедневная статистика глобальной таблицы: число префиксов и AS, кандидаты на агрегацию; Geoff Huston ежегодно публикует на блоге APNIC обзор «BGP in 20XX» с анализом роста.
• Видео: доклады NANOG и RIPE Meeting по запросам «BGP 101», «RPKI deployment», «route leaks» на каналах NANOG и RIPE NCC на YouTube — практики крупнейших операторов из первых рук.

Углубление (по желанию)

Почему BGP медленно сходится

Протокол вектора путей не страдает от счёта до бесконечности, но после отзыва маршрута может долго перебирать всё более длинные альтернативные пути: каждый маршрутизатор, потеряв лучший путь, переключается на следующий из таблицы, который тоже скоро окажется недействительным, и сообщает об этом соседям. Измерения К. Лабовица и соавторов (SIGCOMM 2000) показали, что после отзыва префикса Интернет приходит к согласию в среднем за минуты, а в худшем случае — за время, пропорциональное факториалу числа путей. Сдерживает «перебор» таймер минимального интервала между анонсами (англ. MinRouteAdvertisementInterval, MRAI): RFC 4271 рекомендует 30 с для eBGP, в FRR значение по умолчанию — 0 с: изменения передаются быстрее, но сообщений больше. Связанный механизм — подавление колебаний (англ. route flap damping, RFC 2439): маршрут, часто появляющийся и исчезающий, временно не используется. В своё время он настолько замедлял сходимость, что его рекомендовали отключать, а затем вернули с более мягкими параметрами (RFC 7196).

Роутинг-диспуты и «отрыв» Интернета

Поскольку пиринг между сетями первого уровня — коммерческий договор, его разрыв может разделить Интернет: клиенты одной сети перестают видеть клиентов другой, если обе не покупают транзит у кого-то третьего. Такие эпизоды случались, например, в 2008 году между Cogent и Sprint. Это напоминание о том, что глобальная связность — не свойство протокола, а результат договорённостей.

ASPA: проверка пути на основе отношений

Проект ASPA (англ. Autonomous System Provider Authorization) расширяет RPKI: владелец AS подписывает список своих провайдеров. Маршрутизатор, получив AS_PATH, может проверить, что каждый шаг «вверх» сделан к объявленному провайдеру, и так обнаружить и утечки, и подделку пути. В отличие от BGPsec, ASPA не требует подписей в каждом UPDATE и может внедряться постепенно. На момент написания стандарт находится в стадии проекта IETF, а поддержка появилась в валидаторах (rpki-client, Routinator) и некоторых реализациях BGP.

Лабораторная работа 10. BGP между автономными системами

• Раздел курса: тема 10 «Междоменная маршрутизация и BGP»

Введение

В лабораторной работе 9 маршрутизаторы одной организации договаривались о кратчайших путях по протоколу OSPF. В настоящей работе каждый маршрутизатор представляет отдельную автономную систему со своими интересами, и путь пакета определяется уже не стоимостью каналов, а договорами между сетями, записанными в политиках BGP. Учебный стенд моделирует фрагмент Интернета: компания «Северный узел» (AS 64500) подключена к двум провайдерам, провайдеры связаны пирингом, у одного из них есть ещё клиент — контент-сеть.

Работа проходит путь, описанный в теме 10: от установления eBGP-сессий и чтения таблицы BGP через захват сообщений OPEN и UPDATE к управлению исходящим и входящим трафиком и к главной практической опасности BGP — утечке маршрутов, которую предстоит устроить, наблюдать и устранить. Заключительная часть переносит те же понятия в реальный Интернет: находится автономная система своего провайдера, пути к крупным сервисам и проверяются подписи ROA.

Части 1–6 составляют базовую часть работы. Часть 7 (роли BGP и ограничение числа префиксов) — продвинутая, выполняется по желанию.

Цель работы

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

После выполнения работы можно будет:

• установить eBGP-сессию в FRRouting и определить по выводу show bgp summary её состояние и причину отсутствия маршрутов;
• прочитать таблицу BGP, объяснить по атрибутам выбор лучшего маршрута и предсказать его до эксперимента;
• выделить в захвате трафика сообщения OPEN, UPDATE, KEEPALIVE и разобрать их поля: возможности, время удержания, атрибуты пути, NLRI;
• управлять исходящим трафиком через LOCAL_PREF и объяснить, почему удлинение пути не всегда влияет на входящий трафик;
• воспроизвести утечку маршрутов, обнаружить её по таблицам и traceroute и устранить фильтрацией префиксов;
• определить по публичным инструментам (RIPEstat, bgp.tools, PeeringDB) AS провайдера, пути к сервисам и состояние RPKI для префикса.

Теоретический минимум

Отношения между AS и правило долины — тема 10, раздел «Интернет как сеть автономных систем»; сессия и сообщения — раздел «Протокол BGP-4: сессии и сообщения»; атрибуты и выбор маршрута — раздел «Атрибуты пути и выбор лучшего маршрута»; политики и управление трафиком — раздел «Политики маршрутизации, eBGP и iBGP»; утечки, IRR, RPKI и роли — раздел «Безопасность междоменной маршрутизации».

Учебная топология показана на рисунке ниже.

Политики провайдеров заданы в конфигурациях заранее и соответствуют модели Гао — Рексфорд: маршрутам от клиентов назначается LOCAL_PREF 200 и метка <AS>:100, от пира — 150 и метка <AS>:200; клиентам отдаются все маршруты, пиру — только собственные и клиентские (по метке). Провайдеры поддерживают сообщество действия <AS>:70: маршрут клиента с такой меткой получает LOCAL_PREF 70. Провайдер A принимает от клиентов только их зарегистрированные префиксы; провайдер B этого фильтра не имеет — это намеренная уязвимость стенда.

Команды FRR, используемые в работе (вводятся в vtysh; режим настройки — configure terminal, выход — end):

Полезные фильтры Wireshark: bgp — все сообщения BGP; bgp.type == 1 — OPEN; bgp.type == 2 — UPDATE; bgp.type == 4 — KEEPALIVE; bgp.type == 3 — NOTIFICATION; tcp.port == 179 && tcp.flags.syn == 1 — установление соединения.

Перечень оснащения

• Ubuntu 24.04 (физическая или виртуальная машина, WSL2) с Docker Engine и плагином compose: sudo apt install docker.io docker-compose-v2, пользователь добавлен в группу docker (sudo usermod -aG docker $USER, затем повторный вход). Альтернатива — Docker Desktop.
• Wireshark и tcpdump (установлены в ЛР 1), Python 3, curl, whois (sudo apt install whois).
• Архив окружения lr-env: compose.yaml, конфигурации FRR четырёх маршрутизаторов, сценарий tools/bestpath.py, README.md со схемой адресации.
• Образ quay.io/frrouting/frr:10.2.1 (около 100 МБ) и, для захвата и traceroute внутри контейнеров, образ nicolaka/netshoot; оба скачиваются при первом запуске, требуется доступ в Интернет.
• Права sudo для захвата трафика на мостах хоста.

Порядок выполнения работы

Распакуйте архив и перейдите в каталог lr-env. Топология поднимается командой docker compose up -d и полностью удаляется командой docker compose down; изменения конфигурации, внесённые в vtysh, при этом теряются, что удобно для возврата в исходное состояние. Консоль маршрутизатора открывается командой docker compose exec <имя> vtysh, одиночная команда — docker compose exec <имя> vtysh -c "<команда>".

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

Часть 1. Запуск топологии и eBGP-сессии

Задание

1. Поднимите топологию и убедитесь, что запущены четыре контейнера:

   docker compose up -d
   docker compose ps
   

2. Откройте frr/cust/frr.conf и frr/ispa/frr.conf. Для каждого соседа cust и ispa выпишите в журнал: адрес, номер AS, входную и выходную карту маршрутов, словами — что делает каждая карта.

3. Проверьте состояние сессий на cust:

   docker compose exec cust vtysh -c "show bgp summary"
   

   Ожидается вывод вида:

   IPv4 Unicast Summary:
   BGP router identifier 203.0.113.1, local AS number 64500 VRF default vrf-id 0
   ...
   Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
   10.1.1.3        4      64501        10         9        8    0    0 00:02:41            3        1 ISP-A
   10.1.2.3        4      64502         9         9        8    0    0 00:02:40            3        1 ISP-B
   

   Объясните, почему у каждого соседа отправлен ровно один префикс, и перечислите, какие префиксы, по вашему мнению, приняты от каждого провайдера.

4. Найдите ошибку. Откройте консоль cust и удалите выходную политику для провайдера A:

   configure terminal
   router bgp 64500
    address-family ipv4 unicast
     no neighbor 10.1.1.3 route-map UPSTREAM-OUT out
   end
   show bgp summary
   

   Предскажите, исчезнет ли сессия и что станет с анонсом 203.0.113.0/24 у ispa. Проверьте на ispa командой show bgp ipv4 unicast 203.0.113.0/24. Объясните наблюдение, опираясь на правило bgp ebgp-requires-policy (RFC 8212). Верните политику командой neighbor 10.1.1.3 route-map UPSTREAM-OUT out в том же режиме.

5. Сломайте сессию иначе: на content измените номер AS соседа на неверный (neighbor 10.1.4.2 remote-as 64599). Через 10–20 секунд посмотрите show bgp summary на content и журнал docker compose logs --tail 20 content. Найдите сообщение о NOTIFICATION и расшифруйте его код и подкод. Восстановите правильный номер.

Что должно получиться

Таблица соседей с политиками; вывод show bgp summary в исходном состоянии; вывод с отметкой (Policy) после удаления политики и объяснение; фрагмент журнала с NOTIFICATION и расшифровка кода; ответ: в каком состоянии конечного автомата находилась сессия при неверном номере AS.

Часть 2. Таблица BGP, AS_PATH и выбор маршрута

Задание

1. Предсказать. Не выполняя команд, заполните таблицу: для маршрутизаторов cust, ispb и content и каждого из четырёх префиксов (192.0.2.0/24, 198.51.100.0/25, 198.51.100.128/25, 203.0.113.0/24) укажите все пути, которые придут на маршрутизатор, их AS_PATH и LOCAL_PREF, и отметьте лучший. Учтите правила экспорта провайдеров.

2. Проверьте предсказание:

   docker compose exec cust vtysh -c "show bgp ipv4 unicast"
   docker compose exec ispb vtysh -c "show bgp ipv4 unicast"
   docker compose exec content vtysh -c "show bgp ipv4 unicast"
   

   Фрагмент ожидаемого вывода на cust:

        Network          Next Hop            Metric LocPrf Weight Path
    *>  192.0.2.0/24     10.1.1.3                               0 64501 64503 i
    *                    10.1.2.3                               0 64502 64501 64503 i
    ...
    *>  203.0.113.0/24   0.0.0.0                  0         32768 i
   

   Объясните каждое расхождение с предсказанием. Почему у content к каждому префиксу ровно один путь? Почему на ispb у 192.0.2.0/24 указан LOCAL_PREF 150?

3. Для префикса 198.51.100.128/25 на cust выполните show bgp ipv4 unicast 198.51.100.128/25 и найдите причину выбора в скобках после best. Опишите оба кандидата в файле JSON по образцу tools/example-cust.json и прогоните через python3 tools/bestpath.py <файл>. Совпал ли шаг, на котором принято решение?

4. Проверьте, что маршруты BGP установлены в ядро: docker compose exec cust ip route. Найдите строки proto bgp и объясните поле metric 20 (административное расстояние eBGP в FRR, тема 8).

5. Проверьте связность между AS. Сначала выполните docker compose exec cust ping -c 3 192.0.2.1, затем docker compose exec cust ping -c 3 -I 203.0.113.1 192.0.2.1. Объясните, почему первая команда не получает ответов, а вторая получает (подсказка: какой адрес источника выбран в первом случае и есть ли до него маршрут у content).

6. Выполните трассировку из пространства имён cust с адреса 203.0.113.1:

   docker run --rm --network container:lr10-cust nicolaka/netshoot \
       traceroute -n -s 203.0.113.1 192.0.2.1
   

   Сопоставьте адреса промежуточных узлов с топологией.

Что должно получиться

Таблица предсказаний и таблица наблюдений; объяснение расхождений; вывод подробностей для 198.51.100.128/25 и результат bestpath.py; ответ на вопрос о ping без указания источника; трассировка с подписями узлов.

Часть 3. Сообщения BGP в захвате трафика

Задание

1. Запустите захват на стыке cust — ispa одним из способов из README.md, например на хосте:

   sudo tcpdump -i br-cust-ispa -w bgp-cust-ispa.pcap 'tcp port 179'
   

2. Во второй консоли разорвите и заново установите сессию: docker compose exec cust vtysh -c "clear bgp 10.1.1.3". Подождите не менее трёх минут, чтобы в захват попали периодические KEEPALIVE, затем остановите tcpdump.

3. Откройте файл в Wireshark с фильтром bgp. Найдите трёхэтапное рукопожатие TCP и определите, какая сторона инициировала соединение (порт 179 у получателя). Найдите оба сообщения OPEN и заполните таблицу: версия, My AS, Hold Time, BGP Identifier, список возможностей (код и название) для каждой стороны. Какое время удержания будет действовать в сессии и почему?

4. Сравните объявленные возможности с выводом show bgp neighbors 10.1.1.3 на cust (разделы Neighbor capabilities). Какие из них согласованы обеими сторонами?

5. Найдите UPDATE от cust к ispa с префиксом 203.0.113.0/24. Разберите его по полям, как в теории темы 10: длины, атрибуты (флаги, тип, длина, значение), NLRI. Выпишите шестнадцатеричные байты атрибута AS_PATH и объясните каждый байт.

6. Найдите UPDATE от ispa к cust с префиксом 192.0.2.0/24. Каков AS_PATH, NEXT_HOP и список сообществ? Совпадает ли список сообществ с политикой ispa (какие метки были добавлены и где)?

7. Отзыв маршрута. Не останавливая нового захвата, на cust временно уберите анонс (no network 203.0.113.0/24 в address-family ipv4 unicast), затем верните его. Найдите в захвате UPDATE с непустым полем Withdrawn Routes и определите его длину в байтах; сравните с расчётом из теории.

8. Измерьте интервал между KEEPALIVE одной стороны (столбец Time или фильтр bgp.type == 4 && ip.src == 10.1.1.2). Совпадает ли он со значением по умолчанию FRR?

Что должно получиться

Файл захвата (приложить к журналу); таблица параметров OPEN обеих сторон; разбор UPDATE с анонсом и с отзывом по полям; ответ о времени удержания и интервале KEEPALIVE.

Часть 4. Управление исходящим и входящим трафиком

Задание

Исходящий трафик. Руководство «Северного узла» решило, что основным провайдером является A, а канал к B — резервный.

1. Предсказать: как изменится путь от cust к префиксу провайдера B (198.51.100.128/25), если всем маршрутам от ispa назначить LOCAL_PREF 200? Изменится ли путь от ispb к cust?

2. Реализуйте политику на cust:

   configure terminal
   route-map ISPA-IN permit 10
    set local-preference 200
   exit
   end
   clear bgp ipv4 unicast 10.1.1.3 soft in
   show bgp ipv4 unicast 198.51.100.128/25
   

   Проверьте путь трассировкой с 203.0.113.1 до 198.51.100.129 и обратный путь трассировкой из ispb с 198.51.100.129 до 203.0.113.1. Объясните асимметрию.

Входящий трафик. Теперь требуется, чтобы трафик из контент-сети к «Северному узлу» входил через провайдера B.

3. Предсказать: если cust удлинит путь в анонсе для ispa тремя повторами своего номера, по какому пути пойдёт трафик от content к 203.0.113.1? Запишите рассуждение по шагам выбора маршрута на ispa.

4. Проверьте:

   configure terminal
   route-map UPSTREAM-OUT-A permit 10
    match ip address prefix-list OWN
    set as-path prepend 64500 64500 64500
   exit
   router bgp 64500
    address-family ipv4 unicast
     neighbor 10.1.1.3 route-map UPSTREAM-OUT-A out
   end
   clear bgp ipv4 unicast 10.1.1.3 soft out
   

   На ispa выполните show bgp ipv4 unicast 203.0.113.0/24 и трассировку из content с 192.0.2.1 до 203.0.113.1. Объясните, почему удлинение пути не изменило выбор ispa и какой шаг выбора принял решение.

5. Воспользуйтесь сообществом действия провайдера A. Добавьте в карту UPSTREAM-OUT-A команду set community 64501:70 и повторите clear bgp ipv4 unicast 10.1.1.3 soft out. Повторите наблюдения пункта 4. Через какие маршрутизаторы теперь идёт трафик от content? Откуда ispa знает альтернативный путь к 203.0.113.0/24 и какой у него LOCAL_PREF?

6. Ответьте письменно: при каких условиях удлинение пути всё же изменило бы входящий трафик? Приведите пример удалённой AS, для которой решение принималось бы на шаге сравнения длины пути.

Что должно получиться

Предсказания и наблюдения для пунктов 1–5 (выводы show bgp для префикса и трассировки до и после изменений); объяснение асимметрии; разбор по шагам выбора маршрута на ispa для пунктов 4 и 5; ответ на вопрос пункта 6.

Часть 5. Утечка маршрутов и её предотвращение

Перед частью верните стенд в исходное состояние: docker compose down && docker compose up -d.

Задание

1. Зафиксируйте исходное состояние на ispb: show bgp ipv4 unicast 192.0.2.0/24, show bgp ipv4 unicast 198.51.100.0/25 и трассировку из ispb с 198.51.100.129 до 192.0.2.1.

2. Устройте утечку. Администратор «Северного узла» по ошибке заменил выходную политику к провайдерам на «пропускать всё»:

   configure terminal
   route-map LEAK permit 10
   exit
   router bgp 64500
    address-family ipv4 unicast
     neighbor 10.1.1.3 route-map LEAK out
     neighbor 10.1.2.3 route-map LEAK out
   end
   clear bgp ipv4 unicast * soft out
   

3. Предсказать, а затем проверить: какие префиксы cust теперь отправляет каждому провайдеру (show bgp ipv4 unicast neighbors 10.1.2.3 advertised-routes)? Какие из них примет ispa, а какие ispb? Какой путь выберет ispb к 192.0.2.0/24 и к 198.51.100.0/25 и на каком шаге выбора? Повторите трассировку из пункта 1 и опишите путь трафика. Объясните, почему этот путь нарушает правило долины и чем он опасен для «Северного узла» при реальных объёмах трафика.

4. Найдите, почему ispa не пострадал: выполните на ispa show route-map CUST64500-IN и show ip prefix-list FROM-CUST-64500 и найдите счётчики срабатываний.

5. Устраните уязвимость на стороне провайдера B, не трогая cust: создайте список префиксов клиента и добавьте условие match ip address prefix-list в обе записи карты CUST64500-IN; примените изменения мягким сбросом. Проверьте, что утечка больше не влияет на выбор ispb, а собственный префикс клиента принимается по-прежнему.

6. Устраните первопричину на стороне клиента: верните UPSTREAM-OUT обоим соседям cust.

7. Ответьте письменно: какое из двух исправлений (п. 5 или п. 6) защищает Интернет надёжнее и почему провайдер обязан фильтровать клиентов, даже если клиенты настроены правильно? Сравните ситуацию с инцидентом 24 июня 2019 года, описанным в теме 10.

Что должно получиться

Выводы show bgp и трассировки до утечки, во время и после исправления; таблица «префикс — отправлен cust — принят ispa — принят ispb»; изменённая конфигурация ispb с пояснением; ответы на вопросы пунктов 3 и 7.

Часть 6. Глобальная маршрутизация в реальном Интернете

Задание

1. Определите свой внешний адрес и автономную систему провайдера:

   curl -s https://stat.ripe.net/data/whats-my-ip/data.json | python3 -m json.tool
   whois -h bgp.tools " -v <ваш адрес>"
   

   Если вы работаете через NAT университета или мобильного оператора, это будет адрес и AS этой сети. Запишите номер AS, анонсируемый префикс и название.

2. На странице https://bgp.tools/as/<номер> найдите вышестоящих провайдеров (upstreams) вашей AS и их провайдеров. Нарисуйте фрагмент иерархии до сети, не имеющей провайдеров. Проверьте в PeeringDB (https://www.peeringdb.com), на каких точках обмена трафиком присутствует ваша AS или её провайдер.

3. Для двух крупных сервисов (например, www.wikipedia.org и www.youtube.com) определите адрес (dig +short), префикс и AS-источник через RIPEstat:

   curl -s "https://stat.ripe.net/data/network-info/data.json?resource=<адрес>" | python3 -m json.tool
   

   Получите пути к найденным префиксам, которые видят коллекторы RIS (looking-glass/data.json?resource=<префикс>), и выберите три различных as_path. Объясните, почему пути различаются по длине и почему многие из них состоят из двух номеров.

4. Проверьте состояние RPKI для префикса вашего провайдера и для префиксов сервисов:

   curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS<номер>&prefix=<префикс>" \
     | python3 -m json.tool
   

   Укажите статус (valid, invalid, unknown), найденные ROA и их max_length. Подставьте в запрос чужой номер AS и объясните, почему статус стал invalid.

5. Выполните traceroute -n (или mtr -n -c 10) до одного из сервисов и сопоставьте адреса узлов с AS через whois-запросы к bgp.tools. Отметьте, на каком узле трафик переходит из AS провайдера в другую AS.

Что должно получиться

Таблица «ресурс — адрес — префикс — AS-источник — статус RPKI»; схема иерархии провайдеров; три пути из коллекторов RIS с пояснением; трассировка с разметкой AS; объяснение статуса invalid при подстановке чужой AS.

Часть 7. Роли BGP и ограничение числа префиксов (продвинутая)

Задание

1. Верните стенд в исходное состояние и снова устройте утечку из части 5 (п. 2). Убедитесь, что ispb выбирает путь через cust.

2. Включите на обоих концах стыка cust — ispb роли RFC 9234: на cust — neighbor 10.1.2.3 local-role customer, на ispb — neighbor 10.1.2.2 local-role provider (в режиме router bgp). Сделайте то же для стыка cust — ispa и для пиринга ispa — ispb (роль peer с обеих сторон). Сбросьте сессии командой clear bgp *.

3. Посмотрите show bgp neighbors 10.1.2.3 на cust: найдите согласованную роль. Выполните show bgp ipv4 unicast 192.0.2.0/24 на cust и найдите в подробном выводе пути от ispa отметку атрибута OTC (Only to Customer). Чему равно его значение и кто его установил?

4. Проверьте, принимает ли теперь ispb утёкшие маршруты, хотя фильтра префиксов у него по-прежнему нет. Объясните механизм по правилам RFC 9234: на каком маршрутизаторе и по какому признаку отброшен маршрут.

5. Проверьте несогласованные роли: задайте на ispb для cust роль peer (без strict-mode), сбросьте сессию и опишите, что с ней произойдёт и какое сообщение NOTIFICATION будет отправлено (по RFC 9234 несовместимые роли всегда приводят к разрыву: ошибка OPEN, подкод 11 Role Mismatch). Затем верните на ispb роль provider с ключом strict-mode, а на cust удалите роль (no neighbor 10.1.2.3 local-role customer). Что теперь происходит с сессией и чем отличается поведение без strict-mode? Ключ strict-mode важен только тогда, когда сосед роль не объявляет.

6. Ограничение числа префиксов: на ispb для соседа cust задайте neighbor 10.1.2.2 maximum-prefix 2 в address-family ipv4 unicast, уберите роли с обеих сторон стыка (утечка из п. 1 остаётся настроенной) и сбросьте сессию. Что произошло с сессией? Найдите в журнале причину и объясните, как сессию восстановить (clear bgp 10.1.2.2) и почему автоматическое восстановление без исправления причины бессмысленно.

Что должно получиться

Выводы с согласованными ролями и атрибутом OTC; объяснение отбрасывания утёкшего маршрута; описание поведения при несовпадении ролей; фрагмент журнала с превышением числа префиксов и ответ на вопрос п. 6.

Журнал работы

Ведите для себя журнал: для каждой части записывайте предсказание, сделанное до эксперимента, команду, фактический вывод и объяснение расхождений. Таблицы, графики и файлы захватов, перечисленные в разделах «Что должно получиться», удобно хранить там же. В конце полезно сформулировать несколько предложений собственных выводов по работе.

Контрольные вопросы

1. Почему BGP не обнаруживает соседей автоматически, как OSPF, и что даёт использование TCP вместо собственного механизма надёжной доставки?
2. Сессия долго находится в состоянии Active. Что это означает и какие три причины следует проверить в первую очередь?
3. Чем отличается отсутствие маршрутов из-за (Policy) от отсутствия маршрутов из-за отбрасывания картой маршрутов? Как различить эти случаи по выводу команд?
4. Почему атрибут LOCAL_PREF не передаётся по eBGP, а MED не передаётся дальше соседней AS? Что сломалось бы, если бы передавались?
5. Провайдер получил от клиента путь 64500 64500 64500 64500, а от пира — путь 64502 64500 к тому же префиксу. Какой маршрут он выберет при политике Гао — Рексфорд и почему?
6. Почему в части 2 команда ping без указания источника не получала ответов? Как этот эффект проявляется в реальных сетях провайдеров?
7. Сформулируйте правило долины и покажите на учебной топологии один допустимый и один недопустимый путь.
8. Какие меры на стороне провайдера B предотвратили бы утечку из части 5 и какие из них работают без участия клиента?
9. Префикс 192.0.2.0/24 подписан ROA с AS 64503 и maxLength 24. Какой статус ROV получат анонсы: 192.0.2.0/24 от AS 64503; 192.0.2.0/25 от AS 64503; 192.0.2.0/24 от AS 64666 с путём 64666 64503? Какой из них ROV не обнаружит как атаку?
10. Почему удлинение пути — ненадёжный способ управлять входящим трафиком, а анонс более специфичных префиксов — надёжный? Какова цена второго способа для Интернета?
11. Чем роли BGP (RFC 9234) защищают от утечек лучше, чем фильтры префиксов, и в чём их ограничение?