Samma /24 för två kunder? VPNv4 kräver en RD och en etikett

Två hyresgäster numrerar sin filial med samma 10.50.0.0/24, och efter en ändring försvinner den ena hyresgästens rutt från leverantörens kant medan den andra fortsätter att fungera. Förenklingen bakom den biljetten är oftast att hoppa över route distinguishern eftersom „etiketten identifierar redan kunden“. Det gör den inte. RD:n och etiketten svarar på två olika frågor, och skillnaden blir bara synlig när överlappande adresser tvingar fram den.

En rutt där det borde vara två

Vanlig IPv4 unicast jämför två vägar till samma prefix och installerar den bättre. 10.50.0.0/24 från hyresgäst A och 10.50.0.0/24 från hyresgäst B är en nyckel, så en vinner och den andra överlever bara som reservväg. Protokollet gjorde det det blev tillsagt; kontrollplanet ombads att lagra två olika rutter under en enda identifierare.

Resultatet ser ut som en saknad rutt snarare än ett fel: den PE som förlorade tävlingen vidarebefordrar fortfarande sin egen hyresgäst lokalt, så en ping inom platsen lyckas och testet mellan platser misslyckas. Räkna posterna för det prefixet i VPNv4-tabellen innan du rör någon policy.

RD:n gör en nyckel till två

En åtta byte lång route distinguisher sätts före IPv4-prefixet, och objektet som BGP bär blir en VPN-IPv4-adress i stället för ett IPv4-prefix. Två hyresgäster kan hålla samma 32 bitar eftersom de 64 bitarna framför skiljer sig. Det finns formattyper för en AS-baserad RD och för en adressbaserad, och valet tillhör den ursprungliga PE:n. En AS-baserad RD är vanlig när PE:erna delar ett AS, och en adressbaserad när de inte gör det.

Läs inte RD:n som ett medlemskapsmärke. Ruttmål styr import och export och avgör vilka VRF:er som får installera rutten; RD:n garanterar bara att rutten har sin egen identitet. Att ge varje VRF sin egen RD är vanlig praxis eftersom det håller den mappningen läsbar i en ruttöversikt.

Etiketten är en lokal vidarebefordringsinstruktion

Varje annonsering bär också en MPLS-etikett, och dess betydelse är begränsad till den router som tilldelade den. En annan PE kan dela ut samma nummer för en orelaterad destination. Det är just därför etiketten inte kan ersätta kundens identitet: numret är bara korrekt bredvid nästa hopp och det vidarebefordringstillstånd som installerade det.

Tilldelningens granularitet varierar med implementering och design: vissa plattformar tilldelar en etikett per VRF, andra per prefix, och etiketten kan identifiera en vidarebefordringsåtgärd i stället för en kund. Två olika etiketter som når samma destination är ingen motsägelse, och samma etikettnummer på två PE:er är det heller inte.

Varför den ena inte kan ersätta den andra

Att läsa en annonsering betyder att titta på fyra saker tillsammans: prefixet kvalificerat av RD:n, ruttmålen, nästa hopp och etiketten. Att läsa ett användarpaket betyder att titta på den stack som installerades från den informationen. En sund design visar båda sidorna stämma överens, och en trasig har oftast en sida rätt och den andra inaktuell. Den jämförelsen skiljer ett identitetsproblem från ett vidarebefordringsproblem.

Den prydliga kontrasten mellan kontrollplan och dataplan är ett pedagogiskt grepp, inte en beskrivning av kodningen. RFC 8277 placerar etiketten inne i den etiketterade NLRI:n, så annonseringen själv bär bindningen; att använda den för vidarebefordran är det senare, separata steget.

När en hyresgästs rutt saknas, kontrollera i den här ordningen: två VPNv4-poster för prefixet, rätt ruttmål på varje, ett nästa hopp som går att lösa upp, och en etikett som den mottagande PE:n har tillstånd för. Att rätta identitet med ett vidarebefordringsvärde, eller tvärtom, klarar en kontroll och fallerar på nästa.