Чому ваш L2VPN ігнорує RSVP-TE LSP, який ви щойно побудували

Двоє інженерів можуть вийти з одного вікна обслуговування, впевнені, що новий шлях працює, і обидва помилятися з різних причин. Один побудував LSP і припустив, що сервіс піде за ним. Інший залишив сервіс у спокої і припустив, що нічого не змінилося. Pseudowire завжди використовує лише той транспорт, у який розв'язується адреса його піра в цей момент, тому справжнє питання — що це розв'язання дає зараз, і два проєкти відповідають на нього по-різному.

Одна мітка називає сервіс, інша переміщує пакет

Мітка pseudowire, сигналізована цільовим LDP, як описано в RFC 4447, повідомляє приймальному краю провайдера, яке приєднувальне коло має отримати кадр. Про те, як кадр туди потрапив, вона не говорить нічого. Мітка під нею належить транспорту, і цей стек будується тим, що оголосило досяжність для loopback піра, чи то LDP, RSVP-TE або шлях із сегментною маршрутизацією. Оскільки два рівні сигналізуються різними протоколами, один може бути здоровим, поки інший застарів. Це розділення і є всім джерелом плутанини.

Варто сказати прямо: pseudowire не вибирає LSP. Він передає кадр транспорту, а транспорт вирішує за наданою йому адресою призначення.

Тому й чистий ping через новий LSP доводить так мало. LSP може бути піднятий, мати мітку й нести інші сервіси, поки ваш pseudowire все ще розв'язується через інший наступний хоп. Поки ви не прочитаєте прив'язку, ці два факти не пов'язані.

Варіант A: прив'яжіть pseudowire до вибраного транспорту

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

Ціна — це охоплення. Політика, що збігається за адресою піра, впливає на кожен сервіс, спрямований до цього піра, а не лише на той pseudowire, який ви мали на увазі.

Резервний шлях заслуговує на рішення до вікна змін, а не під час нього. Якщо прив'язаний LSP падає, ви або дозволяєте сервісу йти іншим затвердженим шляхом, або дозволяєте йому зупинитися. Політика, яка тихо відкочується на шлях, що порушує обмеження затримки чи роз'єднаності, перетворила чистий збій на щось значно складніше для пояснення будь-кому.

Варіант B: дайте IGP вибрати й спостерігайте, що станеться

Залишити сервіс у спокої — це законний проєкт, і часто кращий. Pseudowire дотримується того самого розв'язання, що й будь-який інший трафік до loopback піра, тож успадковує збіжність IGP, придушення префіксів і ту надлишковість, яку ядро вже пропонує. Менше політик — менше місць, де може сховатися застарілий збіг. Обмін у тому, що ви більше не контролюєте, яким шляхом іде сервіс, лише те, що якийсь шлях існує.

Багатошляховість з рівною вартістю загострює цей обмін сильніше, ніж здається на перший погляд. Хешування виконується за потоками, тож дві розмови в одному pseudowire можуть вийти з різними зовнішніми мітками.

Прочитайте встановлену переадресацію, перш ніж довіряти будь-якій

Почніть з адреси піра, а не з сервісу. На Junos show route 203.0.113.1 detail друкує вибраний наступний хоп і операцію з міткою, а show route table mpls.0 зіставляє вхідну мітку з цією операцією. На IOS XR show mpls l2transport vc 100 detail видає стан pseudowire разом із накладеним стеком.

Підтвердьте той LSP, який транспорт справді використовує, а не той, що називає ваш проєктний документ. traceroute mpls ipv4 203.0.113.1/32 на IOS XR проходить шлях із комутацією міток і перелічує мітки та вихідні інтерфейси вздовж нього, що найближче до самостійного спостереження за шляхом. Потім повторіть вправу з далекого краю провайдера, бо зворотний напрямок розв'язується незалежно і асиметрія звичайна після часткового розгортання політик. Шлях, правильний в один бік і хибний в інший, гірший за рівномірно хибний, бо половина ваших тестів пройде.

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

Вибирайте за режимом відмови, а не за вподобанням

Прив'язка пасує сервісам з обмеженням, яке IGP не може виразити, і командам, здатним підтримувати політику при кожній зміні. Залишити це IGP пасує сервісам, які мають пережити будь-який одиничний збій без людини в циклі.

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