OSPF-rutetype over ein VPN: ikkje alltid ekstern

Eit kundeprefiks kryssar skya til leverandøren som ei BGP VPN-rute og kjem til den fjerne staden med utsjånad som ei ekstern OSPF-rute, noko mange ingeniørar forventar og ikkje det einaste moglege utfallet. Det den fjerne CE-en ser, avheng av OSPF-domenet prefikset kom frå og den opphavlege rutetypen, og begge reiser med VPN-ruta. Føresetnaden om at kvart redistribuert prefiks blir type 5, fører til preferanseendringar som ikkje kan fungere. Samanlikn domeneidentifikatoren først, ikkje den administrative avstanden.

PE-CE-modellen ber nok kontekst til at den mottakande PE-en kan rekonstruere ei OSPF-annonse i staden for å finne ho opp.

Kva som reiser med ruta

RFC 4577 definerer OSPF-attributta som følgjer ei VPN-rute: domeneidentifikatoren, metrikken og rutetypen frå opphavsstaden. Den mottakande PE-en brukar dei til å avgjere korleis eit kvalifisert prefiks skal framstå for den lokale OSPF-prosessen sin. Utan desse attributta ville den fjerne PE-en ikkje hatt noko grunnlag for anna enn ein ekstern redistribusjon. Derfor kan ei rute kome som ein inter-area-LSA sjølv om BGP frakta ho imellom.

Områdetypen har òg tyding. Eit stub- eller NSSA-område avgrensar kva LSA-ar som kan kome inn, så den same VPN-ruta kan presenterast ulikt avhengig av kvar den mottakande OSPF-instansen ligg. Konfigurert eksportpolitikk kan òg overstyre standardpresentasjonen, noko som er eit medvite val og ikkje ein biverknad.

Same domene, annan presentasjon

Ei intra-area- eller inter-area-rute frå same domene kjem vanlegvis til den fjerne staden som ei inter-area-rute, ein type 3-LSA. Eit prefiks frå eit anna domene, ein opphavsstad som aldri snakka OSPF, eller ei opphavleg ekstern OSPF-annonse følgjer i staden dei eksterne reglane, og det er der type 5 og NSSA-ekvivalenten hans viser seg. Begge åtferdene er korrekte; inndataa er ulike. Samanlikn domeneidentifikatorar og annonserte attributt før du rører preferanseverdiar.

Administrativ avstand vel mellom kjelder på éin rutar. Han skriv ikkje om ein LSA-type og skaper ikkje domeneforholdet som manglar.

Når ein sham-link er det rette svaret

Førestill deg to stader i same område forbundne med ei direkte bakdørlenkje. OSPF held på den intra-area-banen i staden for inter-area-banen som blir tilboden gjennom leverandøren, sjølv når konfigurerte kostnader ville gjere leverandørbanen attraktiv. Ein sham-link representerer eit intra-area-forhold over VPN-en slik at kostnader kan delta i avgjerda. Han finst for det spesifikke banevalproblemet, ikkje for å få kvar rute frå same domene til å sjå intern ut.

Ein sham-link treng tilgjengelege endepunkt og gjensidig konfigurasjon på begge PE-ane. Oppsett på berre éi side gir eit forhold som aldri blir danna, og rutetabellen held på den gamle preferansen sin, noko som ser ut som om funksjonen ikkje gjorde noko.

Ikkje bryt løkkevernet

PE-CE-modellen set DN-biten på rutene han distribuerer, slik at eit prefiks ikkje kan kome tilbake gjennom ein annan CE og bli redistribuert ein gong til. Det vernet hindrar eit prefiks i å gå i løkke mellom stader som deler eit OSPF-domene. Å fjerne eller ignorere det for å få ei rute til å sjå intern ut kan skape nøyaktig den løkka det var laga for å hindre. Når eit prefiks ser feil ut, handsam DN-biten som informasjon og ikkje som ein hindring.

Den same varsemda gjeld redistribusjonsfilter og rutekart som fjernar communities. Kvart av dei fjernar kontekst som den fjerne sida treng, og den resulterande annonsa kan sjå plausibel ut medan ho er feil. Endre éin attributt om gongen og kontroller kva den fjerne CE-en faktisk installerer.

Verifiser deretter frå den fjerne staden: LSA-typen, rutaren som annonserer, og banen han valde. Den dokumentasjonen svarar på spørsmålet billetten stilte.