Resumen

  • Route Refresh solicita a un vecino que reanuncie un AFI/SAFI sin reiniciar BGP; Enhanced Route Refresh puede marcar el inicio y el final.
  • BoRR y EoRR acotan el intercambio, pero no certifican la versión de configuración, el sentido de la política, la selección, el FIB ni la entrega.
  • La reconciliación necesita un recibo que una commit, refresh, prefijo de control, estado de reenvío, tráfico, excepciones y reversión.

Un final de protocolo no cierra el cambio

Supongamos que un operador modifica una política de importación para rechazar una ruta concreta de un proveedor. La plataforma de configuración confirma el commit. El router solicita Route Refresh. Llegan Beginning-of-RIB, los anuncios y End-of-RIB. El panel muestra una secuencia limpia y el ticket parece listo para cerrar.

Sin embargo, una comprobación encuentra el prefijo de control aún seleccionado en uno de los edges. No hay que atribuir el fallo a los marcadores. Estos pueden ser exactos y, al mismo tiempo, insuficientes para la afirmación que se hizo con ellos: el vecino terminó de reanunciar, pero el resultado de política no fue demostrado.

RFC 2918 define Route Refresh para reaplicar políticas sin interrumpir una sesión BGP. La capacidad se anuncia al establecer la sesión. Más tarde, el mensaje identifica AFI y SAFI, y el vecino vuelve a anunciar el estado de salida correspondiente.

El mensaje no transporta el hash de la política local, la transacción que debía activarse ni el resultado deseado para un prefijo. Es una petición de protocolo, no un comprobante de intención.

Qué demuestran BoRR y EoRR

RFC 7313 incorpora Enhanced Route Refresh. Beginning-of-RIB y End-of-RIB separan el conjunto reanunciado para que el receptor pueda identificar y tratar rutas obsoletas. La evidencia es concreta: comenzó y terminó el refresh de esa familia en ese vecino.

No prueba que la nueva configuración estuviera activa antes del primer UPDATE, ni que alcanzara todos los routers, ni que se aplicara en el sentido correcto. Tampoco prueba que la ruta elegida entrara en la tabla de reenvío o que los paquetes llegaran al destino.

El alcance de AFI/SAFI es decisivo. Un refresh de IPv4 unicast no valida IPv6, VPN u otra familia. Una sesión no representa otro peer, reflector o grupo de edges. Convertir un EoRR en un semáforo para toda la red elimina precisamente el contexto que lo hace útil.

La dirección de política cambia la prueba

RFC 4271 separa rutas recibidas, rutas seleccionadas en Loc-RIB y rutas preparadas para anunciar. Si cambia la importación, el receptor necesita anuncios nuevos para ejecutar otra vez sus reglas. Si cambia la exportación, el emisor debe probar que usó la política nueva hacia el vecino nombrado.

Son cadenas distintas. El peer reanuncia su salida mientras el router local procesa su entrada. Un mismo refresh no certifica las configuraciones de ambos lados.

RFC 5291 añade los filtros de rutas salientes. La capacidad ORF, el tipo, el modo y el estado instalado constituyen otra capa. Observar un refresh posterior no demuestra por sí solo que el filtro esperado estuviera vigente.

Un prefijo de control conecta la evidencia

La afirmación debe comprobarse donde vive. Un rechazo de importación se observa en la ruta recibida y en el resultado de política. El cambio de mejor camino se observa en Loc-RIB. El movimiento del tráfico requiere FIB, resolución de next hop y una prueba representativa.

Las vistas pueden diferir. El prefijo rechazado de un vecino puede seguir llegando por otro. Una ruta puede ser mejor en BGP y no resolver su siguiente salto. Una entrada FIB puede coexistir con un túnel o filtro que impide la entrega. Route Refresh no pretende resumir todo eso en un indicador.

Por eso conviene elegir uno o varios prefijos de control. Registrar antes, durante y después de BoRR–EoRR el peer, el AS path, los atributos relevantes, la razón de decisión y el next hop. Después, probar el servicio y la familia afectados.

Esta interpretación no debilita Route Refresh. Le asigna una función verificable: demostrar que se reprodujo un conjunto acotado de rutas. Al aparecer una discrepancia, el equipo puede separar versión errónea, despliegue parcial, familia equivocada, capacidad ausente, ORF distinto o fallo de reenvío posterior a una decisión correcta.