Segment routing: як і чому

Оператори зв'язку та великі корпорації, оцінили всі переваги MPLS, змушені миритися з кількома control plane протоколами у своїй мережі. IGP+LDP став де-факто стандартом в ядрі мережі. Разом з цим відомо, що протокол OSPF розширюємо за рахунок opaque LSA, протокол IS-IS вже багато років успішно розширюється додаванням нових TLV. А якщо додати MPLS мітку безпосередньо в IGP? І чи можна позбутися від не надто гнучкого RSVP? Прихильників оптимізації прошу під кат.


В статті не розглядаються основи MPLS, і автор розраховує на те, що читач як мінімум непогано орієнтується в термінології.

Що не так з LDP і RSVP? По-перше, це додатковий control plane протокол, який повинен тісно і в правильному порядку взаємодіяти з IGP. Звідси
ldp igp sync
в термінології Cisco та інші чудові техніки управління взаємодією IGP-LDP. Неправильно сконфігурований інтерфейс може призвести до скиду трафіку. Такі проблеми не завжди легко діагностувати і виправити. По-друге, будь-control plane протокол споживає ресурси обладнання. Зокрема для класичного IOS додаткові процеси небезпечні ще і тим, що вся ОС працює в одному просторі памяті. Іншими словами, segfault в одному додатку може призвести до крешу всього пристрою. В теорії. Насправді LDP і RSVP у більшості вендорів працюють добре і стабільно. Але ми, як завзяті оптимізатори, звичайно ж, хотіли б від них позбутися. Варто сказати, що з точки зору форвардингу segment routing може бути реалізований з використанням протоколів MPLS і IPv6. Мова піде виключно про forwarding plane з MPLS.

Позбавляємося від LDP
Робоча група SPRING запропонувала перекласти функції протоколів поширення міток на IGP, а LSP будувати сегментами. Сегмент являє собою частина (або вся) LSP до конкретного маршрутизатора. Для призначення міток використовується виділений діапазон, щоб не перетинатися з класичними протоколами. Його називають SRGB — segment routing global block. Цей блок може відрізнятися на різних пристроях, хоча при можливості краще використовувати однаковий, щоб остаточно не заплутатися. Однак мітка для досягнення конкретного PE при цьому повинна бути унікальною. При цьому мітка на всьому сегменті не змінюється. Важливо розуміти, що операція swap проводиться в будь-якому випадку, просто in і out мітки збігаються. За замовчуванням пристрої на платформі IOS XR використовують значення 16000-23999 для SRGB. І, оскільки блоки можуть відрізнятися, інформація про них анонсується через IGP.

З блоком зрозуміло. Але як маршрутизатори приходять до угоди про значення мітки для певного FEC? На кожному пристрої повинен бути налаштований унікальний SID — segment identifier. Існують Node SID і Adjacency SID, про останніх — трохи нижче. Для визначення мітки, яка буде закріплена за лупбэком пристрою, до нижньої межі SRGB додається Node SID. Наприклад, якщо SRGB починається з 16000, а пристрою присвоєно SID 5, то мітка для досягнення лупбэка пристрою буде дорівнює 16005. Цю мітку буде використовувати всі пристрої на шляху прямування (swap 16005 -> 16005).


Приклад конфігурації для IOS XR
router isis SR
net 49.0000.0000.0001.00
address-family ipv4 unicast 
metric-style wide level 2
segment-routing mpls sr-prefer ! включаємо SR для IGP і одночасно
! робимо його пріоритетним по відношенню до LDP
interface lo0
address-family ipv4 unicast 
prefix-sid index 5 ! вказуємо SID для loopback PE маршрутизатора


Чому раптом мова пішла про лупбэках? Справа в тому, що SR — це технологія для побудови шляху до конкретного PE пристрою. Іншими словами, мова йде про транспортні мітках. А досягти PE пристрій — означає досягти його лупбэка. Поширення і призначення сервісних міток, будь то L2VPN, L3VPN або інші технології, не змінюється. Все той же MP-BGP буде необхідний для побудови сервісів, всі ті ж сервісні мітки будуть розташовуватися внизу стека.

Трохи вище я сказав, що SID пристрою повинен бути унікальним. Так от, це нахабна брехня. Adjacency SID має локальне значення. Маршрутизатор генерує Adjacency SID для кожного SR сусіда автоматично, і значення ніяк не перетинається з SRGB. Конфігурувати в цьому випадку нічого не потрібно. Як і все інше, такі мітки поширюються протоколом IGP. Це дає можливість передавати трафік через певний інтерфейс. Як вказати інтерфейс, якщо мітка може не бути унікальною? Тут все просто: для цього використовується стек міток, де верхня мітка — Node SID, а нижня — Adjacency SID.

Позбавляємося від RSVP
LDP всім хороший, ось тільки слід шляху, який обрав IGP, і резервувати смугу не вміє. При необхідності побудувати шлях передачі трафіку відмінний від того, що вибрав IGP, на допомогу приходить RSVP-TE з його explicit paths. У випадку з побудовою шляхом, відмінним від кращого на думку IGP, SR може замінити функціонал RSVP прямо з коробки: достатньо просто створити стек міток, який повністю опише шлях. Наприклад, якщо нам потрібно, щоб трафік відправлявся через Router A до Router B, в стеку транспортних міток буде спочатку SID Router A, а потім SID Router B.


Зізнатися, з точки зору конфігурації мало що змінюється: в explicit path використовуються всі ті ж IP адреси. І одразу відповідь на часто виникає питання: так, оверхед збільшується. Якщо необхідно точно визначити шлях з десяти маршрутизаторів, то в стеку буде 10 міток. Однак такі сценарії на практиці зустрічаються дуже рідко. Зазвичай вистачає декількох міток, щоб вирішити конкретну задачу.

TE-тунель з використанням SR
router isis SR
address-family ipv4 unicast 
mpls traffic-eng level-2
mpls traffic-eng router-id Loopback0
!
!
interface tunnel-te10
ipv4 unnumbered loopback0
destination 192.168.0.1
path-selection segment-routing adjacency protected ! protected - для використання FRR
path-option 1 explicit name PATH1 segment-routing ! нічим не відрізняється від explicit-path для RSVP


А смугу-то як резервувати? З цим поки що складно. Зараз немає проблем з тим, щоб запустити CSPF. Проблема полягає в тому, що для резервування смуги пропускання необхідно стан на маршрутизаторі, яке описує значення зарезервованої ПП для кожного LSP. Тому концепт резервування смуги вимагає введення поняття PCE.

PCE — path computation element — це контролер, який спілкується з маршрутизаторами за протоколом PCEP. Цей контролер може розраховувати TE тунелі з використанням CSPF, у тому числі з атрибутом bandwidth. Зауважу, що PCE і SR — це не єдина існуюча комбінація. З не меншим успіхом PCE може працювати з RSVP, LDP і навіть статично призначати мітки. У загальному випадку завдання PCE полягає в тому, щоб встановити відразу forwarding state на пристрій через протокол PCEP.


Зрозуміло, для розрахунку колії PCE повинен знати існуючу топологію. Розповісти PCE топології можна зробивши його частиною топології, тобто підключивши його до IGP домену. Альтернативний варіант — BGP-LS сесія з контролером.

PCE здатний відстежувати поточну завантаження інтерфейсів і перебудовувати шлях проходження тунелів, якщо це потрібно. Іншими словами, цей елемент можна назвати SDN контролером поверх існуючої MPLS мережі. Однак навіть короткий опис PCE — це тема як мінімум окремої статті. Тому я залишу тут посилання на популярні open source проекти, які в тому чи іншому вигляді підтримують PCEP: ONOS і ODL — а ми повернемося до SR.

Що в підсумку?
Все виглядає дуже гарно і оптимістично, але де ж це застосувати? Давайте розглянемо кілька сценаріїв.

1. Заміна протоколу LDP.

Ми розібралися, що замінити RSVP без PCE буде важко, коли використовується bandwidth reservation. Тому як повноцінну заміну RSVP без додаткових елементів в мережі SR розглядати не будемо. А що стосується LDP, то в теорії цей протокол можна вимкнути і поширювати транспортні мітки через IGP. Однак цей сценарій навряд чи приносить достатньо переваг, враховуючи ризики, на які доведеться йти при редизайні мережі. До того ж не завжди кожний пристрій у мережі підтримує SR. Це можна вирішити за допомогою додаткової конфігурації, коли кілька пристроїв є кордоном між SR і LDP доменом. Однак факт наявності такої конфігурації змушує ще більше задуматись про плюси і мінуси рішення. Кажучи відверто, зараз немає причин замінювати LDP на SR просто для того, щоб замінити.

2. Topology independent LFA.

LFA або IP FRR не працює в довільних топологіях. Наприклад, у кільцевій топології маршрутизатор не зможе розрахувати запасний шлях, оскільки будь-який шлях приведе до петлі. Однак використовуючи інкапсуляцію в MPLS, трафік можна скинути не тільки сусіда, але і віддаленого пристрою. Тут SR має практичний сенс. Зрозуміло, цю ж задачу можна вирішити за допомогою RSVP, але рішення з SR виглядає більш елегантним.

В якості прикладу уявіть згадану кільцеву топологію, де OSPF cost між всіма маршрутизаторами однаковий. Припустимо, кожен маршрутизатор обчислює LFA для певного шляху.


Як видно, єдиний альтернативний шлях при маршрутизації IP призведе до утворення петлі. Іншими словами, в чистій IP мережі LFA вирахувати неможливо. Тому необхідно «скинути» трафік трохи ближче до резервируемым префиксам, для чого прекрасно підійде SR.

LFA з використанням SR
router isis SR
interface Gi0/0/0/1
address-family ipv4 unicast
fast-reroute per-prefix ! тут ми просто включаємо LFA. Ця команда обов'язкове
fast-reroute per-prefix ti-lfa ! а тут дозволяємо TI LFA


3. SDN.

Исопользование SR у сукупності з PCE. Тут і RSVP замінити можна, і смугу динамічно відстежувати і API організувати для сторонніх інструментів. Зрозуміло, цей перелік мізерний і не претендує на повний список всього, чого можна домогтися з впровадженням PCE в мережу. Але з транспортної точки зору на чолі всього стануть гнучкість управління мережею, можливість конфігурації intra-AS LSP (включаючи TE, L2VPN тощо), простота конфігурації і розгортання сервісів. До того ж, PCE не вимагає редизайну мережі і може працювати поверх існуючого forwarding plane.

Тут мене знову понесло трохи в бік від SR. Однак зв'язка SR+PCE виглядає дуже багатообіцяючою. І саме в цій зв'язці segment routing розкриває всі свої переваги.

4. Управління трафіком у великих мережах.

У Cisco є нетривіальний підхід до побудови великих операторських мереж, який називається Unified MPLS. В іншій термінології той же підхід може називатися Seamless MPLS. Мережі з SR зможуть стати відмінною і більш прозорою альтернативою цьому підходу.

Якщо ви уявляєте, яких зусиль необхідно докласти для проектування і конфігурації мережі з використанням Unified MPLS з нуля, SR може вам сподобатися.

Взаємодія LDP і SR
Я навмисно залишив цей розділ наостанок. По-перше, далеко не завжди необхідно, щоб SR і LDP взаємодіяли. По-друге, непогано б розуміти, які завдання можуть бути вирішені за допомогою SR до того, як переходити до питань взаємодії з LDP.

Найбільш часто вирішуються питання взаємодії виникають при міграції з LDP на SR або при відсутності підтримки SR на частини пристроїв у мережі. У IOS XR конфігурація SR безпечна. За умолачнию мітки, отримані за LDP, мають більший пріоритет. Для того щоб LDP пішов на другий план, необхідно сказати маршрутизатора
segment-routing mpls sr-prefer
в IGP процесі. При цьому зовсім необов'язково робити SR обраних на всіх маршрутизаторах відразу. Ця команда локальна, і факт переваги SR ніяк не повідомляється іншим пристроям.

При наявності пристроїв, які не підтримують SR, необхідно сконфігурувати кілька пристроїв в якості Mapping server. Я кажу дещо тільки з міркувань відмовостійкості — для функціонування буде достатньо одного пристрою на кордоні SR/LDP мереж.

Mapping server отримує мітки з LDP, а потім анонсує SID'и від імені пристроїв, які не вміють SR. При цьому data plane не повинен проходити через mapping server — це control plane пристрій. Всі маппинги, які придумав сервер, анонсуються його клієнтам через IGP. Кожен пристрій має бути сконфігурований як клієнт, щоб отримати маппинги для LDP мереж.

Самі маппинги задаються вручну. При цьому в разі використання двох і більше mapping servers очікується, що маппинги на них будуть налаштовані ідентично. Звичайно, мережа не зламається від неправильно настроєний мапінгу, але в разі аварії збіжність може постраждати.

Mapping server і mapping client
! Server
segment-routing
mapping-server
prefix-sid-map
address-family ipv4
10.10.20.1/32 254 range 255 ! кілька SID для пулу префіксів (10.10.20.1,2 ... 255)
! адреси і SID просто инкрементируются
! довжина префікса не обов'язково повинна бути 32.
10.10.10.10/32 400 ! один SID для /32 префікса
!
!
!
router isis GEOR
address-family ipv4 unicast
segment-routing prefix-sid-map advertise-local ! а це змусить анонсувати маппинги в IS-IS 

! Client
router isis GEOR
address-family ipv4 unicast
segment-routing prefix-sid-map receive ! тільки отримувати маппинги. Самі нічого не анонсуємо


Маючи mapping server можна захищати LSP, побудовані протоколом LDP, TI LFA. Іншими словами, MPLS сервіси, мітки для яких згенеровані класичними протоколами, можуть захищатися з використанням SR.

Існує безліч сценаріїв взаємодії LDP і SR, в їх числі LDPoSR і SRoLDP. Трохи більш докладний опис можна знайти по одній з посилань, наведених нижче.

На цьому моє коротке оповідання про segment routing завершено. Хочу зауважити, що матеріал статті не розглядає всі нюанси SR і залишає багато за кадром. Багато чого з того, що залишилося за кадром, можна знайти за посиланнями нижче.

Дякую за увагу.

Посилання на ресурси IETF:

» SR draft
» PCEP

Дуже корисний ресурс SR: Cisco SR
Одна з сесій на Cisco Live: Introduction to Segment Routing
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.