Samme /24 for to kunder? VPNv4 trenger en RD og en etikett

To leietakere nummererer filialen sin med den samme 10.50.0.0/24, og etter en endring forsvinner ruten til den ene leietakeren fra leverandørens kant mens den andre fortsetter å virke. Forenklingen bak den saken er vanligvis å droppe route distinguisheren fordi „etiketten identifiserer allerede kunden“. Det gjør den ikke. RD-en og etiketten svarer på to forskjellige spørsmål, og forskjellen blir bare synlig når overlappende adresser tvinger den fram.

Én rute der det burde vært to

Vanlig IPv4 unicast sammenligner to stier til samme prefiks og installerer den beste. 10.50.0.0/24 fra leietaker A og 10.50.0.0/24 fra leietaker B er én nøkkel, så én vinner og den andre overlever bare som reservevei. Protokollen gjorde det den fikk beskjed om; kontrollplanet ble bedt om å lagre to forskjellige ruter under én identifikator.

Resultatet ser ut som en manglende rute snarere enn en feil: PE-en som tapte konkurransen, videresender fortsatt sin egen leietaker lokalt, så en ping innenfor anlegget lykkes og testen mellom anleggene feiler. Tell oppføringene for det prefikset i VPNv4-tabellen før du rører noen policy.

RD-en gjør én nøkkel til to

En åtte byte lang route distinguisher settes foran IPv4-prefikset, og objektet BGP bærer blir en VPN-IPv4-adresse i stedet for et IPv4-prefiks. To leietakere kan holde de samme 32 bitene fordi de 64 bitene foran er forskjellige. Det finnes formattyper for en AS-basert RD og for en adressebasert, og valget tilhører den opprinnelige PE-en. En AS-basert RD er vanlig når PE-ene deler et AS, og en adressebasert når de ikke gjør det.

Ikke les RD-en som et medlemskapsmerke. Ruttemål styrer import og eksport og avgjør hvilke VRF-er som kan installere ruten; RD-en garanterer bare at ruten har sin egen identitet. Å gi hver VRF sin egen RD er vanlig praksis fordi det holder den tilordningen lesbar i en ruteoversikt.

Etiketten er en lokal videresendingsinstruks

Hver annonsering bærer også en MPLS-etikett, og betydningen er begrenset til ruteren som tildelte den. En annen PE kan dele ut det samme nummeret for en urelatert destinasjon. Det er nettopp derfor etiketten ikke kan erstatte kundens identitet: nummeret er bare riktig ved siden av neste hopp og den videresendingstilstanden som installerte det.

Tildelingsgranulariteten varierer med implementasjon og design: noen plattformer tildeler én etikett per VRF, andre per prefiks, og etiketten kan identifisere en videresendingshandling snarere enn en kunde. To forskjellige etiketter som når samme destinasjon er ingen selvmotsigelse, og det samme etikettnummeret på to PE-er er det heller ikke.

Hvorfor den ene ikke kan erstatte den andre

Å lese en annonsering betyr å se på fire ting sammen: prefikset kvalifisert av RD-en, ruttemålene, neste hopp og etiketten. Å lese en brukerpakke betyr å se på stakken som ble installert fra den informasjonen. Et sunt design viser begge sider stemme overens, og et ødelagt har vanligvis én side riktig og den andre utdatert. Den sammenligningen skiller et identitetsproblem fra et videresendingsproblem.

Den ryddige kontrasten mellom kontrollplan og dataplan er et pedagogisk grep, ikke en beskrivelse av kodingen. RFC 8277 plasserer etiketten inne i den etiketterte NLRI-en, så annonseringen selv bærer bindingen; å bruke den til videresending er det senere, separate trinnet.

Når en leietakers rute mangler, kontroller i denne rekkefølgen: to VPNv4-oppføringer for prefikset, riktig ruttemål på hver, et neste hopp som kan løses opp, og en etikett som den mottakende PE-en har tilstand for. Å rette identitet med en videresendingsverdi, eller omvendt, består én kontroll og feiler på den neste.