IPv6 в MPLS VPN: три решения, а не одна адресная семья
Маршруты VPN клиента, сессия BGP между PE и транспорт в ядре — отдельные решения. Сессия может работать в одной семье и нести другую.
Скажите на обзоре дизайна «запусти IPv6 L3VPN поверх IPv6 BGP», и в этом одном предложении спрятаны три отдельных решения. Какие префиксы принадлежат VPN клиента, какие адреса несут сессию маршрутизации между краями провайдера и какое ядро перемещает помеченный пакет — это независимые выборы. Все они могут быть IPv6, могут быть смешанными, и смешивание разрешено намеренно. Именно разбор этих трёх превращает расплывчатое требование в то, против чего платформу можно проверить.
Разделите три задачи
Первая задача — маршрут клиента: префиксы IPv6, принадлежащие одному контексту маршрутизации VPN и обязанные оставаться вне любого другого контекста. Вторая — соединение маршрутизации между граничными маршрутизаторами провайдера, которые обмениваются этими префиксами. Третья — транспорт, который несёт помеченный пакет клиента через ядро к удалённому краю. Назвать только одну из них — это ещё не дизайн.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
У каждой задачи своя адресная семья, свои режимы отказа и часто своя команда. Таблица полезна именно потому, что одно предложение в документе дизайна склонно сминать все три строки в одну.
Семья маршрута — VPN-IPv6, а не IPv6 unicast
RFC 4659 определяет семью BGP/MPLS IPv6 VPN, и принадлежность к ней конкретнее, чем подразумевает слово IPv6. Маршрут там — это различитель маршрута, соединённый с префиксом IPv6 и закодированный под AFI 2 и SAFI 128. Обычный IPv6 unicast — другая семья, поэтому анонс, который в looking glass выглядит как префикс, может вообще не быть тем же объектом. Неверное чтение семьи — первый способ, которым этот дизайн идёт не так.
Разница кусает на краю, где маршрут должен сначала попасть в правильный контекст VPN, прежде чем что-то сделать. Получение префикса доказывает, что обмен состоялся, и ничего не говорит об установке. Этот разрыв порождает классический отчёт, в котором сессия поднята, а клиент всё ещё в темноте.
Сессия может работать в другой семье, чем VPN
Ничто не заставляет BGP-соединение между двумя краями использовать собственную семью VPN. Спецификация допускает сессию IPv4 или IPv6, а транспорт IPv6 VPN сам определён поверх обоих типов ядра. Поэтому сессия IPv6 ничего не говорит о семье того, что она несёт, и не выбирает плоскость данных. Три независимых бита, и дизайн должен нести все три по отдельности.
Это освобождает и в то же время легко читается неверно. Маршруты клиента IPv6 могут ехать по сессии с адресом IPv4, а маршруты IPv4 — по сессии IPv6, если платформа поддерживает сочетание и следующий хоп разрешается. Чего быть не должно — чтобы сессия подразумевала нагрузку, в документе дизайна или в мониторинге, который позже доказывает услугу.
Следующий хоп на ядре IPv4 имеет собственную кодировку
Когда ядро под VPN — IPv4, маршрут не появляется со следующим хопом, который входной край может использовать напрямую. Он приходит в виде IPv6, отображённого в IPv4, и именно так спецификация выражает выходной край, когда транспорт под ним — IPv4. Входному маршрутизатору приходится превращать этот отображённый адрес в то, до чего он действительно доберётся через ядро, и разрешение — тот шаг, который тихо отказывает.
Читайте это как зависимость пересылки, а не как строку для копирования между устройствами. Подтвердите три вещи на платформе, которой действительно управляете: объявленный следующий хоп разрешается в пригодный путь, стек меток принимается, и назначение попадает в задуманный контекст VPN. Если что-то из этого не сработает, останется сессия, которая выглядит здоровой и ничего не пересылает, поэтому проверка относится к приёмочному прогону, а не к более позднему инциденту.
Напишите требование в четыре строки
Требование, которое стоит проверять, называет четыре вещи: семью VPN, транспорт сессии, кодировку следующего хопа и устройство ядра. Затем оно называет один префикс клиента, который нужно проследить от начала до конца: через обмен, установку, разрешение меток и обратный путь. «Поддерживает IPv6 BGP» не покрывает ни одного из четырёх и скрывает, где на самом деле живёт несоответствие.
Здоровая сессия без обмена VPN-IPv6 неполна, а полученный маршрут VPN без работающей пересылки столь же неполон. Если держать их отдельными приёмочными строками, следующий разговор о поиске неисправности будет коротким, потому что падающая строка уже записана.