Resumen

  • RFC 4456 permite que un route reflector redistribuya rutas iBGP bajo reglas de cliente y no cliente. ORIGINATOR_ID y CLUSTER_LIST aportan la memoria necesaria para que esa excepción no forme ciclos.
  • Encontrar la identidad local autoriza a ignorar el anuncio. La igualdad es correcta entre reflectores redundantes de un mismo clúster; fuera de ese ámbito puede clasificar como retorno una ruta legítima.
  • La verificación une UPDATE y motivo exacto con mapa de roles, candidatos, salida por vecino, FIB y tráfico. El estado de la sesión no demuestra que el prefijo atravesó el reflector.

Dos dominios, una etiqueta

Supongamos una red con un dominio oriental y otro occidental. En cada uno hay dos reflectores redundantes. La pareja oriental comparte deliberadamente 10.0.0.42: representar el mismo clúster les permite descartar una ruta ya reflejada por el compañero.

Una plantilla de consolidación instala ese valor también en la pareja occidental. La jerarquía sigue separando ambos dominios, pero las etiquetas dicen lo contrario. Una ruta del este llega al oeste con 10.0.0.42 en la lista. El receptor encuentra su identidad local y la ignora.

No hace falta un fallo TCP ni un mensaje NOTIFICATION. Los KEEPALIVE continúan. El anuncio es sintácticamente correcto y el origen no desapareció. Un indicador concebido para recordar por dónde pasó la ruta ha recibido autoridad para decidir que no debe existir allí.

La excepción al mallado interno

La regla iBGP clásica impide anunciar a un peer interno lo aprendido de otro peer interno. La protección evita que la información circule sin el AS_PATH que frena los bucles externos, pero exige una malla completa. Route reflection reduce ese coste al permitir una redistribución controlada.

Si el mejor camino viene de un no cliente, el RR lo refleja a sus clientes. Si viene de un cliente, puede enviarlo tanto a clientes como a no clientes. La relación se configura; no existe una negociación que confirme que ambos extremos comparten el mismo dibujo lógico. Una sesión correcta puede estar sosteniendo dos interpretaciones incompatibles.

ORIGINATOR_ID es un atributo opcional no transitivo de cuatro octetos, tipo 9. Al reflejar, conserva el BGP Identifier del hablante que introdujo la ruta en el AS. Un router que ve su propio identificador debe ignorarla.

CLUSTER_LIST, tipo 10, lleva una secuencia ordenada de identificadores de clúster. Cada RR antepone el suyo. Si el receptor encuentra su valor en cualquier posición, trata el anuncio como información que regresó al dominio.

No son credenciales. RFC 6286 exige que el BGP Identifier sea no nulo y único dentro del AS, pero no que sea una dirección IPv4 asignada. Del mismo modo, un cluster ID escrito como decimal punteado no prueba un equipo, una interfaz ni una ubicación.

Compartir puede ser la regla correcta

La redundancia dentro de un clúster explica por qué una política de “todos distintos” sería errónea. Dos RRs que representan el mismo conjunto de clientes pueden compartir una identidad para reconocer actualizaciones procesadas por el otro. La igualdad expresa pertenencia real.

El peligro empieza cuando una herramienta extiende esa pertenencia. Un valor copiado a otra región, un router ID reciclado, una excepción por vecino o una migración jerárquica incompleta pueden agrupar lo que la topología mantiene separado. BGP no conoce la intención y no pregunta al operador; compara bits.

Con ORIGINATOR_ID, dos BGP Identifiers duplicados dentro del AS producen una falsedad equivalente. El segundo router puede considerar propia la ruta creada por el primero. No se ha demostrado ningún bucle de paquetes. Se ha demostrado únicamente una colisión en la capa simbólica, pero esa capa gobierna la aceptación.

La disciplina correcta asigna dos alcances. El BGP Identifier es único en el AS. El cluster ID corresponde a una clase explícita de reflectores redundantes y no debe repetirse en un camino válido entre clases distintas.

Una ruta ignorada no es un UPDATE corrupto

RFC 7606 describe qué hacer con atributos malformados. Una lista bien codificada que coincide con la identidad local no está malformada: activa una decisión semántica. Mezclar ambas causas en una métrica destruye la prueba que necesita la recuperación.

Incluso sin coincidencia, los atributos afectan el desempate. ORIGINATOR_ID ocupa el lugar del identificador del anunciante en el paso correspondiente. Después se prefiere la ruta con CLUSTER_LIST más corta; una ruta sin lista cuenta como cero. Ese número representa historia de reflexión, no kilómetros, latencia ni calidad.

Por ello una renumeración puede cambiar el mejor camino aunque ningún prefijo llegue a cero candidatos. El control debe comparar la población completa, la razón del best path y el Adj-RIB-Out de cada vecino.

ORR cambia el punto de vista IGP desde el que se elige para un cliente. ADD-PATH permite exponer más alternativas. Ninguno anula la comprobación de retorno. Las oscilaciones de RFC 3345 y RFC 7964 son cambios persistentes de selección; una falsa colisión puede producir una ausencia estable. Autenticar el transporte protege los bytes, no el significado del inventario.

Evidencia por cada frontera

El registro técnico incluye AS, VRF, AFI/SAFI, peer, rol, BGP Identifier, ID de clúster global y por vecino, grupo de redundancia, nivel, versión y dueño del cambio. Cada igualdad deliberada necesita una explicación operativa.

Para el NLRI se guardan el UPDATE crudo, ORIGINATOR_ID, la lista ordenada y los valores locales evaluados. El resultado debe distinguir error de sintaxis, coincidencia de origen, coincidencia de clúster, política de importación y derrota en selección. Después siguen Loc-RIB, salida por vecino, recepción aguas abajo, FIB y paquetes.

La configuración solo declara intención. El mensaje es el estado recibido. El comparador ejerce el poder. El RIB conserva una decisión. El FIB la transforma en reenvío. La observación de tráfico descubre si el servicio existe. Esa separación evita convertir una captura parcial en verdad total.

Migrar el grafo, no solo el número

Antes del cambio, dibujar el grafo dirigido de clientes y no clientes y declarar qué RRs son realmente equivalentes. Simular cada ruta válida. Una trayectoria destinada a otro dominio no puede encontrar prematuramente su propia identidad.

Los canarios nacen en cada clase de cliente y atraviesan parejas, niveles, familias, fabricantes y versiones. Se comprueba la secuencia exacta: cada reflector debe anteponer el valor previsto sin perder los anteriores. Se pausa ante una igualdad no explicada, una ruta ausente con sesión sana o divergencia entre releases.

El rollback exige repropagar. Restaurar el archivo de configuración sin confirmar RIBs aguas abajo, best path y paquetes deja la decisión falsa en circulación.

Fuentes