Теоретические основы и архитектура
Для быстрого обнаружения отказов в ядре применяются BFD для MPLS LSP (RFC 5884) и архитектура MPLS Transport Profile (MPLS-TP, RFC 5921). 1. BFD for MPLS LSP: расширяет BFD для мониторинга меченых путей. Сессия запускается через LSP Ping (в Echo Request добавляется BFD Discriminator TLV), после чего ingress в асинхронном режиме шлёт BFD Control-пакеты внутри метки LSP (адрес из 127/8, UDP 3784, TTL 1), а egress отвечает обычным IP-пакетом; эхо-режим здесь не используется. Интервал настраивается: на программных платформах обычно 100 мс и более, на аппаратных с offload до единиц миллисекунд; время обнаружения равно интервалу, умноженному на множитель. Контролируется только прямое направление LSP, зато «тихие» отказы data plane (IGP и LDP исправны, а пересылка по метке сломана) становятся видимыми. 2. MPLS-TP: подмножество MPLS с поведением транспортной сети в духе SDH/OTN (разработано IETF совместно с ITU-T). В плоскости данных нет IP-пересылки, ECMP и слияния LSP; LSP и PW двунаправленные (обычно co-routed) и создаются системой управления или GMPLS RSVP-TE, а не LDP. OAM работает внутри пути через Generic Associated Channel (G-ACh, RFC 5586) без IP, включая BFD для проверки связности (RFC 6428). Линейная защита 1+1 и 1:1 (RFC 6378) использует протокол PSC между концами; целевое время переключения менее 50 мс достижимо только при быстрой детекции и заранее установленном защитном пути.
Зачем BFD, если есть hello-таймеры
Hello-таймеры IGP и LDP рассчитаны на секунды: OSPF по умолчанию шлёт hello раз в 10 с и объявляет соседа недоступным через 40 с, у LDP-сессии keepalive/hold по умолчанию 60/180 с на Cisco и 10/30 с на Junos. Для сервисов с быстрой защитой (FRR, TI-LFA, VPN-резервирование) нужен детектор, срабатывающий за десятки или сотни миллисекунд и не зависящий от конкретного протокола. Это Bidirectional Forwarding Detection (RFC 5880): лёгкий протокол, который проверяет двунаправленную связность пути между двумя узлами и сообщает о потере приложениям-клиентам (OSPF, IS-IS, BGP, статические маршруты, MPLS). Клиент после уведомления сам решает, что делать: ронять соседство, запускать FRR, пересчитывать SPF.
Протокол BFD: пакеты, состояния, таймеры
Обязательная часть BFD Control - 24 байта: Version (1), Diag, State, флаги (P, F, C, A, D, M), Detect Mult, Length, My Discriminator, Your Discriminator, Desired Min TX Interval, Required Min RX Interval, Required Min Echo RX Interval. Односкачковая сессия (RFC 5881) использует UDP-порт назначения 3784, порт источника из диапазона 49152-65535 и IP TTL 255 (приём пакета с другим TTL запрещён, это защита типа GTSM). Многоскачковая (RFC 5883) использует порт 4784, эхо-режим - порт 3785. Состояния: AdminDown, Down, Init, Up; переход в Up происходит после трёхстороннего обмена, пока сессия не Up, пакеты идут не чаще раза в секунду.
Режим asynchronous (основной): оба конца периодически шлют Control-пакеты. Время обнаружения равно Detect Mult удалённого узла, умноженному на согласованный интервал, то есть большее из локального Required Min RX и удалённого Desired Min TX. Для 100 мс и множителя 3 это 300 мс; для 50 мс - 150 мс; на аппаратных платформах с offload в линейную карту доходят до 3,3 мс x 3, то есть около 10 мс. В режиме echo узел сам шлёт пакеты, которые сосед только зеркалит своей плоскостью пересылки, поэтому проверяется data plane соседа, а не его CPU. Diag-коды объясняют причину падения: 1 - истёк таймер обнаружения, 3 - сосед объявил Down, 5 - путь недоступен, 7 - сессия отключена администратором.
BFD в MPLS: что именно контролируется
Для обычных клиентов BFD вешается на интерфейс: BFD for OSPF/IS-IS/BGP/static ловит отказ линка и соседа за миллисекунды, а LDP-сессия падает следом, потому что сходится IGP. Отдельно существует BFD для LSP (RFC 5884, уточнён RFC 7726): ingress отправляет BFD Control внутри метки LSP с адресом назначения из 127/8, UDP-порт 3784 и TTL 1, а egress отвечает обычным IP-пакетом. Сессия запускается через LSP ping: в Echo Request добавляется BFD Discriminator TLV (тип 15), egress узнаёт дискриминатор ingress и поднимает ответную половину. Контролируется только прямое направление LSP: обратный путь идёт по IP. Такой BFD обнаруживает "тихие" отказы data plane, при которых LDP/RSVP и IGP исправны, а пересылка по метке сломана.
Для псевдопроводов существует BFD поверх VCCV (RFC 5885): тип контрольного канала и тип проверки согласуются при установке PW; CV-типы 0x04 и 0x08 - BFD в IP/UDP (без и со статусом AC/PW), 0x10 и 0x20 - BFD в PW-ACH. Для сегментной маршрутизации существует S-BFD (RFC 7880): отражатель с заранее выданным дискриминатором, без трёхстороннего обмена. BFD проверяет только тот путь, по которому идёт сам: он не знает про VPN-метку и таблицу VRF клиента.
MPLS-TP: транспортный профиль
MPLS-TP (RFC 5921, требования RFC 5654) - подмножество MPLS с поведением транспортной сети в духе SDH/OTN. Здесь нет IP-пересылки в плоскости данных, нет ECMP и слияния LSP, пути (LSP и PW) создаёт система управления вручную либо GMPLS RSVP-TE, а не LDP; LSP всегда двунаправленные, обычно co-routed (оба направления идут одним маршрутом). Идентификация узлов использует Global_ID и Node_ID (RFC 6370), а не IP-адрес.
