Кратко

  • BFD быстро проверяет жизнеспособность определённого пути и протокола данных; смысл сессии связан с конечными точками, инкапсуляцией и параметрами.
  • Up не показывает, что все участники ECMP, семейства адресов, маршруты, MTU и сервисы используют тот же исправный путь.
  • Для вывода о сервисе нужна связанная запись: идентичность и таймеры BFD, RIB/FIB, охват участников, двусторонние пробы рабочего размера и транзакция приложения.

Зелёный индикатор рядом с чёрной дырой

Представим гипотетический сценарий: окно обслуживания закрывается, маршрутные соседства восстановлены. Панель показывает BFD Up до клиентского следующего перехода, и изменение считают завершённым. Через несколько минут крупные передачи по-прежнему останавливаются. Малые контрольные пакеты попадают на исправный участник агрегата, а часть рабочих потоков — на другой, где ошибочна запись пересылки или обработка MTU.

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

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

BFD не обнаруживает сессию самостоятельно. Приложение решает, что она нужна, и задаёт адреса и параметры. Для каждого пути связи и протокола данных создаётся отдельная сессия. Физический канал, виртуальная цепь, туннель, MPLS LSP и multihop-путь могут иметь BFD; значение Up остаётся привязанным к проверяемой инкапсуляции.

Что именно записывает Up

В асинхронном режиме обе стороны периодически отправляют BFD Control; достаточно долгое отсутствие приёма ведёт к Down. В Demand периодическая передача может прекратиться, поскольку предполагается независимая проверка связи, а последовательность Poll запрашивает явную проверку. Echo возвращает пакеты через удалённый план пересылки.

Эти режимы дают разное доказательство. Echo способен обнаружить некоторые сбои пересылки, невидимые обычному обмену control-пакетами. Demand зависит от другого механизма. Реализация в control plane может разделять судьбу с routing-процессом; бит C лишь сообщает, объявляет ли удалённая реализация независимость от control plane. Одна запись Up теряет важный контекст.

Таймеры тоже ограничивают вывод. Желаемый интервал передачи, требуемый интервал приёма и множитель определяют время обнаружения в асинхронном режиме. Up в данную секунду означает, что машина состояний не объявила сбой при этих параметрах. Это не обещание на следующую секунду и не доказательство правильной реакции протокола-клиента.

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

Документ называет BFD средством OAM для проверки связи в сетевых сервисах, но прямо исключает обычный BFD из роли детектора отказа между приложениями через Интернет. Доставка BFD соседу не равна успешному DNS-запросу, заказу или передаче файла пользователя.

Последствие определяет клиент

RFC 5882 описывает BFD как консультативный сигнал. Протоколы маршрутизации и другие клиенты получают состояние и применяют собственные механизмы. BFD не переносит прикладные сведения. Down может ускорить отзыв маршрута, однако соседство, топология и пересылка остаются решениями клиента.

Даже история может быть отфильтрована. Реализация вправе скрыть от клиентов быстрый цикл Up/Down/Up с помощью гистерезиса. AdminDown означает административное намерение, а не обязательно отказ пути данных. Текущее состояние, переходы, уведомление и фактическое действие клиента — разные факты.

ECMP может развести BFD и пользовательские потоки по разным участникам. Малый пакет проходит там, где рабочий размер ломается из-за MTU. Может отдельно отказать обратный путь; маршрут может быть в RIB без ожидаемой FIB; приложение может отвергнуть правильно доставленный трафик. Одна зелёная ячейка этого не проверяет.

Источники