Миграция с LDP и TI-LFA: лабораторная

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

Лабораторная: поэтапная миграция с LDP на Segment Routing (SR-MPLS) с минимальным риском для услуг. На рабочей сети жёсткое переключение сотен узлов невозможно, поэтому миграция идёт через сосуществование LDP и SR (ships-in-the-night), SR/LDP interworking (RFC 8661) и сервер отображения Segment Routing Mapping Server (SRMS). SRMS анонсирует привязки префикс-SID от имени узлов, которые SR ещё не поддерживают, а граничные узлы сшивают сегменты SR и LDP. Когда SR-достижимость и TI-LFA проверены на всех узлах, предпочтение переключается на SR настройкой, зависящей от платформы (например, sr-prefer на Cisco). После проверки L3VPN/EVPN-сервисов и мониторинга LDP отключают. Каждый этап нужно проверять и иметь план отката: окно изменений и тесты не заменяются словом hitless.

Зачем миграция делается поэтапно

Переход с LDP на SR-MPLS нельзя выполнить за одну ночь: оборудование в разных городах обновляется по очереди, часть узлов не поддерживает SR или не имеет лицензии, а сервисы (L3VPN, EVPN, VPWS) не должны страдать. Поэтому LDP и SR сосуществуют: оба протокола заполняют LFIB, а выбор между ними делает операционная настройка предпочтения. Базовый документ - RFC 8661 (SR и LDP interworking), опирающийся на RFC 8665/8667 (IGP-расширения) и RFC 8402.

Предварительные условия

• IS-IS на wide-метриках (или OSPF с opaque LSA), единый SRGB, план индексов без повторов: резерв индексов для узлов, которые ещё не мигрировали.
• Все узлы, которые должны быть на пути SR, поддерживают SR-MPLS; MSD достаточно для планируемых стеков и TI-LFA.
• MTU ядра рассчитан на стек меток; тест крупных пакетов с DF до и после переключения.
• Резервируется диапазон меток под SRGB; убедитесь, что он не занят динамическими метками LDP или статикой.

Этапы

1. Включить SR рядом с LDP. SRGB, Prefix-SID для каждого loopback, SR в IGP. Метки SR уже в LFIB, но предпочтение остаётся у LDP: трафик не меняется. Запускается мониторинг и сверка баз SID (нет ли конфликтов).
2. Interworking через SR Mapping Server (SRMS). Для узлов, которые пока без SR, один или несколько SRMS анонсируют привязку "префикс - индекс SID" от их имени: в IS-IS это SID/Label Binding TLV 149 (флаги F, M, S, D, A; S означает флудинг по всему домену), в OSPF - Extended Prefix Range TLV с Prefix-SID и флагом M; приоритет SRMS в OSPF указывает SRMS Preference TLV. Привязка не вступает в силу на самом устаревшем узле, она позволяет остальным узлам использовать SR-метку для его префикса. Собственный Prefix-SID владельца, как правило, приоритетнее записи SRMS, но точные правила разрешения конфликтов зависят от реализации.
3. Сшивка на границе. Граничный узел с SR и LDP выполняет две операции (RFC 8661): SR к LDP - входящая SR-метка префикса устаревшего узла заменяется на LDP-метку, полученную от него; LDP к SR - для префикса SR-узла граничный узел анонсирует LDP-привязку и при получении LDP-метки подставляет SR-метку. Таким образом LSP непрерывен от PE до PE на смешанном пути.
4. Переключение предпочтения. Cisco IOS-XE: sr-label-preferred в set-attributes; Junos: SR в IS-IS (L-ISIS) имеет preference 14, LDP - 9, поэтому по умолчанию побеждает LDP, а для переключения preference LDP увеличивают (set protocols ldp preference 20); Huawei: порядок типов туннелей в tunnel-policy (tunnel select-seq sr-lsp lsp). Переключают сначала на одном PE, проверяют сервисы и только потом расширяют на домен: так работает откат за одну команду.
5. Валидация. Проверяют L3VPN/EVPN/VPWS (ping между CE), traceroute, LSP ping и traceroute для SR FEC (RFC 8287), счётчики на интерфейсах, TI-LFA (покрытие и ремонтные списки), поведение при отказе и возврате линка, MTU.
6. Удаление LDP. После выдержки (дни или недели): убрать LDP с интерфейсов (no mpls ip, no mpls ldp), затем глобально; удалить записи SRMS для мигрировавших узлов; убрать LDP-IGP sync. До этого момента LDP остаётся резервом отката.

Откат

Пока LDP не удалён, откат состоит в обратном переключении предпочтения: LFIB уже содержит LDP-метки, поэтому трафик возвращается без пересчёта IGP. Откат после удаления LDP - это повторная настройка LDP на всех линках, поэтому не ускоряйте шаг 6. Для SRMS правило: сначала включить собственные SID на узле, потом удалять его запись из SRMS.

Подводные камни

• Конфликт SID. Индекс в записи SRMS совпадает с индексом другого узла: у разных маршрутизаторов оказываются разные победители, а трафик идёт не к тому узлу. Все индексы, включая SRMS, ведутся в одной таблице.
• Единственный SRMS. Это точка отказа control plane; используют два SRMS с разным приоритетом.
• PHP и explicit-null на границе. Устаревший узел не понимает SR-метки: на последнем хопе перед ним метка должна сниматься или заменяться LDP-меткой, иначе пакет с неизвестной меткой отбрасывается.
• Preference без готовности. Переключение на SR на PE, чей путь содержит узлы без SID и без SRMS-записей, возвращает трафик на LDP частично либо вызывает потери на путях, где у граничного узла нет сшивки.
• MTU. Стек SR длиннее LDP-метки; проблема проявляется только на больших пакетах.
• TI-LFA и узлы без SR. Ремонтный путь не может проходить через узлы без Prefix-SID: покрытие остаётся неполным до окончания миграции.
• Смешанный вендор. Разные умолчания SRGB и предпочтений требуют явной проверки на каждой платформе.

Что остаётся на потом

LDP-сессии нужны, пока на сети есть узлы, получающие метки только по LDP, а также для некоторых сервисов (например, targeted LDP для pseudowire в старых конфигурациях). RSVP-TE и SR Policy на одном узле сосуществуют независимо от LDP-SR миграции.

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

+---------------------+      LDP-to-SR Interworking (SRMS)      +---------------------+
| Legacy LDP Domain   | <=====================================> | Modern SR-MPLS Core |
| Runs LDP only       |           SR Mapping Server (SRMS)      | Runs IS-IS/OSPF SR  |
| Needs SR translation|        Stitches LDP and SR Labels       | No LDP required     |
+---------------------+                                         +---------------------+

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

Segment Routing Mapping Server (SRMS) and LDP/SR stitching:
1. The SRMS advertises prefix-to-SID-index mappings on behalf of nodes that do not run SR (they only run LDP).
2. The border node has an SR label (SRGB base + index, for example 16002) for the prefix and an LDP label (from the LDP pool, for example 24005) received from the legacy neighbour.
3. SR -> LDP: the incoming SR label of the legacy node's prefix is swapped for the LDP label received from it.
4. LDP -> SR: for the prefix of an SR node the border node advertises an LDP binding; the incoming LDP label is swapped for the SR label.
5. Traffic crosses the mixed domain during the phased migration; labels differ per domain, so each border does a swap.

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