Fra en CE RIP-rute til en ekstern VRF: hvor eksporten skjer

En RIPv2-oppdatering ankommer leverandørens kant, havner i en VRF-rutingstabell og stopper der med mindre noe eksporterer den eksplisitt. Tre beslutninger skjer i rekkefølge, og hver av dem kan avvise prefikset av sin egen grunn. Å lese dem som én hendelse er grunnen til at folk jager feil boks når et eksternt sted ikke når et nettverk som CE-en tydelig annonserer. Følg ruten gjennom PE-en, og rekkefølgen blir åpenbar.

Hva PE-en gjør med en RIP-oppdatering

PE-en mottar oppdateringen på VRF-grensesnittet, kontrollerer at kilden er en tillatt nabo, og installerer prefikset i VRF-rutingstabellen med et hoppantall utledet fra annonsen. Den tabellen er en vanlig rutingstabell med egne administrative avstander og eget valg av beste vei. Hvis CE-en annonserer samme prefiks to ganger med ulike metrikker, overlever bare den bedre i tabellen. Ingenting i dette trinnet involverer leverandørens ryggrad.

Prefikset finnes nå i rutedelen til én enkelt kunde, noe som er langt fra å være tilgjengelig hvor som helst ellers.

Eksport er en policyhandling, ikke en protokollkonsekvens

For å forlate VRF-en må en rute redistribueres inn i MP-BGP-prosessen som bærer VPN-ruter, og den trenger et utvidet rutenettverkssamfunn som identifiserer hvilke eksterne VRF-er som kan importere den. Arkitekturen i RFC 4364 holder disse utvekslingene atskilt fra CE-til-PE-protokollen nettopp av denne grunnen. Å bruke RIP på kanten sier ingenting om hva som skal krysse leverandørnettet.

Skriv ned eksportkontrakten før du konfigurerer noe: kundeprefiksene som må være tilgjengelige eksternt, rutene som må forbli lokale, og eventuelle standard, mer spesifikke eller unntak for delte tjenester. Sammenlign den kontrakten med den faktiske VRF-en og ikke med en med samme navn som tilhører en annen kunde.

Importsiden er en andre policy med egne rutenettverksmål, og en samsvarende eksport med en ikke-samsvarende import gir et prefiks som finnes i ryggraden og ikke vises i noen ekstern tabell.

Redistribusjon og eksplisitt opprinnelse oppfører seg ulikt

Redistribusjon tar ruter som allerede finnes i VRF-tabellen og kopierer dem inn i BGP, filtrert av et rutekart. Kartet avgjør hvilke prefikser som er kvalifiserte og hvilke attributter de bærer, og metrikken må settes eksplisitt fordi et RIP-hoppantall ikke har mening som BGP-metrikk. Alt du lar være usatt, arves på en måte som vanligvis overrasker den som leser konfigurasjonen seks måneder senere.

Gjensidig redistribusjon er der den stille skaden skjer. Et prefiks eksportert til BGP kan komme tilbake gjennom et andre redistribusjonspunkt, og uten tagger eller filtre svinger ruten mens begge tabellene ser plausible ut i hvert øyeblikk. Filtrer på tagger som settes på kanten i stedet for å stole på at topologien hindrer returveien.

Eksplisitt opprinnelse ser ryddigere ut og er ikke ubetinget. En nettverkserklæring trenger vanligvis en samsvarende rute i rutingstabellen før prefikset opprettes, så annonsen forsvinner i det øyeblikket CE-en slutter å annonsere den. Det er ofte oppførselen du ønsker, og den er ikke det samme som en statisk rute som blir stående konfigurert for alltid. Sjekk plattformens faktiske regel i stedet for å anta en av oppførslene.

Uansett er spørsmålet å stille om hvert prefiks hvilken aktiv kilde som gjør det kvalifisert, og hva som skjer når den kilden forsvinner.

Verifiser kjeden fire steder

Se på CE-annonsen, VRF-rutingstabellen, VPN-rutetabellen med sitt rutenettverksmål og importen i den eksterne VRF-en, i den rekkefølgen. På IOS betyr det utdata fra CE-naboen, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, og samme kommando på den eksterne PE-en. På IOS-XR ligger tilsvarende utdata under show bgp vrf CUSTOMER ipv4 unicast. Kommandonavnene er forskjellige, de fire kontrollpunktene ikke.

Kontroller et prefiks som skal avvises like nøye som et som skal slippe gjennom, fordi en policy som tillater alt ser identisk ut med en riktig helt til det første unntaket kommer. Se deretter på en tilbaketrekking: slå av CE-grensesnittet, og bekreft at den eksterne oppføringen forsvinner innen forventet tidsur i stedet for å bli liggende.

Noter hvem som eier hver policy. Når leverandøren driver CE-en, hører den leverte oppførselen til tjenesteavtalen, og en annen protokoll eller tilbaketrekkingspolicy på den administrerte enheten er et dokumentasjonsproblem før det er et rutingproblem.