RD kontra RT i ett MPLS VPN: entydighet kontra importpolicy

Två kundsajter kan annonsera 10.20.0.0/24 och båda förblir giltiga inom ett och samma leverantörsnät. Rute-distinguishern håller dessa annonser åtskilda; rute-targeten avgör vilken kund-VRF som får ta en kopia. De står bredvid varandra i konfigurationen och gör helt olika saker. Att blanda ihop de två leder till ändringar som ser rimliga ut och inte åtgärdar något.

Följ en rutt från kundkanten till en avlägsen VRF och uppdelningen blir konkret: identiteten fästs innan rutten kommer in i BGP, och distributionspolicyn utvärderas när rutten når leverantörskanten som tar emot den.

En VPN-IPv4-rutt är en RD plus ett IPv4-prefix

RFC 4364 definierar VPN-IPv4-adressfamiljen som en åttabyte rute-distinguisher följd av en fyrabyte IPv4-adress. RD:n sätts framför kundens prefix, så två identiska prefix från olika sajter blir två olika BGP-rutter.

Den konstruktionen är hela entydighetsmekanismen. Leverantören behöver inte att kunderna enas om icke-överlappande adressrymd, och en rutt från en sajt kan inte tyst ersätta ett identiskt prefix från en annan sajt.

Själva RD-formatet är ett värde som administratören väljer, vanligen ett autonomt systemnummer och ett lokalt nummer. Dess numeriska form är en konvention, inte ett tecken på att de två fälten delar betydelse med en rute-target som råkar använda samma siffror.

RD:n gör överlappande prefix urskiljbara

Betrakta två annonser för samma prefix. Sajt A bär RD 65000:101 och sajt B bär RD 65000:202, båda för 10.20.0.0/24. BGP håller nu två VPN-IPv4-rutter som kan jämföras, filtreras och väljas oberoende av varandra.

RD:n säger inte vilken VRF som ska ta emot någon av rutterna, och den identifierar inte en kund eller en tjänst. Det är ett identitetsfält för rutten, inte en medlemslista. En VRFs egen RD behöver inte matcha RD:n för en rutt som den importerar.

Därför åtgärdar det ingenting att ändra en RD så att den matchar en annan sajts nummer. Om en rutt saknas på andra sidan skapar de matchande siffrorna ett annat identitetsproblem i stället för att reparera importbeslutet.

RT:n är ett BGP-attribut, inte en tagg i paketet

En exportpolicy fäster ett eller flera rute-targets vid rutten som utökade community-attribut i BGP. Leverantörskanten som tar emot jämför dessa attribut med importpolicyn för varje VRF. RT:n reser med rutten genom kontrollplanet. Jämförelsen sker helt och hållet i rutpolicyn, innan något kundpaket vidarebefordras.

Kundens datapaket bär inte RT:n. När en rutt är installerad i en VRF använder vidarebefordran tabellen för den VRF:n och den MPLS-etikettstack som arkitekturen tilldelar. Leverantörskanten läser inte ett rute-target från varje kundpaket.

En rutt kan bära flera RT:er, och en VRF kan importera flera. Konfigurationen ser ofta ut som ett kort block:

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

Läs det blocket som två separata påståenden. Exportraden styr vad som fästs vid rutter som lämnar denna VRF; importraden styr vad denna VRF är beredd att överväga. Matchande nummer är bekvämt, inte obligatoriskt.

Importberättigande är inte installation

En rutt kan vara berättigad för en VRF och ändå inte dyka upp i dess vidarebefordranstabell. Berättigande är ett filter; därefter jämför den normala BGP-beslutsprocessen berättigade rutter och väljer en. En äldre eller mindre föredragen rutt kan förlora mot en annan berättigad väg.

Kontrollera den valda rutten, inte bara importpolicyn. En VRF som importerar RT 65000:500 och inte visar någon rutt för 10.20.0.0/24 kan ha tagit emot rutten och avvisat den vid valet, eller kanske aldrig tagit emot den.

Denna skillnad spelar roll även när ett oväntat prefix dyker upp. En alltför bred importpolicy kan dra in rutter som sajten inte avsåg att använda, och entydigheten hos RD:n hindrar det inte alls. Distributionsomfånget är en RT-policyfråga.

Felsök en saknad rutt i kontrollplanets ordning

Börja med annonsen: exporterar käll-VRF:n den avsedda RT:n, och finns rutten som en VPN-IPv4-rutt på ruttreflektorn eller den mottagande PE:n? Kontrollera sedan attributet så som det togs emot, inte som det är konfigurerat hos avsändaren.

Jämför därefter importlistan för den mottagande VRF:n med ruttens faktiska RT-värden. Inspektera till sist den valda rutten i den VRF:n och etikettbindningen. Varje steg besvarar en annan fråga, och att hoppa till RD:n hoppar vanligen över just det steg som är fel.

Anteckna RD:n, den exporterade RT:n, den importerade RT:n och nästa hopp som valts för sajten som fungerar och den som fallerar. Fyra värden sida vid sida förvandlar ett vagt ”VPN:et skickar inte rutter” till det exakta kontrollplansteg som avviker.