Да ли је VPNv4 потребан MPLS у језгру? Није обавезно
BGP VPNv4 преговара контекст дистрибуције рута, а не путању прослеђивања. Одвојте увоз, решавање следећег скока и инкапсулацију коју можете да извршите.
Укључивање адресне фамилије VPNv4 између два рутера ствара само контекст дистрибуције рута и ништа више. Оно не инсталира путању прослеђивања и не каже која ће инкапсулација пренети кориснички пакет до удаљене крајње тачке. Када се ове две чињенице раздвоје, питање „да ли је ово потребно MPLS у језгру“ постаје уже и подобно за одговор питање о равни података коју платформа подржава.
Шта адресна фамилија заправо преговара
Вишепротоколни BGP преноси информације о доступности мрежног слоја VPNv4 под AFI 1 и SAFI 128, и сваки запис спаја разликовник руте са префиксом и ознаком. Сесија преговара да обе стране могу да кодирају и декодирају те информације. Оно што не преговара јесте раван података. Све после овог пасуса тиче се прослеђивања, и ништа од тога није решено подизањем сесије.
Дакле, успешна сесија је доказ способности контролне равни, а не прослеђивања. Рутер може да држи хиљаде записа VPNv4 и ипак одбаци сваки кориснички пакет, и баш зато се ове две класе отказа на почетку мешају.
Обратите пажњу на ознаку у NLRI. То је сервисна ознака, везана за префикс унутар VRF, и има улогу у прослеђивању када пакет стигне до излазне крајње тачке. Да ли је чита било који транзитни уређај, одвојена је пројектна одлука.
Пријем, увоз и прослеђивање су три корака
Пријем руте, дозвола да се користи и способност да се њоме прослеђује обављају различити делови уређаја. BGP чува оно што чује; политика увоза и подударање циља руте одлучују која VRF може да је размотри; затим раван прослеђивања мора да реши објављени следећи скок у нешто што заиста може да пошаље на жицу.
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
Баш у овом средњем кораку живе најнеочекиванији откази. Рута може да буде присутна у BGP табели, важећа и чак најбоља, док табела рута VRF остаје празна јер ниједан циљ руте није одговарао листи увоза. Ништа не бележи грешку протокола, јер грешка протокола није настала.
Последњи корак је место где се показује подршка платформе. Следећи скок доступан у доњем слоју не решава се аутоматски као транспорт VPN услуге, и уређај може да захтева одређени тип тунела, одређену операцију са ознаком или обоје. Читање статуса решавања је информативније од читања броја рута.
IP језгро може да носи стек који никада не комутира
Разлику коју вреди сачувати треба повући између „језгро не извршава MPLS“ и „нигде у услузи не постоји ознака“. То су различите тврдње, и само прва се тиче транзитних уређаја. RFC 4023 дефинише преношење MPLS кроз IP или GRE тунеле, и баш тај механизам чини другу тврдњу могућом на потпуно IP језгру.
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningful
Транзитни рутери прослеђују према спољном IP одредишту и не требају ни корисничке префиксе ни изворно пребацивање ознака. На удаљеном крају спољни тунел се уклања и сервисна ознака наставља свој посао. Језгро је пренело непрозирни терет, и баш у томе је IP мрежа јака.
Оно што вам овај дизајн не даје јесте универзална гаранција. То није доказ да сваки рутер решава сваки следећи скок VPNv4 преко било ког GRE интерфејса, и није разлог да избришете радну изворну MPLS конфигурацију. То је противпример универзалној тврдњи, и практично питање остаје локално за платформу. Забележите то питање као ограничење платформе, а не као правило протокола.
Прођите ланац на уређају док се не сломи
Почните од примљене руте и зауставите се на првом кораку који не успева, јер каснији кораци не могу да се дијагностикују док је ранији сломљен. Четири наредбе покривају већину тога у типичној имплементацији.
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A
Читајте их као низ, а не као четири независне провере. Прва потврђује да је фамилија активна и да партнер размењује руте; друга показује да ли је префикс стигао са употребљивим следећим скоком; трећа доказује подобност за увоз; четврта показује да ли је раван прослеђивања везала ознаку или тунел за њега.
Затим тестирајте путању радног оптерећења у оба смера, са MTU који преживљава инкапсулацију. GRE додаје бајтове заглавља, и путања која прође мале сонде може да не успе на пакетима пуне величине само у једном смеру, што изгледа као отказ апликације, а не транспорта.
Две оперативне напомене затварају круг. GRE је инкапсулација, не поверљивост, па неповерљива транзитна мрежа треба подржану безбедносну поставку изнад, а не претпоставку. И запишите коју инкапсулацију платформа заиста подржава пре прегледа дизајна, јер тај један одговор одлучује да ли је језгро само-IP важећи избор или план који не може да прослеђује.