Nga një rrugë RIP në CE drejt një VRF të largët: ku ndodh eksporti

Një përditësim RIPv2 arrin në provider edge, hyn në një tabelë rrugëtimi VRF dhe ndalon aty, përveç nëse diçka e eksporton shprehimisht. Tri vendime ndodhin me radhë dhe secili mund ta refuzojë prefiksin për arsyen e vet. Leximi i tyre si një ngjarje e vetme është arsyeja pse njerëzit kërkojnë në pajisjen e gabuar kur një lokacion i largët nuk arrin një rrjet që CE e shpall qartë. Ndiqni rrugën përmes PE dhe sekuenca bëhet e dukshme.

Çfarë bën PE me një përditësim RIP

PE merr përditësimin në ndërfaqen VRF, verifikon që burimi është një fqinj i lejuar dhe instalon prefiksin në tabelën e rrugëtimit VRF me një numër hopsh të nxjerrë nga shpallja. Ajo tabelë është një tabelë rrugëtimi normale, me distancat e veta administrative dhe zgjedhjen e vet të rrugës më të mirë. Nëse CE e shpall të njëjtin prefiks dy herë me metrika të ndryshme, vetëm ai më i miri mbijeton në tabelë. Asgjë në këtë hap nuk përfshin backbone-in e ofruesit.

Prefiksi tani ekziston brenda kontekstit të rrugëtimit të një klienti të vetëm, gjë që është shumë larg nga të qenit i arritshëm kudo tjetër.

Eksporti është akt politike, jo pasojë e protokollit

Për të dalë nga VRF, një rrugë duhet të rishpërndahet në procesin MP-BGP që mban rrugët VPN dhe i duhet një extended community route target që identifikon cilat VRF të largëta mund ta importojnë. Arkitektura në RFC 4364 i mban ato shkëmbime të ndara nga protokolli CE-PE pikërisht për këtë arsye. Përdorimi i RIP në buzë nuk thotë asgjë për atë që duhet të kalojë rrjetin e ofruesit.

Shkruani kontratën e eksportit përpara se të konfiguroni çdo gjë: prefikset e klientit që duhet të jenë të arritshme nga distanca, rrugët që duhet të mbeten lokale dhe çdo rrugë e paracaktuar, rrugë më specifike ose përjashtime për shërbime të përbashkëta. Krahasoni atë kontratë me VRF-në reale, jo me një VRF me emër të ngjashëm që i përket një klienti tjetër.

Ana e importit është një politikë e dytë me route target-et e veta, dhe një eksport përputhës me një import të papërputhshëm prodhon një prefiks që ekziston në backbone dhe nuk shfaqet në asnjë tabelë të largët.

Rishpërndarja dhe origjinimi i shprehur sillen ndryshe

Rishpërndarja merr rrugët që ekzistojnë tashmë në tabelën VRF dhe i kopjon në BGP, të filtruara nga një route map. Map-i vendos cilat prefikse janë të pranueshme dhe çfarë atributesh mbajnë, dhe metrika duhet vendosur shprehimisht, sepse një numër hopsh RIP nuk ka kuptim si metrikë BGP. Çdo gjë që lini e pavendosur trashëgohet në një mënyrë që zakonisht e surprizon personin që lexon konfigurimin gjashtë muaj më vonë.

Rishpërndarja e ndërsjellë është vendi ku ndodh dëmi i heshtur. Një prefiks i eksportuar në BGP mund të kthehet përmes një pike të dytë rishpërndarjeje dhe, pa tag-e ose filtra, rruga lëkundet ndërsa të dyja tabelat duken të besueshme në çdo çast. Filtroni sipas tag-eve të aplikuara në buzë, në vend që të mbështeteni te topologjia për të parandaluar rrugën e kthimit.

Origjinimi i shprehur duket më i rregullt dhe nuk është i pakushtëzuar. Një network statement zakonisht kërkon një rrugë përputhëse në tabelën e rrugëtimit përpara se prefiksi të origjinohet, kështu që shpallja zhduket në momentin që CE ndalon së shpalluri atë. Shpesh kjo është sjellja që dëshironi, dhe nuk është e njëjtë me një rrugë statike që mbetet e konfiguruar përgjithmonë. Kontrolloni rregullin real të platformës në vend që të supozoni njërën nga sjelljet.

Në çdo rast, pyetja për çdo prefiks është cili burim aktiv e bën të pranueshëm dhe çfarë ndodh kur ai burim zhduket.

Verifikoni zinxhirin në katër vende

Shikoni shpalljen e CE, tabelën e rrugëtimit VRF, tabelën e rrugëve VPN me route target-in e saj dhe importin në VRF-në e largët, në këtë rend. Në IOS kjo do të thotë dalja e fqinjëve CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, dhe e njëjta komandë në PE-në e largët. Në IOS-XR dalja ekuivalente ndodhet nën show bgp vrf CUSTOMER ipv4 unicast. Emrat e komandave ndryshojnë, katër pikat e kontrollit jo.

Kontrolloni një prefiks që duhet të refuzohet po aq kujdesshëm sa një që duhet të kalojë, sepse një politikë që lejon gjithçka duket identike me një të saktë derisa të vijë përjashtimi i parë. Pastaj vëzhgoni një withdrawal: fikni ndërfaqen CE dhe konfirmoni që hyrja e largët zhduket brenda kohëmatësit të pritur, në vend që të mbetet.

Regjistroni kush zotëron secilën politikë. Kur ofruesi operon CE-në, sjellja e dorëzuar i përket kontratës së shërbimit, dhe një protokoll ose politikë withdrawal e ndryshme në pajisjen e menaxhuar është fillimisht problem dokumentacioni dhe vetëm pastaj problem rrugëtimi.