Кратко

  • RFC 9612 добавляет BFD Reverse Path TLV в MPLS LSP echo, чтобы входной узел запросил определённый обратный FEC для BFD Control. Запрос становится явным, но отказ остаётся наблюдением полного круга.
  • Код 193 и BFD Up могут существовать одновременно: нужного возврата нет, зато локальная политика разрешила другой IP-путь. Отказ запроса и рабочий обход не противоречат друг другу.
  • Доказательная цепочка включает прямой LSP, обратный FEC, ответ TLV, фактический маршрут, состояние BFD, Reply Path, перенаправление, уведомление и доставку приложения.

На панели сессия зелёная, однако она уже идёт не тем путём, который должен был проверяться. Входной узел запросил конкретный обратный FEC. Выходной его не нашёл, вернул 193 и по локальной настройке отправил BFD Control через IP. Доступность сохранилась, а исходная конструкция исчезла.

Обратная ситуация столь же опасна. BFD быстро сообщает Down, а система сразу подписывает событие именем прямого LSP. Но контрольный пакет зависит от двух направлений. Молчание доказывает, что круг не завершён вовремя, а не то, что именно прямой сегмент сломан.

RFC 9612 опубликован как Experimental. Он расширяет MPLS LSP echo элементом BFD Reverse Path TLV. Входной узел помещает в него допустимые немультикастовые Target FEC Stack sub-TLV, а выходной использует указание для обратной отправки периодических BFD Control.

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

Круг не равен направлению

RFC 5880 определяет быстрый механизм проверки связности. В MPLS по RFC 5884 прямой пакет может идти по LSP, а ответ возвращаться по IP. Это подтверждает обмен между концами, но не изолированное здоровье прямого LSP.

Reverse Path TLV получил тип 16384. Он содержит ноль или больше подходящих Target FEC Stack sub-TLV. Мультикастовый FEC недопустим и приводит к коду 192. По умолчанию число элементов ограничено 128, чтобы раздутый запрос не создавал неограниченную работу и состояние.

Указанный возврат улучшает постановку проверки. Известно, чего хотел входной узел и что принял выходной. Но при Down причиной всё ещё может быть прямой путь, обратный путь, новое разрешение FEC или отказ от запроса. Быстрый детектор знает время, а не весь граф причин.

Первичное событие поэтому следует называть «круг BFD нарушен, направление проверяется». Такое ограничение не замедляет восстановление. Оно не даёт автоматике переключить исправный путь и не превращает предположение в постоянную статистику отказов.

Точное значение 193

Если заданный обратный путь не найден, выходной узел обязан вернуть 193. Код говорит именно об этом запросе. Он не утверждает, что любая BFD-сессия невозможна или что приложение недоступно.

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

Отдельно измеряется сервис. Резерв может сохранить контроль, но нарушить обещанную физическую разнесённость. BFD может упасть, когда приложение уже переключено. Запрошенный путь, фактический путь, контрольная сессия и доставка — четыре разных состояния.

Пустой Reverse Path TLV отменяет прежний выбор и возвращает решение локальной политике. После заданного пути LSP ping с BFD Discriminator TLV, но без Reverse Path TLV, также возвращает периодическую передачу к поведению RFC 5884. Отсутствие TLV здесь является переходом состояния.

Причина приходит позже сигнала

Разрешение FEC может измениться после установления сессии из-за обслуживания, реконвергенции или политики. Поэтому RFC 9612 требует уметь менять обратный путь уже работающей сессии.

После отказа входной узел применяет Reply Path TLV в LSP ping и проверяет действительность обратного FEC. Если FEC изменился, сессию нужно направить через другой FEC и уведомить оператора. Проверка, автоматическое действие и отчётность дают три квитанции.

BFD Control работает часто. Проверка плоскостей управления и данных через Reply Path выполняется существенно реже. Возникает честный интервал: отказ уже известен, причина ещё нет. Заполнять направление в этот момент означает подменять неизвестность.

Плановое обслуживание может заранее заменить возврат и предотвратить часть сигналов. Оно не устраняет неожиданные изменения и разницу периодов. Система должна показывать промежуточное состояние и измерять время до проверки, перенаправления и уведомления.

Локальная политика должна быть видимой

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

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

Предел 128 — стандартная защита от раздувания, а не целевая ёмкость. Реализация может выбрать меньше. Код 192 точно отказывает неподходящему мультикастовому FEC. Именованная ошибка лучше двусмысленного поведения.

Статус Experimental тоже ограничен. Он описывает поток публикации, не поддержку конкретным продуктом, не распространённость и не зрелость Standards Track. Эти утверждения требуют проверки версии, конфигурации, таблиц и пакетов.

Собрать цепочку хранения фактов

До происшествия записываются прямой LSP, запрошенный обратный FEC, отправленный TLV, ответ и наблюдаемый маршрут. Таймеры и состояние BFD добавляются к ним, а не заменяют их.

После сигнала добавляются Reply Path, текущее разрешение FEC, новый FEC, время перенаправления и уведомление. В конце измеряются потери, задержка и доставка на границе приложения. Живой контрольный канал не является квитанцией пользовательского трафика.

Испытание охватывает переходы. Сначала задаётся валидный возврат и снимаются пакеты. Затем FEC меняется при активной сессии. Запрашивается несуществующий путь и наблюдается 193 с разрешённым и запрещённым резервом. Мультикастовый FEC даёт 192, пустой TLV отменяет выбор, дискриминатор без TLV возвращает локальную политику, а превышение лимита получает ограниченный отказ.

API, плоскость управления, forwarding и захват пакетов должны совпасть. Программа может объявить новый FEC, пока аппаратура использует старый. IP-резерв может работать, не попадая в модель управления. Идентичность пути доказана только при согласии слоёв реальности.

Полезный отчёт звучит так: запрошенный обратный FEC исчез; получен 193; BFD продолжился по IP; сервис остался доступен; Reply Path нашёл замену; сессия перенаправлена, оператор уведомлён. Каждое предложение можно проверить независимо.

Источники