Почему ваш L2VPN игнорирует RSVP-TE LSP, который вы только что построили

Два инженера могут выйти из одного и того же окна обслуживания с убеждением, что новый путь в работе, и оба ошибаться по разным причинам. Один построил LSP и предположил, что сервис последует за ним. Другой оставил сервис в покое и предположил, что ничего не изменилось. Pseudowire всегда использует только тот транспорт, в который разрешается адрес его пира в данный момент, поэтому настоящий вопрос — что это разрешение даёт сейчас, и два проекта отвечают на него по-разному.

Одна метка называет сервис, другая перемещает пакет

Метка pseudowire, сигнализируемая целевым LDP, как описано в RFC 4447, сообщает принимающему краю провайдера, какое присоединительное кольцо должно получить кадр. О том, как кадр туда попал, она не говорит ничего. Метка под ней принадлежит транспорту, и этот стек строится тем, что объявило достижимость для loopback пира, будь то LDP, RSVP-TE или путь с сегментной маршрутизацией. Поскольку два уровня сигнализируются разными протоколами, один может быть здоров, пока другой устарел. Это разделение и есть весь источник путаницы.

Стоит сказать прямо: pseudowire не выбирает LSP. Он передаёт кадр транспорту, а транспорт решает по тому адресу назначения, который ему дан.

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

Вариант A: привяжите pseudowire к выбранному транспорту

Привязка означает сделать разрешение транспорта для сервиса детерминированным. В зависимости от платформы это принимает форму политики выбора туннеля, явной транспортной конечной точки на сервисе или политики маршрутизации, переписывающей следующий хоп для адреса пира. Все три делают под поверхностью одно и то же: заставляют разрешение одного назначения идти через конкретный LSP. Именно это делает результат проверяемым впоследствии.

Цена — это охват. Политика, совпадающая по адресу пира, затрагивает каждый сервис, направленный к этому пиру, а не только тот pseudowire, который вы имели в виду.

Резервный путь заслуживает решения до окна изменений, а не во время него. Если привязанный LSP падает, вы либо позволяете сервису идти по другому одобренному пути, либо позволяете ему остановиться. Политика, которая тихо откатывается на путь, нарушающий ограничение по задержке или разъединённости, превратила чистый отказ в нечто гораздо более трудное для объяснения кому угодно.

Вариант B: дайте IGP выбрать и наблюдайте, что произойдёт

Оставить сервис в покое — законный проект, и часто лучший. Pseudowire следует тому же разрешению, что и любой другой трафик к loopback пира, поэтому наследует сходимость IGP, подавление префиксов и ту избыточность, которую ядро уже предлагает. Меньше политик — меньше мест, где может спрятаться устаревшее совпадение. Размен в том, что вы больше не контролируете, каким путём идёт сервис, только то, что какой-то путь существует.

Многопутевость с равной стоимостью обостряет этот размен сильнее, чем кажется на первый взгляд. Хеширование выполняется по потокам, поэтому два разговора внутри одного pseudowire могут уйти с разными внешними метками.

Прочитайте установленную переадресацию, прежде чем доверять любой из них

Начните с адреса пира, а не с сервиса. На Junos show route 203.0.113.1 detail печатает выбранный следующий хоп и операцию с меткой, а show route table mpls.0 сопоставляет входящую метку этой операции. На IOS XR show mpls l2transport vc 100 detail выдаёт состояние pseudowire вместе с наложенным стеком.

Подтвердите тот LSP, который транспорт действительно использует, а не тот, что называет ваш проектный документ. traceroute mpls ipv4 203.0.113.1/32 на IOS XR проходит по коммутируемому по меткам пути и перечисляет метки и исходящие интерфейсы вдоль него, что ближе всего к самостоятельному наблюдению за путём. Затем повторите упражнение с дальнего края провайдера, потому что обратное направление разрешается независимо и асимметрия обычна после частичного развёртывания политик. Путь, верный в одну сторону и неверный в другую, хуже равномерно неверного, потому что половина ваших тестов пройдёт.

Храните доказательства вместе с записью сервиса: адрес пира, следующий хоп, внешнюю метку и дату проверки. Политики маршрутизации плохо стареют, и никто не помнит, какая действовала два квартала назад.

Выбирайте по режиму отказа, а не по предпочтению

Привязка подходит сервисам с ограничением, которое IGP не может выразить, и командам, способным поддерживать политику при каждом изменении. Оставить это IGP подходит сервисам, которые должны пережить любой единичный отказ без человека в цикле.

Решающий вопрос — сколько вам стоит неверный путь. Если сервис на неверном LSP работает лишь немного хуже, дайте IGP решить и потратьте силы на мониторинг. Если неверный путь нарушает контракт, замечание аудита или требование разъединённости, привяжите его и запишите резерв. Затем проверьте резерв, потому что непроверенный резерв — это допущение, а не план. В любом случае перечитайте установленную привязку после любого изменения в ядре и относитесь к поднявшемуся pseudowire как к доказательству только того, что сигнализация работает.