OSPF-ruttyp över en VPN: inte alltid extern

Ett kundprefix korsar leverantörens moln som en BGP VPN-rutt och anländer till den fjärran platsen med utseendet av en extern OSPF-rutt, vilket många ingenjörer förväntar sig och inte är det enda möjliga resultatet. Vad den fjärran CE:n ser beror på vilken OSPF-domän prefixet kom från och dess ursprungliga ruttyp, och båda färdas med VPN-rutten. Antagandet att varje omdistribuerat prefix blir typ 5 leder till preferensändringar som inte kan fungera. Jämför domänidentifieraren först, inte det administrativa avståndet.

PE-CE-modellen bär tillräckligt med kontext för att den mottagande PE:n ska kunna rekonstruera ett OSPF-meddelande i stället för att hitta på ett.

Vad som färdas med rutten

RFC 4577 definierar de OSPF-attribut som åtföljer en VPN-rutt: domänidentifieraren, metriken och ruttypen från ursprungsplatsen. Den mottagande PE:n använder dem för att avgöra hur ett kvalificerat prefix ska framstå för sin lokala OSPF-process. Utan dessa attribut skulle den fjärran PE:n inte ha någon grund för något annat än en extern omdistribuering. Därför kan en rutt anlända som en inter-area-LSA även om BGP transporterade den däremellan.

Områdestypen har också betydelse. Ett stub- eller NSSA-område begränsar vilka LSA som får komma in, så samma VPN-rutt kan presenteras olika beroende på var den mottagande OSPF-instansen ligger. Konfigurerad exportpolicy kan också åsidosätta standardpresentationen, vilket är ett medvetet val och inte en bieffekt.

Samma domän, annan presentation

En intra-area- eller inter-area-rutt från samma domän anländer vanligtvis till den fjärran platsen som en inter-area-rutt, en typ 3-LSA. Ett prefix från en annan domän, ett ursprung som aldrig talade OSPF eller ett ursprungligen externt OSPF-meddelande följer i stället de externa reglerna, och det är där typ 5 och dess NSSA-motsvarighet dyker upp. Båda beteendena är korrekta; indata skiljer sig. Jämför domänidentifierare och annonserade attribut innan du rör preferensvärden.

Administrativt avstånd väljer mellan källor på en enda router. Det skriver inte om en LSA-typ och skapar inte den saknade domänrelationen.

När en sham-länk är rätt svar

Föreställ dig två platser i samma område sammankopplade med en direkt bakdörrslänk. OSPF behåller den intra-area-vägen i stället för den inter-area-väg som erbjuds via leverantören, även när konfigurerade kostnader skulle göra leverantörsvägen attraktiv. En sham-länk representerar en intra-area-relation över VPN:en så att kostnader kan delta i beslutet. Den finns för det specifika vägvalsproblemet, inte för att få varje rutt från samma domän att se intern ut.

En sham-länk kräver nåbara ändpunkter och ömsesidig konfiguration på båda PE:erna. Att sätta upp den bara på ena sidan ger en relation som aldrig bildas, och routingtabellen behåller sin gamla preferens, vilket ser ut som om funktionen inte gjorde något.

Bryt inte slingningsskyddet

PE-CE-modellen sätter DN-biten på de rutter den distribuerar så att ett prefix inte kan återvända genom en annan CE och omdistribueras en andra gång. Det skyddet hindrar ett prefix från att gå i slinga mellan platser som delar en OSPF-domän. Att ta bort eller ignorera det för att få en rutt att se intern ut kan skapa exakt den slinga det var designat att förhindra. När ett prefix ser fel ut, behandla DN-biten som information och inte som ett hinder.

Samma försiktighet gäller omdistribueringsfilter och rutkartor som tar bort communities. Var och en tar bort kontext som den fjärran sidan behöver, och det resulterande meddelandet kan se rimligt ut medan det är fel. Ändra ett attribut i taget och kontrollera vad den fjärran CE:n faktiskt installerar.

Verifiera sedan från den fjärran platsen: LSA-typen, rutten som annonserar och den väg den valde. Den bevisningen svarar på frågan som biljetten ställde.