Junos L2VPN: спершу правильно оформіть договір на приєднання клієнта

Перш ніж чіпати pseudowire, простежте один кадр клієнта до PE і подивіться, де він має опинитися. Фізичний порт класифікує його в логічну одиницю, ця одиниця несе інкапсуляцію, а одиниця прив'язана до сервісу. Три окремі рішення, три окремі способи помилитися. Більшість випадків, ескалованих як збій сигналізації, насправді є кадром, віднесеним до одиниці, яку ніхто не налаштував для цього сервісу. Тож починайте з приєднання і рухайтеся назовні.

Запишіть договір на кадр

Зафіксуйте договір до вибору будь-якої конфігурації: без тегу, з одним сервісним тегом або зі стеком. Додайте MTU, який надсилатиме клієнт, і обробку тегів, очікувану в кожному напрямку, бо це узгоджені властивості, а не локальні вподобання. Номер одиниці — лише ідентифікатор, і він нічого не каже про те, які кадри прийме інтерфейс.

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

Узгодьте інкапсуляцію з договором

Сервіс з одним тегом зазвичай використовує інкапсуляцію VLAN-кола, наприклад vlan-ccc, тоді як кадри без тегу потребують простої форми Ethernet-кола, а стекові потрібен розширений варіант, який розуміє два теги. На платформі, що підтримує сервісну інкапсуляцію на одиницю, один фізичний інтерфейс може вмістити кілька одразу, що зручно і водночас є способом, у який кадр потрапляє не до тієї одиниці. Там, де посібник для вашої платформи вимагає family ccc, налаштуйте це як частину повного приєднання, а не прикручуйте до маршрутизованого інтерфейсу. Посібник з інкапсуляцій перелічує, які типи приєднання висувають які вимоги.

Не додавайте оператор family на кожен інтерфейс про всяк випадок. Конфігурація, через яку працює одне коло, може змусити наступне приймати кадри, яких його клієнт ніколи не надсилає.

Прив'яжіть приєднання до потрібного сервісу

VPN 2-го рівня із сигналізацією BGP, коло із сигналізацією LDP та інші підтримувані сервіси мають власну конфігурацію прив'язки інтерфейсу й сигналізації, і вони не взаємозамінні. Якщо змішати стиль приєднання одного із сигналізацією іншого, вийде коло, яке повідомляє про піра і ніколи не переносить кадр.

Порівняйте дальній кінець із ближнім, а не розглядайте будь-який із них ізольовано: адреса піра, ідентифікатор сервісу, угода про інкапсуляцію, очікування щодо control word і бюджет розміру. Нижчий рівень MPLS може бути цілком здоровим, поки приєднання відсутнє або класифіковане в іншому місці, тому тест, який дивиться лише на нижчий рівень, тут нічого не доводить.

Перевіряйте кадром, а не статусом

Зніміть лічильники локального інтерфейсу, поки клієнт надсилає трафік, потім стан сервісу і після цього підтвердьте, що кадр, який надходить, — це узгоджений кадр, разом із його тегом. Виправлене приєднання доставляє цей кадр; сама лише зміна статусу нічого не доводить.

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

Потім запишіть це

Зафіксуйте чотири значення в сервісній нотатці: договір, інкапсуляція, одиниця і прив'язка до сервісу. Ці чотири потрібні новому інженерові, і їх рідко промовляє перевірка конфігурації.

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