Resumen

  • RFC 8326 reduce la preferencia de una ruta antes de cerrar deliberadamente una sesión EBGP; RFC 4724 conserva estado de reenvío y rutas obsoletas durante el reinicio del plano de control.
  • El cambio debe declarar si el reenvío desaparecerá o seguirá operativo, y debe asociar esa premisa a política, telemetría, temporizadores y reversión.

Drenar no es conservar

Graceful Shutdown responde a una retirada prevista del camino de reenvío. RFC 8326 define la comunidad GRACEFUL_SHUTDOWN para evitar que la sesión desaparezca antes de que BGP encuentre y propague alternativas. La ruta antigua no se borra de inmediato: se mantiene con una LOCAL_PREF menor mientras otra ruta pasa a ser preferida.

La secuencia exige preparación en ambos lados. El vecino aplica una política de entrada que reconoce la comunidad y reduce la preferencia. En el momento del mantenimiento, el iniciador marca las rutas anunciadas, reduce también la preferencia de las recibidas por la sesión afectada, espera la readvertencia y la convergencia y, sólo entonces, cierra EBGP. RFC 8326 recomienda una preferencia local de cero.

Graceful Restart parte de la premisa contraria. RFC 4724 permite que el reenvío continúe mientras vuelve el proceso BGP. El hablante anuncia una capacidad, conserva cuando puede su estado de reenvío y los vecinos retienen temporalmente rutas marcadas como obsoletas. La reconexión, las nuevas actualizaciones y End-of-RIB reemplazan ese estado provisional.

Por tanto, Shutdown ordena dejar de preferir un camino que va a desaparecer. Restart autoriza seguir confiando de forma limitada en un camino cuyo plano de datos sigue vivo. Decir solamente «graceful» omite cuál de esas dos afirmaciones es verdadera.

La señal cruza la frontera; la decisión no

RFC 8326 usa la comunidad bien conocida 65535:0. RFC 1997 explica que las comunidades son un atributo opcional transitivo y que el receptor puede modificarlas de acuerdo con su política local. El emisor comunica intención, pero no puede imponer la selección de ruta dentro del sistema autónomo vecino.

LOCAL_PREF tampoco cruza normalmente la frontera. RFC 4271 la define como una preferencia interna y obliga a escoger el valor más alto. El vecino traduce una comunidad externa a un valor interno. Un drenaje correcto es, por ello, un resultado bilateral: el iniciador etiqueta, el receptor interpreta y la observación confirma que una alternativa quedó instalada.

La comunidad no certifica capacidad. Un camino alternativo puede existir en BGP y no soportar la carga. Tampoco demuestra que el enlace en mantenimiento vaya a perder realmente el reenvío. El plan de cambio debe aportar esas dos pruebas por separado.

Retener rutas implica una deuda temporal

En Graceful Restart, cada ruta obsoleta es una confianza que vence. Si la sesión no se restablece dentro del Restart Time, el receptor debe eliminarla. Tras la reconexión, la ausencia de la condición de reenvío correspondiente también obliga a retirarla. End-of-RIB cierra el proceso de sustitución de las rutas antiguas.

RFC 4724 advierte que pueden aparecer bucles o agujeros negros transitorios si el reenvío no se preservó de verdad o si la información cambia antes de terminar la convergencia. Por eso, «TCP volvió» no es una prueba suficiente. Hay que observar el reenvío, las familias de direcciones cubiertas, los temporizadores y el fin de la actualización.

El contrato mínimo del cambio

Antes de aprobar una ventana, el responsable debería poder contestar seis preguntas: ¿Shutdown o Restart? ¿Sobrevive el plano de datos? ¿Qué política ha confirmado el vecino? ¿Qué ruta alternativa está instalada y con qué capacidad? ¿Qué evento prueba la convergencia? ¿Quién cancela o revierte la operación si la premisa falla?

Responderlas tiene un coste: automatización, telemetría, coordinación y tiempo de drenaje. Pero ese gasto pertenece al operador que decide el cambio. Sin él, el coste pasa al usuario como pérdida de paquetes y al equipo de operaciones como una investigación sin evidencia suficiente.

Fuentes y límites

El análisis se basa en RFC 8326, RFC 4724, RFC 1997 y RFC 4271. Los textos prueban las reglas publicadas, no la adopción mundial, la capacidad de un camino concreto ni la correcta ejecución por parte de una red o un fabricante determinado.