RD kontra RT i et MPLS VPN: entydighed kontra importpolitik

To kundesites kan annoncere 10.20.0.0/24, og begge forbliver gyldige inden for ét udbydernetværk. Rute-distinguisheren holder disse annoncer adskilt; rute-targeten afgør, hvilken kunde-VRF der må tage en kopi. De står ved siden af hinanden i konfigurationen og løser helt forskellige opgaver. At forveksle de to fører til ændringer, der ser rimelige ud og ikke retter noget.

Følg én rute fra kundekanten til en fjern VRF og opdelingen bliver konkret: identiteten tilknyttes, før ruten kommer ind i BGP, og distributionspolitikken vurderes, når ruten når den modtagende udbyderkant.

En VPN-IPv4-rute er en RD plus et IPv4-præfiks

RFC 4364 definerer VPN-IPv4-adressefamilien som en otte-byte rute-distinguisher efterfulgt af en fire-byte IPv4-adresse. RD’en sættes foran kundens præfiks, så to identiske præfikser fra forskellige sites bliver to forskellige BGP-ruter.

Den konstruktion er hele entydighedsmekanismen. Udbyderen har ikke brug for, at kunderne bliver enige om ikke-overlappende adresseområde, og en rute fra ét site kan ikke lydløst erstatte et identisk præfiks fra et andet site.

Selve RD-formatet er en værdi, administratoren vælger, ofte et autonomesystemnummer og et lokalt nummer. Dens numeriske form er en konvention, ikke et signal om, at de to felter deler betydning med en rute-target, der tilfældigvis bruger de samme cifre.

RD’en gør overlappende præfikser adskillelige

Betragt to annoncer for samme præfiks. Site A bærer RD 65000:101, og site B bærer RD 65000:202, begge for 10.20.0.0/24. BGP holder nu to VPN-IPv4-ruter, der kan sammenlignes, filtreres og vælges uafhængigt.

RD’en siger ikke, hvilken VRF der skal modtage nogen af ruterne, og den identificerer ikke en kunde eller en tjeneste. Det er et identitetsfelt for ruten, ikke en medlemsliste. En VRF’s egen RD behøver ikke at matche RD’en for en rute, den importerer.

Derfor retter det intet at ændre en RD, så den matcher et andet sites nummer. Hvis en rute mangler på den anden side, skaber de matchende cifre et andet identitetsproblem i stedet for at reparere importbeslutningen.

RT’en er et BGP-attribut, ikke et mærke i pakken

En eksportpolitik knytter et eller flere rute-targets til ruten som udvidede community-attributter i BGP. Den modtagende udbyderkant sammenligner disse attributter med importpolitikken for hver VRF. RT’en rejser med ruten gennem kontrolplanet. Sammenligningen sker udelukkende i rutepolitikken, før nogen kundepakke videresendes.

Kundens datapakker bærer ikke RT’en. Når en rute er installeret i en VRF, bruger videresendelsen den VRF’s tabel og den MPLS-labelstak, som arkitekturen tildeler. Udbyderkanten læser ikke en rute-target fra hver kundepakke.

En rute kan bære flere RT’er, og en VRF kan importere flere. Konfigurationen ser ofte ud som en kort blok:

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

Læs den blok som to separate udsagn. Eksportlinjen styrer, hvad der knyttes til ruter, der forlader denne VRF; importlinjen styrer, hvad denne VRF er villig til at overveje. Matchende numre er bekvemt, ikke obligatorisk.

Importberettigelse er ikke installation

En rute kan være berettiget for en VRF og alligevel ikke optræde i dens videresendelsestabel. Berettigelse er et filter; derefter sammenligner den normale BGP-beslutningsproces berettigede ruter og vælger én. En ældre eller mindre foretrukken rute kan tabe til en anden berettiget vej.

Kontrollér den valgte rute, ikke kun importpolitikken. En VRF, der importerer RT 65000:500 og ikke viser nogen rute for 10.20.0.0/24, kan have modtaget ruten og afvist den under valget, eller måske aldrig have modtaget den.

Denne forskel betyder også noget, når et uventet præfiks dukker op. En for bred importpolitik kan trække ruter ind, som siteet ikke havde til hensigt at bruge, og RD’ens entydighed forhindrer det ikke. Distributionsomfang er et RT-politikspørgsmål.

Fejlfind en manglende rute i kontrolplanets rækkefølge

Begynd med annoncen: eksporterer den oprindelige VRF den tilsigtede RT, og findes ruten som en VPN-IPv4-rute på rutereflektoren eller den modtagende PE? Kontrollér derefter attributtet, som det er modtaget, ikke som det er konfigureret på afsenderen.

Sammenlign derefter den modtagende VRF’s importliste med rutens faktiske RT-værdier. Undersøg til sidst den valgte rute i den VRF og labelbindingen. Hvert trin besvarer et forskelligt spørgsmål, og at springe til RD’en springer normalt det trin over, der er forkert.

Notér RD’en, den eksporterede RT, den importerede RT og det valgte næste hop for det fungerende og det fejlende site. Fire værdier side om side gør et vagt “VPN’et sender ikke ruter” til det præcise kontrolplanstrin, der afviger.