Туннель RSVP-TE работает, но у клиентского L3VPN нет пути
Транспорт и услуга — разные решения. Прочитайте стек меток, отдельно проверьте разрешение следующего перехода и привязку VRF, затем проверьте один реальный поток клиента.
Две команды могут быть правы одновременно, когда клиент сообщает, что VPN не работает, а транспортная команда сообщает, что туннель в порядке. LSP с инженерией трафика и MPLS L3VPN отвечают на разные вопросы: один переносит помеченные пакеты через ядро, другой решает, к какому контексту маршрутизации относится пакет. Когда их смешивают, спор ходит по кругу, потому что каждая сторона измеряет другой объект, и оба измерения верны.
Транспорт работает, а услуга нет — это нормальное состояние
LSP может быть установлен, передавать трафик и быть видимым в каждой системе мониторинга, пока клиентская услуга остаётся непригодной. В этой комбинации нет ничего противоречивого, потому что туннель не имеет мнения о том, существует ли удалённый префикс, приняла ли его политика импорта или пропускает ли кадры присоединённая цепь.
Симптом, который обычно вскрывает путаницу, асимметричен: ping с loopback PE проходит, а хост в клиентской LAN ничего не получает, или наоборот. Запишите, какие адреса работали, прежде чем строить теорию. Как только вы заметите, что проверяете два разных объекта, следующим шагом будет прочитать стек меток, а не спорить, чей граф правильный. Два адреса, два владельца и обычно два разных человека, каждый из которых считает, что другой что-то сломал.
Читайте стек как две ответственности
Нижняя метка принадлежит услуге, а верхняя метка принадлежит пути. RFC 4364 просто описывает последовательность: сначала накладывается метка VPN-маршрута, затем этот помеченный пакет туннелируется к следующему переходу BGP, где туннель инженерии трафика кладёт сверху свою метку.
| Object | Decision it encodes | Who owns it |
|---|---|---|
| Attachment and VRF | Which customer context receives the arriving packet | Edge configuration |
| VPN route and service label | Which remote forwarding context handles the destination | BGP VPN signalling |
| Transport LSP and tunnel label | How the core carries the packet to the BGP next hop | RSVP-TE or another tunnel mechanism |
На дальнем PE метка услуги выбирает обработку, которая может быть поиском в VRF или решением о привязке. Эту метку нельзя заменить на метку, которая лишь пересекает ядро, и они не взаимозаменяемы, даже когда обе появляются в одном стеке на одном интерфейсе.
Что доказывает успех RSVP, а что нет
RSVP-TE устанавливает явно маршрутизируемые LSP, с резервированием ресурсов или без него, и это конкретная и полезная гарантия относительно пути, который пакет проходит через ядро. Это не утверждение о клиентских маршрутах, а настроенное имя туннеля вовсе не маршрут.
Наличие RSVP также не даёт обещания производительности от края до края. Резервирование полосы пропускания на одном LSP ничего не говорит о присоединённой цепи, собственной линии доступа клиента или поведении очереди на дальнем крае. Отношение к нему как к гарантии даёт уверенные ответы на вопросы, которых никто не задавал. Если требование действительно является обязательством по полосе пропускания, его нужно собрать из частей, которые действительно его обеспечивают, а LSP — лишь середина этой цепочки.
Проверяйте по порядку, затем остановитесь
Работайте от транспорта наружу и остановитесь на первом шаге, который не удался, потому что каждый следующий шаг предполагает, что предыдущие выдержали. Сначала убедитесь, что LSP установлен и что запись пересылки для префикса услуги действительно указывает на него. Затем убедитесь, что маршрут VPN существует в нужной таблице, что его привязка метки присутствует и что политика импорта его приняла. Затем убедитесь в привязке: интерфейс, инкапсуляция и, где применимо, идентификатор VLAN, принадлежащий этому договору.
show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMERСинтаксис команд зависит от платформы, поэтому относитесь к этим четырём строкам как к четырём вопросам, а не как к сценарию. Важно то, что каждая из них опрашивает другой объект, и именно поэтому сбой указывает на конкретного владельца.
Проследите один разрешённый запрос и сохраните хорошие доказательства
Завершите одним реальным клиентским запросом, разрешённым политикой, и ответом на него. Один работающий поток от края до края решает больше, чем страница показаний счётчиков, и он проверяет комбинацию, а не каждую часть отдельно.
Когда более поздний этап не удался, сохраните успешное наблюдение LSP вместо того, чтобы перестраивать транспорт. Перестройка работающего туннеля не может исправить отсутствующий удалённый префикс, неверную привязку VRF или правило доступа к пункту назначения, и она уничтожает доказательство, которое изначально говорило, что транспорт здоров.