Кратко

  • В модели разреженного пиринга RFC 9815 сессия с рефлектором или контроллером переносит Link NLRI, но не обязательно проходит по описанной линии и не измеряет её живость.
  • Рабочее ребро появляется только после цепочки отдельных решений: локальное наблюдение, полномочный источник, новая последовательность и статус, EoR при его использовании, встречный совместимый NLRI, допуск в LSDB, расчёт SPF, установка и проверка пакетами.
  • Чем меньше сессий обслуживает топологию, тем важнее не сжимать доказательства в один зелёный индикатор. Свежая копия утверждения не становится фактом физического мира благодаря центральному распространению.

Два графа на одной панели

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

RFC 9815, опубликованный в июле 2025 года как Standards Track, вводит BGP-LS-SPF SAFI 80. Он сохраняет транспорт и механизм сообщений BGP, но использует Node, Link и Prefix NLRI для построения топологии и заменяет соответствующий процесс выбора расчётом кратчайших путей. RFC 9816 описывает применение, в том числе сессии между loopback-адресами, рефлекторы и контроллеры.

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

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

В инциденте это выглядит коварно: сессия рефлектора Established, TCP-AO подтвердил партнёра, Link NLRI имеет максимальную последовательность, SPF отработал, маршрут появился в RIB — а одно направление не несёт пакеты. Все показания могут быть истинны. Они отвечают на разные вопросы. Управленческая ошибка начинается тогда, когда здоровье канала распространения получает полномочия датчика физической линии.

Последняя версия — это порядок, а не истина

Link NLRI является направленным утверждением локального узла. Удалённый узел создаёт отдельное утверждение для обратного направления. Рефлектор может переслать оба; он не становится источником наблюдения ни для одного.

Каждый BGP-LS-SPF NLRI несёт обязательный 64-битный номер последовательности. Самостоятельно созданные версии должны увеличивать его, а состояние следует сохранять через холодный перезапуск доступными средствами. Получатели обычно предпочитают наибольший номер; для напрямую связанных соседей предусмотрено восстановление после старого состояния источника.

Последовательность отвечает на вопрос о более новой версии. Она ничего не знает о том, к правильному ли интерфейсу подключён детектор и не скомпрометирован ли полномочный узел. Совершенно свежая запись может быть ошибочной. Полезная трасса поэтому включает источник, идентификаторы линии, отпечатки NLRI и атрибута, последовательность, SPF Status, путь получения и правило выбора. Несколько источников одной NLRI не образуют автоматического кворума: RFC рассматривает это как возможную ошибку конфигурации или маскировку.

При падении линии источник сначала распространяет более новую Link NLRI со статусом недоступности, а затем снимает её после настраиваемого интервала. Рекомендованный LinkStatusDownAdvertise равен двум секундам. Если линия вернулась в этот период, ещё большая последовательность убирает статус down. Новое отрицательное утверждение таким образом обгоняет старые положительные копии.

Но эти две секунды не являются временем гарантированного восстановления. Для проверки нужны отметки обнаружения, создания объявления, приёма каждым потребителем, планирования и завершения SPF, изменения RIB/FIB и успешной пробы. Иначе «быстрая сходимость» остаётся характеристикой без измеряемого содержания.

EoR не проверяет пульс линии

RFC 9815 допускает ожидание End-of-RIB перед публикацией Link NLRI, связанной с пиром. Поддерживаемая настройка должна быть одинаковой во всём домене. При её включении по умолчанию ожидают неограниченно, хотя оператор может задать максимум.

Эта граница нужна, чтобы не направить трафик на узел, который ещё не завершил начальную передачу RIB и не подготовил пересылку. В примере с контроллером тот может дождаться EoR и Link NLRI от обоих концов, прежде чем выпустить линию в граф. Это сильное правило готовности, но не измерение среды передачи. EoR сообщает о завершении начального обмена для семейства адресов в данной сессии.

Несогласованная политика EoR способна вызвать временные микропетли и потери. Поэтому единый столбец «готово» вреден. Отдельно видимыми должны быть сессия, согласованное семейство, EoR, локальный детектор, две актуальные направленные записи, их взаимное соответствие, включение в LSDB, маршрут и пакетная проверка.

Обратное объявление должно описывать ту же линию

Односторонняя стрелка не становится ребром SPF. Для текущей Link NLRI потребитель ищет у удалённого узла запись, указывающую обратно. У нумерованных интерфейсов перекрёстно сопоставляются локальный адрес интерфейса и адрес удалённого соседа.

Для ненумерованных линий используются Link Local/Remote Identifiers и Address Family Link Descriptor. Без дескриптора семейства линия исключается и из IPv4-, и из IPv6-расчёта. Ноль может выступать шаблоном, когда удалённый идентификатор неизвестен. Это упрощает старт, но делает параллельные ненумерованные линии неоднозначными: стороны могут временно иметь в виду разные физические рёбра. Поэтому раздел управления рекомендует получать или задавать удалённые идентификаторы.

Проверенная Errata 8835 исправляет именно взаимное условие. В опубликованном тексте одно сравнение было повторено дважды. Правильно сравнить Current Remote с Remote Local и Current Local с Remote Remote. Версия с встроенными пометками удобна для чтения исправленного фрагмента.

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

Запись можно переслать, не допустив к расчёту

Граница проходит и через обработку ошибок. NLRI без BGP-LS Attribute может сохраниться и распространяться, например после отбрасывания атрибута, но не должна выдаваться для использования SPF. Некорректный статус или дескриптор семейства может рассматриваться как withdrawal. Счётчик в Adj-RIB-In без причины допуска завышает размер вычислимого графа.

Если базы link-state у двух BGP-LS-SPF-участников расходятся, RFC требует сбросить сессию, если нет другого механизма ресинхронизации вне его области. Уведомление определено, а метод обнаружения рассинхронизации оставлен реализации. И здесь стандартное действие начинается после локально полученного доказательства.

TCP-AO уменьшает риск подмены участника, но не исправляет поведение скомпрометированного авторизованного пира. Тот может менять Node, Link или Prefix NLRI, порождать дубли или заставлять систему слишком часто считать SPF. Проверка курьера не проверяет рассказ в посылке.

Испытание, в котором рефлектор остаётся жив

Минимальный стенд должен специально развести физический и распределительный графы и включить пару параллельных ненумерованных линий. Базовое состояние фиксирует обе направленные NLRI, точное взаимное соответствие, EoR, одинаковые отпечатки LSDB и пробы по каждому ожидаемому ECMP-пути.

Затем одно направление разрывают, не закрывая сессию рефлектора. Нужно увидеть, какой детектор сработал первым; только ли полномочный источник повысил нужную последовательность; успел ли down-статус опередить старые положительные копии; исчезло ли взаимное ребро из SPF и следующий переход из FIB. При восстановлении ещё более новая запись должна убрать down, не воскресив старую идентичность.

Далее проверяются отсутствующий дескриптор семейства, переставленные идентификаторы, нулевой шаблон при параллельности, разные метрики, задержка EoR, отброшенный атрибут, холодный перезапуск с потерей состояния, двойной источник, рассинхронизация и потеря рефлектора. Различающиеся фильтры также обязательны: RFC 9816 предупреждает о локально разных таблицах, недоступности и петлях.

Каждый опыт должен оставлять связанную строку доказательств: идентичность ребра, привязку детектора, исходное время, источник, отпечатки дескрипторов и атрибутов, последовательность и статус, отправляющего и принимающего пира, EoR, причину допуска, поколение LSDB, времена SPF, различия RIB/FIB, пробы, тревогу, решение и результат отката.

Так практически работает приоритет исполняемого кода: спецификация, конфигурация, исполненная смена состояния и наблюдаемый пакетный эффект связаны, но не заменяют друг друга.

Чего источники не подтверждают

В материалах нет названного внедрения у оператора, полной матрицы реализаций, значений по умолчанию у производителей, измеренного распределения сходимости, доказанного снижения аварий или публичного инцидента безопасности. Эффективность из RFC 9816 — архитектурное обоснование, а не полевой результат.

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

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

Источники

  1. Карточка RFC 9815 в Datatracker
  2. История RFC 9815
  3. Ссылки RFC 9815
  4. Документы, ссылающиеся на RFC 9815
  5. Информационная страница RFC 9815
  6. RFC 9815: BGP-LS SPF Routing
  7. Errata RFC 9815
  8. RFC 9815 со встроенными исправлениями
  9. Информационная страница RFC 9816
  10. RFC 9816: применение и границы
  11. RFC 4271: BGP-4
  12. RFC 9552: BGP-LS
  13. RFC 5880: BFD
  14. RFC 4724: Graceful Restart и EoR
  15. RFC 8405: задержка SPF
  16. RFC 7606: обработка ошибок UPDATE
  17. RFC 5925: TCP-AO
  18. Heng Lu: Running-Code Primacy
  19. Heng Lu: Minimum Initial Specification
  20. Heng Lu: Reality Layers