De CE RIP-itinero al fora VRF: kie okazas la eksporto

RIPv2-ĝisdatigo alvenas ĉe la rando de la provizanto, eniras VRF-enkursigan tabelon kaj haltas tie, se io ne eksplicite eksportas ĝin. Tri decidoj okazas sinsekve, kaj ĉiu povas rifuzi la prefikson pro sia propra kialo. Legi ilin kiel unu solan eventon estas la kialo, kial homoj postkuras la malĝustan skatolon, kiam fora ejo ne povas atingi reton, kiun la CE klare anoncas. Sekvu la itinieron tra la PE kaj la sinsekvo fariĝas evidenta.

Kion la PE faras kun RIP-ĝisdatigo

La PE ricevas la ĝisdatigon ĉe la VRF-interfaco, kontrolas ke la fonto estas permesita najbaro, kaj instalas la prefikson en la VRF-enkursigan tabelon kun salta nombro derivita de la anonco. Tiu tabelo estas ordinara enkursiga tabelo kun propraj administraj distancoj kaj propra elekto de la plej bona vojo. Se la CE anoncas la saman prefikson dufoje kun malsamaj metrikoj, nur la pli bona restas en la tabelo. Nenio en ĉi tiu paŝo koncernas la dorsan reton de la provizanto.

La prefikso nun ekzistas ene de la enkursiga kunteksto de unu kliento, kio estas tre malproksime de esti atingebla ie ajn alie.

Eksporto estas politika ago, ne protokola sekvo

Por forlasi la VRF, itinero devas esti redistribuita en la MP-BGP-procezon, kiu portas VPN-itinerojn, kaj ĝi bezonas etenditan komunumon de tipo route target, kiu identigas, kiujn forajn VRF-ojn rajtas importi ĝin. La arkitekturo en RFC 4364 tenas tiujn interŝanĝojn apartaj de la protokolo CE-al-PE ĝuste pro ĉi tiu kialo. Uzi RIP ĉe la rando diras nenion pri tio, kio devus transiri la reton de la provizanto.

Skribu la eksportan kontrakton antaŭ ol agordi ion ajn: la klientaj prefiksoj, kiuj devas esti atingeblaj de malproksime, la itineroj, kiuj devas resti lokaj, kaj ajnaj defaŭltaj, pli specifaj aŭ komunej-servaj esceptoj. Komparu tiun kontrakton kun la reala VRF, ne kun simile nomata, kiu apartenas al alia kliento.

La importa flanko estas dua politiko kun propraj route target-oj, kaj kongrua eksporto kun nekongrua importo produktas prefikson, kiu ekzistas en la dorso kaj aperas en neniu fora tabelo.

Redistribuado kaj eksplicita origino kondutas malsame

Redistribuado prenas itinerojn, kiuj jam ekzistas en la VRF-tabelo, kaj kopias ilin en BGP, filtritaj per itinera mapo. La mapo decidas, kiuj prefiksoj estas elekteblaj kaj kiujn atributojn ili portas, kaj la metriko devas esti agordita eksplicite, ĉar salta nombro de RIP havas neniun signifon kiel BGP-metriko. Ĉio, kion vi lasas neagordita, estas heredata tiel, ke ĝi kutime surprizas la personon, kiu legas la agordon ses monatojn poste.

Reciproka redistribuado estas kie la silenta difekto okazas. Prefikso eksportita en BGP povas reveni tra dua redistribua punkto, kaj sen etikedoj aŭ filtriloj la itinero oscilas dum ambaŭ tabeloj aspektas kredindaj en ajna momento. Filtru laŭ etikedoj aplikataj ĉe la rando anstataŭ fidi la topologion por malhelpi la revenan vojon.

Eksplicita origino aspektas pli ordema kaj ne estas senkondiĉa. Reta deklaro kutime bezonas kongruan itinero en la enkursiga tabelo antaŭ ol la prefikso originiĝas, do la anonco malaperas en la momento, kiam la CE ĉesas anonci ĝin. Tio ofte estas la konduto, kiun vi volas, kaj ĝi ne samas kiel statika itinero, kiu restas agordita por ĉiam. Kontrolu la faktan regulon de la platformo anstataŭ supozi iun ajn el la du kondutoj.

Ĉiuokaze, la demando pri ĉiu prefikso estas, kiu aktiva fonto igas ĝin elektebla kaj kio okazas, kiam tiu fonto malaperas.

Kontrolu la ĉenon en kvar lokoj

Rigardu la anoncon de la CE, la VRF-enkursigan tabelon, la VPN-itinertabelon kun sia route target, kaj la importon de la fora VRF, en tiu ordo. En IOS tio signifas la eligon de la CE-najbaro, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, kaj la saman komandon ĉe la malproksima PE. En IOS-XR la ekvivalenta eligo troviĝas sub show bgp vrf CUSTOMER ipv4 unicast. La komandnomoj malsamas, la kvar kontrolpunktoj ne.

Kontrolu prefikson, kiu devus esti rifuzita, same zorge kiel unu, kiu devus pasi, ĉar politiko, kiu permesas ĉion, aspektas identa al ĝusta, ĝis la unua escepto alvenos. Poste observu retiron: malŝaltu la CE-interfacon kaj konfirmu, ke la fora enskribo malaperas ene de la atendata tempigilo anstataŭ resti.

Registru, kiu posedas ĉiun politikon. Kiam la provizanto funkciigas la CE, la liverita konduto apartenas al la servo-kontrakto, kaj malsama protokolo aŭ retira politiko sur la administrata aparato estas dokumenta problemo antaŭ ol ĝi estas enkursiga problemo.