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 маршрут без работещо препращане е също толкова непълен. Задържането им като отделни редове за приемане прави следващия разговор за отстраняване на проблеми кратък, защото проваленият ред вече е записан.