Кратко

  • RFC 6428 объединяет в одном сеансе BFD проверку непрерывности CC, проактивную проверку связности CV и индикацию удалённого дефекта RDI.
  • CC и CV чередуются; в нормальной работе на каждую секунду приходится одна CV. Для них используются разные коды G-ACh: 0x0022 для BFD CC и 0x0023 для BFD proactive CV.
  • CV добавляет неизменяемый TLV Source MEP-ID. Принимающий MEP может обнаружить неверную связность. RDI передаётся только в поле диагностики CC, а поле диагностики CV необходимо игнорировать.

Что означает работающий сеанс

Оператор задаёт MEG, MEP-ID, периодичность CC, требуемое состояние CV, состояние аутентификации и ключ, если он используется. Дискриминатор соседа также может быть задан конфигурацией или назначен локально. Источник MEP отправляет доказательство, но не может единолично объявить на приёмной стороне правильность связности. Принимающий MEP сопоставляет Source MEP-ID и тип, инкапсуляцию, дискриминатор, метку и аутентификацию, затем классифицирует дефект. Воздействие на клиентский трафик определяется последующим действием при дефекте в рамках OAM MPLS-TP; сам факт получения пакета не является самостоятельной командой блокировки.

Все изменения состояния BFD и обмены Poll/Final должны идти через CC. Состояние сеанса и Poll/Final, обнаруженные в CV, игнорируются. Потеря непрерывности выявляется после периода сеанса, умноженного на удалённый Detect Multiplier 3; неверная связность выявляется в течение одной секунды. Условия неверной связности включают неправильную инкапсуляцию, неожиданные Source MEP-ID или тип, дискриминатор, сопоставленный с другой меткой, ожидаемый дискриминатор на неправильной метке и недействительную аутентификацию, если она включена. При входе в дефект принимающий MEP заявляет Signal Fail процессам клиента.

Выход возможен только после 3,5 секунды без CV-сообщения, демонстрирующего неверную связность.

При согласованной работе состояние дефекта отслеживает один двунаправленный сеанс BFD. При независимой работе используются два сеанса; один из них может оставаться UP, получая RDI. Поэтому UP не доказывает ни исправность приложения, ни правильность пути. Источник не устанавливает, какие операторы или поставщики применяют RFC 6428 и какой режим выбирают; он также не содержит распространённости, измерений ложных срабатываний, коммерческих значений, длительности воздействия на клиента или наблюдаемых результатов восстановления. Спецификации не выбирают за оператора схему MEG, политику аутентификации, порог эскалации или ответ на трафик клиента.

Путь решения оператора

  1. Захватите последовательные пакеты CC и CV. Если используется GAL, проверьте, что он находится внизу стека и его TTL не меньше единицы. Проверьте G-ACh: 0x0022 для CC и 0x0023 для CV.
  2. В CV проверьте Source MEP-ID и тип; ни один узел не должен менять значение TLV. Сопоставьте их с ожидаемыми MEG и MEP.
  3. Проверьте соответствие дискриминатора и метки в обоих направлениях, инкапсуляцию и аутентификацию. Учтите: TLV Source MEP-ID находится за пределами длины управляющего пакета BFD и не включается в digest при digest-аутентификации BFD; это отдельный вопрос целостности.
  4. Читайте RDI только из поля диагностики CC. Поле диагностики CV игнорируйте; изменения состояния и Poll/Final обрабатывайте через CC.
  5. Проверьте таймеры: истечение времени обнаружения означает Diagnostic 1, Link Down — Diagnostic 5, обнаруженная неверная связность — Diagnostic 9. Для выхода подтвердите 3,5 секунды без дефектной CV.
  6. Установите, используется ли согласованный или независимый режим, и применяйте предусмотренное OAM последующее действие, а не превращайте получение пакета автоматически в блокировку.

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

Источники

Роли вспомогательных документов разделены: RFC 5880 описывает автомат состояний и диагностику BFD, RFC 5586 — перенос GAL/G-ACh, RFC 5921 — рамки и идентификаторы MPLS-TP, RFC 5860 и RFC 6371 — требования и контекст последующих действий, RFC 5884 — BFD для MPLS LSP, RFC 5885 — BFD VCCV и совместимость CC-only. Ни один из них не заменяет правила обработки RFC 6428. Страница errata является сохранённым снимком получения, а не утверждением о внесённом исправлении.