Dy PE, një prefiks: pse RD vendos dukshmërinë
Dy routera buzë që shpallin të njëjtin prefiks ndajnë një destinacion, përveç nëse route distinguisher-at e tyre ndryshojnë. Caktoni me qëllim, më pas kontrolloni VRF-në.
Dy routera buzë që shpallin të njëjtin prefiks klienti përshkruajnë një destinacion VPNv4 derisa diçka t’i ndajë, dhe ndarësi është route distinguisher. Ai e kualifikon prefiksin; nuk vendos kush e importon rezultatin, kjo është puna e route target. Caktoni RD nga grupi i rrugëve që duhet të mbeten të dallueshme në çdo domen ku ato shpallje mund të takohen, jo nga plani i skedarëve të një kutie të vetme. Numri që zgjidhni është një identitet nga i cili do të varen rishikimet e mëvonshme, prandaj i takon një inventari përpara se të hyjë në një konfigurim.
Një RD plus një prefiks është një destinacion
Një RD plus një prefiks IPv4 formojnë destinacionin VPNv4 që krahason rrafshi i kontrollit. Jepini dy PE-ve të njëjtin prefiks për klientë të ndryshëm dhe, pa RD të ndryshme, ata shpallin rrugë drejt një destinacioni. Asgjë në ekran nuk ju thotë se ky grupim është i gabuar, sepse platforma bën saktësisht atë që thotë identiteti. Ndryshoni RD-në në njërin prej tyre dhe shpallja e vjetër tërhiqet, ndërsa nën një identitet tjetër shfaqet një e re. Gjithçka në rrjedhën e poshtme që mbështetej te identiteti i vjetër, nga përzgjedhja e rrugës deri te një filtër operatori i ruajtur, tani i referohet diçkaje që nuk ekziston më.
Disa rrugë për një destinacion është sjellje normale e BGP-së, jo një simptomë. Një folës mund të mbajë disa rrugë të marra ndërsa zgjedh një rrugë më të mirë për përcjellje, dhe hendeku midis marrë dhe zgjedhur është vendi ku jetojnë pyetjet e dukshmërisë. Kur një rrugë duket se është zhdukur, konfirmoni nëse identiteti të cilit i përkiste ekziston ende përpara se të shikoni sesionin.
I njëjti RD, i njëjti destinacion, rrugë të ndryshme
Dërgoni një RD dhe një prefiks nga dy routera në emër të të njëjtit shërbim dhe të dy ofrojnë rrugë drejt një destinacioni, zakonisht me kërcime të ardhshme të ndryshme. Cila prej tyre do të kalojë një route reflector është një vendim për reflektorin: përzgjedhja e rrugës, aftësia për të shpallur dhe çdo politikë e shtresuar mbi të. Asnjëri prej routerave buzë nuk e kontrollon atë zgjedhje. Jepini dy shpalljeve RD të veçanta dhe secila bëhet destinacioni i vet, kështu që të dyja mund t’i mbijetojnë një rrafshi kontrolli që përndryshe mbart vetëm rrugën e zgjedhur për një identitet.
Dukshmëria dhe shumërrjedhshmëria takohen në VRF-në marrëse, por nuk janë i njëjti vendim, dhe një reflektor që mbart dy identitete nuk ka konfiguruar një rrugë të dytë të instaluar. VRF-ja instalon atë që lejon politika e saj e importit dhe atë që lejon vetë cilësimi i saj i numrit maksimal të rrugëve. Kontrolloni atë cilësim veçmas kur dëshironi që rruga e dytë të përdoret dhe jo thjesht të jetë e dukshme.
Rregulli lokal i unicitetit nuk është politikë
T’i japësh çdo PE-je dhe çdo instance rrugëtimi RD-në e vet është një konventë e shëndoshë: emërton origjinën, mban shërbimet e palidhura nga përplasja mbi një identitet dhe i jep inventarit një çelës të qëndrueshëm. Disa platforma kërkojnë unicitet vetëm brenda kutisë dhe lejojnë shprehimisht që routerat të ndajnë një RD për të njëjtën instancë VPN. Ai leje është një kufizim implementimi, jo një rregull ndërmjet rrjeteve që mund t’i delegoni një furnizuesi. Nëse domeni përfshin ekipe, shkruajeni vetë politikën e caktimit.
Anëtarësimi nuk vjen kurrë nga shifrat. Një model si 65000:12 për një PE dhe 65000:13 për një tjetër është zakon, ndërsa objektivat e eksportit dhe importit që përputhen si 65000:112 janë ajo që e vendos një rrugë në një VRF. Trajtojeni RD-në si identitetin e një rruge dhe route target-in si lejen që e çon atë në një VRF.
Provoje ndryshimin në VRF, jo në ekran
Përpara se të prekni një RD, shkruani katër gjëra: çfarë shpall PE-ja sot, çfarë reflekton reflektori, çfarë importon VRF-ja marrëse dhe cilën rrugë zgjedh. Një RD i re tërheq një shpallje dhe fut një tjetër, kështu që ndryshimi shfaqet në të dyja anët e sesionit dhe lexohet lehtë gabimisht nëse shikoni vetëm anën që shpall. Pranimi duhet të mbështetet te arritshmëria që dëshironit, jo te një rresht shtesë që shfaqet në një listë prefiksesh. Tabela më poshtë i mban tre identifikuesit të mos përzihen gjatë asaj rishikimi.
| Identifier | Question it answers | What breaks when it is confused with another |
|---|---|---|
| Route distinguisher | Which route identity is this? | Two services collapse into one destination, so one advertisement withdraws the other |
| Route target | Who is allowed to import it? | Routes arrive in a VRF that should not have them, or never arrive at all |
| VRF import policy | What does this instance accept and install? | The route is visible on the PE but never selected in the VRF |
Filloni te PE-ja që shpall dhe krahasoni të dy identitetet për të njëjtin prefiks përpara se të hiqni ndonjë gjë. Komandat IOS më poshtë përgjigjen me radhë tri pyetjeve: a është ende aty shpallja e vjetër, a është identiteti i re i dukshëm për reflektorin dhe a e zgjedh VRF-ja prefiksin.
show bgp vpnv4 unicast rd 65000:12 203.0.113.0/24 show bgp vpnv4 unicast rd 65000:13 203.0.113.0/24 show ip route vrf CUSTOMER-A 203.0.113.0/24
Platformat e tjera shtypin të njëjtin informacion me një sintaksë tjetër, dhe pyetjet i mbijetojnë atij ndryshimi. Nëse identiteti i re mungon te reflektori, ndërsa PE-ja e liston si të shpallur, i dyshuari i parë është politika ose aftësia e reflektimit, jo numërimi.
Regjistroni PE-në, instancën, RD-në, objektivat e eksportit dhe importit dhe pronësinë e prefiksit në një vend, sepse caktimi i radhës është një kërkim dhe jo një hamendje vetëm kur ai regjistrim ekziston. Mbani RD-në e vjetër derisa identiteti i re të jetë i dukshëm në VRF-në marrëse, më pas tërhiqeni në një hap të dytë, që çdo fazë të mbetet e kthyeshme.