RD mot RT i eit MPLS VPN: eintydigheit mot importpolicy

To kundesider kan annonsere 10.20.0.0/24, og begge blir verande gyldige i eitt leverandørnettverk. Rute-distinguisheren held desse annonsane frå kvarandre; rute-targeten avgjer kva kunde-VRF som kan ta ein kopi. Dei står ved sida av kvarandre i konfigurasjonen og gjer heilt ulike arbeidsoppgåver. Å blande dei to fører til endringar som ser rimelege ut og ikkje rettar noko.

Følg éi rute frå kundekanten til ein ekstern VRF og oppdelinga blir konkret: identiteten blir festa før ruta kjem inn i BGP, og distribusjonspolicyen blir vurdert når ruta når leverandørkanten som tek imot henne.

Ei VPN-IPv4-rute er ein RD pluss eit IPv4-prefiks

RFC 4364 definerer VPN-IPv4-adressefamilien som ein åtte-byte rute-distinguisher etterfølgd av ei fire-byte IPv4-adresse. RD-en blir sett framfor prefikset til kunden, slik at to identiske prefiks frå ulike område blir to ulike BGP-ruter.

Den konstruksjonen er heile eintydigheitsmekanismen. Leverandøren treng ikkje at kundane blir samde om eit ikkje-overlappande adresseområde, og ei rute frå eitt område kan ikkje stille erstatta eit identisk prefiks frå eit anna område.

Sjølve RD-formatet er ein verdi administratoren vel, vanlegvis eit autonomt systemnummer og eit lokalt nummer. Den numeriske forma er ein konvensjon, ikkje eit signal om at dei to felta deler meining med ein rute-target som tilfeldigvis brukar dei same sifra.

RD-en gjer overlappande prefiks skilbare

Tenk på to annonsar for same prefiks. Område A ber RD 65000:101 og område B ber RD 65000:202, begge for 10.20.0.0/24. BGP held no to VPN-IPv4-ruter som kan samanliknast, filtrerast og veljast uavhengig.

RD-en seier ikkje kva VRF som skal ta imot noka av rutene, og han identifiserer ikkje ein kunde eller ei teneste. Det er eit identitetsfelt for ruta, ikkje ei medlemsliste. Eigen RD til ein VRF treng ikkje samsvara med RD-en til ei rute han importerer.

Difor rettar det ingenting å endre ein RD slik at han samsvarer med nummeret til eit anna område. Viss ei rute manglar på den andre sida, skapar samsvarande siffer eit anna identitetsproblem i staden for å reparere importavgjerda.

RT-en er eit BGP-attributt, ikkje ein tag i pakken

Ein eksportpolicy festar ein eller fleire rute-targets til ruta som utvida fellesskapsattributtar i BGP. Leverandørkanten som tek imot, samanliknar desse attributtane med importpolicyen for kvar VRF. RT-en reiser med ruta gjennom kontrollplanet. Samanlikninga skjer heilt og fullt i rutepolicyen, før nokon kundepakke blir send vidare.

Datapakkane til kunden ber ikkje RT-en. Når ei rute er installert i ein VRF, brukar videresendinga tabellen til den VRF-en og MPLS-etikettstakken som arkitekturen tildeler. Leverandørkanten les ikkje ein rute-target frå kvar kundepakke.

Ei rute kan bera fleire RT-ar, og ein VRF kan importere fleire. Konfigurasjonen ser ofte ut som ein 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 utsegner. Eksportlinja styrer kva som blir festa til ruter som forlèt denne VRF-en; importlinja styrer kva denne VRF-en er villig til å vurdere. Samsvarande nummer er praktisk, ikkje påkravd.

Importrett er ikkje installasjon

Ei rute kan vera rett for ein VRF og likevel ikkje dukka opp i videresendingstabellen. Rett er eit filter; deretter samanliknar den vanlege BGP-avgjerdsprosessen rette ruter og vel éi. Ei eldre eller mindre føretrekt rute kan tapa mot ein annan rett veg.

Kontroller den valde ruta, ikkje berre importpolicyen. Ein VRF som importerer RT 65000:500 og ikkje viser noka rute for 10.20.0.0/24, kan ha teke imot ruta og avvist henne under valet, eller han har kanskje aldri teke imot henne.

Denne skilnaden tel også når eit uventa prefiks dukkar opp. Ein for brei importpolicy kan trekke inn ruter som området ikkje hadde til føremål å bruke, og eintydigheita til RD-en hindrar det ikkje i det heile. Distribusjonsomfanget er eit RT-policy-spørsmål.

Feilsøk ei manglande rute i rekkjefølgja til kontrollplanet

Byrja med annonsen: eksporterer kjelde-VRF-en den tiltenkte RT-en, og finst ruta som ei VPN-IPv4-rute på rutereflektoren eller den mottakande PE-en? Kontroller deretter attributtet slik det blei motteke, ikkje slik det er konfigurert på sendaren.

Samanlikn deretter importlista til den mottakande VRF-en med dei faktiske RT-verdiane til ruta. Sjå til slutt på den valde ruta i den VRF-en og etikettbindinga. Kvart trinn svarar på eit anna spørsmål, og å hoppe til RD-en hoppar vanlegvis over nettopp det trinnet som er feil.

Noter RD-en, den eksporterte RT-en, den importerte RT-en og neste hopp som er valt for området som fungerer og det som feilar. Fire verdiar side om side gjer eit vagt «VPN-et sender ikkje ruter» til det presise kontrollplanstrinnet som avvik.