Кратко

  • В редакции 19 строгий режим считается согласованным лишь после обмена Capability 74 в обеих BGP OPEN; односторонняя настройка не равна двустороннему обязательству.
  • Реальные реализации связываются с разными редакциями проекта, различают negotiated, unilateral и override-поведение, а в одном указанном релизе отсутствует BfdHoldTimer.
  • Закупка и ввод в эксплуатацию должны принимать конкретную пару релизов по наблюдаемым состояниям, таймерам и сценарию отката, а не по декларации «поддерживается strict mode».

В требованиях к закупке была одна строка: «BGP BFD strict mode — поддерживается». Три семейства маршрутизаторов прошли формальную проверку. После миграции одно ждало взаимного объявления capability, второе блокировало BGP по локальной команде, третье не имело таймера, на который опирался общий план восстановления.

Поставщики выполнили строку. Сеть не получила единого поведения.

Так проявляется управленческая сторона draft-ietf-idr-bgp-bfd-strict-mode-19. Активный проект рабочей группы IDR датирован 26 августа 2026 года. В заголовке указан Standards Track и намерение обновить RFC 4271 в случае принятия, но Datatracker всё ещё показывает I-D Exists: это не RFC и не завершённое решение IETF. Отзывы Operations, Security и BGP Directorate помогают увидеть открытые эксплуатационные вопросы, но не являются сертификатом для оборудования.

Механизм решает понятную проблему. При обычной связи по RFC 5882 BGP может перейти в Established до готовности связанной BFD-сессии. На деградировавшем канале маршруты успевают появиться, прежде чем BFD обнаружит отказ и разорвёт BGP. Strict mode меняет условие допуска: локальный BFD должен достичь Up, прежде чем конечный автомат BGP продолжит установление сессии.

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

Взаимная способность и одностороннее право — разные товары

Редакция 19 назначает BFD Strict-Mode Capability код 74. Поддерживающий speaker помещает capability нулевой длины в OPEN. Переменная BfdStrictNegotiated становится истинной только тогда, когда способность присутствует и в локальном, и в удалённом OPEN. Конфигурационное намерение становится предложением; встречное предложение образует пересечение; только пересечение меняет общий порядок запуска.

В продуктах рядом существуют и другие модели. Актуальная документация Cisco различает proprietary или unilateral strict mode, strict-mode-negotiate и override, заставляющий применять барьер без объявления поддержки соседом. Документация Juniper описывает взаимное объявление и рекомендует одинаковую конфигурацию на обоих концах. Это не обвинение в несовместимости конкретного продукта. Это доказательство того, что слово strict не определяет единый предмет закупки.

В спецификации поставки поэтому должны быть названы точная команда и её область действия, семантика в конкретном релизе, capability sent и received, вычисленный negotiated-результат, наличие override и субъект, который вправе его разрешить. Boolean-поле «есть/нет» пригодно для презентации, но недостаточно для приёмки.

Security Directorate указывает ещё на одну границу. Смысл capability зависит от целостности OPEN. Если участник на пути способен удалить код 74, двусторонний барьер может быть незаметно понижен при отсутствии достаточной защиты BGP-обмена. С другой стороны, локальный override может сохранить барьер, хотя сосед ничего не обещал. Наблюдаемая capability доказывает содержание сообщения в данной точке; она сама по себе не удостоверяет полномочие политики.

Версия реализации является частью обязательства

Приложение о реализациях к проекту необычно полезно для закупщика. В нём Junos 23.2R1 и новее отмечен как Used с совместимостью относительно редакции 17, IOS XR 24.3.1 и новее — относительно редакции 12, Nokia 23.7R1 — относительно редакции 07; для указанной Nokia-реализации BfdHoldTimer не реализован. Это сведения внутри незавершённого проекта, не независимая сертификация и не обещание о каждом шасси.

Однако они показывают, почему недостаточно принять capability по номеру. Реализации могут соответствовать разным срезам развивающегося автомата. В более позднем тексте появляется явная обработка раннего KEEPALIVE, уточняется pending-состояние или таймер, которого в более раннем коде нет. Одинаковый код 74 сообщает о совместном классе намерения, но не перечисляет весь набор переходов.

Следовательно, объект приёмки — не модель маршрутизатора и не версия проекта по отдельности. Это конкретная пара: платформа, релиз, режим, поддерживаемые состояния и таймеры на каждой стороне. Пара считается принятой после воспроизводимого испытания. Подмена этого решения общей матрицей «feature supported» переносит риск на первую производственную смену.

Право ждать исполняют два автомата

После согласования редакция 19 вводит pending-подсостояния для Connect, Active и OpenSent. Стороны могут обменяться OPEN, но локальный speaker удерживает KEEPALIVE до Up своего BFD. У соседа BFD может подняться раньше, и он отправит KEEPALIVE, пока локальная сторона ещё ждёт.

Состояние OpenSentConfirmedBfdUpPending сохраняет обе истины: удалённый BGP уже продвинулся, локальное BFD-условие ещё не выполнено. В отзыве BGP Directorate на редакцию 18 эта гонка была существенным вопросом: обычная обработка OpenSent могла воспринять ранний KEEPALIVE как ошибку FSM и сбросить TCP. В редакции 19 событие имеет явное место. Для закупки телеметрии это важно не меньше, чем сам протокол: скрытый подстатус лишает оператора возможности отличить законное ожидание от зависшей сессии.

Если BFD падает до установления BGP в согласованном режиме, speaker отправляет Cease с подкодом BFD Down, закрывает TCP, освобождает ресурсы и возвращается в Idle. После Established удаляются и маршруты, выученные через соединение. Подкод из RFC 9384 делает непосредственную причину закрытия точнее, но не определяет первопричину. Ею могут быть физический отказ, разные настройки, временная геометрия, потеря или подавление пакетов, аутентификация, перегрузка либо реализация.

Таймеры формируют скрытые условия поставки

Проект задаёт конфигурируемый BfdHoldTime по умолчанию 30 секунд и BfdHoldTimer для случая, когда согласованный BGP holdtime равен нулю. Отдельный BFD hold-down может потребовать, чтобы состояние Up сохранялось заданный интервал до Established. Значения hold-down локальны: документ рекомендует близкие величины, но не согласует единое число.

Один peer способен достичь Established и запустить отсчёт BGP holdtime, пока другой ещё не имеет права послать KEEPALIVE. Если первая сторона истечёт раньше окончания удалённого hold-down, защитный механизм сам создаст разрыв. Juniper документирует для линии 23.2R2 случай неопределённого Idle при strict mode плюс holddown на одной стороне и отсутствии соответствующей настройки на другой: один маршрутизатор ждёт BFD, второй — BGP. Это не рассказ о конкретном заказчике, а полезная иллюстрация замкнутой зависимости.

Поэтому значения таймеров — не мелкая локальная настройка после покупки. Это часть совместимости. Контракт должен требовать раскрытия BGP holdtime, BFD hold time, hold-down или dampening, поведения при нулевом holdtime и доступности соответствующей телеметрии. Если один релиз не имеет предполагаемого таймера, архитектура не может притвориться, что он существует благодаря общей модели данных.

Приёмка обязана включать неуспешный сценарий

До изменения для каждого конца фиксируются платформа, релиз, точный режим, версия документированного поведения, таймеры, аутентификация и ожидаемые pending-состояния. В испытании сохраняются Capability 74 sent/received, BfdStrictNegotiated, идентификаторы и адреса BFD, переходы по времени, BGP substate, уведомление о закрытии, изменения RIB и фактический результат трафика.

Положительный тест, где обе стороны сразу поднялись, проверяет только счастливую последовательность. Приёмка должна намеренно включать четыре неудобных варианта: capability объявлена одной стороной; hold-down различается; удалённый BFD/BGP продвигается раньше локального; BFD-пакеты подавляются после появления маршрутов. В каждом варианте ожидаются именованное состояние, ограниченное время ожидания, понятная причина закрытия и сохранённые доказательства.

Откат также является двусторонним сценарием, а не отменой одной строки. Удаление локального барьера не подтверждает, что сосед перестал ждать. Изменение strict mode после Established может не повлиять на текущую сессию до следующего рестарта. План должен определить порядок действий, условие рестарта, проверку эффективного режима у обоих peers и критерий восстановления трафика. Иначе rollback возвращает конфигурацию, но не обязательно возвращает систему.

Running-Code Primacy у Heng Lu даёт правильную иерархию решений. Проект задаёт минимальную общую норму. Исполняемый код образует множества совместимости. Оператор принимает поведение, когда запускает, проверяет и сознательно выбирает совместимого контрагента. Ни стандартный заголовок, ни строка тендера не могут заменить этот акт.

BFD strict mode полезен именно потому, что даёт устройству право не выпускать BGP до готовности механизма отказа. Такое право нельзя покупать как абстрактную галочку. Необходимо приобрести наблюдаемое обещание двух реализаций, испытать момент, когда каждая из них прекращает ждать, и заранее доказать путь назад.

Источники