¿O mesmo /24 para dous clientes? VPNv4 necesita un RD e unha etiqueta
Dous inquilinos poden anunciar o mesmo /24 só porque o RD dá a cada ruta a súa propia identidade. A etiqueta responde a outra pregunta: como reenviar.
Dous inquilinos numeran a súa sucursal co mesmo 10.50.0.0/24, e tras un cambio a ruta dun deles desaparece da beira do provedor mentres a do outro segue funcionando. A simplificación que hai detrás dese ticket adoita ser eliminar o distinguidor de ruta (RD) porque «a etiqueta xa identifica o cliente». Non o fai. O RD e a etiqueta responden a dúas preguntas distintas, e a diferenza só se ve cando os enderezos solapados a impoñen.
Unha ruta onde debería haber dúas
O unicast IPv4 simple compara dous camiños cara ao mesmo prefixo e instala o mellor. 10.50.0.0/24 do inquilino A e 10.50.0.0/24 do inquilino B son unha soa clave, así que un gaña e o outro só sobrevive como camiño de reserva. O protocolo fixo o que se lle dixo; pediuse ao plano de control que gardase dúas rutas distintas baixo un único identificador.
O resultado parece unha ruta ausente máis que un erro: o PE que perdeu a competición segue reenviando o seu inquilino localmente, así que un ping dentro do sitio funciona e a proba entre sitios falla. Conta as entradas dese prefixo na táboa VPNv4 antes de tocar calquera política.
O RD converte unha clave en dúas
Un distinguidor de ruta de oito bytes antepónse ao prefixo IPv4, e o obxecto que transporta BGP pasa a ser un enderezo VPN-IPv4 en lugar dun prefixo IPv4. Dous inquilinos poden manter os mesmos 32 bits porque os 64 bits de diante difiren. Existen tipos de formato para un RD baseado en AS e para un baseado en enderezo, e a elección pertence ao PE de orixe. Un RD baseado en AS é habitual cando os PE comparten un AS, e un baseado en enderezo cando non o fan.
Non leas o RD como unha etiqueta de pertenza. Os obxectivos de ruta gobernan a importación e a exportación e deciden que VRF poden instalar a ruta; o RD só garante que a ruta teña unha identidade propia. Dar a cada VRF o seu propio RD é a práctica habitual porque mantén esa correspondencia lexible nun visor de rutas.
A etiqueta é unha instrución de reenvío local
Cada anuncio tamén leva unha etiqueta MPLS, e o seu significado queda limitado ao router que a asignou. Outro PE pode entregar o mesmo número para un destino sen relación. Por iso mesmo a etiqueta non pode substituír a identidade do cliente: o número só é correcto xunto ao seguinte salto e ao estado de reenvío que o instalou.
A granularidade da asignación varía segundo a implementación e o deseño: algunhas plataformas asignan unha etiqueta por VRF, outras por prefixo, e a etiqueta pode identificar unha acción de reenvío en lugar dun cliente. Dúas etiquetas distintas que chegan ao mesmo destino non son unha contradición, e o mesmo número de etiqueta en dous PE tampouco.
| 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 que un non pode substituír o outro
Ler un anuncio significa mirar catro cousas á vez: o prefixo cualificado polo RD, os obxectivos de ruta, o seguinte salto e a etiqueta. Ler un paquete de usuario significa mirar a pila instalada a partir desa información. Un deseño san mostra as dúas partes coincidentes, e un roto adoita ter unha parte correcta e a outra obsoleta. Esa comparación separa un problema de identidade dun problema de reenvío.
O contraste limpo entre plano de control e plano de datos é un recurso didáctico, non unha descrición da codificación. RFC 8277 coloca a etiqueta dentro do NLRI etiquetado, así que o propio anuncio leva a vinculación; usala para reenviar é o paso posterior e separado.
Cando falta unha ruta de inquilino, comproba nesta orde: dúas entradas VPNv4 para o prefixo, o obxectivo de ruta correcto en cada unha, un seguinte salto resoluble e unha etiqueta para a que o PE receptor teña estado. Arranxar a identidade cun valor de reenvío, ou ao revés, pasará unha comprobación e fallará a seguinte.