Rrugëtimi i degëve MPLS: çfarë mëson CE dhe nga kush

Një host në një degë hap një lidhje me një server në një degë tjetër, dhe të dyja lokacionet qëndrojnë pas të njëjtit VPN MPLS të nivelit 3 të menaxhuar. Host-i njeh vetëm portën e vet të paracaktuar dhe asgjë tjetër, gjë që është e saktë. E rëndësishme është që buza vendore e klientit ia dorëzon paketën buzës së ofruesit të saj, dhe gjendja e rrugëtimit të VPN të ofruesit e çon atë te dega që zotëron prefiksin e destinacionit.

Ndjekja e një pakete përgjatë rrugës është mënyra më e shpejtë për të parë cila pjesë është përgjegjësi e klientit dhe cila pjesë i përket shërbimit.

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

Ku mbaron puna e secilit hop

CE-A ka nevojë për një rrugë drejt LAN-it të largët që tregon lidhjen e saj vendore me ofruesin, jo adresën WAN të degës së largët. Më pas ofruesi e transporton paketën nëpër bërthamën e vet duke përdorur gjendjen e rrugëtimit të VPN, dhe CE-B e dorëzon në LAN-in e destinacionit. Në asnjë moment një host nuk ka nevojë të kuptojë etiketa, VRF ose qarkun e internetit të palës tjetër.

Gabimi që përsëritet vazhdimisht në tiketat është konfigurimi i adresës WAN të degës B si hop i ardhshëm në degën A. Të dyja degët blenë të njëjtin shërbim, ndaj duket sikur duhet të jenë fqinjë. Nuk janë: një hop i ardhshëm duhet të jetë i arritshëm përmes dizajnit të rrugëtimit që keni në të vërtetë, dhe CE-ja e largët zakonisht ndodhet shumë hop-e larg, pas pajisjeve që nuk i administroni. Një rrugë statike e ndërtuar mbi këtë supozim shfaqet si aktive dhe nuk zgjidhet në asgjë, gjë që është më keq se një rrugë që mungon, sepse në tabelë duket e saktë.

RFC 4364 e ndan shkëmbimin midis buzës së klientit dhe buzës së ofruesit nga shpërndarja e rrugëve të VPN nga ofruesi, dhe ky është pikërisht kufiri për të cilin flet ky udhëzues. Puna e klientit është t'i thotë buzës së vet çfarë mund të dorëzojë dhe të pranojë arritshmërinë që shërbimi ofron mbrapsht.

Për çfarë duhet të bien dakord në dorëzim

Zgjidhni mekanizmin bashkë me ofruesin, jo rreth tij. Rrugët statike, BGP ose një marrëveshje protokolli rrugëtimi midis CE dhe PE janë të gjitha legjitime, dhe OSPF ka një model MPLS VPN të përcaktuar për një dorëzim të tillë. Asnjëra prej tyre nuk është arsye për të ndërtuar një fqinjësi OSPF midis dy buzëve të klientit të largët përmes një bërthame ofruesi të paspecifikuar, sepse ky është një dizajn me të cilin ofruesi nuk është dakord dhe nuk mund ta mbështesë.

Përpara se një LAN i ri të vihet në punë, shkruani katër gjëra: prefiksin, rrugën vendore pasuese në CE, njoftimin që ofruesi do të pranojë dhe rrugët që ofruesi do të kthejë. Shtoni çdo filtrim, kufi prefiksesh ose kufizim midis lokacioneve që imponon kontrata. Një fqinjësi e shëndoshë është një kanal për shkëmbim informacioni, dhe nuk është provë se një prefiks i caktuar u pranua; sesioni mund të jetë aktiv ndërsa nënrrjeti juaj i ri qëndron brenda një filtri.

Më pas ndiqni përgjigjen. Dega B ka nevojë për një rrugë kthimi drejt LAN-it burim, dhe host-i në anën pritëse ka nevojë për portën e vet dhe lejet e veta të shërbimit. Një rrugë që shfaqet në CE-A vendos gjysmën e udhëtimit vajtje-ardhje, dhe pikërisht gjysma e udhëtimit është arsyeja pse një drejtim i testit ping duket i shëndoshë ndërsa aplikacioni ende dështon.

Verifikoni të dyja dorëzimet përpara pranimit

Mblidhni gjendjen e rrugëtimit në të dyja buzët e klientit, konfirmoni me ofruesin se prefikset e synuara të LAN-it u pranuan në VPN, dhe më pas provoni një aplikacion të lejuar në çdo drejtim. Vetëm tabelat e rrugëve nuk provojnë se aplikacioni funksionon, dhe vetëm testi i aplikacionit nuk ju thotë cili plan kontrolli dështoi kur ai nuk funksionon.

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

Lexoni të tre daljet së bashku. I pari thotë çfarë beson buza, i dyti thotë çfarë mësoi dhe nga cili partner, dhe i treti thotë çfarë do të përcjellë në të vërtetë. Mospërputhja midis tyre është zakonisht problem politike ose rekursioni, jo një njoftim që mungon, dhe ia vlen të zgjidhet përpara se t'i kërkoni ofruesit të hetojë. Çoni këto tre dalje në bisedën me operatorin, sepse përgjigjen për shumicën e pyetjeve që një inxhinier mbështetjeje do t'ju bënte ndryshe.

Dijeni çfarë nuk ofron shërbimi

Ky është akses i rrugëtuar i nivelit 3. Ky nuk është një qark i nivelit 2 që shtrin transmetimet midis zyrave, prandaj protokollet e zbulimit, aplikacionet që varen nga transmetimi dhe supozimet për një segment të përbashkët nuk udhëtojnë me të. Printimi, shfletimi i emrave dhe çdo gjë që varet nga një segment vendor kanë nevojë për dizajnin e tyre.

Ndarja e VPN nuk është as kriptim. Komutimi i etiketave i mban klientët të ndarë brenda rrjetit të ofruesit, dhe nuk e bën ngarkesën konfidenciale nëse kontrata kërkon konfidencialitet. Aty ku kjo ka rëndësi, duhet ta sigurojë aplikacioni ose një shtresë mbi të.

Së fundi, mbajeni modelin e shërbimit të shkruar pranë konfigurimit të rrugëtimit të lokacionit. Inxhinieri i ardhshëm që shton një nënrrjet duhet të jetë në gjendje të lexojë cilat prefikse njoftohen, kush i pranon dhe cila është rruga e kthimit e pritur: specifikimi BGP/MPLS IP VPN është referenca për modelin që qëndron pas gjithë kësaj.