Высокоскоростные корпоративные магистрали и распределенные сети Anycast VPN требуют гибкого управления трафиком и восстановления после сбоев менее чем за одну секунду. На протяжении двух десятилетий многопротокольная коммутация по меткам (MPLS) служила основой для инженерии трафика и сервисов виртуальных частных сетей 3-го уровня (L3VPN).

Однако классический стек MPLS создает колоссальную эксплуатационную сложность. Одновременная поддержка протокола распределения меток (LDP), резервирования ресурсов для инженерии трафика (RSVP-TE) и сессий целевого BGP вынуждает промежуточные маршрутизаторы хранить тысячи параметров состояний в аппаратной памяти.

Для устранения этой перегрузки инженерная группа IETF стандартизировала протокол Segment Routing over IPv6 (SRv6) в документах RFC 8402, RFC 8754 и RFC 8986. Объединяя плоскость управления и плоскость передачи данных непосредственно внутри стандартных пакетов IPv6, SRv6 обеспечивает маршрутизацию от источника без сохранения состояний на промежуточных узлах, гибкое программирование сети и детерминированную защиту от аварий менее чем за 50 миллисекунд благодаря технологии TI-LFA (Topology-Independent Loop-Free Alternate).

Кризис сложности MPLS: необходимость единой плоскости данных IPv6

Традиционные сети MPLS отделяют коммутацию меток от базовой IP-маршрутизации. В современных распределенных облачных инфраструктурах это разделение приводит к серьезным эксплуатационным барьерам:

  1. Разрастание стека протоколов: Сетевым инженерам приходится запускать внутренний протокол маршрутизации IGP (OSPF/IS-IS), протокол LDP для связывания меток, RSVP-TE для резервирования путей и MP-BGP для передачи клиентских маршрутов VPN.
  2. Перегрузка промежуточных узлов состояниями: При использовании RSVP-TE каждый маршрутизатор на пути туннеля хранит отдельные состояния. В сетях с десятками тысяч туннелей память оборудования исчерпывается, а время сходимости при сбоях резко возрастает.
  3. Фрагментация инкапсуляции: Трафик MPLS не способен преодолевать стандартные транзитные сети IP без дополнительного оборачивания в туннели GRE или UDP, что усложняет мониторинг и телеметрию.

SRv6 заменяет многоуровневый сложный стек единым нативным протоколом — стандартным IPv6. Пакеты несут полные инструкции по маршрутизации внутри компактного расширенного заголовка, позволяя стандартным маршрутизаторам обрабатывать транзитный трафик по классическому правилу наибольшего совпадения префикса (LPM).

Архитектура сетевого программирования SRv6: основы стандарта RFC 8986

Стандарт RFC 8986 формализует концепцию сетевого программирования: сетевой маршрут выражается в виде упорядоченного списка инструкций, закодированных непосредственно в адресе IPv6.

Вместо поддержания сложных таблиц туннелей на каждом узле, пограничный маршрутизатор входа кодирует полный путь следования пакета в последовательность 128-битных идентификаторов сегментов (Segment Identifiers — SID). По мере движения пакета по магистрали каждый узел с поддержкой SRv6 считывает активный SID, выполняет ассоциированную инструкцию и переходит к следующему сегменту.

Анатомия 128-битного SID: структура Locator, Function и Arguments

Идентификатор сегмента SRv6 SID полностью повторяет 128-битную структуру стандартного адреса IPv6 и подразделяется на логические компоненты:

$$ ext{SRv6 SID (128 bits)} = ext{Locator} ,|, ext{Function} ,|, ext{Arguments}$$

  • Locator ($L$ бит): Префикс IPv6, выделенный конкретному сетевому узлу. Промежуточные транзитные маршрутизаторы направляют пакет к этому узлу по кратчайшему пути IGP (IS-IS или OSPFv3), даже если они не поддерживают SRv6.
  • Function ($F$ бит): Код операции (opcode), определяющий действие, которое узел должен выполнить (например, переслать в интерфейс X, декапсулировать в таблицу VRF Y или передать на фильтрацию).
  • Arguments ($A$ бит): Необязательные аргументы функции, такие как идентификаторы потоков или метки качества обслуживания.

Например, при использовании локатора /64 и 16-битной функции адрес 2001:db8:acad:1:: идентифицирует шлюз, а 2001:db8:acad:1:0042:: предписывает шлюзу выполнить функцию 0x0042 (направление трафика в изолированную таблицу маршрутизации VPN).

Заголовок Segment Routing (SRH): структура пакета по стандарту RFC 8754

Для передачи упорядоченного списка сегментов RFC 8754 определяет расширенный заголовок маршрутизации IPv6 Segment Routing Header (SRH, Routing Type 4):

+-------------------------------------------------------------------+
| Next Header (8) | Hdr Ext Len (8) | Routing Type (4) | Segments Left (8) |
+-------------------------------------------------------------------+
| Last Entry (8)  | Flags (8)       | Tag (16)                             |
+-------------------------------------------------------------------+
| Segment List[0] (128 бит - Финальный целевой SID)                 |
+-------------------------------------------------------------------+
| Segment List[1] (128 бит - Промежуточный рабочий SID)             |
+-------------------------------------------------------------------+
| Segment List[2] (128 бит - Начальный транзитный SID)              |
+-------------------------------------------------------------------+

Основные поля управления включают:

  • Segments Left (SL): Указатель на индекс следующего активного сегмента в списке.
  • Segment List: Массив 128-битных адресов IPv6, записанных в обратном порядке относительно их выполнения (сегмент с индексом Last Entry исполняется первым, а сегмент с индексом 0 — последним).

При передаче пакета адрес назначения IPv6 всегда содержит активный SID. По прибытии на соответствующий узел маршрутизатор уменьшает значение Segments Left, копирует следующий адрес из Segment List[SL] в поле адреса назначения IPv6 и пересылает пакет дальше.

Парадигма маршрутизации от источника: устранение промежуточных состояний в сети

SRv6 переносит весь управляющий интеллект на границу сети. Входной шлюз анализирует требования политики передачи — на основе задержки, доступности каналов или соглашений об уровне сервиса — и внедряет список SID в заголовок пакета.

Эта архитектура обеспечивает фундаментальные преимущества:

  • Отсутствие состояний в ядре сети: Промежуточные маршрутизаторы поддерживают только стандартную маршрутизацию IPv6 для локаторов. Им не требуется хранить записи о туннелях, резервировании полосы или метках MPLS.
  • Точное соблюдение маршрутных политик: Входной узел может направить пакет через конкретных транзитных операторов или каналы с минимальной задержкой путем добавления соответствующих сегментов.
  • Совместимость с существующей инфраструктурой: Узлы сети, не поддерживающие расширения SRv6, продолжают пересылать пакеты на основе обычного префикса локатора в адресе назначения IPv6, что обеспечивает плавную поэтапную модернизацию.

Быстрое переключение TI-LFA: детерминированное резервирование до 50 мс без RSVP-TE

Аварии на магистральных линиях связи могут нарушать передачу чувствительного к задержкам трафика. Классическая сходимость протоколов IP занимает сотни миллисекунд, требуя обнаружения обрыва, рассылки обновлений IGP и полного пересчета таблиц маршрутизации.

Технология Topology-Independent Loop-Free Alternate (TI-LFA) гарантирует автоматическое детерминированное переключение менее чем за 50 миллисекунд для любых топологий сети:

  1. Предварительный расчет резервных путей: Маршрутизаторы заранее рассчитывают альтернативные маршруты на основе алгоритма Дейкстры с учетом состояния сети после будущей сходимости.
  2. Предотвращение петель: В отличие от классического LFA (RFC 5286), который не работает в сложных топологиях из-за риска зацикливания пакетов соседними узлами, TI-LFA точно моделирует итоговый маршрут.
  3. Использование сегментов перенаправления: При сбое линии маршрутизатор применяет сегменты SRv6, чтобы направить поток минуя аварийный участок к узлу схождения ($Q$-node), откуда пакет штатно доходит до адресата.

В момент аппаратной фиксации аварии сетевая плата немедленно инкапсулирует пакеты в предварительно рассчитанный список сегментов TI-LFA. Защитное переключение выполняется на аппаратном уровне за время менее 50 мс, полностью исключая микропетли и минимизируя потери данных.

Отображение сервисов SRv6: инкапсуляция оверлеев L3VPN и Anycast

Спецификация RFC 9252 описывает, как протокол MP-BGP распространяет информацию о сервисах оверлейных виртуальных сетей поверх инфраструктуры SRv6. Вместо традиционных 32-битных меток MPLS VPN, протокол BGP анонсирует функциональные идентификаторы SRv6 SID:

  • End.DT4 / End.DT6: Принимающий шлюз снимает внешний заголовок IPv6 и направляет внутренний пакет IPv4 или IPv6 в указанную таблицу виртуальной маршрутизации (VRF).
  • End.DX4 / End.DX6: Декапсулирует пакет и передает трафик напрямую в выделенный клиентский интерфейс связи.
  • Anycast SID: Единый локатор, анонсируемый сразу из нескольких географически распределенных узлов Anycast. Трафик к Anycast SID автоматически поступает на ближайший доступный шлюз.

Такой механизм упрощает магистраль распределенных VPN, исключает использование LDP и гарантирует строгую изоляцию пользовательских потоков данных.

Накладные расходы MTU и Micro-SID (uSID): устранение разрастания заголовков IPv6

Каждый 128-битный SID внутри заголовка SRH увеличивает размер пакета на 16 байт. Маршрутная политика, содержащая список из 4 сегментов, добавляет 64 байта данных сегментов плюс 8 байт базового заголовка SRH, увеличивая заголовок пакета на 72 байта.

Для предотвращения фрагментации и снижения накладных расходов применяются две ключевые методики:

  1. Механизм Micro-SID (uSID): Стандарт сжатия заголовков объединяет несколько коротких 16- или 32-битных инструкций внутри одного общего 128-битного контейнера адреса IPv6. Это позволяет разместить до 6 инструкций сегментов в одном адресе, сокращая накладные расходы расширенных заголовков более чем на 75%.
  2. Автоматическое ограничение MSS (MSS Clamping): Шлюзы корректируют значение максимального размера сегмента при согласовании TCP SYN, гарантируя, что клиентские пакеты не превысят Path MTU магистрали.

Вопросы безопасности: ограничение доверенного домена SRv6 на границе сети

Поскольку инструкции маршрутизации в SRv6 закодированы прямо в адресе назначения, несанкционированные внешние пакеты с внутренними SID могли бы активировать системные функции шлюзов или вызвать перенаправление трафика.

Стандарты RFC 8754 и RFC 8986 четко определяют границы Доверенного домена SRv6 (SRv6 Trusted Domain) — замкнутого периметра сети, в котором пакеты SRv6 создаются, проверяются и обрабатываются.

Проверка подписи HMAC и предотвращение модификации заголовка SRH

Раздел 2.1 стандарта RFC 8754 определяет опциональное поле HMAC TLV в заголовке SRH. С использованием предварительно настроенных криптографических ключей пограничные маршрутизаторы формируют цифровую подпись:

  • Входной шлюз вычисляет криптографический хеш HMAC для списка SID и критических полей заголовка IPv6.
  • Узлы применения политик верифицируют подпись перед исполнением защищенных инструкций.
  • Пакеты с искаженными SID или некорректным значением HMAC немедленно отбрасываются сетевыми процессорами на полной скорости порта.

Пограничная фильтрация через BCP 38 для защиты от внедрения внешних SID

Периметральные межсетевые экраны и пограничные маршрутизаторы обязаны применять строгие фильтры доступа:

  1. Входная фильтрация: Уничтожение любых входящих из публичного интернета пакетов, содержащих заголовок SRH или адресованных к внутренним префиксам локаторов.
  2. Очистка на выходе: Полное удаление заголовков SRH перед выпуском пакетов за пределы доверенной магистрали для исключения утечки внутренней топологии.
  3. Защита от спуфинга адресов: Внедрение правил фильтрации источников BCP 38 / RFC 2827 для блокировки пакетов с поддельными адресами внутренних шлюзов.

Магистральная сеть Anycast RiceGuard: детерминированная архитектура SRv6

VPNRice использует сетевую матрицу RiceGuard Уровня 3 для связи глобальных точек присутствия Anycast через ведущих операторов Tier-1. В географически распределенных сетях сбои у провайдеров транзита могут вызывать непредвиденную перемаршрутизацию и разрыв соединений.

Инфраструктура RiceGuard использует протокол SRv6 для поддержания надежности и низкой задержки:

  • Резервирование TI-LFA: Магистральные маршрутизаторы применяют автоматическую защиту TI-LFA, переводя аварийные каналы на резервные оптические трассы быстрее чем за 35 миллисекунд.
  • Бесситуационная маршрутизация: RiceGuard динамически внедряет micro-SID в трафик Anycast, уводя пакеты от перегруженных транзитных каналов без хранения состояний на узлах ядра.
  • Плавное переключение узлов: Пользовательские сессии плавно распределяются между дата-центрами при проведении регламентных работ с помощью плановых сервисных SID.
  • Контроль параметров среды: Непрерывный сбор телеметрии отслеживает границы MTU и целостность каналов. Пользователи могут проверить статус соединения на странице /what-is-my-ip.

Пользователи, заинтересованные в стабильном и защищенном подключении, могут загрузить клиентские приложения в разделе /download. Анализ балансировки трафика по параллельным каналам ECMP представлен в статье /news/gre-in-udp-rfc-8086-geneve-ecmp-hash-polarization-vpn, а аспекты устойчивости маршрутизации при перезапуске BGP рассмотрены в материале /news/bgp-graceful-restart-rfc-4724-llgr-anycast-resilience.

Практическая реализация: настройка эндпоинтов SRv6 и инкапсуляции в Linux

Ядро Linux штатно поддерживает функционал сетевого программирования SRv6 и инкапсуляцию пакетов с помощью пакета iproute2. Сетевые инженеры могут настраивать логику обработки SRv6 стандартными системными утилитами.

Включение маршрутизации IPv6 и подсистемы Segment Routing:

Активируйте пересылку IPv6 и обработку seg6 на Шлюзе A:

# Включение пересылки IPv6 и активация подсистемы seg6
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv6.conf.all.seg6_enabled=1
sysctl -w net.ipv6.conf.eth0.seg6_enabled=1

Настройка инкапсуляции SRv6 на входном шлюзе:

Направьте исходящий трафик в политику SRv6 путем инкапсуляции в заголовок IPv6 со списком сегментов SRH:

# Инкапсуляция трафика к подсети 10.100.0.0/16 по маршруту SRv6
ip -6 route add 10.100.0.0/16 encap seg6 mode encap     segs 2001:db8:beef:2::,2001:db8:acad:1::     dev eth0

В этой конфигурации исходящие пакеты упаковываются в заголовок IPv6, где начальным сегментом служит 2001:db8:acad:1::, а конечной точкой маршрута — 2001:db8:beef:2::.

Настройка функции End.DT4 на выходном шлюзе:

На Шлюзе B настройте локатор для декапсуляции пакетов и передачи полезной нагрузки IPv4 в таблицу VRF:

# Привязка функции End.DT4 к локатору SID для направления в VRF
ip -6 route add 2001:db8:acad:1::/64 encap seg6local action End.DT4     vrftable 100     dev eth0

Проверка состояния туннелей SRv6 через телеметрию:

Просмотрите активные маршруты с инкапсуляцией seg6:

ip -6 route show encap seg6

10.100.0.0/16  encap seg6 mode encap segs 2 [ 2001:db8:beef:2:: 2001:db8:acad:1:: ] dev eth0 metric 1024

Проверьте структуру передаваемых пакетов утилитой tcpdump:

tcpdump -ni eth0 'ip6[6] == 43' -vv

07:18:22.410928 IP6 2001:db8:feed:1:: > 2001:db8:acad:1::: HBH, routing (type 4, segleft 1, [2] 2001:db8:beef:2::, [1] 2001:db8:acad:1::)

Вывод телеметрии подтверждает наличие расширенного заголовка SRH и корректное переключение сегментов, реализуя детерминированную маршрутизацию от источника в транзитной сети.