От VXLAN к MPLS IP VPN: VNI — не метка MPLS

Обе технологии помещают идентификатор перед пакетом, поэтому вывод кажется очевидным: сопоставьте VNI с меткой MPLS и позвольте двум сетям объединиться. Такого сопоставления не существует как поддерживаемой операции, потому что идентификаторы означают разные вещи и создаются разными плоскостями управления. VNI идентифицирует сегмент VXLAN внутри оверлея; метка MPLS идентифицирует обработку пересылки вдоль пути с коммутацией меток. Соединение доменов — это решение о маршрутизации, а не перевод чисел.

Миф: обе используют метки, значит сопоставьте их

Поверхностное сходство реально и обманчиво. VXLAN несёт 24-битный VNI в заголовке, а MPLS несёт стек меток, поэтому кажется, что одно значение можно переписать в другое на пограничном устройстве.

Идею разрушает всё, что окружает значение. VNI разрешается плоскостью управления EVPN и конечными точками туннеля в нижнем слое. Метку назначает плоскость пересылки MPLS вдоль пути. Ни у одной стороны нет определённой процедуры принять идентификатор другой стороны как свой собственный.

Что на самом деле пересылает каждая сторона

На стороне фабрики пограничное устройство завершает туннель VXLAN, сопоставляет VNI с VRF арендатора и маршрутизирует пакет как обычный IP. На стороне провайдера PE принимает маршрут клиента в VRF, накладывает стек меток MPLS и пересылает его через IP VPN.

Эта передача — хорошо понятная модель в RFC 4364: клиентский край обменивается IP-маршрутами с краем провайдера, и каждый домен владеет своей инкапсуляцией. VNI исчезает к моменту, когда пакет доходит до PE, и именно поэтому модель работает.

Почему плоскости управления не сливаются

EVPN Type 5 несёт маршруты префиксов IP с оверлейными следующими переходами, тогда как объявления VPN-IPv4 относятся к другому семейству адресов. Одинаково выглядящие цели маршрутов с обеих сторон не переводят одно семейство в другое и не разрешают следующие переходы за границей.

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

На этой границе терпят крах ещё два допущения. MPLS IP VPN обеспечивает маршрутизируемую доступность, а не сегмент Ethernet, поэтому для растягивания широковещания требуется вместо этого поддерживаемая услуга 2-го уровня. И обе инкапсуляции расходуют байты, поэтому эффективный MTU меньше, чем предполагает любой из нижних уровней.

Выберите маршрутизируемую передачу или интегрированный шлюз

Выбирайте маршрутизируемую передачу, когда арендатору нужна IP-доступность и провайдер уже предлагает услугу, обращённую к CE. Она сохраняет владение чистым: фабрика владеет VXLAN и EVPN, провайдер владеет MPLS и VPN, а граница владеет сопоставлением VRF с интерфейсом. Планируйте масштаб подключения, адресацию и переключение при сбое вместе с провайдером, а не предполагайте, что одного канала достаточно.

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

Что записывать по каждому арендатору

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

Именно эта запись связывает два административных домена, не делая вид, что их допущения о маршрутизации и инкапсуляции одинаковы. Когда позже кто-то спросит, может ли VNI просто стать меткой, документ ответит проектом, а не спором.