Frå ei CE RIP-rute til ein ekstern VRF: kvar eksporten skjer

Ei RIPv2-oppdatering kjem inn til kanten hos leverandøren, hamnar i ein VRF-rutetabell og stoppar der med mindre noko eksporterer ho eksplisitt. Tre avgjerder skjer i rekkjefølgje, og kvar av dei kan avvise prefikset av si eiga grunn. Å lese dei som éin hending er grunnen til at folk jagar feil boks når ein ekstern stad ikkje når eit nettverk som CE-en tydeleg annonserer. Følg ruta gjennom PE-en, og rekkjefølgja blir openber.

Kva PE-en gjer med ei RIP-oppdatering

PE-en tek imot oppdateringa på VRF-grensesnittet, kontrollerer at kjelda er ein tillaten nabo, og installerer prefikset i VRF-rutetabellen med eit hopptal utleia frå annonsen. Den tabellen er ein vanleg rutetabell med eigne administrative avstandar og eige val av beste veg. Viss CE-en annonserer same prefikset to gonger med ulike metrikkar, overlever berre den betre i tabellen. Ingenting i dette steget involverer ryggrada til leverandøren.

Prefikset finst no i rutedelen til éin einaste kunde, noko som er langt frå å vere tilgjengeleg kvar som helst elles.

Eksport er ei policyhandling, ikkje ein protokollkonsekvens

For å forlate VRF-en må ei rute redistribuerast inn i MP-BGP-prosessen som ber VPN-ruter, og ho treng eit utvida rutenettverkssamfunn som identifiserer kva eksterne VRF-ar som kan importere ho. Arkitekturen i RFC 4364 held desse utvekslingane åtskilde frå CE-til-PE-protokollen nettopp av denne grunnen. Å bruke RIP på kanten seier ingenting om kva som skal krysse leverandørnettet.

Skriv ned eksportkontrakten før du konfigurerer noko: kundeprefiksa som må vere tilgjengelege eksternt, rutene som må halde seg lokale, og eventuelle standard, meir spesifikke eller unntak for delte tenester. Samanlikn den kontrakten med den faktiske VRF-en og ikkje med ein med same namn som høyrer til ein annan kunde.

Importsida er ein andre policy med eigne rutenettverksmål, og ein samsvarande eksport med ein ikkje-samsvarande import gir eit prefiks som finst i ryggrada og ikkje viser seg i nokon ekstern tabell.

Redistribusjon og eksplisitt opphav oppfører seg ulikt

Redistribusjon tek ruter som allereie finst i VRF-tabellen og kopierer dei inn i BGP, filtrerte av eit rutekart. Kartet avgjer kva prefiks som er kvalifiserte og kva attributt dei ber, og metrikken må setjast eksplisitt fordi eit RIP-hopptal ikkje har meining som BGP-metrikk. Alt du lèt vere usett, blir arva på ein måte som vanlegvis overraskar den som les konfigurasjonen seks månader seinare.

Gjensidig redistribusjon er der den stille skaden skjer. Eit prefiks eksportert til BGP kan kome tilbake gjennom eit andre redistribusjonspunkt, og utan taggar eller filter svingar ruta medan begge tabellane ser truverdige ut i kvart augneblink. Filtrer på taggar som blir sette på kanten i staden for å stole på at topologien hindrar returvegen.

Eksplisitt opphav ser ryddigare ut og er ikkje vilkårslaust. Ei nettverkserklæring treng vanlegvis ei samsvarande rute i rutetabellen før prefikset blir oppretta, så annonsen forsvinn i det augneblinken CE-en sluttar å annonsere han. Det er ofte oppførselen du ønskjer, og han er ikkje det same som ei statisk rute som blir ståande konfigurert for alltid. Sjekk den faktiske regelen til plattformen i staden for å anta ein av oppførslene.

Uansett er spørsmålet å stille om kvart prefiks kva aktiv kjelde som gjer det kvalifisert, og kva som skjer når den kjelda forsvinn.

Stadfest kjeda fire stader

Sjå på CE-annonsen, VRF-rutetabellen, VPN-rutetabellen med sitt rutenettverksmål og importen i den eksterne VRF-en, i den rekkjefølgja. På IOS tyder det utdata frå CE-naboen, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, og same kommando på den eksterne PE-en. På IOS-XR ligg tilsvarande utdata under show bgp vrf CUSTOMER ipv4 unicast. Kommandonamna er ulike, dei fire kontrollpunkta ikkje.

Kontroller eit prefiks som skal avvisast like nøye som eit som skal sleppe gjennom, fordi ein policy som tillèt alt ser identisk ut med ein riktig heilt til det første unntaket kjem. Sjå deretter på ein tilbaketrekking: slå av CE-grensesnittet, og stadfest at den eksterne oppføringa forsvinn innan forventa tidsur i staden for å bli liggjande.

Noter kven som eig kvar policy. Når leverandøren driv CE-en, høyrer den leverte oppførselen til tenesteavtalen, og ein annan protokoll eller tilbaketrekkingspolicy på den styrte eininga er eit dokumentasjonsproblem før det er eit ruteproblem.