Нужен ли VPNv4 MPLS в ядре? Не обязательно

BGP VPNv4 согласует контекст распределения маршрутов, а не путь пересылки. Отделите импорт, разрешение следующего перехода и инкапсуляцию, которую вы можете запустить.

Включение семейства адресов VPNv4 между двумя маршрутизаторами создаёт только контекст распределения маршрутов и ничего больше. Оно не устанавливает путь пересылки и не сообщает, какая инкапсуляция понесёт клиентский пакет к удалённой оконечной точке. Как только эти два факта разделены, вопрос «нужен ли здесь MPLS в ядре» становится более узким и допускающим ответ вопросом о плоскости данных, поддерживаемой платформой.

Что на самом деле согласует семейство адресов

Многопротокольный BGP переносит информацию о достижимости сетевого уровня VPNv4 в рамках AFI 1 и SAFI 128, и каждая запись связывает различитель маршрута с префиксом и меткой. Сессия согласует, что обе стороны умеют кодировать и декодировать эту информацию. Что она не согласует, так это плоскость данных. Всё после этого абзаца касается пересылки, и ничего из этого не решается поднятием сессии.

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

Обратите внимание на метку в NLRI. Это метка службы, привязанная к префиксу внутри VRF, и у неё есть роль в пересылке, когда пакет достигает выходной оконечной точки. Читает ли её какое-либо транзитное устройство — отдельное проектное решение.

Приём, импорт и пересылка — это три шага

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

Step in the chainWhat has to be trueHow it fails quietly
NLRI exchangeBoth speakers negotiate the VPNv4 capabilitySession stays up while the family is never activated
Import eligibilityA route target on the received route matches the VRF import policyThe route exists in the table but never enters the VRF
Next-hop resolutionThe advertised next hop resolves to a usable tunnel or label pathBest path is selected, then marked unreachable or unusable
EncapsulationThe egress endpoint can decapsulate what the ingress producedPackets arrive and are discarded for a format mismatch

Именно на этом среднем шаге живут самые неожиданные отказы. Маршрут может присутствовать в таблице BGP, быть допустимым и даже лучшим, а таблица маршрутов VRF останется пустой, потому что ни одна цель маршрута не совпала со списком импорта. Ничто не регистрирует ошибку протокола, потому что ошибки протокола не произошло.

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

IP-ядро может нести стек, который никогда не коммутирует

Различие, которое стоит сохранить, — между «ядро не запускает MPLS» и «в службе нигде нет метки». Это разные утверждения, и только первое относится к транзитным устройствам. RFC 4023 определяет перенос MPLS через туннели IP или GRE, и именно этот механизм делает второе утверждение возможным в полностью IP-ядре.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

Транзитные маршрутизаторы пересылают по внешнему IP-назначению и не нуждаются ни в клиентских префиксах, ни в собственной коммутации меток. На дальнем конце внешний туннель снимается, и метка службы возобновляет свою работу. Ядро переместило непрозрачную полезную нагрузку, и именно в этом IP-сеть сильна.

Чего этот проект вам не даёт, так это универсальной гарантии. Это не доказательство того, что каждый маршрутизатор разрешает каждый следующий переход VPNv4 через любой интерфейс GRE, и не причина удалять работающую собственную конфигурацию MPLS. Это контрпример к универсальному утверждению, и практический вопрос остаётся локальным для платформы. Запишите этот вопрос как ограничение платформы, а не как правило протокола.

Пройдите цепочку на устройстве, пока она не сломается

Начните с полученного маршрута и остановитесь на первом шаге, который не удаётся, потому что последующие шаги нельзя диагностировать, пока предыдущий сломан. Четыре команды охватывают большую часть этого в типичной реализации.

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

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

Затем проверьте путь рабочей нагрузки в обоих направлениях, с MTU, который выдерживает инкапсуляцию. GRE добавляет байты заголовка, и путь, проходящий небольшие пробы, может отказывать на пакетах полного размера только в одном направлении, что выглядит как сбой приложения, а не транспорта.

Две эксплуатационные заметки замыкают цикл. GRE — это инкапсуляция, а не конфиденциальность, поэтому недоверенной транзитной сети нужна поддерживаемая схема безопасности сверху, а не предположение. И запишите, какую инкапсуляцию платформа действительно поддерживает, до проектного обзора, потому что этот единственный ответ решает, является ли ядро только-IP допустимым выбором или планом, который не может пересылать.

Похожие статьи