Algunas rutas L2VPN desaparecen tras añadir reflectores de ruta

Las sesiones siguen activas, el IGP es estable y, aun así, un puñado de rutas L2VPN nunca aparecen en dos de las cuatro aristas del proveedor. Ese patrón pertenece a un problema de reflexión y no a uno de transporte, porque una sesión rota falla por completo mientras que una frontera de reflexión reutilizada falla de forma selectiva. El anillo físico no tiene nada que ver; el grafo lógico de distribución es donde se detuvieron esas rutas. Encontrar ese punto no exige reconstruir el plano de control.

La pérdida es selectiva, lo que estrecha la búsqueda

Cuatro aristas de proveedor en un anillo físico necesitan seis sesiones lógicas para una malla completa, ya que cada router se empareja con los otros tres. Esas sesiones viajan sobre el transporte enrutado, así que el cableado no dice nada sobre cuántas adyacencias existen ni cuál de ellas refleja. Cuando dos aristas pierden un conjunto concreto de prefijos mientras todo lo demás converge, el cable no es el sospechoso.

La pérdida selectiva apunta a la prevención de bucles, a la política o a la dirección de la relación, donde algunas rutas cruzan una frontera y otras se descartan por el camino. La pérdida total apunta a la sesión o a la familia de direcciones. Decidir cuál de las dos está mirando es el primer paso útil, y cuesta un solo comando.

Qué cambia realmente la reflexión

La reflexión de rutas relaja la regla de que un hablante iBGP no puede reanunciar una ruta aprendida de otro hablante iBGP. RFC 4456 expresa la excepción mediante la relación entre el hablante y el origen de la ruta, y la dirección de esa relación importa más de lo que sugieren la mayoría de los resúmenes. Una ruta aprendida de un cliente puede reflejarse a otros clientes y a no clientes, mientras que una ruta aprendida de un no cliente solo puede reflejarse a clientes. Lea la asimetría dos veces, porque explica cómo añadir una relación de cliente puede ocultar un error de diseño: abre un camino que la topología nunca pretendió.

El atributo CLUSTER_LIST registra el historial de reflexión, y un reflector que encuentra su propio identificador de clúster en esa lista debe ignorar el anuncio. Eso es la prevención de bucles, y también es el mecanismo que borra rutas cuando los identificadores se reutilizan por accidente. ORIGINATOR_ID desempeña un papel relacionado al nombrar el router que anunció la ruta por primera vez.

Los identificadores de clúster reutilizados son la forma en que desaparecen las rutas

Una red pequeña invita a un atajo: dé a cada router un identificador de clúster igual a su loopback, añada después otro reflector y reutilice un loopback existente porque lo tiene a mano. Si ese identificador aparece ahora en dos etapas de reflexión independientes, la segunda etapa ve su propio ID en CLUSTER_LIST y descarta la ruta. Nada registra un error, porque descartar es la respuesta correcta a un bucle.

Los reflectores redundantes que sirven a un solo clúster son la excepción legítima: comparten un ID a propósito para que cualquiera de los dos pueda servir a los mismos clientes. El identificador debe coincidir con el diseño de reflexión y no distinguir nombres de chasis.

Dibuje el grafo previsto antes de tocar cualquier configuración: quién origina el prefijo, qué relación de cliente permite la primera reflexión, qué reflector lo lleva a la siguiente etapa y dónde se sitúa el último cliente. Cada salto de ese grafo es un lugar donde un identificador reutilizado, una relación de cliente ausente o un filtro de política pueden detener la ruta. Con el grafo dibujado, una ruta ausente tiene una ubicación en lugar de un misterio.

Resista la tentación de hacer cliente a cada vecino

La reparación rápida de una ruta ausente es hacer que cada vecino sea cliente de cada reflector. La propagación vuelve y el diseño deja de decirle nada: multiplica las rutas que carga cada hablante mientras oculta qué relación debía hacer el trabajo.

Una red pequeña suele necesitar una de dos formas. Una malla iBGP completa son seis sesiones para cuatro routers sin reflexión alguna, y un par designado de reflectores que sirve a las aristas restantes es la otra. Ambas son más fáciles de razonar que una malla parcial en la que cada router refleja un poco. Elija la forma por escala y comportamiento ante fallos, no por el diagrama de cableado.

Compruebe la familia de direcciones antes de culpar a la reflexión

Una sesión TCP en el puerto 179 demuestra que los dos hablantes pueden hablar, y nada sobre si la familia de direcciones VPN ha intercambiado una sola ruta. Establezca el estado de la sesión, después la familia y después el prefijo individual.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Esas tres salidas separan un problema de adyacencia de un problema de intercambio y de un problema de prefijo ausente. Si la familia no muestra ningún prefijo, inspeccione el estado de activación y la política de exportación del vecino antes de mirar la reflexión. Si los prefijos aparecen en una arista pero no en otra, compare la lista de clústeres y el originador en el lado receptor y luego recorra el grafo de la sección anterior.

Mantenga la accesibilidad del siguiente salto y el estado de reenvío fuera de esa comprobación. Una ruta reflejada con un siguiente salto inaccesible está presente y es inservible, lo que parece un fallo de reflexión hasta que mira la columna del siguiente salto. Resuelva el siguiente salto, confirme la entrada de reenvío y solo entonces decida si el grafo de distribución necesita otro reflector.