Fra en CE RIP-rute til et fjernt VRF: hvor eksporten sker

En RIPv2-opdatering ankommer til udbyderens kant, lander i en VRF-routingtabel og stopper der, medmindre noget eksplicit eksporterer den. Tre beslutninger sker i rækkefølge, og hver af dem kan afvise præfikset af sin egen grund. Det er netop læsningen af dem som én hændelse, der får folk til at jage den forkerte boks, når et fjernsidessted ikke kan nå et netværk, som CE'en tydeligt annoncerer. Følg ruten gennem PE'en, og rækkefølgen bliver indlysende.

Hvad PE'en gør med en RIP-opdatering

PE'en modtager opdateringen på VRF-interfacet, kontrollerer at kilden er en tilladt nabo, og installerer præfikset i VRF-routingtabellen med et hopantal, der er udledt af annonceringen. Den tabel er en almindelig routingtabel med sine egne administrative afstande og sin egen valg af bedste vej. Hvis CE'en annoncerer samme præfiks to gange med forskellige metrikker, overlever kun den bedste i tabellen. Intet i dette trin involverer udbyderens backbone.

Præfikset findes nu inde i én kundes routingkontekst, hvilket er langt fra at være tilgængeligt andre steder.

Eksport er en politisk handling, ikke en protokolkonsekvens

For at forlade VRF'et skal en rute redistribueres ind i den MP-BGP-proces, der bærer VPN-ruter, og den har brug for et udvidet route target-fællesskab, der identificerer, hvilke fjerne VRF'er der må importere den. Arkitekturen i RFC 4364 holder netop disse udvekslinger adskilt fra CE-til-PE-protokollen af denne grund. At bruge RIP på kanten siger intet om, hvad der skal krydse udbyderens netværk.

Skriv eksportkontrakten ned, før du konfigurerer noget: de kundepræfikser, der skal være tilgængelige eksternt, de ruter der skal forblive lokale, og eventuelle default, mere specifikke eller delte tjenesteydelser. Sammenhold den kontrakt med det faktiske VRF og ikke med et lignende navngivet, der tilhører en anden kunde.

Importsiden er en anden politik med sine egne route targets, og en matchende eksport med en ikke-matchende import giver et præfiks, der findes i backbonen og ikke vises i nogen fjern tabel.

Redistribution og eksplicit oprindelse opfører sig forskelligt

Redistribution tager ruter, der allerede findes i VRF-tabellen, og kopierer dem ind i BGP, filtreret af et rutekort. Kortet afgør, hvilke præfikser der er kvalificerede, og hvilke attributter de bærer, og metrikken skal sættes eksplicit, fordi et RIP-hopantal ikke har nogen betydning som BGP-metrik. Alt, hvad du lader være usat, nedarves på en måde, der normalt overrasker den person, der læser konfigurationen et halvt år senere.

Gensidig redistribution er stedet, hvor den stille skade sker. Et præfiks, der eksporteres til BGP, kan komme tilbage gennem et andet redistributionspunkt, og uden tags eller filtre svinger ruten, mens begge tabeller ser plausible ud i ethvert øjeblik. Filtrér på tags, der anvendes på kanten, i stedet for at stole på, at topologien forhindrer returvejen.

Eksplicit oprindelse ser pænere ud og er ikke ubetinget. En netværkserklæring kræver normalt en matchende rute i routingtabellen, før præfikset oprettes, så annonceringen forsvinder i det øjeblik, CE'en holder op med at annoncere den. Det er ofte den opførsel, du ønsker, og den er ikke det samme som en statisk rute, der forbliver konfigureret for evigt. Kontrollér platformens faktiske regel i stedet for at antage en af de to opførsler.

Uanset hvad er spørgsmålet for hvert præfiks, hvilken aktiv kilde der gør det kvalificeret, og hvad der sker, når den kilde forsvinder.

Bekræft kæden fire steder

Se på CE-annonceringen, VRF-routingtabellen, VPN-rutetabellen med sit route target og importen i det fjerne VRF, i den rækkefølge. På IOS betyder det CE-naboens output, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, og den samme kommando på den fjerne PE. På IOS-XR findes det tilsvarende output under show bgp vrf CUSTOMER ipv4 unicast. Kommandonavnene er forskellige, de fire kontrolpunkter ikke.

Kontrollér et præfiks, der bør afvises, lige så omhyggeligt som et, der bør passere, fordi en politik, der tillader alt, ser identisk ud med en korrekt, indtil den første undtagelse kommer. Overvåg derefter en tilbagetrækning: luk CE-interfacet, og bekræft, at den fjerne post forsvinder inden for den forventede timer i stedet for at hænge.

Notér, hvem der ejer hver politik. Når udbyderen driver CE'en, hører den leverede adfærd hjemme i servicekontrakten, og en anden protokol eller tilbagetrækningspolitik på den administrerede enhed er et dokumentationsproblem, før det er et routingproblem.