OSPF-rutetype på tværs af en VPN: ikke altid ekstern

Et kundepræfiks krydser udbyderens cloud som en BGP VPN-rute og ankommer til det fjerne sted med udseende af en ekstern OSPF-rute, hvilket mange ingeniører forventer, og det er ikke det eneste mulige udfald. Hvad den fjerne CE ser, afhænger af det OSPF-domæne, præfikset kom fra, og dets oprindelige rutetype, og begge rejser med VPN-ruten. At antage, at hvert redistribueret præfiks bliver til type 5, fører til præferenceændringer, som ikke kan fungere. Sammenlign domæneidentifikatoren først, ikke den administrative afstand.

PE-CE-modellen bærer nok kontekst til, at den modtagende PE kan rekonstruere en OSPF-annonce i stedet for at opfinde en.

Hvad rejser med ruten

RFC 4577 definerer de OSPF-attributter, der følger en VPN-rute: domæneidentifikatoren, metrikken og rutetypen fra oprindelsesstedet. Den modtagende PE bruger dem til at beslutte, hvordan et kvalificeret præfiks skal fremstå for dens lokale OSPF-proces. Uden disse attributter ville den fjerne PE ikke have noget grundlag for andet end en ekstern redistribution. Derfor kan en rute ankomme som en inter-area-LSA, selvom BGP transporterede den imellem.

Områdetypen har også betydning. Et stub- eller NSSA-område begrænser, hvilke LSA'er der må komme ind, så den samme VPN-rute kan præsenteres forskelligt afhængigt af, hvor den modtagende OSPF-instans ligger. Konfigureret eksportpolitik kan også tilsidesætte standardpræsentationen, hvilket er et bevidst valg og ikke en bivirkning.

Samme domæne, forskellig præsentation

En intra-area- eller inter-area-rute fra samme domæne ankommer normalt til det fjerne sted som en inter-area-rute, en type 3-LSA. Et præfiks fra et andet domæne, en oprindelse der aldrig talte OSPF, eller en oprindeligt ekstern OSPF-annonce følger i stedet de eksterne regler, og det er der, type 5 og dens NSSA-ækvivalent vises. Begge adfærd er korrekte; inputtet er forskelligt. Sammenlign domæneidentifikatorer og annoncerede attributter, før du rører præferenceværdier.

Administrativ afstand vælger mellem kilder på én router. Den omskriver ikke en LSA-type og skaber ikke det domæneforhold, der mangler.

Hvornår et sham link er det rigtige svar

Forestil dig to steder i samme område forbundet med et direkte bagdørslink. OSPF holder den intra-area-sti i stedet for den inter-area-sti, der tilbydes gennem udbyderen, selv når konfigurerede omkostninger ville gøre udbyderstien attraktiv. Et sham link repræsenterer et intra-area-forhold på tværs af VPN, så omkostninger kan deltage i beslutningen. Det findes for det specifikke stiudvælgelsesproblem, ikke for at få enhver rute fra samme domæne til at se intern ud.

Et sham link kræver nåbare endepunkter og gensidig konfiguration på begge PE'er. Opsætning på kun den ene side giver et forhold, der aldrig dannes, og routingtabellen beholder sin gamle præference, hvilket ser ud som om funktionen ikke gjorde noget.

Bryd ikke løkkebeskyttelsen

PE-CE-modellen sætter DN-bitten på de ruter, den distribuerer, så et præfiks ikke kan vende tilbage gennem en anden CE og blive redistribueret en anden gang. Den beskyttelse er det, der forhindrer et præfiks i at loope mellem steder, der deler et OSPF-domæne. At fjerne eller ignorere den for at få en rute til at se intern ud kan skabe præcis den løkke, den blev designet til at forhindre. Når et præfiks ser forkert ud, skal du behandle DN-bitten som information og ikke som en forhindring.

Den samme forsigtighed gælder for redistributionsfiltre og rutemaps, der fjerner communities. Hver af dem fjerner kontekst, som den fjerne side har brug for, og den resulterende annonce kan se plausibel ud, mens den er forkert. Ændr én attribut ad gangen, og kontrollér, hvad den fjerne CE faktisk installerer.

Verificér derefter fra det fjerne sted: LSA-typen, den annoncerende router og den valgte sti. Det bevis besvarer det spørgsmål, som billetten stillede.