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 без робочого пересилання такий самий неповний. Якщо тримати їх окремими приймальними рядками, наступна розмова про пошук несправності буде короткою, бо рядок, що падає, вже записаний.