Rutarea sucursalelor MPLS: ce învață CE și de la cine

Un host dintr-o sucursală deschide o conexiune către un server din alta, iar ambele locații stau în spatele aceleiași VPN MPLS de nivel 3 administrată. Hostul cunoaște doar propriul gateway implicit și nimic altceva, ceea ce este corect. Important este că marginea de client locală predă pachetul marginii sale de furnizor, iar starea de rutare VPN a furnizorului îl livrează sucursalei care deține prefixul de destinație.

Urmărirea unui pachet de-a lungul căii este cea mai rapidă cale de a vedea care parte este responsabilitatea clientului și care parte aparține serviciului.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Unde se termină treaba fiecărui salt

CE-A are nevoie de o rută către LAN-ul îndepărtat care să indice conexiunea locală la furnizor, nu adresa WAN a sucursalei îndepărtate. Apoi furnizorul transportă pachetul prin propriul nucleu folosind starea de rutare VPN, iar CE-B îl livrează pe LAN-ul de destinație. În niciun moment un host nu trebuie să înțeleagă etichete, VRF sau circuitul de internet al celeilalte părți.

Greșeala care apare mereu în tichete este configurarea adresei WAN a sucursalei B ca următor salt în sucursala A. Ambele sucursale au cumpărat același serviciu, așa că pare că ar trebui să fie vecine. Nu sunt: un următor salt trebuie să fie accesibil prin designul de rutare pe care îl aveți cu adevărat, iar CE-ul îndepărtat este de obicei la multe salturi distanță, în spatele unor echipamente pe care nu le administrați. O rută statică construită pe această presupunere apare ca activă și nu se rezolvă în nimic, ceea ce este mai rău decât o rută lipsă, pentru că în tabel pare corectă.

RFC 4364 separă schimbul dintre marginea de client și marginea de furnizor de distribuirea rutelor VPN de către furnizor, iar aceasta este exact granița despre care este acest ghid. Treaba clientului este să îi spună marginii sale ce poate livra și să accepte accesibilitatea pe care serviciul o oferă înapoi.

Asupra a ce trebuie să cadă de acord predarea

Alegeți mecanismul împreună cu furnizorul, nu în jurul lui. Rutele statice, BGP sau o înțelegere privind protocolul de rutare între CE și PE sunt toate legitime, iar OSPF are un model MPLS VPN definit pentru o astfel de predare. Niciuna dintre ele nu este motiv să construiești o adiacență OSPF între două margini de client îndepărtate printr-un nucleu de furnizor nespecificat, pentru că este un design la care furnizorul nu a fost de acord și pe care nu îl poate susține.

Înainte ca un LAN nou să intre în exploatare, notați patru lucruri: prefixul, ruta locală următoare pe CE, anunțul pe care furnizorul îl va accepta și rutele pe care furnizorul le va returna. Adăugați orice filtrare, limită de prefixe sau restricție între locații impusă de contract. O adiacență sănătoasă este un canal de schimb de informații și nu este dovada că un anumit prefix a fost acceptat; sesiunea poate fi activă în timp ce noua subrețea stă într-un filtru.

Apoi urmăriți răspunsul. Sucursala B are nevoie de o rută înapoi către LAN-ul sursă, iar hostul din partea receptoare are nevoie de propriul gateway și de propriile permisiuni de serviciu. O rută care apare pe CE-A stabilește jumătate de drum dus-întors, iar jumătatea de drum este motivul pentru care o direcție a unui test ping pare sănătoasă în timp ce aplicația încă eșuează.

Verificați ambele predări înainte de acceptare

Colectați starea de rutare pe ambele margini de client, confirmați cu furnizorul că prefixele LAN dorite au fost acceptate în VPN, apoi testați o aplicație permisă în fiecare direcție. Tabelele de rutare singure nu dovedesc că aplicația funcționează, iar un test de aplicație singur nu vă spune care plan de control a eșuat când nu funcționează.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Citiți cele trei ieșiri împreună. Prima spune ce crede marginea, a doua spune ce a învățat și de la ce partener, iar a treia spune ce va transmite efectiv. Dezacordul dintre ele este de obicei o problemă de politică sau recursie, nu un anunț lipsă, și merită rezolvat înainte de a cere furnizorului să investigheze. Aduceți aceste trei ieșiri la discuția cu operatorul, pentru că răspund la majoritatea întrebărilor pe care un inginer de suport le-ar pune altfel.

Aflați ce nu oferă serviciul

Acesta este acces rutat de nivel 3. Nu este un circuit de nivel 2 care extinde difuzările între birouri, așa că protocoalele de descoperire, aplicațiile dependente de difuzare și presupunerile despre un segment partajat nu călătoresc cu el. Tipărirea, răsfoirea numelor și orice depinde de un segment local au nevoie de propriul design.

Separarea VPN nu este nici criptare. Comutarea etichetelor ține clienții separați în rețeaua furnizorului și nu face încărcătura confidențială dacă contractul cere confidențialitate. Acolo unde contează, aplicația sau un strat suprapus trebuie să o furnizeze.

În final, păstrați modelul serviciului scris lângă configurația de rutare a locației. Următorul inginer care adaugă o subrețea ar trebui să poată citi ce prefixe sunt anunțate, cine le acceptă și care este calea de întoarcere așteptată: specificația BGP/MPLS IP VPN este referința pentru modelul din spatele tuturor acestora.