OSPF-routetype over een VPN: niet altijd extern

Een klantprefix doorkruist de cloud van de provider als BGP VPN-route en komt op de verre locatie aan met het uiterlijk van een externe OSPF-route, wat veel ingenieurs verwachten en niet de enige mogelijke uitkomst is. Wat de verre CE ziet, hangt af van het OSPF-domein waar het prefix vandaan komt en van het oorspronkelijke routetype, en beide reizen mee met de VPN-route. Aannemen dat elk herverdeeld prefix type 5 wordt, leidt tot preferentiewijzigingen die niet kunnen werken. Vergelijk eerst de domeinidentificatie, niet de administratieve afstand.

Het PE-CE-model draagt genoeg context zodat de ontvangende PE een OSPF-aankondiging kan reconstrueren in plaats van verzinnen.

Wat er met de route meereist

RFC 4577 definieert de OSPF-attributen die een VPN-route begeleiden: de domeinidentificatie, de metriek en het routetype van de oorspronkelijke locatie. De ontvangende PE gebruikt ze om te beslissen hoe een geschikt prefix aan zijn lokale OSPF-proces moet verschijnen. Zonder die attributen zou de verre PE geen grondslag hebben voor iets anders dan een externe herverdeling. Daarom kan een route aankomen als een inter-area-LSA, ook al heeft BGP hem daartussen vervoerd.

Het areatype is ook van belang. Een stub- of NSSA-area beperkt welke LSA's mogen binnenkomen, dus dezelfde VPN-route kan anders worden gepresenteerd afhankelijk van waar de ontvangende OSPF-instantie zit. Geconfigureerd exportbeleid kan de standaardpresentatie ook overschrijven, wat een bewuste keuze is en geen bijwerking.

Hetzelfde domein, andere presentatie

Een intra-area- of inter-area-route uit hetzelfde domein komt gewoonlijk op de verre locatie aan als een inter-area-route, een type 3-LSA. Een prefix uit een ander domein, een oorsprong die nooit OSPF sprak, of een oorspronkelijk externe OSPF-aankondiging volgt in plaats daarvan de externe regels, en daar verschijnen type 5 en zijn NSSA-equivalent. Beide gedragingen zijn correct; de invoer verschilt. Vergelijk domeinidentificaties en aangekondigde attributen voordat u preferentiewaarden aanraakt.

Administratieve afstand kiest tussen bronnen op één router. Het herschrijft geen LSA-type en creëert niet de ontbrekende domeinrelatie.

Wanneer een sham-link het juiste antwoord is

Stel u twee locaties in dezelfde area voor die door een directe achterdeurverbinding zijn verbonden. OSPF houdt dat intra-area-pad aan in plaats van het inter-area-pad dat via de provider wordt geboden, zelfs wanneer geconfigureerde kosten het providerpad aantrekkelijk zouden maken. Een sham-link vertegenwoordigt een intra-area-relatie over de VPN zodat kosten aan de beslissing kunnen deelnemen. Hij bestaat voor dat specifieke padselectieprobleem, niet om elke route uit hetzelfde domein intern te laten lijken.

Een sham-link vereist bereikbare eindpunten en wederzijdse configuratie op beide PE's. Hem slechts aan één kant instellen levert een relatie op die nooit ontstaat, en de routingtabel behoudt zijn oude preferentie, wat lijkt alsof de functie niets heeft gedaan.

Breek de lusbescherming niet

Het PE-CE-model zet de DN-bit op de routes die het distribueert, zodat een prefix niet via een andere CE kan terugkeren en een tweede keer worden herverdeeld. Die bescherming is wat voorkomt dat een prefix tussen locaties die een OSPF-domein delen in een lus terechtkomt. Hem verwijderen of negeren om een route intern te laten lijken kan precies de lus creëren waarvoor hij is ontworpen. Wanneer een prefix verkeerd lijkt, behandel de DN-bit als informatie en niet als een obstakel.

Dezelfde voorzichtigheid geldt voor herverdelingsfilters en routemaps die communities verwijderen. Elk verwijdert context die de verre kant nodig heeft, en de resulterende aankondiging kan geloofwaardig lijken terwijl hij onjuist is. Wijzig één attribuut per keer en controleer wat de verre CE werkelijk installeert.

Verifieer daarna vanaf de verre locatie: het LSA-type, de aankondigende router en het gekozen pad. Dat bewijs beantwoordt de vraag die het ticket stelde.