Same /24 for to kundar? VPNv4 treng ein RD og ein etikett

To leigetakarar nummererer filialen sin med den same 10.50.0.0/24, og etter ei endring forsvinn ruta til den eine leigetakaren frå kanten hos leverandøren medan den andre held fram med å verke. Forenklinga bak den saka er vanlegvis å droppe route distinguisheren fordi „etiketten identifiserer alt kunden“. Det gjer han ikkje. RD-en og etiketten svarar på to ulike spørsmål, og skilnaden blir berre synleg når overlappande adresser tvingar han fram.

Éi rute der det burde vore to

Vanleg IPv4 unicast samanliknar to stigar til same prefiks og installerer den beste. 10.50.0.0/24 frå leigetakar A og 10.50.0.0/24 frå leigetakar B er éin nøkkel, så éin vinn og den andre overlever berre som reserveveg. Protokollen gjorde det han fekk beskjed om; kontrollplanet vart bedt om å lagre to ulike ruter under éin identifikator.

Resultatet ser ut som ei manglande rute snarare enn ein feil: PE-en som tapte konkurransen, vidaresender framleis sin eigen leigetakar lokalt, så ein ping innanfor anlegget lukkast og testen mellom anlegga feilar. Tel oppføringane for det prefikset i VPNv4-tabellen før du rører nokon policy.

RD-en gjer éin nøkkel til to

Ein åtte byte lang route distinguisher blir sett føre IPv4-prefikset, og objektet BGP ber blir ei VPN-IPv4-adresse i staden for eit IPv4-prefiks. To leigetakarar kan halde dei same 32 bita fordi dei 64 bita føre er ulike. Det finst formattypar for ein AS-basert RD og for ein adressebasert, og valet høyrer til den opphavlege PE-en. Ein AS-basert RD er vanleg når PE-ane deler eit AS, og ein adressebasert når dei ikkje gjer det.

Ikkje les RD-en som eit medlemskapsmerke. Rutemål styrer import og eksport og avgjer kva VRF-ar som kan installere ruta; RD-en garanterer berre at ruta har sin eigen identitet. Å gje kvar VRF sin eigen RD er vanleg praksis fordi det held den tilordninga lesbar i ei ruteoversikt.

Etiketten er ein lokal vidaresendingsinstruks

Kvar annonsering ber òg ein MPLS-etikett, og tydinga er avgrensa til rutaren som tildelte han. Ein annan PE kan dele ut det same nummeret for ein urelatert destinasjon. Det er nettopp difor etiketten ikkje kan erstatte identiteten til kunden: nummeret er berre rett ved sida av neste hopp og den vidaresendingstilstanden som installerte det.

Tildelingsgranulariteten varierer med implementasjon og design: nokre plattformar tildeler éin etikett per VRF, andre per prefiks, og etiketten kan identifisere ei vidaresendingshandling snarare enn ein kunde. To ulike etikettar som når same destinasjon er inga sjølvmotsegn, og det same etikettnummeret på to PE-ar er det heller ikkje.

Kvifor den eine ikkje kan erstatte den andre

Å lese ei annonsering tyder å sjå på fire ting saman: prefikset kvalifisert av RD-en, rutemåla, neste hopp og etiketten. Å lese ein brukarpakke tyder å sjå på stakken som vart installert frå den informasjonen. Eit sunt design viser begge sider stemme overeins, og eit øydelagt har vanlegvis éi side rett og den andre utdatert. Den samanlikninga skil eit identitetsproblem frå eit vidaresendingsproblem.

Den ryddige kontrasten mellom kontrollplan og dataplan er eit pedagogisk grep, ikkje ei skildring av kodinga. RFC 8277 plasserer etiketten inne i den etiketterte NLRI-en, så annonseringa sjølv ber bindinga; å bruke han til vidaresending er det seinare, separate trinnet.

Når ruta til ein leigetakar manglar, kontroller i denne rekkjefølgja: to VPNv4-oppføringar for prefikset, rett rutemål på kvar, eit neste hopp som kan løysast opp, og ein etikett som den mottakande PE-en har tilstand for. Å rette identitet med ein vidaresendingsverdi, eller omvendt, går gjennom éin kontroll og feilar på den neste.