De la o rută RIP din CE la o VRF la distanță: unde are loc exportul

Un update RIPv2 sosește la provider edge, intră într-un tabel de rutare VRF și se oprește acolo dacă ceva nu îl exportă explicit. Trei decizii au loc în succesiune și fiecare poate refuza prefixul din propriul motiv. Citirea lor ca un singur eveniment este motivul pentru care oamenii caută în echipamentul greșit atunci când un sediu la distanță nu poate ajunge la o rețea pe care CE-ul o anunță clar. Urmați ruta prin PE și succesiunea devine evidentă.

Ce face PE-ul cu un update RIP

PE-ul primește update-ul pe interfața VRF, verifică faptul că sursa este un vecin permis și instalează prefixul în tabelul de rutare VRF cu un număr de salturi derivat din anunț. Acel tabel este un tabel de rutare normal, cu distanțe administrative proprii și cu propria alegere a celei mai bune căi. Dacă CE-ul anunță același prefix de două ori cu metrici diferite, doar cel mai bun supraviețuiește în tabel. Nimic din acest pas nu implică backbone-ul furnizorului.

Prefixul există acum în contextul de rutare al unui singur client, ceea ce este departe de a fi accesibil oriunde altundeva.

Exportul este un act de politică, nu o consecință a protocolului

Pentru a părăsi VRF-ul, o rută trebuie redistribuită în procesul MP-BGP care transportă rute VPN și are nevoie de o extended community de tip route target care să identifice ce VRF-uri la distanță o pot importa. Arhitectura din RFC 4364 ține aceste schimburi separate de protocolul CE-PE exact din acest motiv. Folosirea RIP la margine nu spune nimic despre ce ar trebui să traverseze rețeaua furnizorului.

Scrieți contractul de export înainte de a configura ceva: prefixele clienților care trebuie să fie accesibile la distanță, rutele care trebuie să rămână locale și orice rute implicite, rute mai specifice sau excepții pentru servicii partajate. Comparați acel contract cu VRF-ul real, nu cu unul cu nume similar al altui client.

Partea de import este o a doua politică, cu propriile route targets, iar un export potrivit cu un import nepotrivit produce un prefix care există în backbone și nu apare în niciun tabel de la distanță.

Redistribuirea și origination-ul explicit se comportă diferit

Redistribuirea ia rutele care există deja în tabelul VRF și le copiază în BGP, filtrate de un route map. Map-ul decide ce prefixe sunt eligibile și ce atribute poartă, iar metrica trebuie stabilită explicit, pentru că un număr de salturi RIP nu are sens ca metrică BGP. Tot ce lăsați nesetat este moștenit într-un mod care de obicei îl surprinde pe cel care citește configurația șase luni mai târziu.

Redistribuirea mutuală este locul unde apar daunele tăcute. Un prefix exportat în BGP poate reveni printr-un al doilea punct de redistribuire, iar fără tag-uri sau filtre ruta oscilează în timp ce ambele tabele par plauzibile în orice moment. Filtrați pe tag-urile aplicate la margine, în loc să vă bazați pe topologie pentru a împiedica calea de întoarcere.

Origination-ul explicit pare mai ordonat și nu este necondiționat. Un network statement are de obicei nevoie de o rută potrivită în tabelul de rutare înainte ca prefixul să fie originat, așa că anunțul dispare în momentul în care CE-ul nu mai anunță prefixul. Acesta este adesea comportamentul dorit și nu este același lucru cu o rută statică ce rămâne configurată pentru totdeauna. Verificați regula reală a platformei în loc să presupuneți unul dintre comportamente.

În orice caz, întrebarea de pus pentru fiecare prefix este care sursă activă îl face eligibil și ce se întâmplă când acea sursă dispare.

Verificați lanțul în patru locuri

Priviți anunțul CE, tabelul de rutare VRF, tabelul de rute VPN cu route target-ul său și importul în VRF-ul la distanță, în această ordine. Pe IOS asta înseamnă ieșirea vecinilor CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, și aceeași comandă pe PE-ul de la distanță. Pe IOS-XR ieșirea echivalentă se află sub show bgp vrf CUSTOMER ipv4 unicast. Numele comenzilor diferă, cele patru puncte de control nu.

Verificați un prefix care ar trebui respins la fel de atent ca unul care ar trebui să treacă, pentru că o politică ce permite tot pare identică cu una corectă până la prima excepție. Apoi urmăriți un withdrawal: închideți interfața CE și confirmați că intrarea de la distanță dispare în intervalul de timp așteptat, în loc să persiste.

Notați cine deține fiecare politică. Când furnizorul operează CE-ul, comportamentul livrat aparține contractului de serviciu, iar un protocol sau o politică de withdrawal diferită pe echipamentul administrat este mai întâi o problemă de documentație și abia apoi una de rutare.