Високошвидкісні корпоративні магістралі та розподілені мережі 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-маршрутизації. У сучасних розподілених хмарних середовищах це розмежування породжує суттєві труднощі:
- Розростання стека протоколів: Мережевим інженерам доводиться підтримувати внутрішній протокол маршрутизації IGP (OSPF/IS-IS), протокол LDP для прив'язки міток, RSVP-TE для захисту каналів та MP-BGP для передачі маршрутів клієнтів.
- Перевантаження проміжних вузлів станами: При використанні RSVP-TE кожен маршрутизатор уздовж тунелю зберігає окремий стан. У мережах з десятками тисяч тунелів апаратна пам'ять вичерпується, а час збіжності при збоях різко зростає.
- Фрагментація інкапсуляції: Трафік 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 мілісекунд для будь-яких топологій мережі:
- Попередній розрахунок резервних шляхів: Маршрутизатори заздалегідь розраховують альтернативні маршрути за алгоритмом Дейкстри з урахуванням стану мережі після майбутньої збіжності.
- Запобігання петлям: На відміну від класичного LFA (RFC 5286), що не працює в складних топологіях через ризик зациклення пакетів сусідніми вузлами, TI-LFA точно моделює підсумковий маршрут.
- Використання сегментів перенаправлення: У разі збою лінії маршрутизатор застосовує сегменти 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 байти.
Для запобігання фрагментації та оптимізації смуги пропускання застосовують два ключові заходи:
- Механізм Micro-SID (uSID): Стандарт стиснення заголовків об'єднує кілька коротких 16- або 32-бітних інструкцій усередині одного спільного 128-бітного контейнера адреси IPv6. Це дозволяє розмістити до 6 інструкцій сегментів в одній адресі, зменшуючи накладні витрати розширених заголовків більш ніж на 75%.
- Автоматичне обмеження MSS (MSS Clamping): Шлюзи коригують значення максимального розміру сегмента під час узгодження TCP SYN, гарантуючи, що клієнтські пакети не перевищать Path MTU магістралі.
Безпекові аспекти: обмеження довіреного домену 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
Периметральні брандмауери та прикордонні маршрутизатори зобов'язані застосовувати суворі фільтри доступу:
- Вхідна фільтрація: Знищення будь-яких вхідних із публічного інтернету пакетів, що містять заголовок SRH або адресовані до внутрішніх префіксів локаторів.
- Очищення на виході: Повне видалення заголовків SRH перед випуском пакетів за межі довіреної магістралі для унеможливлення витоку внутрішньої топології.
- Захист від спуфінгу адрес: Упровадження правил фільтрації джерел 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 і коректне перемикання сегментів, реалізуючи детерміновану маршрутизацію від джерела в транзитній мережі.



