(Унесено с хабра, где было опубликовано 2024-05-23; автор — Борис Хасанов, сетевой архитектор в Яндексе)

Технологии MPLS более двадцати лет. Всё это время она широко использовалась операторами связи, а также в больших корпоративных сетях. Казалось бы, стоит ли искать «лучшее вместо хорошего»? Так, да не так.

В завершающей части нашего цикла про Traffic Engineering обсудим подробнее тему Segment Routing, к которой мы подошли в прошлый раз. И для этого нам будет нужно разобраться, что же не хватало в MPLS.

Часть 1. Основы, распределённый и централизованный расчёт туннелей, магия РСЕ

Часть 2. Основы РСЕР и Stateful PCE, Междоменный RSVP‑TE, новый взгляд на РСЕСС

Часть 3. Жизнь после MPLS

Итак, сначала был MPLS

Основные причины феноменального успеха MPLS

Но некоторые ограничения MPLS вынудили индустрию думать про что‑то ещё.

Недостатки MPLS

Да, для этих проблем были найдены обходные пути или решения: RSVP‑TE Automesh, Autobandwidth, Refresh reduction, Seamless MPLS, Inter‑AS VPN, — но сами проблемы всё равно оставались.

Поэтому в индустрии зрело мнение о том, что необходим новый подход, свободный от этих недостатков.

В 2013 году на свет появилась технология, о которой мы начали говорить в прошлый раз, — Segment Routing. Буквально это «маршрутизация сегментов», дальше по тексту будем называть её SR. Суть очень коротко заключается в том, что она:

SR прошла долгий путь за эти 10 лет, от изначального неприятия и межвендорских споров о том, например, чья имплементация MPLS лучше, — до достаточно зрелой и стабильной технологии, которая получила своё признание и место в различных сетях и была поддержана всеми основными сетевыми вендорами (с нюансами). Сейчас SR выглядит вполне достойной альтернативой классическому MPLS.

Некоторое время тому назад мы в NOC Яндекса решили, что надо двигаться в сторону SR, для чего прошли через все этапы планирования и внедрения новой технологии:

Не буду далее погружаться в теоретизирование по SR, а приведу несколько базовых примеров.

Базовая настройка SR-MPLS на маршрутизаторе Huawei: 

mpls lsr-id 192.168.200.24

segment-routing
 tunnel-prefer segment-routing  <- Задание предпочтительности выбора SR-BE  vs. LDP
 local-block 156502 159999         <- SRLB

isis 20
 is-level level-2
 cost-style wide
 network-entity 1921.6820.0024.00:00
 is-name lab2
 traffic-eng level-2
 segment-routing mpls
 segment-routing global-block 150000 156000  <- SRGB


interface LoopBack0
 ip address 192.168.200.24 255.255.255.255
 isis enable 20
 isis tag-value 20
 isis prefix-sid index 5090  <-  Задание индекса для Prefix-SID для Loopback

Просмотр Adj-SID на маршрутизаторе Huawei: 

[~lab2]dis segment-routing adjacency mpls forwarding

            Segment Routing Adjacency MPLS Forwarding Information

Label     Interface                     NextHop           Type    MPLSMtu   Mtu       VPN-Name
-------------------------------------------------------------------------------------------------------------
48083     100GE0/1/29.860    172.16.26.249   ISIS-V4     ---       9000      _public_
48084     100GE0/1/29.887    172.16.26.195   ISIS-V4     ---       9000      _public_
48085     100GE0/1/29.886    172.16.26.197   ISIS-V4     ---       9000      _public_
[SNIP]

Просмотр SR-MPLS Label Forwarding Information Base на маршрутизаторе Huawei: 

[~lab2] display segment-routing prefix mpls forwarding

                   Segment Routing Prefix MPLS Forwarding Information
             --------------------------------------------------------------
             Role : I-Ingress, T-Transit, E-Egress, I&T-Ingress And Transit

Prefix                          Label      OutLabel   Interface                NextHop          Role  MPLSMtu   Mtu     State
            -----------------------------------------------------------------------------------------------------------------
192.168.200.180/32  152860     3          100GE0/1/29.860   172.16.26.249    I&T   ---       9000    Active
192.168.200.181/32  152861     3          100GE0/1/29.861   172.16.26.247    I&T   ---       9000    Active
192.168.200.182/32  152862     3          100GE0/1/29.862   172.16.26.245    I&T   ---       9000    Active
192.168.200.183/32  152863     3          100GE0/1/29.863   172.16.26.243    I&T   ---       9000    Active
192.168.200.24 /32   155090     NULL       Loop0                    127.0.0.1             E       ---       1500    Active
[SNIP]

Просмотр LSDB на маршрутизаторе Huawei: 

[~lab2] dis isis 20 lsdb local verbose

                        Database information for ISIS(20)
                        -----------------------------------
                          Level-2 Link State Database

LSPID                  Seq Num    Checksum   HoldTime       Length   ATT/P/OL
-----------------------------------------------------------------------------
0872.5022.8232.00-00*  0x000172f6 0x36d1     32230          1165     0/0/0
 SOURCE       lab2.00
 HOST NAME    lab2
 NLPID        IPV4
 AREA ADDR    01
 INTF ADDR    192.168.200.24
 INTF ADDR    172.16.4.158
 INTF ADDR    172.16.4.126
 INTF ADDR    172.16.4.94
 [SNIP]
+NBR  ID      rr1.00  COST: 10
   Adj-Sid    48082      F:0 B:0 V:1 L:1 S:0 P:0 Weight: 0 <-  По флагам см. ниже. Вес используется для балансировки
+NBR  ID      rr1-clone.00  COST: 10
   Adj-Sid    48083      F:0 B:0 V:1 L:1 S:0 P:0 Weight: 0
[SNIP]
+IP-Extended  192.168.200.24      255.255.255.255  COST: 0          Tag: 20
   Prefix-Sid   5090       Algorithm: 0   Flag: R:0 N:1 P:1 E:0 V:0 L:0   Metric: --  <-  Алгоритм 0 – SPF (1 – Strict SPF)
 Router ID    192.168.200.24
 Router Cap   192.168.200.24 D: 0  S: 0
   Segment Routing Cap   I: 1   V: 0   SRGB Base: 150000     Range: 6001  <- Диапазон SRGB
   Segment Routing MSD   BMI: 10    <- Максимальная глубина стека меток 
   Segment Routing Local Block  Flags: 0x00  SRLB Base: 156502     Range: 3498  <- SRLB
[SNIP]

Комментарий по флагам Prefix‑SID ( R:0 N:1 P:1 E:0 V:0 L:0 — передаются в Prefix‑SID sub‑TLV):

Комментарий по флагам Adj‑SID ( F:0 B:0 V:1 L:1 S:0 P:0 — передаются в Adj‑SID sub‑TLV):

Аналогичную информацию можно посмотреть и на оборудовании других вендоров в их документации, для краткости я пропущу это в статье.

Очень быстро скажу и про SRv6: помимо первоисточников RFC 8402 и RFC 8986, а также докладов на nexthop я рекомендую прочитать книгу SRv6 Network Programming Ushering a New Era of IP Networks. Принципиальное отличие SRv6 от SR‑MPLS заключается в том, что сегмент — это IPv6-адрес, согласно RFC 8986, поделённый на две части: локатор и функцию. Локатор — это IPv6-префикс, идентифицирующий маршрутизатор, а функция — это инструкция по обработке пакета, также опционально может быть и третья часть — аргументы для функции. Таким образом SRv6 — это первая технология, реализующая на практике концепцию сетевого программирования и существенно уменьшающая нагрузку на control plane.

Вот сравнительная таблица из доклада: https://habrastorage.org/r/w1560/getpro/habr/upload_files/1e9/767/c0b/1e9767c0b80bc61b827253834f2bfe13.png [ПРИКРЕПЛЁННЫЙ ФАЙЛ]

SRv6 обладает уникальной возможностью которая не существовала ни в классическом MPLS, ни в SR‑MPLS. Так как локатор — сегмент (SID), идентифицирующий маршрутизатор, — это IPv6-префикс, то мы можем агрегировать локаторы со всех маршрутизаторов одного домена и отправлять в другой домен сети только один агрегат! Конечно, это требует тщательного планирования IPv6 адресов, примеров в литературе достаточно.

Выше я объяснил наш выбор SR‑MPLS, но мы также смотрим в сторону использования SRv6 в будущем и прорабатываем возможные сценарии, так как нам очевиден её огромный потенциал.

Естественно, для работы SRv6 (аналогично SR‑MPLS) нужны расширения для протоколов, и ниже список некоторых из них на момент написания статьи:

Внимательный читатель может заметить в списке ещё одно преимущество ISIS — в нём необходимо лишь включение поддержки IPv6-топологии, в отличие от OSPF, который требует дополнительно новый протокол OSPFv3.

Я сознательно пропускаю описание таких важных моментов технологии, как варианты Fast Reroute (FRR), Flex‑Algo, измерение производительности и OAM — они напрямую не относятся к теме статьи и нуждаются в отдельном и подробном рассмотрении.

Реализация ТЕ в Segment Routing

Обратимся к первоисточникам и разберёмся в паре терминов.

Обзор SR Policy

RFC 8402 прямо описывает модель реализации ТЕ в архитектуре Segment Routing: 

An SR Policy can be used for Traffic Engineering (TE), Operations, Administration, and Maintenance (OAM), or Fast Reroute (FRR) reasons.

Что же такое эта SR Policy, и в чём здесь развитие и отличие от предыдущего RSVP‑ТE?

Приведу формальное определение, также из RFC 8402: 

SR Policy: an ordered list of segments. The headend of an SR Policy steers packets onto the SR Policy. The list of segments can be specified explicitly in SR‑MPLS as a stack of labels and in SRv6 as an ordered list of SRv6 SIDs. Alternatively, the list of segments is computed based on a destination and a set of optimization objective and constraints (e.g., latency, affinity, SRLG, etc.). The computation can be local or delegated to a PCE server. An SR Policy can be configured by the operator, provisioned via NETCONF [ RFC6241 ] or provisioned via PCEP [ RFC5440 ]. An SR Policy can be used for Traffic Engineering (TE), Operations, Administration, and Maintenance (OAM), or Fast Reroute (FRR) reasons.

https://habrastorage.org/r/w1560/getpro/habr/upload_files/f1f/37d/a61/f1f37da610f8cbc799b18d0feffe212d.png [ПРИКРЕПЛЁННЫЙ ФАЙЛ]

Давайте на основе этой диаграммы рассмотрим, что это за конструкции и как они совмещаются вместе. Для простоты пойдём слева направо.

Сама SR Policy по RFC 9256 определяется, как кортеж (tuple) из трёх параметров:

SR Policy — это итоговая конструкция, или самая большая матрёшка, которая содержит в себе N‑конструкций следующего уровня. Такой следующей вложенной конструкцией является путь‑кандидат (candidate path, СP), их количество не ограничивается стандартом. На практике, как правило, у многих вендоров поддерживается до 64 CP — но это уже ограничение маршрутизатора. Путь‑кандидат однозначно ассоциируется только с определенной SR Policy (не может разделяться между несколькими). Из N путей‑кандидатов, которые могут быть в одной политике, в моменте активным должен быть только один, про алгоритм его выбора поговорим ниже.

Путь‑кандидат имеет несколько важных параметров, про которые я должен написать.

Таким образом, кортеж <Protocol‑Origin, Originator, Discriminator> однозначно идентифицирует путь‑кандидат в рамках одной SR Policy.

Возможны ещё другие опциональные параметры, например, имя пути‑кандидата.

Кроме перечисленных параметров, путь‑кандидат содержит в себе ещё несколько маленьких матрешек — списки сегментов (Segment List). Каждый Segment List содержит помимо самих сегментов, описывающих путь пакета от headend к endpoint, ещё и вес (weight). Вес используется для балансировки нагрузки между несколькими путями в рамках одного пути‑кандидата: либо ECMP, если вес у всех Segment List одинаков, либо weighted ECMP, если веса разные.

Путь‑кандидат остаётся активным до той поры, пока в его составе есть хотя бы один активный список сегментов (Segment List). Список сегментов остаётся активным, пока NH первого сегмента в списке находится в FIB и маршрутизатор может его разрешить (resolve), либо пока механизм мониторинга этого SL (например, S‑BFD) не определит его переход в состояние Down. Если путь‑кандидат имеет несколько активных SL, то трафик между ними будет балансироваться в зависимости от выставленного для каждого из них веса: ECMP или w/ECMP.

Какой же путь‑кандидат будет выбран активным в случае наличия нескольких? Во‑первых, в игру вступает Preference — тот, у кого она наиболее высокая, и становится активным. Если есть несколько путей‑кандидатов с одинаковой Preference — движемся дальше:

Но это ещё не всё, что мы должны знать о пути‑кандидате. Если заглянуть поглубже в его «личное дело», то можно узнать, что пути‑кандидаты бывают трёх видов:

Методы доставки SR Policy на оборудование

В предыдущем параграфе я указал, что принципиально существует три пути доставки SR Policy на оборудование:

Полагаю, вариант конфигурации через CLI/Netconf является очевидным, его темплейты описаны в вендорской документации. Как я говорил в докладах на nexthop, мы использовали этот вариант в качестве промежуточного: «разливали» конфигурации с политиками, посчитанными нашим контроллером, на РЕ через доступные средства автоматизации. Перейдём к следующему возможному варианту.

РСЕР (как бы он нам ни надоел). К сожалению или счастью, РСЕР относится к классу достаточно несложно расширяемых протоколов (опять вспомним BGP), так как использует сообщения, которые состоят из набора объектов. Они, в свою очередь, состоят из TLV и sub-TLV. Поэтому вполне логичным было предложить использовать его и для передачи SR Policy, нужны лишь некоторые расширения. Эти расширения описаны в PCEP Extensions for SR Policy Candidate Paths.

Суть заключается в новом объекте: ASSOCIATION. Черновик стандарта также использует термин SR Policy Association (SRPA). Вспомним пример из прошлой части:

Здесь записываются параметры SR Policy (или ассоциации), такие как:

SRPA‑объект также содержит следующие важные TLV:

Как видно, обязательным является только передача идентификатора пути‑кандидата, всё остальное — опционально. К сожалению, поддержка передачи имён SR Policy и пути‑кандидата на момент написания статьи — крайне слабая со стороны вендоров.

РСЕ и РСС должны сигнализировать друг другу то, что они поддерживают передачу SR Policy в РСЕР. Для этого используется SR‑POLICY‑CAPABILITY TLV, который содержится в объекте OPEN, его формат описан в секции 5.1 черновика стандарта.

Я хочу ещё отметить появление нового важного и полезного механизма, которого не было в более ранних версиях черновика стандарта, а именно: INVALIDATION TLV. С его помощью любая из сторон (РСС и/или РСЕ) может контролировать отправку трафика через LSP, в случае если с ним что‑то случилось (сбой, падение). Ранее, без механизма с INVALIDATION TLV, LSP сразу переводился в состояние Down, трафик переставал передаваться через него, и РСС переходил либо на SR‑BE с SPF, либо на резервный LSP (segment list или другой путь‑кандидат). В случае с INVALIDATION TLV LSP переходит в состояние «сброса» (drop state), т. е. LSP остается в статусе Up, но его трафик сбрасывается headend»ом. Это т. н. поведение «Drop‑upon‑Invalid», описанное в секции 8.2 RFC 9256.

Читатель задаст резонный вопрос: зачем такие сложности, что вы тут «намутили», товарищи? Эта сложность нужна там, где необходимо, чтобы определённый сервис, крайне чувствительный к SLA/SLO, передавался по строго определенному пути с какими‑то заданными ограничениями, например, минимальная задержка, либо не передавался вообще.

Возможные причины попадания LSP в это состояние:

Чуть позже мы ещё подробнее скажем про важность для SR Policy специального типа сегмента, называемого Binding SID (BSID). Сейчас же просто отметим, что в SRPA‑объекте нет никакой информации про него. Действительно, он посылается с РСЕ на РСС другим образом, посредством TE‑PATH‑BINDING TLV (тип 55, LSP объект). Это описано в RFC 9604 Carrying Binding Label/Segment Identifier (SID) in PCE‑based Networks.

BGP — третий протокол, который может быть использован для доставки SR Policy. Для этого придумали отдельную SAFI (BGP SR, 73), используемую с AFI 1 (IPv4) или AFI 2(IPv6) для SR‑MPLS и SRv6 соответственно. Реализация описана в RFC 9830 Advertising Segment Routing Policies in BGP.

Появился новый параметр под названием Distinguisher, 4-байтное значение, которое делает SR Policy уникальной в контексте кортежа <color, endpoint>. Более конкретно — он делает уникальными пути‑кандидаты одной SR Policy либо SR Policies с одинаковыми кортежами <color, endpoint>, но с разными headend»ами.

Также видим Policy Color, 4-байтное значение идентифицирующее endpoint, так как трафик, имеющий BGP Color Community с таким же цветом будет отправляться этому endpoint. Про это поговорим отдельно в разделе про отправление трафика в SR Policy.

Надо сфокусировать внимание на том, что сам сегмент (SID) передаётся в Segment Sub‑TLV. RFC 9256 определяет несколько типов (А‑К) сегментов, и чтобы окончательно не заплутать, упомяну лишь два основных:

Остальные можно найти в секции 2.4.4.2 RFC 9256.

Стоит сделать небольшое отступление в сторону SRv6. Теперь стало совершенно очевидным, что SRv6 Policy будет представлять собой набор, стек IPv6-адресов. Как же должен выглядеть IPv6-пакет с этими адресами, где они все должны размещаться?

Для ответа на вопрос обратимся к RFC 8754, который описывает новый тип IPv6 Routing Header, называемый IPv6 Segment Routing Header (SRH).

При прохождении пакета из SRH (снизу вверх) берётся SID и записывается в поле DA внешнего IPv6-заголовка, а также уменьшается счётчик Segments Left.

А если нам надо описать достаточно длинный путь, например, с MSD == 10, то у нас будет 10 IPv6-префиксов в SRH? Как насчёт эффективности?

Ответ: да, будет 10 IPv6-префиксов. Для повышения эффективности в случае ТЕ на SRv6 и SRH используется т. н. «компрессия» SRH. В IETF была создана специальная design team, которая должна была на основе консенсуса сделать один общий вариант. В итоге он был описан в черновике стандарта RFC 9800 Compressed SRv6 Segment List Encoding и теперь предлагается использовать два подхода (Flavors) для этого:.NEXT‑C-SID, REPLACE‑C-SID.

Вернёмся к BGP SR.

Кто посылает SR Policy на headend в случае BGP SR? В отличие от варианта с РСЕР, тут может быть три варианта:

На Headend программный компонент SR Policy Manager (SRPM), получив одинаковые SR Policy из одного или нескольких источников, выбирает одну из них на основе значения Protocol Origin для инсталляции в FIB и передачи трафика через неё.

Какой из трёх вариантов более предпочтителен? Ответ, как обычно: It depends. Всё зависит от конкретной ситуации. Например, если у вас нет контроллера, создающего динамические политики с путями‑кандидатами, то ответ будет очевидным: CLI/Netconf.

Если же контроллер есть, то ситуация будет более сложная: необходимо понять, какие варианты он поддерживает: PCEP, BGP или оба? Какие варианты поддерживает ваше оборудование? Какие ограничения есть с обеих сторон?

Открытых вопросов много, приведу общие соображения на основе полученного опыта:

Передача трафика через SR Policy

Секция 8 RFC 9256 определяет несколько вариантов передачи трафика через SR Policy, от простых до достаточно сложных. Я перечислю их:

Теперь будет уместно сравнить SR Policy с перечисленными выше способами передачи трафика через RSVP‑TE LSP и убедиться в огромной разнице и намного большей гибкости в случае SR Policy.

BSID — специальный сегмент, дающий невероятные возможности

Я решил специально остановиться на Binding SID и на том, что он может нам дать. Давайте вспомним его определение из RFC 8402:

In order to provide greater scalability, network capacity, and service independence, SR utilizes a Binding SID (BSID). The BSID is bound to an SR Policy, instantiation of which may involve a list of SIDs Any packets received with an active segment equal to BSID are steered onto the bound SR Policy.

Это очевидно специальный SID, авторы RFC придумали для него потрясающее применение — при его получении РЕ «разворачивает» его в новый стек сегментов. Таким образом, мы можем преодолевать любые имеющиеся ограничения на глубину стека меток (MSD). Вот пример такого использования на основе моих тестов.

https://habrastorage.org/r/w1560/getpro/habr/upload_files/f0e/6b3/b5b/f0e6b3b5b80f86fc09e50d712f68e29a.png [ПРИКРЕПЛЁННЫЙ ФАЙЛ]

Сравнение SR Policy и RSVP-TE

Достаточно сложно сравнивать такие различные технологии, тем не менее, я попытаюсь.

Функциональность

RSVP‑TE

SR Policy

Необходимость специального протокола для сигнализации LSP

Да, RSVP

Нет

Наличие forwarding (soft) state на промежуточных (Р) маршрутизаторах

Да, количество состояний пропорционально количеству LSP

Нет

Наличие встроенного механизма (протокола) для резервирования полосы

Да, RSVP

Нет, РСЕ должен отвечать за это

Необходимость поддерживать forwarding (soft) state на промежуточных (Р) маршрутизаторах

Да, необходим обмен Path/Resv сообщениями (либо поддержка Refresh Reduction)

Нет

Поддерживаемый тип ТЕ

Распределённый, централизованный

Распределённый, централизованный

Тип LSP

Симплексный, точка‑точка

Симплексный, иерархический N Segment Lists → N Candidate Paths→ N SR Policies

Междоменный LSP

Да, с определёнными сложностями

Да, существенно легче организуемый

Поддержка Stateful РСЕ

Да

Да

Протокол для взаимодействия с РСЕ

Только РСЕР

PCEP+BGP+Netconf

Встроенная поддержка балансировки трафика

Нет

Да (ECMP/wECMP)

Возможность расширять глубину стека меток

Нет

Да, с помощью BSID

Поддержка защиты

Да: HSB, защита линка и узла

Да: резервные SL, резервные СР

Управляемость и контролируемость

Сложная

Более лёгкая

Развитие технологии вендорами

Нет

Да, очень активно

Поддержка вендорами

Все основные вендоры

BGP для SR‑MPLS: Все основные вендоры

PCEP для SR‑MPLS: три из четырех.

Для SRv6 — надо тестировать.

Выводы делайте сами.

Quo vadis или камо грядеши?

В заключение постараюсь кратко обрисовать основные на момент написания статьи тенденции в развитии ТЕ и связанных технологий на основе обсуждений в IETF. На каких вопросах фокусируется экспертное сообщество:

Подводя итог: идёт нормальная работа по оптимизации и доведения до стабильно работающего состояния имеющихся технологий, появляется что‑то новое типа BGP‑CT, сетевых слайсов и т. д. Видимо, достаточно скоро встанет вопрос с использованием AI.

На этом позвольте закончить, если найдёте приведенную здесь информацию полезной, я буду очень рад.

LecturesCMC/LinuxNetwork2026/Six/YandexTEEvolution/03_BeyondMPLS (последним исправлял пользователь ArsenyMaslennikov 2026-06-30 00:38:37)