¿El mismo /24 para dos clientes? VPNv4 necesita un RD y una etiqueta
Dos inquilinos pueden anunciar el mismo /24 solo porque el RD da a cada ruta su propia identidad. La etiqueta responde a otra pregunta: cómo reenviar.
Dos inquilinos numeran su sucursal con el mismo 10.50.0.0/24, y tras un cambio la ruta de uno desaparece del borde del proveedor mientras la del otro sigue funcionando. La simplificación que hay detrás de ese ticket suele ser eliminar el distinguidor de ruta (RD) porque «la etiqueta ya identifica al cliente». No lo hace. El RD y la etiqueta responden a dos preguntas distintas, y la diferencia solo se ve cuando las direcciones solapadas la fuerzan.
Una ruta donde debería haber dos
El unicast IPv4 simple compara dos caminos hacia el mismo prefijo e instala el mejor. 10.50.0.0/24 del inquilino A y 10.50.0.0/24 del inquilino B son una sola clave, así que uno gana y el otro solo sobrevive como camino de respaldo. El protocolo hizo lo que se le dijo; se pidió al plano de control que guardara dos rutas distintas bajo un único identificador.
El resultado parece una ruta ausente más que un error: el PE que perdió la competición sigue reenviando a su inquilino localmente, así que un ping dentro del sitio funciona y la prueba entre sitios falla. Cuente las entradas de ese prefijo en la tabla VPNv4 antes de tocar cualquier política.
El RD convierte una clave en dos
Un distinguidor de ruta de ocho bytes se antepone al prefijo IPv4, y el objeto que transporta BGP pasa a ser una dirección VPN-IPv4 en lugar de un prefijo IPv4. Dos inquilinos pueden mantener los mismos 32 bits porque los 64 bits de delante difieren. Existen tipos de formato para un RD basado en AS y para uno basado en dirección, y la elección corresponde al PE de origen. Un RD basado en AS es habitual cuando los PE comparten un AS, y uno basado en dirección cuando no lo hacen.
No lea el RD como una etiqueta de pertenencia. Los objetivos de ruta gobiernan la importación y la exportación y deciden qué VRF pueden instalar la ruta; el RD solo garantiza que la ruta tenga una identidad propia. Dar a cada VRF su propio RD es la práctica habitual porque mantiene esa correspondencia legible en un visor de rutas.
La etiqueta es una instrucción de reenvío local
Cada anuncio también lleva una etiqueta MPLS, y su significado queda limitado al router que la asignó. Otro PE puede entregar el mismo número para un destino sin relación. Por eso mismo la etiqueta no puede sustituir la identidad del cliente: el número solo es correcto junto al siguiente salto y al estado de reenvío que lo instaló.
La granularidad de la asignación varía según la implementación y el diseño: algunas plataformas asignan una etiqueta por VRF, otras por prefijo, y la etiqueta puede identificar una acción de reenvío en lugar de un cliente. Dos etiquetas distintas que llegan al mismo destino no son una contradicción, y el mismo número de etiqueta en dos PE tampoco.
| 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 |
Por qué uno no puede sustituir al otro
Leer un anuncio significa mirar cuatro cosas a la vez: el prefijo cualificado por el RD, los objetivos de ruta, el siguiente salto y la etiqueta. Leer un paquete de usuario significa mirar la pila instalada a partir de esa información. Un diseño sano muestra las dos partes coincidentes, y uno roto suele tener una parte correcta y la otra obsoleta. Esa comparación separa un problema de identidad de un problema de reenvío.
El contraste limpio entre plano de control y plano de datos es un recurso didáctico, no una descripción de la codificación. RFC 8277 coloca la etiqueta dentro del NLRI etiquetado, así que el propio anuncio lleva la vinculación; usarla para reenviar es el paso posterior y separado.
Cuando falta una ruta de inquilino, compruebe en este orden: dos entradas VPNv4 para el prefijo, el objetivo de ruta correcto en cada una, un siguiente salto resoluble y una etiqueta para la que el PE receptor tenga estado. Arreglar la identidad con un valor de reenvío, o al revés, pasará una comprobación y fallará la siguiente.