Dorëzimi i L3VPN: rrugë private, një rrugë e paracaktuar apo një tabelë e plotë?

Qarku juaj është lart, VRF-ja është konfiguruar dhe ofruesi bën një pyetje të shkurtër që përcakton pjesën tjetër të projektimit: çfarë duhet të marrë skaji i klientit? Tri përgjigje janë të zakonshme dhe asnjëra nuk rrjedh nga fakti se ekziston një stivë etiketash. Ato janë vendime shërbimi për vendin ku trafiku largohet nga dega.

Kalimi i dorëzimit sipas radhës është mënyra më e lirë për ta bërë këtë si duhet. Filloni nga ajo që ndodh me trafikun që nuk përputhet me asgjë, më pas shkruani prefikset private dhe sjelljen e tyre në dështim, dhe vetëm pastaj flisni për sa i madh është furnizimi që jeni gati të mbani.

Filloni me trafikun që askush nuk e planifikoi

Bëni një pyetje përpara se të shfaqet ndonjë listë prefiksesh: kur një paketë nuk përputhet me asnjë rrugë private, ku duhet të shkojë? Një degë me qark interneti të vetin zakonisht mban një të paracaktuar lokale, kështu që trafiku normal i uebit del përmes firewall-it lokal dhe nuk e prek kurrë ofruesin. Në atë projekt VPN-ja mban vetëm sajtet private të largëta, dhe prefikset më specifike bëjnë zgjedhjen.

Një degë që synohet të përdorë një dalje qendrore është rasti i kundërt. Atje e paracaktuara tregon brenda shërbimit, dhe ofruesi ose sajti qendror zotëron përcjelljen, rrugëtimin e kthimit dhe çdo përkthim. Të thuash "e paracaktuar në VPN" pa atë pronar prodhon një degë që zgjidh emrat dhe nuk arrin asgjë.

Dy projektet ndryshojnë në atë se si duket një dështim rrugëtimi, dhe për këtë arsye hamendja kushton shtrenjtë. Me një të paracaktuar lokale, një rrugë private e humbur e dërgon atë trafik në internet, ku firewall-i e hedh ose, më keq, përgjigjet diçka që nuk e kishit menduar. Me një të paracaktuar qendrore, i njëjti humbje heq plotësisht aksesin në internet dhe bileta vjen si "e gjithë dega është poshtë". Asnjëri dështim nuk është i gabuar në vetvete, por vetëm njëri përputhet me shërbimin që shitët, dhe një konfigurim BGP i vetëm nuk ju thotë cilin ndërtuat.

Shkruani prefikset private bashkë me rastin e dështimit

Renditni prefikset që dega duhet të arrijë dhe shënoni cilat janë përmbledhur. Një agregat një bit më i gjerë tërheq destinacione të panjohura në VPN, dhe kjo është në rregull vetëm nëse ana e largët i zotëron vërtet dhe i përcjell.

Më pas përshkruani sjelljen e synuar kur shërbimi privat dështon. Një rrugë hedhëse e mbajtur e mban trafikun larg një rruge të paautorizuar dhe jep një ndërprerje të pastër e të pritur. Një e paracaktuar lundruese mund të ruajë disponueshmërinë duke kaluar në një rrugë rezervë, por vetëm nëse asaj rrugë rezervë i lejohet të mbajë atë trafik.

Mbajini disponueshmërinë dhe rezervën e lejuar si dy kërkesa të ndara në dokumentin e dorëzimit. Ekipet që i bashkojnë përfundojnë duke debatuar nëse dega duhej të kishte rënë, në vend që të kontrollojnë nëse politika e rënë dakord u zbatua.

Kontrolloni çfarë instaloi vërtet CE-ja

Qëllimi i konfigurimit dhe gjendja e përcjelljes ndryshojnë mjaft shpesh saqë verifikimi i përket dorëzimit, jo rishikimit të incidentit. Në një customer edge IOS-XE, tre komandat më poshtë përgjigjen tre pyetjeve të ndryshme: çfarë u ofrua, çfarë u pranua dhe çfarë po përdoret në të vërtetë.

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

Ekzekutoni të tre në ditën e dorëzimit dhe jo një muaj më vonë, sa kohë dikush kujton ende çfarë u ra dakord. Dalja e parë varet nga soft-reconfiguration inbound ose një rifreskim rrugësh i ruajtur; pa njërën ose tjetrën, CE-ja nuk mund t'ju tregojë çfarë refuzoi. E dyta tregon rrugët e pranuara dhe më të mirat pas politikës. E treta tregon ku shkon vërtet e paracaktuara, dhe ajo është rreshti më i dobishëm i të gjithë dorëzimit.

Ekzekutoni të njëjtat kontrolle në një CE të dytë nëse sajti ka dy lidhje. Pranimi asimetrik midis dy skajeve është një shkak i zakonshëm i "punon nga një server dhe jo nga tjetri", dhe është i padukshëm në një diferencë konfigurimi që duket simetrike.

Kualifikoni një furnizim më të madh në vend që ta supozoni

Ndonjëherë klienti ka vërtet nevojë për informacion mbi rrugët e internetit brenda VRF-së, për rrugëtim politikash ose për një dalje qendrore që drejton sipas prefiksit. Kjo është një kërkesë që duhet deklaruar, kufizuar dhe çmuar, jo një e paracaktuar e fshehur. Vjen me memorie për RIB dhe FIB, CPU për përditësime, mirëmbajtje filtrash dhe një pronar për tabelën që rezulton.

Argumentet mbi kapacitetin gabojnë në të dyja drejtimet. Një tabelë e plotë nuk është e ndaluar brenda VRF-së, dhe nuk është as falas. Po ashtu, kostoja e sotme nuk mund të nxirret nga një numër i vjetër rrugësh, dhe një ndarje më e vogël etiketash nuk heq koston e ruajtjes së rrugëve.

Specifikimi BGP/MPLS IP VPN diskuton disa rregullime aksesi në internet pranë vetë shërbimit VPN dhe nuk shpall një tabelë të plotë ose një të paracaktuar të detyrueshme për çdo klient, dhe pikërisht ai seksion vlen të tregohet kur shfaqet një pretendim për "praktikë standarde": RFC 4364.

Mbyllni dorëzimin duke regjistruar bashkësinë e shpallur, bashkësinë e marrë dhe bashkësinë e zgjedhur pranë politikës së daljes së rënë dakord, dhe duke provuar një destinacion privat, një destinacion publik të synuar dhe një rast humbjeje rrugësh. Një regjistrim i nënshkruar i atyre tre provave zgjidh më shumë debate sesa çdo deklaratë për atë që bëjnë shumica e rrjeteve.