Junos L2VPN: сначала правильно оформите договор на подключение клиента

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

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

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

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

Согласуйте инкапсуляцию с договором

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

Не добавляйте оператор family на каждый интерфейс на всякий случай. Конфигурация, из-за которой работает одна цепь, может заставить следующую принимать кадры, которые её клиент никогда не отправляет.

Привяжите подключение к нужному сервису

VPN 2-го уровня с сигнализацией BGP, цепь с сигнализацией LDP и другие поддерживаемые сервисы имеют собственную конфигурацию привязки интерфейса и сигнализации, и они не взаимозаменяемы. Если смешать стиль подключения одного с сигнализацией другого, получится цепь, которая сообщает о пире и никогда не переносит кадр.

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

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

Снимите счётчики локального интерфейса, пока клиент отправляет трафик, затем состояние сервиса и после этого подтвердите, что приходящий кадр — это согласованный кадр, включая его тег. Исправленное подключение доставляет этот кадр; одно лишь изменение статуса ничего не доказывает.

Там, где у вас есть право на захват, посмотрите кадр в обоих направлениях. Асимметрию тегов легко пропустить в представлении статуса и она очевидна в захвате. Эта асимметрия объясняет и жалобы, которые работают в одну сторону и не работают в другую.

Затем запишите это

Зафиксируйте четыре значения в сервисной заметке: договор, инкапсуляция, единица и привязка к сервису. Эти четыре нужны новому инженеру и их редко проговаривает проверка конфигурации.

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