Кратко

  • Маршрутный сервер точки обмена — посредник управляющей плоскости, а не транзитный маршрутизатор. Поэтому RFC 7947 рекомендует ему не добавлять свой AS в AS_PATH и требует сохранять NEXT_HOP исходного участника.
  • Клиент получает UPDATE, где сосед сессии, крайний левый AS и фактический следующий маршрутизатор различаются. Исключение из проверки первого AS допустимо только для проверенных серверных соседей и не отменяет локальные фильтры.
  • Результат подтверждает цепочка: исходный анонс, входная проверка, выбор для клиента, Adj-RIB-Out, приём, FIB, разрешение соседа и пакеты. Established и одинаковое число префиксов не доказывают эквивалентность.

Разрешённая альтернатива, которой не показали

Рассмотрим синтетический стенд с адресами и ASN, предназначенными для документации. Участники A и C объявляют два пути к одному тестовому префиксу двум маршрутным серверам. Клиент B разрешает оба, кроме пути A на одном направлении распространения.

Первый сервер выбирает A в общей RIB, затем применяет правило B и удаляет уже выбранный путь. C остаётся в исходных данных, но B его не получает. Второй сервер вычисляет представление отдельно для B и после фильтра выбирает C.

Обе BGP-сессии имеют состояние Established. Общее число префиксов совпадает. Но для конкретного NLRI один сервис создаёт отсутствие достижимости, другой — допустимый маршрут.

Полученный от второго сервера UPDATE тоже выглядит необычно для стандартного eBGP: AS_PATH начинается с C, NEXT_HOP указывает на интерфейс C в peering LAN, а ASN сервера отсутствует. После точечного исключения из проверки первого AS B устанавливает прямой следующий переход. Пакеты идут к C через общую коммутационную среду и не проходят через сервер.

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

Посредничество в достижимости не равно транзиту

В точке обмена автономные системы соединены общей инфраструктурой второго уровня. Полная сеть двусторонних BGP-сессий становится всё сложнее при росте числа участников. Маршрутный сервер сокращает эту нагрузку: клиент обменивается маршрутами со многими сетями через небольшое число соседств.

Это не пассивный коллектор. Коллектор принимает feeds для наблюдения; сервер IXP участвует в рабочем распространении маршрутов, проверяет вход, выбирает кандидатов и формирует разные результаты для клиентов.

Но это и не транзитный маршрутизатор. Он говорит по BGP и хранит RIB, однако не должен пересылать пользовательские пакеты. Трафик проходит непосредственно между участниками по фабрике обмена.

Поэтому AS_PATH — не перечень всех программ, обработавших UPDATE. Атрибут отражает AS-путь для политики, выбора и обнаружения петель. Добавление ASN посредника только из-за сессии создало бы вымышленный транзитный переход и могло изменить решение получателя.

Сервер обладает властью над распространением, но не получает права переписывать историю передачи так, будто сам переносит трафик.

Прозрачность требует доказуемого невмешательства в атрибуты

Обычная процедура eBGP в RFC 4271 предполагает добавление собственного AS при внешнем анонсе. RFC 7947 рекомендует маршрутному серверу по умолчанию этого не делать и не менять AS_PATH без явной настройки. Дополнительный AS влияет на длину, фильтры и предпочтения.

NEXT_HOP должен передаваться без изменения. Если маршрут объявил C, B направляет пакет непосредственно на адрес C в сети обмена. Переписывание на адрес сервера привлекло бы трафик к системе, которая не предназначена для пересылки.

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

Прозрачность не делает сервер бездействующим. Он проверяет префикс и origin, интерпретирует Communities распространения, выбирает путь и строит клиентское представление. Его влияние может отсутствовать в AS_PATH и всё же определять доступность.

Нужны два связанных журнала. Атрибуты описывают маршрут для управления и передачи. Adj-RIB, результаты проверок и версия политики описывают действие посредника. Один журнал не заменяет другой.

Исключение первого AS должно быть узким

Многие реализации проверяют, совпадает ли крайний левый AS с ASN внешнего соседа. Для транзита и двустороннего peering это полезный сигнал несоответствия. Прозрачный сервер намеренно нарушает это равенство: UPDATE приходит от посредника, но путь начинается с исходного участника.

RFC 7947 требует возможности отключить проверку и рекомендует делать это для конкретного peer. Безопасность определяется границей. ASN, адреса и семейства сервера берутся из авторитетной информации IXP; исключение прикрепляется только к этим объектам соседства.

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

Отключение одной проверки не означает доверия любой информации. B продолжает искать собственный ASN в пути, применять правила префиксов и происхождения, лимиты и свою политику IRR/RPKI. Сервер предлагает кандидатов; решение о Loc-RIB и FIB остаётся у B.

Почему один общий выбор скрывает маршрут

Участник может попросить распространить префикс всем, отдельным AS или никому. RFC 7948 перечисляет Communities, реестры маршрутизации и клиентские базы правил. Документы IXP Manager, AMS-IX и LINX показывают действующие схемы Standard и Large Communities.

Сам тег не является универсальной командой. Значение задаёт договор конкретного IXP, а исполнение подтверждает только клиентский Adj-RIB-Out.

Path hiding возникает, когда общий best path вычислен до клиентского фильтра. Удаление победителя после выбора не запускает автоматически выбор среди оставшихся. Клиент теряет разрешённую альтернативу.

RFC 7947 описывает отдельную Loc-RIB для клиента как переносимое решение: применить его ограничения и только затем выбрать лучший путь. Общую часть состояния можно хранить совместно, сохраняя различия. Возможна и отправка нескольких маршрутов через Diverse Paths или ADD-PATH. Для ADD-PATH серверу рекомендуется режим send-only к клиентам, чтобы их неактивные пути не возвращались как сомнительные новые входы.

FRRouting документирует отдельную RIB для RS-client, а AMS-IX указывает на secondary в BIRD. Название функции не подтверждает её фактический результат. Нужен canary с двумя путями: предпочитаемый запрещается для B, после чего проверяется получение второго.

Сохранение NEXT_HOP переносит проверку к входу

Прямой NEXT_HOP удерживает пакеты вне сервера, но позволяет злоупотребление. A может объявить свой префикс с адресом C как следующий переход. Если посредник распространит маршрут, множество клиентов направит трафик к C.

RFC 7948 рекомендует сравнивать NEXT_HOP с интерфейсом объявляющего клиента и отвергать несовпадение между разными AS. Для нескольких подключений одного AS возможно явное исключение. IXP Manager описывает такую проверку рядом с правилами пути, префикса, IRR и RPKI.

Именно сервер ещё знает личность входной сессии. После объединения маршрутов сотен участников в одном соседстве B трудно восстановить полномочия каждого адреса.

Но разрешённый адрес может быть недоступен. Нетранзитивный сбой коммутатора оставляет BGP до серверов живым, а прямую связь B–C разрывает. ARP или NDP не завершается. Проверка адреса посредника наблюдает не тот путь, по которому должны идти пакеты.

Два сервера должны доказывать один контракт

RFC 7948 рекомендует несколько серверов на общем сегменте. Разные реализации и ОС уменьшают общий риск одного программного дефекта.

Однако две сессии не гарантируют равные выходы. Различаются поколения политики, снимки IRR, состояние RPKI, моменты сходимости и алгоритмы клиентских представлений. Одинаковые суммы не замечают разные AS_PATH, NEXT_HOP, MED или Communities.

Сравнение выполняется для каждого клиента, семейства и NLRI. Значимые атрибуты нормализуются и превращаются в fingerprint. Любое ожидаемое различие получает объяснение. Запущенный процесс сообщает конкретное поколение конфигурации и данных.

Разнообразие без наблюдаемой эквивалентности даёт непредсказуемость. Две непрозрачные копии могут повторять один дефект. Надёжная избыточность объединяет независимость отказов с проверяемым равенством услуги.

От исходного UPDATE до пакета

Полная цепочка состоит из восьми свидетельств:

  1. Adj-RIB-Out A или capture показывает исходный анонс.
  2. Adj-RIB-In сервера показывает полученный вход.
  3. Журнал проверок объясняет решения по префиксу, origin, первому AS и NEXT_HOP.
  4. Представление B и версия политики объясняют выбор кандидата.
  5. Adj-RIB-Out сервера к B показывает отправленные атрибуты.
  6. Adj-RIB-In B подтверждает прохождение сессии.
  7. Выбранная RIB, FIB и таблица соседей показывают прямой следующий переход.
  8. Счётчики, probe или capture доказывают доставку пакетов к C.

Общая RIB не равна представлению B. Looking glass не всегда показывает отклонённые варианты. Желаемый файл не доказывает запущенную версию. Временные метки и идентификаторы превращают снимки в причинную последовательность.

Ответственность разделена так же: объявляющий отвечает за вход, оператор сервера — за проверку и распространение, B — за импорт и выбор, IXP — за прямую доставку второго уровня. Зелёный индикатор одного участника не закрывает этап другого.

Миграция, проверяющая границы модели

Сначала по официальным данным IXP фиксируются ASN, адреса, AFI/SAFI, возможности и договор Communities обоих серверов. Исключение первого AS назначается только этим соседям.

Тестовый префикс проходит последовательную проверку входа, валидации, представления B, выхода, приёма, FIB, разрешения MAC и пакетов. Ожидаемый результат сохраняет AS объявляющего слева и его NEXT_HOP; ASN сервера не добавляется ради привычного вида.

Затем проверяются запреты: разрешить B и исключить другого клиента, поменять решение, предложить два пути и запретить предпочтительный, указать NEXT_HOP чужого AS и потребовать отклонение, повторить для IPv4 и IPv6. Выходы серверов сравниваются по атрибутам.

Rollback хранит прошлые версии клиента и сервера. Возврат строки конфигурации не гарантирует исчезновения уже выученных маршрутов; возможны route refresh, повторная оценка или ограниченное действие сессии. Несвязанные службы не перезапускаются.

Источники и пределы

Основа — RFC 7947 в сравнении с базовым BGP из RFC 4271. RFC 7948 охватывает избыточность, утечки, Layer 2 и захват NEXT_HOP. RFC 7911 и RFC 6774 описывают многопутевые механизмы.

Текущие примеры реализации взяты из документации FRRouting, BIRD и IXP Manager. Официальные страницы AMS-IX и LINX показывают опубликованную практику, но не доказывают состояние неназванного IXP. Начальный случай синтетический.