Resumen

  • BGP Graceful Restart permite que un vecino compatible retenga rutas durante el reinicio de una sesión, pero ese estado de control no demuestra por sí solo que el router siga reenviando el tráfico afectado.
  • La protección operativa es un recibo por familia que vincula capacidades, temporizadores, continuidad de paquetes observada, End-of-RIB y disposición final de las rutas obsoletas.

Pensemos en un mantenimiento hipotético. Un router reinicia BGP, el vecino conserva los prefijos aprendidos y el panel muestra una recuperación ordenada en vez de una retirada inmediata. Sin embargo, el tráfico de una familia se detiene. El vecino sigue eligiendo la ruta obsoleta hasta que un temporizador u otro evento la elimina. El mecanismo destinado a ocultar una interrupción breve ha convertido su retención en la duración del fallo.

Esto no indica que Graceful Restart sea defectuoso. Indica que se trataron como una sola cosa la recuperación del control y la conservación del reenvío. El protocolo coordina la primera; el uso seguro exige que la segunda siga siendo cierta mientras el vecino actúa sobre información obsoleta.

Lo que anuncia la capacidad

RFC 4724 define la capacidad Graceful Restart. Restart State informa de que el hablante reinició. Para cada AFI/SAFI, Forwarding State informa de si conservó el estado de reenvío. La promesa no es global para todo el equipo.

Si no se conservó el estado de una familia, RFC 4724 exige eliminar sus rutas obsoletas. Si se indicó conservación, el ayudante puede retenerlas mientras vuelve la sesión y se refrescan las rutas. Esa diferencia es el límite de seguridad.

Restart Time estima cuánto tardará en restablecerse la sesión. El ayudante aplica además un límite local de retención. Ningún valor mide continuidad de paquetes; ambos acotan cuánto tiempo el plano de control acepta la afirmación de conservación.

End-of-RIB cierra otra pregunta

Al regresar la sesión, End-of-RIB señala que terminó la actualización inicial de una familia. Las rutas refrescadas quedan vigentes y las no refrescadas pueden retirarse. Esto cierra la reconciliación de rutas, no reconstruye la entrega durante el intervalo anterior.

Restablecimiento de sesión, End-of-RIB y tráfico correcto son tres observaciones. Reducirlas a una bandera de éxito impide saber si el mecanismo protegió el servicio o solo mantuvo una ruta instalada.

Una retención mayor exige más prueba

RFC 9494 incorpora Long-Lived Graceful Restart. Define una retención más larga y la marca LLGR_STALE, y recomienda reducir la preferencia de esas rutas para que pueda ganar una alternativa. Puede ayudar si el reenvío sobrevive; también prolonga una suposición errónea si dejó de sobrevivir.

La cuestión no es que un temporizador largo sea siempre incorrecto. Debe estar respaldado por el comportamiento real de plataforma, topología y alternativa. La evidencia de una familia o tarjeta no valida otra.

Una NOTIFICATION no prueba el reenvío

RFC 8538 permite aplicar Graceful Restart tras determinados mensajes BGP NOTIFICATION. La señal puede explicar por qué terminó la sesión y qué procedimiento seguirá el vecino, pero no demuestra que los paquetes atravesaran el equipo durante el evento. La ausencia de retirada puede ser exactamente el comportamiento solicitado al ayudante, no un resultado de entrega.

Crear un recibo por familia

Registre vecinos, AFI/SAFI, capacidad, bits Restart State y Forwarding State, Restart Time, límite local, política LLGR y ruta alternativa. Añada horas de pérdida y regreso de sesión, primer paquete correcto, End-of-RIB y retirada o refresco definitivo.

La prueba debe representar al servicio. Un ping a loopback puede tener éxito mientras fallan prefijos de clientes o una tabla distinta. El éxito en IPv4 no valida IPv6; una tarjeta, FIB, VRF o cohorte de servicio no valida otra. El recibo debe coincidir con la familia, plataforma, tabla y tráfico cuyo estado retiene el ayudante.

Fuentes