RD mot RT i et MPLS VPN: entydighet mot importpolicy

To kundesider kan annonsere 10.20.0.0/24, og begge forblir gyldige i ett leverandørnettverk. Rute-distinguisheren holder disse annonsene atskilt; rute-targeten avgjør hvilken kunde-VRF som kan ta en kopi. De står ved siden av hverandre i konfigurasjonen og gjør helt forskjellige jobber. Å forveksle de to fører til endringer som ser rimelige ut og ikke retter noe.

Følg én rute fra kundekanten til en ekstern VRF og oppdelingen blir konkret: identiteten festes før ruten kommer inn i BGP, og distribusjonspolicyen vurderes når ruten når leverandørkanten som mottar den.

En VPN-IPv4-rute er en RD pluss et IPv4-prefiks

RFC 4364 definerer VPN-IPv4-adressefamilien som en åtte-byte rute-distinguisher etterfulgt av en fire-byte IPv4-adresse. RD-en settes foran kundens prefiks, slik at to identiske prefikser fra ulike områder blir to forskjellige BGP-ruter.

Den konstruksjonen er hele entydighetsmekanismen. Leverandøren trenger ikke at kundene blir enige om ikke-overlappende adresseområde, og en rute fra ett område kan ikke stille erstatte et identisk prefiks fra et annet område.

Selve RD-formatet er en verdi administratoren velger, vanligvis et autonomt systemnummer og et lokalt nummer. Den numeriske formen er en konvensjon, ikke et signal om at de to feltene deler betydning med en rute-target som tilfeldigvis bruker de samme sifrene.

RD-en gjør overlappende prefikser skillbare

Tenk på to annonser for samme prefiks. Område A bærer RD 65000:101 og område B bærer RD 65000:202, begge for 10.20.0.0/24. BGP holder nå to VPN-IPv4-ruter som kan sammenlignes, filtreres og velges uavhengig.

RD-en sier ikke hvilken VRF som skal motta noen av rutene, og den identifiserer ikke en kunde eller en tjeneste. Det er et identitetsfelt for ruten, ikke en medlemsliste. En VRFs egen RD trenger ikke å samsvare med RD-en til en rute den importerer.

Derfor retter det ingenting å endre en RD slik at den samsvarer med et annet områdes nummer. Hvis en rute mangler på den andre siden, skaper samsvarende sifre et annet identitetsproblem i stedet for å reparere importbeslutningen.

RT-en er et BGP-attributt, ikke en tag i pakken

En eksportpolicy fester én eller flere rute-targets til ruten som utvidede fellesskapsattributter i BGP. Leverandørkanten som mottar sammenligner disse attributtene med importpolicyen for hver VRF. RT-en reiser med ruten gjennom kontrollplanet. Sammenligningen skjer helt og holdent i rutepolicyen, før noen kundepakke videresendes.

Kundens datapakker bærer ikke RT-en. Når en rute er installert i en VRF, bruker videresendingen tabellen til den VRF-en og MPLS-etikettstakken som arkitekturen tildeler. Leverandørkanten leser ikke en rute-target fra hver kundepakke.

En rute kan bære flere RT-er, og en VRF kan importere flere. Konfigurasjonen ser ofte ut som en kort blokk:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

Les den blokken som to separate utsagn. Eksportlinjen styrer hva som festes til ruter som forlater denne VRF-en; importlinjen styrer hva denne VRF-en er villig til å vurdere. Samsvarende numre er praktisk, ikke påkrevd.

Importberettigelse er ikke installasjon

En rute kan være berettiget for en VRF og likevel ikke dukke opp i videresendingstabellen. Berettigelse er et filter; deretter sammenligner den vanlige BGP-beslutningsprosessen berettigede ruter og velger én. En eldre eller mindre foretrukket rute kan tape mot en annen berettiget vei.

Kontroller den valgte ruten, ikke bare importpolicyen. En VRF som importerer RT 65000:500 og ikke viser noen rute for 10.20.0.0/24, kan ha mottatt ruten og avvist den under valget, eller den har kanskje aldri mottatt den.

Denne forskjellen betyr noe også når et uventet prefiks dukker opp. En for bred importpolicy kan trekke inn ruter som området ikke hadde til hensikt å bruke, og entydigheten til RD-en hindrer det ikke i det hele tatt. Distribusjonsomfanget er et RT-policy-spørsmål.

Feilsøk en manglende rute i kontrollplanets rekkefølge

Begynn med annonsen: eksporterer kilde-VRF-en den tiltenkte RT-en, og finnes ruten som en VPN-IPv4-rute på rutereflektoren eller den mottakende PE-en? Kontroller deretter attributtet slik det ble mottatt, ikke slik det er konfigurert på avsenderen.

Sammenlign deretter importlisten til den mottakende VRF-en med rutens faktiske RT-verdier. Se til slutt på den valgte ruten i den VRF-en og etikettbindingen. Hvert trinn besvarer et annet spørsmål, og å hoppe til RD-en hopper vanligvis over nettopp det trinnet som er feil.

Noter RD-en, den eksporterte RT-en, den importerte RT-en og neste hopp som er valgt for området som fungerer og det som feiler. Fire verdier side om side gjør et vagt «VPN-et sender ikke ruter» til det presise kontrollplanstrinnet som avviker.