Predarea L3VPN: rute private, o rută implicită sau un tabel complet?

Circuitul este activ, VRF-ul este configurat, iar furnizorul pune o întrebare scurtă care decide restul proiectării: ce trebuie să primească marginea clientului? Trei răspunsuri sunt obișnuite și niciunul nu decurge din faptul că există un stivă de etichete. Sunt decizii de serviciu privind locul pe unde traficul părăsește filiala.

Parcurgerea predării în ordine este cea mai ieftină cale de a face acest lucru corect. Începeți cu ce se întâmplă cu traficul care nu se potrivește cu nimic, apoi notați prefixele private și comportamentul lor la defect, și abia după aceea discutați despre cât de mare este fluxul pe care sunteți dispus să îl transportați.

Începeți cu traficul pentru care nimeni nu a planificat

Puneți o întrebare înainte de a apărea orice listă de prefixe: când un pachet nu se potrivește cu nicio rută privată, unde ar trebui să meargă? O filială cu circuit propriu de internet păstrează de obicei o rută implicită locală, astfel încât traficul web obișnuit iese prin firewall-ul local și nu atinge niciodată furnizorul. În acea proiectare VPN-ul transportă doar site-urile private aflate la distanță, iar prefixele mai specifice fac selecția.

O filială menită să folosească o ieșire centrală este cazul opus. Acolo ruta implicită indică în interiorul serviciului, iar furnizorul sau site-ul central deține comutarea, rutarea de retur și orice traducere. A spune "implicit în VPN" fără acel proprietar produce o filială care rezolvă nume și nu ajunge la nimic.

Cele două proiectări diferă prin felul în care arată un defect de rutare, și de aceea ghicitul costă scump. Cu o rută implicită locală, o rută privată pierdută trimite acel trafic pe internet, unde firewall-ul îl aruncă sau, mai rău, răspunde ceva ce nu intenționați. Cu o rută implicită centrală, aceeași pierdere elimină complet accesul la internet și tichetul vine ca "întreaga filială este căzută". Niciun defect nu este greșit în sine, dar doar unul corespunde serviciului pe care l-ați vândut, iar o configurație BGP singură nu vă spune pe care l-ați construit.

Notați prefixele private împreună cu cazul lor de defect

Enumerați prefixele pe care filiala trebuie să le atingă și notați care dintre ele sunt rezumate. Un agregat cu un bit prea larg atrage destinații necunoscute în VPN, iar acest lucru este în regulă doar dacă partea îndepărtată le deține într-adevăr și le comută.

Apoi descrieți comportamentul dorit atunci când serviciul privat eșuează. O rută de eliminare păstrată ține traficul departe de o cale neautorizată și produce o întrerupere curată și așteptată. O rută implicită flotantă poate păstra disponibilitatea trecând pe o cale de rezervă, dar numai dacă acea cale de rezervă este autorizată să transporte acel trafic.

Păstrați disponibilitatea și rezerva permisă ca două cerințe separate în documentul de predare. Echipele care le unesc ajung să dezbată dacă filiala ar fi trebuit să cadă, în loc să verifice dacă politica convenită a fost implementată.

Verificați ce a instalat de fapt CE-ul

Intenția configurației și starea de comutare diverg suficient de des încât verificarea își are locul în predare, nu în analiza incidentului. Pe un customer edge IOS-XE, cele trei comenzi de mai jos răspund la trei întrebări diferite: ce a fost oferit, ce a fost acceptat și ce este folosit efectiv.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Rulați toate trei în ziua predării, nu o lună mai târziu, cât timp cineva își mai amintește ce s-a convenit. Prima ieșire depinde de soft-reconfiguration inbound sau de un route refresh stocat; fără una sau alta, CE-ul nu vă poate arăta ce a respins. A doua arată rutele acceptate și cele mai bune după politică. A treia vă spune unde merge de fapt ruta implicită, iar aceea este cea mai utilă linie din întreaga predare.

Rulați aceleași verificări pe un al doilea CE dacă site-ul are două conexiuni. Acceptarea asimetrică între două margini este o cauză obișnuită a "funcționează de pe un server și nu de pe celălalt", și este invizibilă într-un diff de configurație care pare simetric.

Calificați un flux mai mare în loc să îl presupuneți

Uneori clientul are într-adevăr nevoie de informații despre rutele de internet în interiorul VRF-ului, pentru policy routing sau pentru o ieșire centrală care dirijează după prefix. Aceasta este o cerință de declarat, delimitat și tarifat, nu o rută implicită ascunsă. Vine cu memorie pentru RIB și FIB, CPU pentru actualizări, întreținerea filtrelor și un proprietar pentru tabelul rezultat.

Argumentele privind capacitatea greșesc în ambele direcții. Un tabel complet nu este interzis în interiorul unui VRF și nici nu este gratuit. La fel, nu puteți deduce costul de astăzi dintr-un număr vechi de rute, iar o alocare mai mică de etichete nu elimină costul stocării rutelor.

Specificația BGP/MPLS IP VPN discută mai multe aranjamente de acces la internet alături de serviciul VPN în sine și nu declară un tabel complet sau o rută implicită obligatorii pentru fiecare client, iar aceea este secțiunea de indicat atunci când apare o afirmație despre "practica standard": RFC 4364.

Încheiați predarea notând setul anunțat, setul primit și setul selectat lângă politica de ieșire convenită și testând o destinație privată, o destinație publică intenționată și un caz de pierdere a rutei. O înregistrare semnată a acestor trei teste rezolvă mai multe dispute decât orice afirmație despre ce fac majoritatea rețelelor.