Același /24 pentru doi clienți? VPNv4 are nevoie de un RD și o etichetă

Doi chiriași își numerotează sucursala cu același 10.50.0.0/24, iar după o modificare ruta unuia dispare de la marginea furnizorului, în timp ce a celuilalt continuă să funcționeze. Simplificarea din spatele acelui tichet este de obicei eliminarea distinctorului de rută (RD) pentru că „eticheta identifică deja clientul“. Nu o face. RD și eticheta răspund la două întrebări diferite, iar diferența devine vizibilă doar când adresele suprapuse o impun.

O rută acolo unde ar trebui să fie două

Unicastul IPv4 obișnuit compară două căi către același prefix și o instalează pe cea mai bună. 10.50.0.0/24 de la chiriașul A și 10.50.0.0/24 de la chiriașul B sunt o singură cheie, așa că una câștigă, iar cealaltă supraviețuiește doar ca rută de rezervă. Protocolul a făcut ce i s-a spus; planului de control i s-a cerut să stocheze două rute diferite sub un singur identificator.

Rezultatul arată ca o rută lipsă, nu ca o eroare: PE-ul care a pierdut competiția își transmite în continuare chiriașul local, așa că o verificare în interiorul sitului reușește, iar testul între situri eșuează. Numărați intrările pentru acel prefix în tabelul VPNv4 înainte de a atinge vreo politică.

RD transformă o cheie în două

Un distinctor de rută de opt biți este adăugat în fața prefixului IPv4, iar obiectul pe care îl transportă BGP devine o adresă VPN-IPv4 în loc de prefix IPv4. Doi chiriași pot păstra aceiași 32 de biți pentru că cei 64 de biți din față diferă. Există tipuri de format pentru un RD bazat pe AS și pentru unul bazat pe adresă, iar alegerea aparține PE-ului de origine. Un RD bazat pe AS este obișnuit când PE-urile împart un AS, iar unul bazat pe adresă când nu împart.

Nu citiți RD ca pe o etichetă de apartenență. Țintele de rută guvernează importul și exportul și decid ce VRF pot instala ruta; RD garantează doar că ruta are o identitate proprie. A da fiecărui VRF propriul RD este practica obișnuită pentru că păstrează acea mapare lizibilă într-un vizualizator de rute.

Eticheta este o instrucțiune locală de transmitere

Fiecare anunț poartă și o etichetă MPLS, iar semnificația ei este limitată la routerul care a alocat-o. Un alt PE poate emite același număr pentru o destinație fără legătură. Exact de aceea eticheta nu poate înlocui identitatea clientului: numărul este corect doar lângă următorul salt și starea de transmitere care l-a instalat.

Granularitatea alocării variază în funcție de implementare și proiectare: unele platforme alocă o etichetă pe VRF, altele pe prefix, iar eticheta poate identifica o acțiune de transmitere în loc de un client. Două etichete diferite care ajung la aceeași destinație nu sunt o contradicție, iar același număr de etichetă pe două PE nici atât.

De ce unul nu poate înlocui celălalt

A citi un anunț înseamnă a privi patru lucruri împreună: prefixul calificat de RD, țintele de rută, următorul salt și eticheta. A citi un pachet de utilizator înseamnă a privi stiva instalată din acele informații. Un proiect sănătos arată ambele părți potrivindu-se, iar unul defect are de obicei o parte corectă și cealaltă învechită. Acea comparație separă o problemă de identitate de o problemă de transmitere.

Contrastul îngrijit dintre planul de control și planul de date este un instrument didactic, nu o descriere a codificării. RFC 8277 pune eticheta în interiorul NLRI etichetat, așa că anunțul însuși poartă legătura; folosirea ei pentru transmitere este pasul ulterior și separat.

Când lipsește ruta unui chiriaș, verificați în această ordine: două intrări VPNv4 pentru prefix, ținta de rută corectă pe fiecare, un următor salt rezolvabil și o etichetă pentru care PE-ul receptor are stare. Repararea identității cu o valoare de transmitere, sau invers, va trece o verificare și va eșua la următoarea.