Почему 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. Эта запись связывает объявленное с тем, что реально делает плоскость пересылки, а это единственное звено, которое имеет значение, и именно это спросит следующий инженер.