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 рута без рада прослеђивања једнако је непотпуна. Држање тога као одвојених пријемних редова скраћује следећи разговор о решавању проблема, јер је ред који отказује већ записан.