Нормалізація тегів VLAN на кінцевих точках pseudowire: runbook

Визначте, який кадр має отримувати кожен клієнтський край, перш ніж торкатися pseudowire. У простому випадку CE A надсилає один тег, що розмежовує послугу, а CE B очікує кадри без тега, і саме на краю провайдера ця різниця розв'язується. Тег є локальною політикою, а не частиною Ethernet-контракту клієнта, і pseudowire передає узгоджений кадр, а не початковий. Запишіть обидва напрямки до будь-якого налаштування.

Спочатку запишіть контракт на кадр

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

Тримайте контракт достатньо коротким, щоб вставити його в заявку на зміну: який край надсилає з тегом, який очікує без тега і яке значення тега розмежовує послугу.

Узгодьте режим pseudowire

RFC 4448 розрізняє режими pseudowire raw і tagged та описує, як обробляються теги, що розмежовують послугу. Режим raw все ще може нести теги, що належать кадру клієнта, тому розрізнення стосується службової ролі тега, а не самої наявності заголовка 802.1Q. Читання режиму як tagged проти untagged — найпоширеніший спосіб неправильно визначити обсяг цієї роботи. Узгодьте режим із партнером, перш ніж вирішувати, які операції вам потрібні.

Потім перевірте фактичний тип pseudowire і параметри партнера. Локальне підключення VLAN і віддалене підключення порту потребують підтримуваної схеми interworking, а дві локальні інструкції перезапису не доводять, що оголошені типи ланцюгів збігаються.

Якщо очікування щодо control word і MTU різняться, у вас проблема узгодження, яку не виправить жоден перезапис. Підтвердьте обидва з робочої конфігурації партнера, а не з проєктного документа.

Застосуйте локальні операції з тегами

посібник Juniper з перезапису VLAN CCC описує операції pop, push і swap з обмеженнями, що залежать від платформи. Для вже налаштованого сумісного блока з тегом ілюстративний напрямок — input-vlan-map pop на вході та output-vlan-map push на виході. Ці рядки ілюструють операції, а не повну конфігурацію інтерфейсу чи ланцюга. Підтвердьте точну платформу та версію, замість того щоб застосовувати приклад однієї родини пристроїв повсюдно.

Підтримувані блоком параметри VLAN та інкапсуляції все одно мають визначати потрібний тег і класифікацію. Інструкція перезапису на блоці, який класифікує неправильні кадри, переміщує проблему, а не виправляє її.

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

Плануйте розмір, а не лише теги

Включіть у бюджет розміру збережені теги, фактичний стек MPLS і control word. RFC 8469 рекомендує control word для Ethernet pseudowire, і ця рекомендація змінює бюджет кадру незалежно від того, чи вмикає його ваша платформа за замовчуванням. Узгодьте невідповідність MTU, а не пригнічуйте її попередження як ремонт. Пригнічене попередження — це планова аварія зі стертою датою.

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

Якщо числа не збігаються, змініть план, а не рівень журналювання.

Приймайте кадр за кадром

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

Тримайте режим, операції з тегами, бюджет MTU і результат тесту в одному місці, оскільки вони мають сенс лише разом. Розподіл їх по трьох заявках гарантує, що наступний інженер знову виявить те саме обмеження.

Ланцюг готовий, коли обидва напрямки відповідають контракту, написаному на початку, а не коли проходить перший напрямок.