Теоретические основы и архитектура
Базовый FRR из предыдущих уроков закрывает один отказ линка, но в реальной сети вопросов больше: чем отличается facility backup от one-to-one detour на уровне меток, что делает merge point, когда нужна защита узла, а не линка, и как сигнализируются P2MP-деревья для рассылки одного потока многим получателям. Отдельная задача - TE между областями и автономными системами: база TED каждой области изолирована, и голова не может посчитать путь целиком, поэтому ERO содержит loose-хопы, а путь на каждом участке считает ABR или ASBR. Урок разбирает FRR по RFC 4090 (флаги, RRO, метки при обходе), P2MP RSVP-TE по RFC 4875, межобластной и междоменный TE (RFC 5151, роль PCE), а также re-optimization по схеме make-before-break и SRLG для общих рисков. Предполагается, что вы уже знаете основы RSVP-TE, CSPF и базовый FRR (bypass-туннель, PLR, MP) из этого модуля.
Что закрывает базовый FRR, а что нет
Базовый урок о FRR показал bypass-туннель вокруг линка и PLR/MP. Здесь разберём детали RFC 4090, без которых защита узла, ECMP-варианты и междоменные случаи непонятны. Голова запрашивает защиту двумя способами. В объекте SESSION_ATTRIBUTE флаги: 0x01 local protection desired, 0x02 label recording desired, 0x04 SE style desired, 0x08 bandwidth protection desired, 0x10 node protection desired. В объекте FAST_REROUTE (RFC 4090) - режим: 0x01 one-to-one backup desired, 0x02 facility backup desired, плюс приоритеты setup/hold для резервного пути, hop limit и опционально bandwidth. Каждый хоп добавляет в RRO подобъект с адресом и (при label recording) меткой, а также флагами: 0x01 local protection available, 0x02 local protection in use, 0x04 bandwidth protection, 0x08 node protection. По этим флагам видно на любом хопе, защищён ли LSP и чем.
Facility backup: метки на практике
Facility-bypass - один туннель на защищаемый ресурс (линк или узел) для всех LSP через него. Пусть PLR = P1, защищаемый линк P1-PE2, MP = PE2, bypass идёт P1-P2-PE2 с меткой bypass B. Основной LSP принят PLR с меткой на входе и должен уйти к PE2 с меткой L (её назвал PE2). При отказе PLR выполняет swap на L и кладёт поверх B: пакет уходит со стеком [B, L]. Следующий за P1 узел обходного пути меняет B и, как предпоследний хоп bypass, снимает (PHP), так что PE2 получает пакет с одной меткой L, будто линк цел. Для защиты узла (NHOP/NNHOP) MP - уже узел через один, и PLR обязан знать метку L, которую MP ждёт от следующего за защищаемым узла; он берёт её из RRO основного LSP, поэтому label recording необходим. Один bypass NNHOP защищает все LSP, идущие через пару PLR - защищаемый узел - MP, и состояние растёт с числом ресурсов, а не LSP: в этом основной довод в пользу facility.
One-to-one detour
В схеме one-to-one каждый PLR вдоль пути строит отдельный detour LSP на каждый защищаемый LSP (RFC 4090 раздел 3). У detour свои метки на каждом хопе, стек не нужен, MP либо конечный узел, либо merge point - узел, где detour подключается к основному LSP или к другому detour. Слияние выполняется в общей сессии RSVP (стиль shared explicit через detour-объекты), чтобы одно и то же состояние не учитывалось дважды в резервировании полосы. Плюсы: нет стека меток (проще для платформ с ограничениями на глубину), защита каждого LSP индивидуально настраивается, включая полосу. Минусы: состояния растёт пропорционально числу LSP и длине пути; при тысячах LSP это тысячи detour на каждом PLR, поэтому в крупных сетях преобладает facility. На практике Juniper по умолчанию строит detour (fast-reroute), а link-protection на интерфейсе RSVP даёт facility-bypass; Cisco IOS-XE реализует facility.
Link или node protection и поведение merge point
Link protection (NHOP) обходит только линк: MP - соседний узел, и отказ самого соседа не покрыт. Node protection (NNHOP) обходит и узел, и линк: bypass заканчивается на узле через один. NNHOP требует топологии, где такой путь существует без общего риска, и метки из RRO. Если NNHOP-bypass нет, большинство платформ откатывается к NHOP; поэтому после включения защиты проверяйте в базе FRR тип защиты на каждом PLR. Поведение на MP: он принимает пакет по метке основного LSP, сначала ничего не меняет, а получив Path с обходного интерфейса (другой PHOP), обновляет состояние и в Resv отвечает по обходному пути. После отказа голова получает PathErr с кодом Notify (код ошибки 25, значение 3 - tunnel locally repaired) и начинает замену LSP.
P2MP RSVP-TE (RFC 4875)
P2MP LSP - дерево от одного корня (ingress) к листьям (egress). Каждая пара корень-лист называется S2L sub-LSP. Ключевая идея: дерево сигнализируется как набор sub-LSP в одной сессии, с объектом S2L_SUB_LSP на каждый лист в Path; branch-узлы реплицируют пакеты на несколько исходящих интерфейсов, поэтому одна копия потока на общем участке, а не по копии на получателя. Добавление и удаление листа не прерывает остальные: sub-LSP добавляется отдельным Path. Каждый sub-LSP может задаваться explicit-путём или считаться CSPF; общие участки пути sub-LSP разделяют ресурсы. Применение: transport для mVPN (профили с P2MP RSVP-TE), IPTV и другая рассылка на сети оператора, где важны гарантированная полоса и FRR для рассылки. Защита FRR действует и здесь, но bypass для sub-LSP строится на каждый исходящий линк ветви. Ограничения: ёмкость replication на линейных картах, число sub-LSP и размер состояния на ingress растут с числом листьев; сеть с сотнями листьев нередко переходит на mLDP или Segment Routing. Конфигурация и платформа: на Juniper sub-LSP задаётся p2mp <имя> у label-switched-path, на Cisco - destination list и режим point-to-multipoint на туннеле.
