Resumen

  • Route Target Constraints convierte el interés de importación de cada PE en estado de divulgación por par: los NLRI de pertenencia avanzan hacia las fuentes y las rutas VPN coincidentes regresan por el grafo inverso.
  • La prueba de una incorporación, baja o migración exige capacidad AFI/SAFI negociada, pertenencia exacta, sincronización acotada, diferencias de Adj-RIB-Out, filtros de seguridad independientes y evidencia de VRF, etiquetas, FIB y paquetes.

El parte de cambio dice que el nuevo VRF está activo. Su Route Target de importación coincide con el de la ruta remota. El PE de origen anuncia el prefijo VPN y los vecinos BGP llevan horas en Established. El equipo busca una avería en el prefijo, en la etiqueta o en el reflector. Ninguna aparece.

La ausencia está antes y circula en dirección opuesta. El PE nuevo todavía no ha anunciado el RT Membership NLRI que expresa su interés. El reflector, por tanto, no incluye la ruta VPN en el conjunto que puede revelar a ese par. La ruta existe; lo que falta es la suscripción.

Ese comportamiento es el propósito de RFC 4684. En vez de inundar todos los PE con todas las rutas VPN para que cada uno descarte lo que no importa, RTC —también llamado RT-Constrain— permite que el receptor declare qué Route Targets necesita. El reflector construye un filtro de salida específico y devuelve únicamente los NLRI VPN coincidentes.

El ahorro de memoria, CPU y actualizaciones puede ser considerable cuando la pertenencia es dispersa. Pero la optimización añade un plano de evidencia. El estado verde de la sesión, la existencia de la ruta en la fuente y la configuración local del VRF ya no bastan para explicar qué debía conocer un receptor.

Route Target decide elegibilidad, no entrega

RFC 4364 distingue dos identificadores. El Route Distinguisher vuelve únicos en BGP prefijos VPN que podrían solaparse. El Route Target es una comunidad extendida que participa en la política de exportación e importación de los VRF.

Cuando un Route Target de una ruta coincide con el conjunto de importación de un VRF, la ruta queda habilitada para ese VRF. No queda automáticamente instalada. Aún intervienen selección BGP, política local, recursión del siguiente salto, resolución de etiqueta, proceso PE/CE y programación del plano de datos.

RTC tampoco transforma la pertenencia en identidad de cliente. Propaga conocimiento sobre demanda de distribución para que otro router evite enviar NLRI irrelevantes. El anuncio no valida la ruta, no crea el VRF y no demuestra que el tráfico pueda circular.

Conviene separar los puntos de fallo. La fuente puede no originar el prefijo. El RR puede no recibirlo. Puede faltar el interés RTC o perderse una ruta de pertenencia en la reflexión. El filtro derivado puede quedar obsoleto. El PE puede recibir la ruta pero rechazarla en importación, perder la selección o no resolver etiqueta y siguiente salto. Incluso una FIB correcta puede convivir con un fallo de paquetes fuera de ese nodo.

La investigación debe localizar el primer límite sin el estado esperado. Un contador agregado de “rutas VPN” no responde a esa pregunta.

Dos familias, dos direcciones

La idea decisiva de RFC 4684 es un grafo inverso. El receptor anuncia interés hacia quienes poseen o distribuyen rutas VPN; la alcanzabilidad coincidente vuelve hacia el receptor. No es una petición imperativa enviada a la fuente, sino estado BGP sujeto a selección, reflexión y política en cada salto.

La pertenencia usa MP_REACH_NLRI y MP_UNREACH_NLRI de RFC 4760, con AFI 1 y SAFI 132. Salvo la ruta de pertenencia por defecto, la clave contiene un AS de origen de cuatro octetos y un Route Target de ocho octetos, codificados como prefijo entre 32 y 96 bits. Los prefijos menos específicos permiten expresar interés más amplio, pero amplían también el coste y el perímetro revelado.

El prefijo de longitud cero es la pertenencia RT por defecto. Significa que el par acepta recibir todas las rutas VPN pertinentes de esa relación. No es una ruta IP por defecto, ni un VRF por defecto, ni un cliente comodín, ni una orden para instalarlo todo.

Puede ser legítimo que un reflector reciba un conjunto denso, y una implantación mixta puede necesitar distribución amplia hacia vecinos sin RTC. La excepción debe ser explícita: una pertenencia por defecto reduce la selectividad, eleva el volumen de rutas y actualizaciones y ensancha la superficie de información.

Capacidad negociada no equivale a interés presente

La capacidad multiprotocolo confirma que ambos pares aceptaron intercambiar AFI 1/SAFI 132. Es una condición necesaria, no una prueba del resultado. Un bloque de configuración como family route-target o rtfilter tampoco prueba negociación efectiva, origen de un NLRI concreto, recepción, selección ni filtro derivado.

La cadena mínima empieza con las dos vistas del OPEN. Continúa con el UPDATE exacto de pertenencia, la RIB RTC recibida, los caminos seleccionados y alternativos, la política aplicada y el filtro de salida calculado para las familias VPN. Cada artefacto prueba una frontera distinta.

La nota operativa de Cisco sobre Route Target Constraint muestra cómo una familia de equipos obtiene interés desde los RT de importación de VRF, anuncia rtfilter y deriva filtros recibidos. La referencia de Juniper sobre family route-target describe la misma dirección funcional.

Son fuentes útiles para esos productos, no reglas portátiles. La versión de software, la herencia real del vecino y el estado vivo deben conservarse. El comando de Cisco bgp default route-target filter y los controles de Route Target Filtering de Juniper documentan decisiones locales específicas; su presencia no demuestra por sí sola que el par intercambió pertenencia RFC 4684.

El reflector no puede quedarse con una sola demanda

La reflexión de rutas añade una dificultad particular. Varios PE del mismo AS pueden originar el mismo {AS de origen, Route Target}. Si se conservara únicamente el mejor camino iBGP ordinario, una sola procedencia podría ocultar que varios clientes necesitan recibir rutas coincidentes.

RFC 4684 exige considerar todos los caminos iBGP disponibles para un prefijo RT al construir el filtro de salida y ajusta la publicidad de pertenencia originada localmente. Es una extensión sobre la topología de reflexión de RFC 4456, no una prueba automática de que toda implementación preserve correctamente cada arco.

Tampoco es ADD-PATH para rutas VPN. El objetivo no es entregar al receptor varias alternativas de alcanzabilidad con identificadores de camino, sino conservar todas las direcciones de demanda necesarias para decidir a qué par se revela cada ruta.

Por eso “el RT aparece en la tabla BGP” es una evidencia insuficiente. Hay que responder qué PE originó el interés, qué caminos retuvo cada reflector, qué filtro quedó instalado para cada vecino y qué VPN NLRI entró finalmente en su Adj-RIB-Out.

Alta y baja son transiciones del grafo

Cuando llega un anuncio o retirada de pertenencia, RFC 4684 indica que el emisor debe reevaluar los VPN Adj-RIB-Out y producir el mínimo conjunto de anuncios y retiradas que lleve del estado anterior al nuevo. El commit de un VRF no cierra un alta, y borrar un RT de un archivo no cierra una baja.

En un alta, la secuencia verificable es: intención de importación aprobada; pertenencia originada; recepción y tratamiento por los RR; ampliación del filtro del par; aparición de rutas coincidentes en Adj-RIB-Out; recepción por el PE; importación en el VRF; resolución de etiquetas y siguiente salto; programación de FIB; y canarios de tráfico.

En una baja, debe desaparecer la pertenencia sólo cuando ningún VRF local siga necesitando el target. El filtro se contrae y se retiran únicamente las rutas que ya no coinciden con otro RT activo. Una ruta puede llevar varios targets y un VRF puede importar varios; el total de entradas puede permanecer igual mientras una ruta correcta se pierde y otra indebida aparece.

Las comparaciones deben ser por identidad y atributos, antes y después. La reversibilidad sólo existe si se conserva evidencia de que la autoridad de divulgación antigua terminó en todos los reflectores relevantes.

EoR marca sincronización, no paciencia infinita

En el arranque, el reflector puede retrasar los anuncios VPN mientras espera que llegue el conjunto inicial de pertenencias. RFC 4684 recomienda un End-of-RIB para la familia RTC incluso sin Graceful Restart. El EoR ayuda a distinguir un conjunto completo de uno todavía en vuelo.

La espera debe estar acotada. El RFC fija 60 segundos como valor por defecto para ese límite. No es un SLO universal; es la demostración de que una optimización no puede bloquear indefinidamente la distribución VPN. Hay que registrar temporizador efectivo, hora del EoR y conducta al vencer: liberación con el estado disponible, divulgación más amplia u otra política específica del producto.

Route Refresh y RTC no son la misma superficie. Los UPDATE de pertenencia modifican el interés actual. Route Refresh solicita volver a anunciar estado de exportación. RFC 7543 describe cómo Covering Prefix ORF puede provocar origen de pertenencia RTC cuando faltan rutas VPN; es una composición posterior, no un requisito del RTC ordinario. RFC 5291 define ORF como entradas tipadas transportadas con ROUTE-REFRESH, distinto de los NLRI de pertenencia.

Un filtro de escala no es una barrera de seguridad

RFC 4684 advierte expresamente que los filtros de salida derivados de pertenencia RT no están destinados a seguridad. Entre dominios administrativos deben existir filtros independientes de NLRI de entrada y salida, además de controles sobre la pertenencia que el par puede anunciar.

Aceptar una pertenencia significa aceptar una afirmación BGP de interés. No autentica al cliente, no prueba contrato, no autoriza cualquier RT, no valida la ruta VPN y no limita por sí sola el plano de datos. Si un vecino puede declarar interés arbitrario y el emisor confunde ese interés con permiso, puede ampliar la información que recibe.

La política independiente debe delimitar namespaces RT, roles de pares, traducciones en fronteras, anuncios VPN permitidos, máximos de estado, registro y reversión. RTC hace más eficiente la distribución bajo esas reglas; no las sustituye.

Una prueba que recorre ambos sentidos

El modelo Adj-RIB-In, Loc-RIB y Adj-RIB-Out de RFC 4271 evita que una captura aislada represente todo el proceso. Para RTC hay que recorrerlo dos veces y en direcciones opuestas.

Desde el PE receptor, conservar la intención aprobada de VRF y sus RT de importación. Verificar capacidad negociada, UPDATE de pertenencia, políticas y todos los caminos iBGP relevantes. En el RR, capturar la RIB RTC y el filtro por par. Después seguir la ruta VPN desde la fuente hasta el Adj-RIB-Out exacto y, en el PE, hasta la RIB VPN, importación VRF, selección, etiqueta, siguiente salto y FIB.

Cerrar con canarios positivos y negativos en ambos sentidos. Un destino esperado debe funcionar; uno fuera de la pertenencia autorizada debe permanecer oculto o inaccesible según política. Repetir la prueba durante retirada, traslado entre reflectores y actualización de software. Los contadores agregados no prueban ni exactitud ni ausencia de fuga.

Fuentes