Are nevoie VPNv4 de MPLS în nucleu? Nu neapărat

Activarea familiei de adrese VPNv4 între doi routere creează doar un context de distribuire a rutelor și nimic mai mult. Nu instalează o cale de forwarding și nu spune ce incapsulare va duce un pachet de client până la punctul final îndepărtat. Odată separate aceste două fapte, întrebarea «are nevoie asta de MPLS în nucleu» devine mai îngustă și poate primi un răspuns, despre planul de date pe care îl suportă platforma.

Ce negociază de fapt familia de adrese

BGP multiprotocol transportă informațiile de accesibilitate ale stratului de rețea VPNv4 sub AFI 1 și SAFI 128, iar fiecare intrare asociază un distinctor de rută cu un prefix și o etichetă. Sesiunea negociază că ambele părți pot codifica și decodifica acele informații. Ce nu negociază este un plan de date. Tot ce urmează acestui paragraf privește forwardingul, iar nimic din asta nu este decis de ridicarea sesiunii.

Deci o sesiune reușită este dovada capacității planului de control, nu a forwardingului. Un router poate ține mii de intrări VPNv4 și totuși poate elimina fiecare pachet de client, și de aceea cele două clase de eșec sunt confundate de la bun început.

Observați eticheta din NLRI. Este o etichetă de serviciu, legată de un prefix în interiorul unei VRF, și are un rol de forwarding când pachetul ajunge la punctul final de ieșire. Dacă vreun dispozitiv de tranzit o citește este o decizie de proiectare separată.

Recepție, import și forwarding sunt trei pași

Primirea unei rute, permisiunea de a o folosi și capacitatea de a face forwarding cu ea sunt realizate de părți diferite ale echipamentului. BGP stochează ce aude; politica de import și potrivirea țintei rutei decid ce VRF o poate lua în considerare; apoi planul de forwarding trebuie să rezolve următorul salt anunțat în ceva ce poate într-adevăr împinge pe un cablu.

În acest pas intermediar locuiesc cele mai surprinzătoare eșecuri. O rută poate fi prezentă în tabelul BGP, validă și chiar cea mai bună, în timp ce tabelul de rute al VRF rămâne gol pentru că nicio țintă de rută nu s-a potrivit cu lista de import. Nimic nu înregistrează o eroare de protocol, pentru că nu a avut loc nicio eroare de protocol.

Ultimul pas este locul unde se vede suportul platformei. Un următor salt accesibil în stratul inferior nu este rezolvabil automat ca transport de serviciu VPN, iar echipamentul poate cere un anumit tip de tunel, o anumită operație cu etichete sau ambele. Citirea stării de rezolvare este mai informativă decât citirea numărului de rute.

Un nucleu IP poate transporta un stack pe care nu îl comută niciodată

Distincția care merită păstrată este între «nucleul nu rulează MPLS» și «nu există nicio etichetă nicăieri în serviciu». Sunt afirmații diferite, și doar prima se referă la dispozitivele de tranzit. RFC 4023 definește transportul MPLS prin tuneluri IP sau GRE, și acesta este mecanismul care face posibilă a doua afirmație pe un nucleu complet 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

Routerele de tranzit fac forwarding după destinația IP exterioară și nu au nevoie nici de prefixele clienților, nici de comutarea nativă de etichete. La capătul îndepărtat tunelul exterior este eliminat și eticheta de serviciu își reia lucrul. Nucleul a mutat o încărcătură opacă, și exact la asta o rețea IP este bună.

Ceea ce acest design nu vă oferă este o garanție universală. Nu este dovada că fiecare router rezolvă fiecare următor salt VPNv4 prin orice interfață GRE și nu este un motiv să ștergeți o configurație MPLS nativă care funcționează. Este un contraexemplu la afirmația universală, iar întrebarea practică rămâne locală platformei. Înregistrați acea întrebare ca o limitare a platformei, nu ca o regulă de protocol.

Parcurgeți lanțul pe echipament până se rupe

Începeți de la ruta primită și opriți-vă la primul pas care eșuează, pentru că pașii următori nu pot fi diagnosticați cât timp unul anterior este rupt. Patru comenzi acoperă cea mai mare parte a acestui lucru într-o implementare tipică.

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

Citiți-le ca o secvență și nu ca patru verificări independente. Prima confirmă că familia este activă și că vecinul schimbă rute; a doua arată dacă prefixul a sos-it cu un următor salt utilizabil; a treia dovedește eligibilitatea pentru import; a patra arată dacă planul de forwarding a legat de el o etichetă sau un tunel.

Apoi testați calea încărcării în ambele direcții, cu un MTU care supraviețuiește incapsulării. GRE adaugă octeți de antet, iar o cale care trece de sonde mici poate eșua pe pachete de dimensiune completă doar într-o direcție, ceea ce arată ca o defecțiune a aplicației și nu a transportului.

Două note operaționale închid ciclul. GRE este incapsulare, nu confidențialitate, deci o rețea de tranzit neîncrezută are nevoie de o soluție de securitate suportată deasupra și nu de o presupunere. Și înregistrați ce incapsulare suportă de fapt platforma înainte de revizuirea proiectării, pentru că acel singur răspuns decide dacă un nucleu doar IP este o alegere validă sau un plan care nu poate face forwarding.