OSPF-itinera tipo trans VPN: ne ĉiam ekstera
Redistribuita prefikso ne devas fariĝi ekstera OSPF-itinero. La domajno kaj la origina tipo vojaĝas kun la VPN-itinero kaj difinas tion, kion la malproksima CE instalas.
Klienta prefikso transiras la nubon de la provizanto kiel BGP-VPN-itinero kaj alvenas al la malproksima ejo aspektante kiel ekstera OSPF-itinero, kion multaj inĝenieroj atendas kaj ne estas la sola ebla rezulto. Tio, kion vidas la malproksima CE, dependas de la OSPF-domajno, el kiu venis la prefikso, kaj de ĝia origina itinera tipo, kaj ambaŭ vojaĝas kun la VPN-itinero. Supozi, ke ĉiu redistribuita prefikso fariĝas tipo 5, kondukas al preferoŝanĝoj, kiuj ne povas funkcii. Komparu unue la domajnan identigilon, ne la administran distancon.
La modelo PE-CE portas sufiĉan kuntekston, por ke la ricevanta PE povu rekonstrui OSPF-anoncon anstataŭ inventi ĝin.
Kio vojaĝas kun la itinero
RFC 4577 difinas la OSPF-atributojn, kiuj akompanas VPN-itinero: la domajnan identigilon, la metrikon kaj la itineran tipon de la origina ejo. La ricevanta PE uzas ilin por decidi, kiel taŭga prefikso devus aperi al ĝia loka OSPF-procezo. Sen tiuj atributoj la malproksima PE havus neniun bazon por io ajn krom ekstera redistribuado. Tial itinero povas alveni kiel interarea LSA, kvankam BGP portis ĝin intere.
Ankaŭ la area tipo gravas. Stub aŭ NSSA areo limigas, kiuj LSA-oj rajtas eniri, do la sama VPN-itinero povas esti prezentata malsame depende de tio, kie situas la ricevanta OSPF-kazo. Konfigurita eksporta politiko ankaŭ povas anstataŭigi la defaŭltan prezentadon, kio estas intenca elekto kaj ne kromefiko.
Sama domajno, malsama prezentado
Itinero ene de areo aŭ inter areoj el la sama domajno normale alvenas al la malproksima ejo kiel interarea itinero, LSA de tipo 3. Prefikso el alia domajno, origino, kiu neniam parolis OSPF, aŭ komence ekstera OSPF-anonco sekvas anstataŭe la eksterajn regulojn, kaj tie aperas tipo 5 kaj ĝia NSSA-ekvivalento. Ambaŭ kondutoj estas ĝustaj; la enigo malsamas. Komparu domajnajn identigilojn kaj anoncitajn atributojn antaŭ ol tuŝi prefervalorojn.
Administra distanco elektas inter fontoj sur unu enkursigilo. Ĝi ne reskribas LSA-tipon nek kreas la mankan domajnan rilaton.
Kiam sham ligo estas la ĝusta respondo
Imagu du ejojn en la sama areo kunligitajn per rekta malantaŭa ligo. OSPF tenas tiun enearan vojon anstataŭ la interarean, kiun la provizanto ofertas, eĉ kiam konfiguritaj kostoj farus la provizantan vojon alloga. Sham ligo reprezentas enearan rilaton trans la VPN, por ke kostoj povu partopreni en la decido. Ĝi ekzistas por tiu specifa vojelekta problemo, ne por igi ĉiun itineron de la sama domajno aspekti interna.
Sham ligo bezonas atingeblajn finpunktojn kaj reciprokan konfiguradon ĉe ambaŭ PE-oj. Agordi ĝin nur unuflanke produktas rilaton, kiu neniam formiĝas, kaj la enkursigilo-tabelo konservas sian malnovan preferon, kio aspektas kvazaŭ la funkcio faris nenion.
Ne rompu la buklan protekton
La modelo PE-CE agordas la DN-biton sur la itineroj, kiujn ĝi distribuas, por ke prefikso ne povu reveni tra alia CE kaj esti redistribuita duan fojon. Tiu protekto malebligas, ke prefikso buklu inter ejoj, kiuj kunhavas OSPF-domajnon. Forigi aŭ ignori ĝin, por ke itinero aspektu interna, povas krei ĝuste la buklon, kiun ĝi estis destinita malhelpi. Kiam prefikso aspektas malĝuste, traktu la DN-biton kiel informon, ne kiel obstaklon.
La sama singardemo validas por redistribuaj filtriloj kaj itinermapoj, kiuj forigas komunumojn. Ĉiu el ili forigas kuntekston, kiun la malproksima flanko bezonas, kaj la rezulta anonco povas aspekti kredinda, dum ĝi estas malĝusta. Ŝanĝu unu atributon samtempe kaj kontrolu, kion la malproksima CE efektive instalas.
Poste kontrolu de la malproksima ejo: la LSA-tipon, la anoncantan enkursigilon kaj la elektitan vojon. Tiu pruvo respondas al la demando, kiun starigis la bileto.