Кратко

  • В BGP-SPF отсутствие Node SPF Status TLV означает, что узел считается работающим и доступным для транзита. Если ранее был объявлен статус 2, последующее объявление Node NLRI без этого TLV не сохраняет ограничение: прежнее состояние статуса считается неявно отозванным.
  • Статус 2 не делает узел недостижимым. Его префиксы могут оставаться доступными, но при обработке такого узла SPF не разворачивает его исходящие Link NLRI для построения дальнейшего транзитного пути. Поэтому успешная проверка сервиса и подтверждение нетранзитной роли — две разные приёмочные проверки.

После перезапуска проверяется не только то, что осталось

Представим узел, который до холодного перезапуска объявлял Node NLRI со статусом 2. После запуска его сервис снова отвечает. Мониторинг видит адрес, запрос проходит, владелец приложения получает положительный результат. Если аудит заканчивается здесь, он отвечает лишь на вопрос о достижимости.

Для маршрутизации остаётся другой вопрос: существует ли после перезапуска то ограничение, которое запрещало использовать этот узел как промежуточный транзитный шаг?

Это не семантическая тонкость. RFC 9815 имеет статус Standards Track и требует, чтобы каждый маршрутизатор в домене BGP SPF безусловно объявлял свой Node NLRI. Сам SPF Status TLV при этом является дополнительным атрибутом. В разделе 5.2.1.1 RFC 9815 прямо задано значение отсутствия: если SPF Status TLV не включён, узел считается работающим и доступным для транзитного трафика.

Тем самым «Node NLRI присутствует» и «нетранзитное ограничение присутствует» не являются эквивалентными утверждениями. Более того, восстановление первого без второго имеет определённую протоколом семантику.

Тот же раздел устанавливает правило перехода состояния: если Node NLRI получен без SPF Status TLV, ранее полученная информация SPF Status считается неявно отозванной. Поэтому исчезновение значения 2 нельзя трактовать как нейтральное отсутствие телеметрии. На уровне SPF-семантики старое ограничение больше не действует.

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

Что именно означает статус 2

Реестр значений не оставляет статус 2 для локальной интерпретации. Раздел 8.3 RFC 9815 и специализированный реестр IANA BGP SPF задают значения Node SPF Status следующим образом: 0 зарезервировано, 1 означает недостижимость узла относительно BGP SPF, 2 — отсутствие поддержки транзитного трафика относительно BGP SPF, диапазон 3–254 не назначен, а 255 зарезервировано.

Различие между 1 и 2 особенно важно.

Статус 1 исключает узел как достижимый элемент расчёта. В алгоритме SPF из раздела 6.3 на шаге 3 узел со статусом недостижимости игнорируется.

Статус 2 действует иначе. Узел остаётся достижимым. На шаге 4 рассматриваются префиксы текущего достижимого узла, поэтому его собственные сервисы не обязаны исчезать только из-за нетранзитного статуса. Ограничение проявляется на шаге 5: если текущий Node NLRI сообщает, что узел не поддерживает транзит, алгоритм не использует его исходящие Link NLRI для дальнейшего расширения пути.

Именно поэтому проверка «сервис отвечает» не способна подтвердить сохранение статуса 2. При корректно действующем статусе 2 сервис как раз может оставаться доступным.

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

Исчезновение ограничения — это допустимость, а не выбранный маршрут

Здесь легко сделать следующий чрезмерный вывод: если статус 2 исчез, узел немедленно начинает переносить транзит. RFC такого утверждения не даёт.

После исчезновения TLV узел вновь становится допустимым для транзитного использования в расчёте. Но допустимость — лишь одно из условий выбора пути.

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

Поэтому корректная формулировка риска звучит не как «потеря статуса 2 направляет трафик через сервер», а как «потеря статуса 2 снимает протокольное ограничение, которое не позволяло SPF расширять через этот узел транзитные пути».

Эта разница важна и для расследования. Если после перезапуска статус 2 отсутствует, но проверенный поток всё равно обходит узел, это не доказывает сохранение прежнего ограничения. Возможно, топология и метрики просто не сделали узел выбранным переходом в данном расчёте.

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

Значения, которые нельзя молча переосмысливать

Тип SPF Status имеет код 1184. Это отражено как в разделе 8.2 RFC 9815, так и в специализированном реестре IANA BGP-LS Parameters, где 1184 зарегистрирован как SPF Status.

Для значений Node Status действует отдельный реестр BGP SPF. Такое разделение источников полезно сохранять и в технической документации: код TLV 1184 и значения его Node Status не следует приписывать какой-либо иной общей таблице IANA.

Диапазон 3–254 сейчас не назначен. RFC требует распространять полученное неизвестное значение, но игнорировать соответствующий Status TLV при SPF-вычислении; реализация может зарегистрировать такую ситуацию для последующего анализа. Это не пространство, в которое оператор может безопасно вложить собственную локальную семантику «перегружен», «на обслуживании» или «почти нетранзитный» и ожидать одинакового поведения остальных участников.

Значения 0 и 255 устроены иначе: они зарезервированы. Когда SPF Status TLV содержит зарезервированное значение, он считается некорректным. Правила обработки ошибок RFC 9815 §7.1 требуют считать соответствующий Node NLRI некорректным и применить обработку treat-as-withdraw.

Таким образом, для аудита существует как минимум три разных класса состояния: определённое значение 1 или 2; неизвестное неназначенное значение, которое SPF игнорирует; и зарезервированное значение, вызывающее обработку некорректного объявления. Смешивать их в одну категорию «необычный статус» опасно для анализа.

RFC 9816 сужает, а не расширяет смысл нетранзитности

RFC 9816 служит документом по применению и применимости BGP-LS SPF. Его информационная страница RFC Editor полезна как точка проверки статуса и связи документа с RFC 9815.

Для Node SPF Status 2 особенно важен раздел 7 RFC 9816. Он приводит два применения нетранзитной возможности.

Первое — сервер приложений, услуги которого должны быть достижимы из подсетей домена BGP-SPF, но который не должен выполнять роль маршрутизатора и переносить транзитный трафик.

Второе — контроллер, размещённый на сервере, к которому нужна непосредственная достижимость из домена, при этом сам сервер не должен становиться транзитным узлом.

Из этих двух примеров нельзя выводить более широкую нормативную семантику. RFC 9816 не определяет статус 2 как универсальный признак технического обслуживания, перегрузки, деградации мощности или административной готовности к выводу из эксплуатации. Такие локальные намерения могут существовать у оператора, но они не становятся значением стандарта только потому, что статус 2 кажется удобным механизмом.

И столь же важно обратное: два примера RFC не доказывают, что кто-либо фактически применяет статус 2 именно таким образом. Документ описывает применимость, а не наблюдаемое распространение.

Видимость топологии и проверка трафика отвечают на разные вопросы

Разделение доказательств становится ещё яснее в RFC 9816 §5.5.2. Этот раздел описывает использование BGP-LS-SPF объявлений для получения видимости топологии и отмечает, что средство управления также может использоваться для проверки пути передачи данных.

Для эксплуатации это два разных слоя знания.

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

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

Поэтому после перезапуска разумно не подменять одну проверку другой. Наличие статуса 2 подтверждается в соответствующем состоянии управления; результат SPF проверяется отдельно; установленное состояние пересылки — ещё отдельно; выбранные тестовые потоки затем дают ограниченное подтверждение поведения для заданных случаев.

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