Resumen

  • RFC 2918 permite solicitar el Adj-RIB-Out actual de un vecino capaz para un AFI/SAFI negociado; el vecino conserva su política de exportación.
  • RFC 7313 encierra la repetición entre BoRR y EoRR: marca rutas antiguas como stale, reemplaza las que vuelven y elimina las ausentes al terminar.
  • Una orden exitosa no demuestra el resultado. Hay que comparar prefijos, atributos, decisiones, FIB y tráfico antes y después.

Un operador corrige un filtro inbound que rechazaba doscientos prefijos válidos. El commit entra sin errores. Sin embargo, si el router no guardó aquellas actualizaciones sin modificar, la regla nueva no tiene objetos que reevaluar. La intención cambió; el estado puede seguir igual.

También puede ocurrir lo contrario. Una policy más estricta pretende retirar rutas ya aceptadas. Cambiar el texto no garantiza que la RIB existente haya pasado de nuevo por la cadena. El repositorio y el sistema en ejecución pueden contar historias distintas.

La soft reconfiguration inbound conservaba una copia íntegra de todos los anuncios recibidos. Así el receptor podía ejecutar una nueva política localmente, pero pagaba memoria y procesamiento continuo incluso cuando los cambios eran infrecuentes.

RFC 2918 asigna el coste de otro modo. Route Refresh Capability, código 2, dice al peer que el speaker puede recibir y procesar solicitudes. Solo se envía ROUTE-REFRESH después de recibir esa capacidad. El mensaje identifica un AFI/SAFI negociado.

El peer vuelve a anunciar su Adj-RIB-Out de esa familia conforme a su política outbound. Ahí está la frontera de autoridad. El solicitante no inspecciona una base remota ni ordena revelar rutas filtradas. Recibe lo que el vecino está dispuesto a exportar ahora.

No es una copia histórica. Una ruta de ayer puede haber desaparecido, cambiado de atributos o dejado de cumplir la política del emisor. Otra puede ser nueva. El resultado combina el presente del exportador con el presente del importador.

Por eso un cambio de conteo no atribuye causalidad. Quinientas rutas menos pueden deberse al nuevo filtro local, a retiradas remotas o a una export policy distinta. Se necesitan conjuntos exactos, timestamps y atributos.

RFC 2918 básico tampoco marcaba el principio y el final de una repetición completa. UPDATE ordinarios podían mezclarse. La ausencia temporal de una ruta no permitía saber si había sido retirada o si aún no había llegado.

RFC 7313 define Enhanced Route Refresh, código 70. BoRR, subtipo 1, abre la época; EoRR, subtipo 2, la cierra. Al recibir BoRR, el receptor marca stale las rutas del peer para ese AFI/SAFI. Cada anuncio que vuelve reemplaza su entrada. EoRR elimina lo que sigue stale.

La secuencia es viva. Los cambios ocurridos durante la repetición pueden anunciarse y no existe una fotografía congelada. EoRR acredita el cierre del ciclo, no la corrección de cada ruta ni la fidelidad a un estado pasado.

El receptor puede fijar un límite local de retención stale y limpiar sin esperar eternamente EoRR. La protección evita conservar alcance obsoleto; un límite demasiado corto puede retirar rutas sanas durante una repetición lenta.

EoRR no es el End-of-RIB de Graceful Restart. El primero delimita una reevaluación; el segundo coordina continuidad durante un reinicio del control plane. RFC 7313 los mantiene separados y ordena su interacción.

Inbound y outbound soft reset tampoco son iguales. En el primero, el router local necesita que el vecino repita o usa su copia guardada. En el segundo, regenera sus propios anuncios. La palabra “soft” oculta dos autoridades distintas.

La documentación de Cisco expone las alternativas: solicitud dinámica cuando existe capability, reevaluación de updates almacenados cuando se configuró soft reconfiguration, o hard reset si ninguna fuente está disponible. Este último derriba la sesión y afecta toda la reachability que transporta.

La elección intercambia recursos y dependencia. Guardar rutas crudas consume memoria pero mantiene independencia local. Route Refresh ahorra memoria y depende del peer, de su respuesta y de su export actual. El reset duro amplía el radio de fallo.

FRRouting advierte que ciertas funciones aún requieren almacenar rutas rechazadas, por ejemplo algunos modos de maximum-prefix. Poder pedir el flujo actual no crea automáticamente el inventario histórico necesario para otro control.

RFC 5291 permite Outbound Route Filtering negociado. Puede acompañar un refresh, pero es una capacidad separada. ROUTE-REFRESH ordinario no concede autoridad para editar el export remoto.

La evidencia comienza antes del cambio. Registre capacidades anunciadas y recibidas por sentido y familia. Soporte básico no prueba Enhanced. Una línea local no prueba que el vecino pueda responder.

Construya un baseline con prefijos y atributos exactos, rutas aceptadas, best paths, policy version, session uptime y next hops FIB. Si el sistema no muestra rutas rechazadas, documente ese punto ciego.

Ejecute primero sobre un peer y un AFI/SAFI. Registre solicitud, BoRR, EoRR y duración. Observe EoRR ausente, timeout stale, CPU, reset inesperado, withdraws y cambios de selección.

Compare conjuntos, no solo cantidades. Diez bajas y diez altas dejan el mismo número. Sustituir un aggregate por more-specifics altera el volumen. Cambiar una community puede cambiar policy sin alterar el NLRI.

Después verifique forwarding. Una ruta aceptada puede no ganar, su next hop puede no resolver o el nuevo enlace puede carecer de capacidad. Route Refresh aporta inputs; no demuestra entrega de paquetes.

Rollback también requiere repetición. Restaurar el archivo anterior no devuelve por sí solo las decisiones previas. Si el export remoto cambió durante la ventana, reconstruir exactamente el estado inicial puede ser imposible.

La automatización debe limitar concurrencia. Pedir refresh a miles de peers y familias a la vez genera UPDATE y recomputación. “Soft” evita la destrucción intencionada de la sesión, no elimina el trabajo del control plane.

La especificación mínima de Heng Lu aparece en el mensaje acotado: peer, familia, solicitud. Cada AS conserva su policy. Running-code primacy determina la aceptación: capacidades negociadas, época observada, diferencias RIB y FIB pesan más que el mensaje de éxito.

Route Refresh permite corregir una regla sin convertirla necesariamente en un corte de conectividad. Pero una repetición no es una verdad. Solo las rutas que regresaron, fueron juzgadas y cambiaron el forwarding demuestran que la policy nueva ya gobierna.

Sources