Чому L2VPN у Junos показує мітку, але нічого не передає

Надходять звернення клієнтів: з'єднання L2VPN у стані Up, приєднання підняте, але жоден кадр не проходить. Індикатори стану чесні; кадр класифікується в сервіс, який на віддаленому кінці не має придатного стану пересилання. У L2VPN «точка-точка» з сигналізацією BGP перше рішення належить приєднанню, а не пошуку маршруту. Кадр клієнта надходить на логічний інтерфейс, і цей інтерфейс задає з'єднання, а отже, й віддалений майданчик. Усе дальше — стан пересилання за мітками, побудований з того, що оголосили партнери.

Кадр ніколи не виконує пошук маршруту

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

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

Дві мітки, два напрямки

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

show l2vpn connections instance CUST-A extensive

У цьому виводі вхідна мітка — та, яку цей PE виділив і звелів партнерові використовувати, а вихідна мітка — виділення партнера, яке цей PE вставляє. Читати дві мітки навпаки — класична помилка, і вона відправляє вас шукати величину, яка ніколи не мала з'явитися на цьому боці. Довідник зі з'єднань документує поля поряд із мітками, зокрема майданчик, стан і інформацію про блок.

Що доводить пошук мітки

Коли вхідну величину отримано, локальний пошук — одна команда:

show route label 160042

Цей вивід має показати запис l2vpn із наступним переходом, а операція з міткою повідомляє, чи кадр вставляється, замінюється або знімається перед виходом. Якщо вивід порожній, стан сервісу так і не було встановлено, хоча з'єднання показує Up, і розбіжність у сигналізації, а не в транспорті.

Простежте один кадр

Один пакет, вставлений у приєднання, вирішує більше, ніж будь-який огляд конфігурації. Маршрут мітки сервісу має вказувати на транспортний LSP до віддаленого PE, і дві мітки мають відповідати значенням, які повідомив партнер. Коли транспорт здоровий, а мітка сервісу неправильна, кадр досягає потрібного маршрутизатора і там відкидається, тому лічильники далекого кінця виглядають порожніми, а ближнього — зайнятими.

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

Тримайте моделі сервісів окремо

VPLS вивчає MAC-адреси, а EVPN анонсує кінцеві точки, тоді як L2VPN «точка-точка» не робить ні того, ні того, тому їхні процедури вибору кадру не взаємозамінні, хоча вони їдуть на тій самій інфраструктурі BGP і MPLS. Перенесення кроку діагностики з однієї моделі в іншу дає впевнені, але необґрунтовані висновки.

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