Du randaj enkursigiloj, kiuj reklamas la saman klientan prefikson, priskribas unu VPNv4-celon ĝis io disigas ilin, kaj la disigilo estas la route distinguisher. Ĝi kvalifikas la prefikson; ĝi ne decidas, kiu importas la rezulton, tio estas la tasko de la route target. Asignu RD-ojn el la aro de itineroj, kiuj devas resti distingeblaj en ĉiu domajno, kie tiuj reklamoj povas renkontiĝi, ne el la dosiera aranĝo de unu skatolo. La numero, kiun vi elektas, estas identeco, sur kiu dependos postaj revizioj, do ĝi apartenas al inventaro antaŭ ol ĝi eniras konfiguron.

RD plus prefikso estas unu celo

RD plus IPv4-prefikso formas la VPNv4-celon, kiun komparas la rega ebeno. Donu al du PE-oj la saman prefikson por malsamaj klientoj kaj, sen malsamaj RD-oj, ili reklamas vojojn al unu celo. Nenio sur ekrano diras al vi, ke tiu grupigo estas malĝusta, ĉar la platformo faras ĝuste tion, kion diras la identeco. Ŝanĝu la RD-on ĉe unu el ili kaj la malnova reklamo retiriĝas, dum sub alia identeco aperas nova. Ĉio malsupre, kio baziĝis sur la malnova identeco, de itinera selektado ĝis konservita operatora filtrilo, nun referencas al io, kio ne plu ekzistas.

Pluraj vojoj por celo estas ordinara BGP-konduto, ne simptomo. Parolanto povas teni plurajn ricevitajn vojojn dum ĝi elektas unu plej bonan por plusendado, kaj la breĉo inter ricevita kaj elektita estas kie loĝas la demandoj pri videbleco. Kiam vojo ŝajnas malaperinta, konfirmu, ĉu la identeco, al kiu ĝi apartenis, ankoraŭ ekzistas, antaŭ ol rigardi la seancon.

Sama RD, sama celo, malsamaj vojoj

Sendu unu RD-on kaj unu prefikson el du enkursigiloj nome de la sama servo kaj ambaŭ proponas vojojn al unu celo, kutime kun malsamaj sekvaj hopoj. Kiun el ili route reflector plusendas estas decido pri la reflector: ĝia voja selektado, ĝia reklama kapablo kaj iu ajn politiko metita supre. Neniu el la randaj enkursigiloj kontrolas tiun elekton. Donu al la du reklamoj apartajn RD-ojn kaj ĉiu fariĝas sia propra celo, tiel ke ambaŭ povas postvivi regan ebenon, kiu alie portas nur la elektitan vojon por unu identeco.

Videbleco kaj plureco renkontiĝas en la ricevanta VRF, sed ili ne estas la sama decido, kaj reflector portanta du identecojn ne agordis duan instalitan vojon. La VRF instalas kion ĝia importa politiko permesas kaj kion permesas ĝia propra agordo de maksimumaj vojoj. Kontrolu tiun agordon aparte, kiam vi volas, ke la dua vojo estu uzata, ne nur videbla.

Loka unikeca regulo ne estas politiko

Doni al ĉiu PE kaj ĉiu enkursiga okazo sian propran RD-on estas sana konvencio: ĝi nomas la originon, gardas nesrilatajn servojn de kolizio sur unu identeco kaj donas al la inventaro stabilan ŝlosilon. Iuj platformoj postulas unikecon nur ene de la skatolo kaj eksplicite permesas al enkursigiloj kunhavigi RD-on por la sama VPN-okazo. Tiu permeso estas efektiviga limigo, ne regulo inter retoj, kiun vi povas delegi al vendisto. Se la domajno etendiĝas trans teamoj, skribu la asignan politikon mem.

Membreco neniam venas el la ciferoj. Skemo kiel 65000:12 por unu PE kaj 65000:13 por alia estas kutimo, dum kongruaj eksportaj kaj importaj celoj kiel 65000:112 estas tio, kio metas itinero en VRF-on. Traktu la RD-on kiel la identecon de itinero kaj la route target kiel la permeson, kiu portas ĝin en VRF-on.

Pruvu la ŝanĝon sur la VRF, ne sur la ekrano

Antaŭ ol tuŝi RD-on, skribu kvar aferojn: kion la PE reklamas hodiaŭ, kion la reflector reflektas, kion la ricevanta VRF importas kaj kiun vojon ĝi elektas. Nova RD retiras unu reklamon kaj enkondukas alian, do la ŝanĝo montriĝas ambaŭflanke de la seanco kaj facile mislegeblas, se vi observas nur la reklaman flankon. Akcepto devus baziĝi sur la atingeblo, kiun vi volis, ne sur plia linio aperanta en prefiksa listo. La suba tabelo gardas la tri identigilojn de kunfandiĝo dum tiu revizio.

IdentifierQuestion it answersWhat breaks when it is confused with another
Route distinguisherWhich route identity is this?Two services collapse into one destination, so one advertisement withdraws the other
Route targetWho is allowed to import it?Routes arrive in a VRF that should not have them, or never arrive at all
VRF import policyWhat does this instance accept and install?The route is visible on the PE but never selected in the VRF

Komencu ĉe la reklamanta PE kaj komparu ambaŭ identecojn por la sama prefikso antaŭ ol forigi ion. La IOS-komandoj sube respondas tri demandojn laŭvice: ĉu la malnova reklamo ankoraŭ estas tie, ĉu la nova identeco estas videbla al la reflector kaj ĉu la VRF elektas la prefikson.

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

Aliaj platformoj presas la saman informon per alia sintakso, kaj la demandoj postvivas tiun ŝanĝon. Se la nova identeco mankas ĉe la reflector dum la PE listigas ĝin kiel reklamitan, la unua suspektato estas la politiko aŭ reklama kapablo de la reflector, ne la numerado.

Registru la PE-on, la okazon, la RD-on, la eksportajn kaj importajn celojn kaj la posedon de la prefikso en unu loko, ĉar la sekva asigno estas serĉo kaj ne konjekto nur kiam tiu registro ekzistas. Tenu la malnovan RD-on ĝis la nova identeco videblos en la ricevanta VRF, poste retiru ĝin en dua paŝo, por ke ĉiu etapo restu inversigebla.

Rilataj artikoloj