Теоретические основы и архитектура

Лабораторная: MPLS Fast Reroute (FRR, RFC 4090) в ядре RSVP-TE. При обрыве линка полное восстановление от головного узла (PathErr до ingress PE, пересчёт CSPF, сигнализация нового LSP) занимает от сотен миллисекунд до секунд и зависит от времени обнаружения и числа туннелей. FRR сокращает это время: резервный путь рассчитывается и сигнализируется заранее, а переключение выполняет узел, ближайший к отказу, - Point of Local Repair (PLR). Есть два варианта: 1. One-to-One (Detour): отдельный detour-LSP на каждый защищаемый туннель. 2. Facility Backup (bypass-туннель): один общий bypass защищает линк (link protection) или следующий узел (node protection) для многих LSP; это наиболее распространённый вариант. При отказе PLR переключает трафик в bypass, добавляя внешнюю метку bypass. Цель переключения - десятки миллисекунд, но реальное время зависит от способа обнаружения отказа (LOS, BFD) и платформы.

Почему нужен локальный ремонт

При отказе линка на пути TE LSP end-to-end восстановление идёт по цепочке: обнаружение отказа, PathErr/ResvTear к голове, повторный CSPF на голове, сигнализация нового LSP. Это от нескольких секунд и более: IGP должен сообщить изменение, а голова - пересчитать и поднять новый путь. Fast Reroute (RFC 4090) переносит ремонт в узел перед отказом: он заранее подготовил обход и переключает трафик сразу после обнаружения, не дожидаясь головы.

Роли:

  • PLR (Point of Local Repair) - узел, который видит отказ и переключает трафик в обход.
  • MP (Merge Point) - узел, где обход возвращается в защищаемый LSP.
  • Backup tunnel / bypass - LSP от PLR до MP, который обходит защищаемый элемент.
  • Защита линка (NHOP, next-hop bypass): MP - следующий узел за защищаемым линком. Защита узла (NNHOP, next-next-hop bypass): MP - узел за следующим, обход обходит сам узел. Последний узел LSP защитить как узел нельзя: после него нет MP; предпоследний узел может защищать только линк до хвоста.

Два метода

МетодКак защищаетсяМасштабОсобенность
Facility backup (bypass)один bypass-LSP защищает все LSP, проходящие через линк или узелчисло bypass-туннелей зависит от числа защищаемых элементов, а не LSPв обход идёт стек меток: основная метка + метка bypass
One-to-one backup (detour)для каждого LSP на каждом узле строится отдельный detour-LSPчисло detour растёт с числом LSP и хоповdetour сливается с основным LSP на одном из следующих узлов; нет стека

Facility backup - основной вариант в сетях провайдеров: состояние на транзитных узлах не растёт с числом LSP. Detour встречается реже и поддерживается не везде.

Что сигнализирует голова

Голова запрашивает защиту при установке LSP одним из двух способов. Через флаги SESSION_ATTRIBUTE (0x01 - local protection desired, 0x08 - bandwidth protection desired, 0x10 - node protection desired) или через объект FAST_REROUTE (RFC 4090, Class-Num 205): он добавляет setup/hold priority для backup, hop limit, bandwidth, include-any/exclude-any/include-all и флаги метода (0x01 - one-to-one, 0x02 - facility). Для NNHOP PLR нужна метка, которую назначил MP (узел за защищаемым), а узнать её можно только из RRO с метками, поэтому включается label recording (0x02 в SESSION_ATTRIBUTE).

Когда PLR действительно готов защитить LSP, он выставляет в RRO-подобъекте флаги: 0x01 - local protection available, 0x04 - bandwidth protection, 0x08 - node protection; при активном ремонте добавляется 0x02 - local protection in use. Так голова видит, что LSP защищён. FRR-флаг на туннеле без подготовленного backup не защищает ничего.

Что происходит в плоскости данных

Подготовка (до отказа): PLR выбирает backup-туннель, подходящий под защищаемый интерфейс и свойства LSP, и записывает его в FRR-таблицу: для каждого защищаемого LSP хранится пара "основная метка, исходящий интерфейс" и "метка backup".

Ремонт (после отказа): PLR (1) выбирает метку, которую ждёт MP: для NHOP это обычная исходящая метка LSP (её MP уже передал в Resv), для NNHOP - метка узла за защищаемым, она берётся из RRO с метками, (2) добавляет сверху метку bypass-туннеля и (3) отправляет пакет в интерфейс bypass. Пример для VPN-трафика PE1 -> PE2 при отказе линка PE1-P1: пакет имел стек [VPN][TE-метка к P1]; после переключения стек становится [VPN][метка, которую ждёт P1][метка bypass]. Транзитный P2 - предпоследний узел bypass: он снимает метку bypass (PHP), поэтому P1 получает пакет с обычной меткой защищаемого LSP и не знает о ремонте. Все изменения идут в аппаратной таблице: вычисления и сигнализации в момент отказа нет.

Пока трафик идёт по обходу, стек на один уровень глубже (плюс 4 байта на пакет), поэтому MTU ядра должен учитывать запас под метку bypass.

Обнаружение отказа и время

Ремонт выполняется за доли секунды только после обнаружения. Источники:

  • потеря сигнала (LOS) на оптическом интерфейсе: единицы-десятки миллисекунд; на линках через транспортную сеть или L2-коммутатор сигнал не пропадает, и отказ невидим;
  • BFD на линке (интервал 50 мс, множитель 3 даёт около 150 мс);
  • RSVP Hello (RFC 3209): секунды; Junos по умолчанию hello-interval 9 с, keep-multiplier 3;
  • IGP (hello/dead): десятки секунд без тюнинга; без BFD ремонт откладывается до IGP.

Цифра "менее 50 мс" - целевое значение проектирования для переключения в FIB, а не гарантия: итоговое время равно обнаружению плюс программированию. Без потерь не бывает: пакеты, находящиеся в линке в момент отказа, будут потеряны.

После ремонта

PLR отправляет голове PathErr с Error Code 25 (Notify) и subcode 3 (Tunnel locally repaired). Голова в ответ перестраивает LSP по новому пути (make-before-break) и сбрасывает старый; пока этого не произошло, трафик идёт через bypass, и LSP в состоянии repaired не защищён от следующего отказа в той же зоне (двойной отказ). Голова пересчитывает путь только после получения обновления IGP, до этого трафик остаётся на bypass; не отключайте re-optimization.

QoS и полоса: bypass может резервировать полосу (bandwidth protection, Cisco bw-protect, Junos через bandwidth bypass): без неё обходной путь не гарантирует, что в нём хватит ёмкости для всех LSP, и трафик в ремонте может испытывать перегрузку. Резервация полосы под bypass не заменяет контроль нагрузки и должна быть согласована с политикой.

Конфигурационные модели

  • Cisco: bypass - обычный TE-туннель к MP (адрес router-id), привязанный к защищаемому интерфейсу командой mpls traffic-eng backup-path TunnelN; головной туннель включает fast-reroute. Путь bypass задаётся exclude-address или явным путём; без autoroute bypass не принимает обычного трафика.
  • Huawei: bypass-туннель (mpls te bypass-tunnel) с mpls te protected-interface, основной туннель включает mpls te fast-reroute.
  • Junos: link-protection на RSVP-интерфейсе PLR создаёт bypass автоматически через CSPF (исключая защищаемый линк), на LSP link-protection (facility) или node-link-protection просит защиту; fast-reroute на LSP - это метод detour.

Типовые отказы

  • Нет bypass: FRR-флаг включён, но backup не поднят (путь не нашёлся, ограничения несовместимы).
  • Bypass проходит через тот же SRLG или линк-партнёр: при отказе падают оба.
  • Отказ не обнаружен: линк через L2/транспорт, BFD не включён.
  • Не включён label recording/RRO: NNHOP не может определить метку MP.
  • Не хватает MTU: пакеты с дополнительной меткой фрагментируются или отбрасываются.
  • Сервис остаётся на bypass после восстановления, потому что голова не выполнила re-optimization.

Схема архитектуры и топология

text
           primary LSP (protected link)
+---------+ ====================X====================> +--------+ ====> tail
| PLR     |        failed link                         | MP     |
| (PE-1)  |                                            | (P-1)  |
+---------+ ===> [bypass LSP around the link] =======> +--------+
  Link protection: the MP is the next node after the protected link.
  Node protection: the MP is the node after the next one; the bypass avoids the next node.

Схема прохождения трафика и стек меток

text
FRR facility backup, link protection:
1. The head-end signals the primary LSP asking for local protection (SESSION_ATTRIBUTE flags).
2. The PLR (PE-1) uses a pre-signaled bypass tunnel that avoids the protected link and ends at the merge point (MP).
3. The PLR prepares the backup next hop in its forwarding plane before any failure.
4. A failure is detected (loss of signal, BFD or other detection).
5. The PLR switches the LSP into the bypass: it swaps the label to the one the MP expects and pushes the bypass label.
6. The penultimate node of the bypass pops the bypass label (PHP), so the MP receives the packet with its normal LSP label.
7. The PLR notifies the head-end (PathErr/Resv with notification) and the head-end re-optimizes make-before-break.

Таблица состояний и параметров