Лаборатория MPLS L3VPN не пингуется? Проверьте эти пять шагов

Два клиентских маршрутизатора, пара устройств provider edge и пинг, который умирает без сообщения об ошибке. В небольшой лаборатории MPLS L3VPN неисправность почти всегда сидит в одной из пяти контрольных точек, и у каждой есть команда, которая показывает либо что зависимость работает, либо что её нет. Ошибка — перезапускать BGP каждый раз, когда пинг не проходит, вместо того чтобы проверять зависимости по порядку. Если сразу прыгнуть в конфигурацию VRF, можно потратить час на проблему, начавшуюся с неразрешённого следующего шага двумя устройствами дальше.

Проходите список снизу вверх. Контрольная точка, которая прошла, остаётся пройденной, и первая ошибка — та, которую стоит отлаживать.

Контрольная точка первая: PE достигают друг друга

Каждому PE нужен маршрут к loopback другого PE, и этот маршрут должен разрешаться через что-то реальное. Interior gateway protocol — обычный путь туда, но и статический маршрут работает, пока рекурсивный поиск заканчивается на живом adjacency. На устройствах в стиле IOS show ip route 10.0.0.2 и затем show ip cef 10.0.0.2 показывают, существует ли префикс и есть ли за ним разрешённый adjacency. Маршрут в таблице без adjacency за ним — не доступность.

Проверьте оба направления. Асимметричные затраты IGP, passive interface не с той стороны или distribute list, фильтрующий loopback, ломают каждое только одно направление, а одного направления достаточно, чтобы убить сессию. Если loopback пингуются, но сессия BGP стоит в Active, посмотрите на update source, прежде чем трогать что-то ещё.

Контрольная точка вторая: существует путь меток

IP-маршрут к удалённому loopback не доказывает, что транспорт поставит метку. В проекте LDP подтвердите, что у удалённого loopback есть локальная и удалённая привязка и что исходящая метка появляется в forwarding-таблице. show mpls ldp bindings 10.0.0.2 32 показывает пары меток, а show mpls forwarding-table 10.0.0.2 — что линейная карта действительно поставит. Когда вторая команда не показывает никакой метки или откатывается на IP, транспорт не несёт VPN-трафик так, как предполагает проект.

Разница возникает из того, как MPLS отделяет forwarding state от префиксов назначения, — модель, описанная в RFC 3031. Если ваша лаборатория использует RSVP-TE или метки, смежные с BGP, вместо LDP, проверьте собственное состояние этого механизма; предполагать, что LDP распространяет каждую метку нижнего уровня, — частый способ гоняться за фантомной ошибкой. Сломанный путь меток обычно позже проявляется как VPN-маршрут, который есть, но непригоден.

Контрольная точка третья: VPN-маршрут пришёл целым

Смотрите на маршрут VPNv4 или VPNv6 для точного префикса клиента, а не на сводку сессии. show bgp vpnv4 unicast all 10.10.1.0/24 должен показать route distinguisher, next hop, установленный на loopback удалённого PE, и метку. Если префикса нет, первый подозреваемый — политика экспорта на исходном PE или политика импорта на принимающем PE, а route target — обычный виновник.

Читайте проверку route target отдельно от приёма BGP. Маршрут может прийти с правильным next hop и всё же не попасть в VRF, потому что importtarget не совпадает. На принимающем PE show ip route vrf CUSTOMER 10.10.1.0 — тот тест, который имеет значение; таблица BGP доказывает лишь, что маршрут пересёк плоскость управления.

Контрольная точка четвёртая: interface находится в VRF

Определение VRF с route distinguisher и route target не переносит в неё ни один interface. Interface в сторону CE нуждается в назначении VRF, и show ip vrf interfaces или show ip interface brief должен перечислить его под правильным экземпляром. Это та контрольная точка, где скопированная конфигурация чаще всего ошибается, потому что блок VRF выглядит полным, пока interface всё ещё сидит в глобальной таблице.

Затем подтвердите, что PE выучил локальный префикс клиента в эту VRF и что у CE есть маршрут обратно через подключение. Статический default на CE, указывающий на PE, достаточен для лаборатории при условии, что в VRF на PE есть маршрут к LAN клиента. Если отсутствует любая из двух половин, пинг падает ещё до того, как будет поставлена хоть какая-то метка.

Контрольная точка пятая: ответ находит дорогу домой

Проследите пакет вперёд, а затем обратный пакет, потому что они используют разные таблицы. На входном PE источник клиента должен разрешиться внутри VRF в удалённый префикс с удалённой меткой. На выходном PE назначение должно разрешиться внутри той же VRF в interface в сторону CE. Пинг, отправленный с самого PE, не является доказательством: он может уйти через глобальную таблицу или другой исходный адрес, и поэтому ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 — это тест, который нужно выполнить.

Межсетевые экраны на хостах, reverse-path filtering и access-списки на CE по-прежнему действуют. Если путь вперёд работает, а ответ умирает, проблема в маршруте или фильтре на обратной стороне, а не в транспорте MPLS.

Держите по одной строке на каждую контрольную точку с именем первой отказавшей зависимости. Эта строка превращает жалобу, что клиент не может пинговать, в конкретный вопрос о доступности, состоянии меток, импорте маршрутов, принадлежности interface или обратном пути, и она не даёт следующей сессии отладки повторить те же пять команд в том же порядке.