Van een CE RIP-route naar een remote VRF: waar de export gebeurt

Een RIPv2-update komt aan bij de provider-edge, belandt in een VRF-routingtabel en stopt daar tenzij iets hem expliciet exporteert. Drie beslissingen volgen elkaar op, en elk kan de prefix om zijn eigen reden weigeren. Ze als één gebeurtenis lezen is de reden dat mensen het verkeerde apparaat najagen wanneer een remote site een netwerk niet bereikt dat de CE duidelijk adverteert. Volg de route door de PE en de volgorde wordt vanzelfsprekend.

Wat de PE met een RIP-update doet

De PE ontvangt de update op de VRF-interface, controleert dat de bron een toegestane buur is, en installeert de prefix in de VRF-routingtabel met een hopcount die van de aankondiging is afgeleid. Die tabel is een normale routingtabel met eigen administratieve afstanden en een eigen beste-padverkiezing. Als de CE dezelfde prefix twee keer adverteert met verschillende metrics, overleeft alleen de betere in de tabel. Niets in deze stap betreft de backbone van de provider.

De prefix bestaat nu binnen de routingcontext van één klant, wat ver verwijderd is van overal elders bereikbaar zijn.

Export is een beleidshandeling, geen gevolg van het protocol

Om de VRF te verlaten moet een route worden geredistribueerd naar het MP-BGP-proces dat VPN-routes draagt, en hij heeft een route-target extended community nodig die aangeeft welke remote VRF's hem mogen importeren. De architectuur in RFC 4364 houdt die uitwisselingen juist om deze reden gescheiden van het CE-naar-PE-protocol. RIP aan de rand gebruiken zegt niets over wat het providernetwerk moet oversteken.

Schrijf het exportcontract op voordat je iets configureert: de klantprefixen die op afstand bereikbaar moeten zijn, de routes die lokaal moeten blijven, en eventuele default-, meer specifieke of gedeelde-service-uitzonderingen. Vergelijk dat contract met de werkelijke VRF en niet met een gelijknamige van een andere klant.

De importkant is een tweede beleid met eigen route-targets, en een passende export met een niet-passende import levert een prefix op die in de backbone bestaat en in geen enkele remote tabel verschijnt.

Redistributie en expliciete origination gedragen zich anders

Redistributie neemt routes die al in de VRF-tabel staan en kopieert ze naar BGP, gefilterd door een route map. De map bepaalt welke prefixen in aanmerking komen en welke attributen ze dragen, en de metric moet expliciet worden gezet omdat een RIP-hopcount als BGP-metric geen betekenis heeft. Alles wat je oningesteld laat, wordt geërfd op een manier die degene die de configuratie zes maanden later leest meestal verrast.

Wederzijdse redistributie is waar de stille schade gebeurt. Een prefix die naar BGP wordt geëxporteerd kan via een tweede redistributiepunt terugkomen, en zonder tags of filters oscilleert de route terwijl beide tabellen op elk moment plausibel lijken. Filter op tags die aan de rand zijn toegepast in plaats van erop te vertrouwen dat de topologie de terugweg tegenhoudt.

Expliciete origination ziet er netter uit en is niet onvoorwaardelijk. Een network statement heeft meestal een overeenkomende route in de routingtabel nodig voordat de prefix wordt georigineerd, dus de aankondiging verdwijnt op het moment dat de CE hem niet meer adverteert. Dat is vaak het gewenste gedrag, en het is niet hetzelfde als een statische route die voor altijd geconfigureerd blijft. Controleer de werkelijke regel van het platform in plaats van een van beide gedragingen aan te nemen.

Hoe dan ook, de vraag bij elke prefix is welke actieve bron hem in aanmerking laat komen en wat er gebeurt als die bron verdwijnt.

Verifieer de keten op vier plaatsen

Kijk naar de CE-aankondiging, de VRF-routingtabel, de VPN-routetabel met zijn route-target en de import in de remote VRF, in die volgorde. Op IOS betekent dat de CE-buuruitvoer, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, en hetzelfde commando op de verre PE. Op IOS-XR staat de equivalente uitvoer onder show bgp vrf CUSTOMER ipv4 unicast. De commandonamen verschillen, de vier controlepunten niet.

Controleer een prefix die geweigerd zou moeten worden net zo zorgvuldig als een die zou moeten passeren, want een beleid dat alles toestaat ziet er identiek uit aan een correct beleid tot de eerste uitzondering komt. Kijk dan naar een intrekking: sluit de CE-interface af en bevestig dat de remote vermelding binnen de verwachte timer verdwijnt in plaats van te blijven staan.

Leg vast wie eigenaar is van elk beleid. Wanneer de provider de CE beheert, hoort het geleverde gedrag in het servicecontract, en een ander protocol of intrekkingsbeleid op het beheerde apparaat is een documentatieprobleem voordat het een routingprobleem is.