OSPF-rutetype på tvers av en VPN: ikke alltid ekstern

Et kundeprefiks krysser leverandørens sky som en BGP VPN-rute og ankommer det fjerne stedet med utseende som en ekstern OSPF-rute, noe mange ingeniører forventer og ikke det eneste mulige utfallet. Det den fjerne CE-en ser, avhenger av OSPF-domenet prefikset kom fra og dets opprinnelige rutetype, og begge reiser med VPN-ruten. Antakelsen om at hvert redistribuert prefiks blir type 5, fører til preferanseendringer som ikke kan fungere. Sammenlign domeneidentifikatoren først, ikke den administrative avstanden.

PE-CE-modellen bærer nok kontekst til at den mottakende PE-en kan rekonstruere en OSPF-annonse i stedet for å finne den opp.

Hva som reiser med ruten

RFC 4577 definerer OSPF-attributtene som følger en VPN-rute: domeneidentifikatoren, metrikken og rutetypen fra opprinnelsesstedet. Den mottakende PE-en bruker dem til å avgjøre hvordan et kvalifisert prefiks skal fremstå for sin lokale OSPF-prosess. Uten disse attributtene ville den fjerne PE-en ikke hatt noe grunnlag for annet enn en ekstern redistribusjon. Derfor kan en rute ankomme som en inter-area-LSA selv om BGP fraktet den imellom.

Områdetypen har også betydning. Et stub- eller NSSA-område begrenser hvilke LSA-er som kan komme inn, så den samme VPN-ruten kan presenteres forskjellig avhengig av hvor den mottakende OSPF-instansen ligger. Konfigurert eksportpolicy kan også overstyre standardpresentasjonen, noe som er et bevisst valg og ikke en bivirkning.

Samme domene, annen presentasjon

En intra-area- eller inter-area-rute fra samme domene ankommer vanligvis det fjerne stedet som en inter-area-rute, en type 3-LSA. Et prefiks fra et annet domene, en opprinnelse som aldri snakket OSPF, eller en opprinnelig ekstern OSPF-annonse følger i stedet de eksterne reglene, og det er der type 5 og dens NSSA-ekvivalent vises. Begge atferdene er korrekte; inndataene er forskjellige. Sammenlign domeneidentifikatorer og annonserte attributter før du rører preferanseverdier.

Administrativ avstand velger mellom kilder på én rutere. Den skriver ikke om en LSA-type og skaper ikke domeneforholdet som mangler.

Når en sham link er det riktige svaret

Se for deg to steder i samme område forbundet med en direkte bakdørlenke. OSPF beholder den intra-area-banen i stedet for den inter-area-banen som tilbys gjennom leverandøren, selv når konfigurerte kostnader ville gjøre leverandørbanen attraktiv. En sham link representerer et intra-area-forhold over VPN-en slik at kostnader kan delta i beslutningen. Den finnes for det spesifikke banefordelingsproblemet, ikke for å få enhver rute fra samme domene til å se intern ut.

En sham link trenger tilgjengelige endepunkter og gjensidig konfigurasjon på begge PE-ene. Oppsett på bare én side gir et forhold som aldri dannes, og rutetabellen beholder sin gamle preferanse, noe som ser ut som om funksjonen ikke gjorde noe.

Ikke bryt løkkebeskyttelsen

PE-CE-modellen setter DN-biten på rutene den distribuerer, slik at et prefiks ikke kan komme tilbake gjennom en annen CE og bli redistribuert en gang til. Den beskyttelsen hindrer et prefiks i å gå i løkke mellom steder som deler et OSPF-domene. Å fjerne eller ignorere den for å få en rute til å se intern ut kan skape nøyaktig den løkken den var designet for å forhindre. Når et prefiks ser feil ut, behandle DN-biten som informasjon og ikke som en hindring.

Den samme forsiktigheten gjelder redistribusjonsfiltre og rutekart som fjerner communities. Hver av dem fjerner kontekst som den fjerne siden trenger, og den resulterende annonsen kan se plausibel ut mens den er feil. Endre én attributt om gangen og kontroller hva den fjerne CE-en faktisk installerer.

Verifiser deretter fra det fjerne stedet: LSA-typen, ruteren som annonserer, og banen den valgte. Den dokumentasjonen svarer på spørsmålet billetten stilte.