El mateix /24 per a dos clients? VPNv4 necessita un RD i una etiqueta
Dos llogaters poden anunciar el mateix /24 només perquè el RD dona a cada ruta la seva pròpia identitat. L’etiqueta respon una altra pregunta: com reenviar.
Dos llogaters numeren la seva sucursal amb 10.50.0.0/24, i després d’un canvi la ruta d’un dels llogaters desapareix de la vora del proveïdor mentre l’altre continua funcionant. La simplificació que hi ha darrere d’aquest tiquet sol ser eliminar el distingidor de ruta (RD) perquè «l’etiqueta ja identifica el client». No ho fa. El RD i l’etiqueta responen dues preguntes diferents, i la diferència només es fa visible quan les adreces solapades ho fan inevitable.
Una ruta on n’hi hauria d’haver dues
L’unicast IPv4 simple compara dos camins cap al mateix prefix i instal·la el millor. 10.50.0.0/24 del llogater A i 10.50.0.0/24 del llogater B són una sola clau, així que un guanya i l’altre només sobreviu com a camí de reserva. El protocol va fer el que se li va dir; es va demanar al pla de control que desés dues rutes diferents sota un sol identificador.
El resultat sembla una ruta que falta més que no pas un error: el PE que va perdre la competició continua reenviant el seu llogater localment, de manera que un ping dins del lloc té èxit i la prova entre llocs falla. Compteu les entrades d’aquest prefix a la taula VPNv4 abans de tocar cap política.
El RD converteix una clau en dues
Un distingidor de ruta de vuit bytes s’anteposa al prefix IPv4, i l’objecte que BGP transporta es converteix en una adreça VPN-IPv4 en lloc d’un prefix IPv4. Dos llogaters poden tenir els mateixos 32 bits perquè els 64 bits del davant difereixen. Hi ha tipus de format per a un RD basat en AS i per a un de basat en adreça, i l’elecció correspon al PE d’origen. Un RD basat en AS és habitual quan els PE comparteixen un AS, i un de basat en adreça quan no ho fan.
No llegiu el RD com una etiqueta de pertinença. Les destinacions de ruta governen la importació i l’exportació i decideixen quins VRF poden instal·lar la ruta; el RD només garanteix que la ruta tingui una identitat pròpia. Donar a cada VRF el seu propi RD és la pràctica habitual perquè manté aquesta correspondència llegible en una eina de visualització de rutes.
L’etiqueta és una instrucció de reenviament local
Cada anunci també porta una etiqueta MPLS, i el seu significat queda limitat al router que l’ha assignat. Un altre PE pot lliurar el mateix número per a una destinació sense relació. Per això mateix l’etiqueta no pot substituir la identitat del client: el número només és correcte al costat del següent salt i de l’estat de reenviament que l’ha instal·lat.
La granularitat de l’assignació varia segons la implementació i el disseny: algunes plataformes assignen una etiqueta per VRF, altres per prefix, i l’etiqueta pot identificar una acció de reenviament en lloc d’un client. Dues etiquetes diferents que arriben a la mateixa destinació no són cap contradicció, i el mateix número d’etiqueta en dos PE tampoc.
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
Per què l’un no pot substituir l’altre
Llegir un anunci vol dir mirar quatre coses alhora: el prefix qualificat pel RD, les destinacions de ruta, el següent salt i l’etiqueta. Llegir un paquet d’usuari vol dir mirar la pila que s’ha instal·lat a partir d’aquesta informació. Un disseny sa mostra les dues bandes coincidents, i un de trencat sol tenir una banda correcta i l’altra obsoleta. Aquesta comparació separa un problema d’identitat d’un problema de reenviament.
El contrast net entre pla de control i pla de dades és un recurs didàctic, no una descripció de la codificació. RFC 8277 posa l’etiqueta dins de l’NLRI etiquetat, de manera que l’anunci mateix porta la vinculació; fer-la servir per reenviar és el pas posterior i separat.
Quan falta una ruta de llogater, comproveu en aquest ordre: dues entrades VPNv4 per al prefix, la destinació de ruta correcta a cadascuna, un següent salt resoluble i una etiqueta per a la qual el PE receptor tingui estat. Arreglar la identitat amb un valor de reenviament, o a l’inrevés, passarà una comprovació i fallarà la següent.