Samme /24 til to kunder? VPNv4 kræver en RD og en label

To lejere nummererer deres filial med 10.50.0.0/24, og efter en ændring forsvinder den ene lejers rute fra udbyderens kant, mens den anden fortsat virker. Den forenkling, der ligger bag den sag, er som regel at droppe route distinguisheren, fordi „labelen identificerer allerede kunden“. Det gør den ikke. RD'en og labelen svarer på to forskellige spørgsmål, og forskellen bliver først synlig, når overlappende adresser tvinger den frem.

Én rute, hvor der burde være to

Almindelig IPv4 unicast sammenligner to stier til samme præfiks og installerer den bedste. 10.50.0.0/24 fra lejer A og 10.50.0.0/24 fra lejer B er én nøgle, så én vinder, og den anden overlever kun som backupsti. Protokollen gjorde, hvad den fik besked på; kontrolplanet blev bedt om at gemme to forskellige ruter under én identifikator.

Resultatet ligner en manglende rute snarere end en fejl: den PE, der tabte konkurrencen, videresender stadig sin egen lejer lokalt, så et ping inden for lokaliteten lykkes, og testen mellem lokaliteter fejler. Tæl indgangene for det præfiks i VPNv4-tabellen, før du rører ved nogen politik.

RD'en gør én nøgle til to

En otte byte lang route distinguisher sættes foran IPv4-præfikset, og det objekt, BGP bærer, bliver en VPN-IPv4-adresse i stedet for et IPv4-præfiks. To lejere kan holde de samme 32 bit, fordi de 64 bit foran er forskellige. Der findes formattyper til en AS-baseret RD og til en adressebaseret, og valget tilhører den oprindelige PE. En AS-baseret RD er almindelig, når PE'erne deler et AS, og en adressebaseret, når de ikke gør.

Læs ikke RD'en som et medlemskabsmærke. Ruttargets styrer import og eksport og afgør, hvilke VRF'er der må installere ruten; RD'en garanterer kun, at ruten har sin egen identitet. At give hver VRF sin egen RD er almindelig praksis, fordi det holder den mapping læsbar i en ruteoversigt.

Labelen er en lokal videresendelsesinstruks

Hver annoncering bærer også en MPLS-label, og dens betydning er begrænset til den router, der tildelte den. En anden PE kan udstede det samme nummer til en urelateret destination. Det er netop derfor, labelen ikke kan stå i stedet for kundens identitet: nummeret er kun korrekt ved siden af næste hop og den videresendelsestilstand, der installerede det.

Tildelingsgranulariteten varierer med implementering og design: nogle platforme tildeler en label pr. VRF, andre pr. præfiks, og labelen kan identificere en videresendelseshandling snarere end en kunde. To forskellige labels, der når samme destination, er ingen selvmodsigelse, og det samme labelnummer på to PE'er er det heller ikke.

Hvorfor den ene ikke kan erstatte den anden

At læse en annoncering betyder at se på fire ting sammen: det RD-kvalificerede præfiks, ruttargets, næste hop og labelen. At læse en brugerpakke betyder at se på den stak, der blev installeret ud fra den information. Et sundt design viser begge sider stemme overens, og et brudt har som regel den ene side rigtig og den anden forældet. Den sammenligning adskiller et identitetsproblem fra et videresendelsesproblem.

Den pæne kontrast mellem kontrolplan og dataplan er et pædagogisk greb, ikke en beskrivelse af kodningen. RFC 8277 placerer labelen inde i den labeled NLRI, så annonceringen selv bærer bindingen; at bruge den til videresendelse er det senere, særskilte skridt.

Når en lejers rute mangler, så kontrollér i denne rækkefølge: to VPNv4-indgange for præfikset, det rigtige ruttarget på hver, et næste hop der kan opløses, og en label, som den modtagende PE har tilstand for. At rette identitet med en videresendelsesværdi, eller omvendt, består én kontrol og fejler den næste.