Resumen

  • El HoldTimer clásico mide cuándo llegó el último mensaje BGP válido; puede mantenerse fresco aunque todos los UPDATE, retiros y KEEPALIVE locales estén bloqueados en sentido contrario.
  • RFC 9687 incorpora un SendHoldTimer de política local. Al expirar, el hablante registra la causa, libera recursos, cierra TCP y vuelve a Idle.
  • El despliegue responsable separa generación, transmisión, procesamiento remoto y reenvío, elige un valor mayor que el HoldTime negociado y evita que la reparación produzca tormentas de reconexión.

El borde ya ha decidido retirar una ruta caída. Su RIB contiene la alternativa y el proceso ha creado el retiro. Sin embargo, el par continúa enviando KEEPALIVE; cada uno reinicia el HoldTimer. En la otra dirección, la aplicación remota no consume el flujo TCP, la cola local aumenta y el último anuncio que sí cruzó la sesión conserva autoridad en el vecino.

No falta una decisión de encaminamiento. Falta la capacidad de convertirla en una verdad compartida.

La bidireccionalidad no implica progreso simétrico

TCP ofrece dos sentidos dentro de una conexión, pero uno puede avanzar mientras el otro queda detenido. RFC 9687 describe el caso de una ventana de recepción remota igual a cero. El vecino todavía puede escribir hacia el sistema local aunque ya no acepte bytes desde él. Un lector bloqueado, sobrecarga o una cola defectuosa producen la misma asimetría operativa.

RFC 4271 reinicia el HoldTimer cuando llegan UPDATE o KEEPALIVE admisibles. Esa es prueba de recepción, no de entrega inversa. Crear un UPDATE no demuestra que salió; aceptar bytes en el búfer del núcleo no demuestra lectura remota; TCP Established no demuestra que el proceso BGP esté atendiendo; construir una NOTIFICATION no asegura su recepción.

La diferencia pesa porque los mensajes no son simples latidos. Un retiro retenido permite que una ruta obsoleta siga atrayendo tráfico. La edad de la última transmisión BGP exitosa es, por tanto, una señal de autoridad más precisa que la mera llegada de mensajes.

Un reloj local para el emisor bloqueado

RFC 9687 agrega SendHoldTime, SendHoldTimer y el evento 29 SendHoldTimer_Expires a la máquina de estados. SendHoldTime se configura localmente por par; no es una capacidad negociada. El mecanismo no depende de que el vecino lo implemente.

Al entrar en Established desde OpenConfirm, el temporizador comienza si la configuración no es cero. Cada mensaje BGP enviado con éxito lo reinicia. Se detiene al abandonar Established o si SendHoldTime o el HoldTime negociado valen cero. Todo SendHoldTime no nulo debe ser mayor que el HoldTime negociado.

La recomendación de RFC 9687 es habilitarlo por defecto con el mayor valor entre ocho minutos y dos veces el HoldTime. Esa referencia no convierte a todos los pares en una sola clase. Un servidor de rutas, un reflector, un cliente limitado y un tránsito soportan cargas y costes de reinicio diferentes.

Cuando expira, el sistema debe registrar Send Hold Timer Expired, liberar recursos BGP, cerrar TCP, actualizar el reintento y pasar a Idle. Puede intentar una NOTIFICATION solo si no retrasa el cierre. IANA asigna el código 8, subcódigo 0. Como el propio bloqueo puede impedir que llegue, la evidencia local no puede depender del registro remoto.

HoldTimer, SendHoldTimer, BFD y TCP no compiten

Cada señal responde a una pregunta. HoldTimer observa recepción BGP; SendHoldTimer, progreso de envío BGP; BFD, continuidad rápida de una ruta de reenvío; TCP, mecánica de transporte. Sus resultados pueden divergir legítimamente.

BFD puede estar sano porque el enlace reenvía. TCP puede seguir Established. El HoldTimer puede renovarse con KEEPALIVE entrantes. Aun así, SendHoldTimer puede expirar porque no salió ningún mensaje BGP local. Esa combinación es el diagnóstico, no una inconsistencia que deba ocultarse.

La cronología debe conservar cuatro afirmaciones: recepción local, envío local, procesamiento remoto de rutas y reenvío de paquetes. El nuevo temporizador no detecta todos los zombis BGP ni prueba una avería de datos. Acota una incapacidad persistente de transmitir y autoriza a descartar el estado de la sesión.

El cierre también tiene radio de daño

Un reinicio invalida rutas aprendidas, provoca selecciones nuevas, cambios de FIB y anuncios alternativos. La reconexión puede iniciar una tabla completa. Varias expiraciones en un reflector o servidor de rutas generan una ola de convergencia.

Un valor demasiado corto convierte una pausa transitoria, presión de cola o ventana cero breve en un corte innecesario. Si el receptor sigue saturado, las reconexiones y transferencias completas aumentan la carga y forman un ciclo. Un valor demasiado largo deja retiros y reemplazos atrapados mientras la visión obsoleta sigue gobernando.

La selección debe considerar HoldTime, pausas medidas, ráfagas de UPDATE, planificación de CPU, volumen de rutas y coste del reintento. Las clases de pares requieren márgenes propios. La amortiguación de oscilación puede frenar reintentos, pero no arregla un lector bloqueado ni una plataforma sin capacidad.

El canario correcto no corta la conectividad

Desconectar la interfaz prueba otra cosa y probablemente activa BFD o HoldTimer primero. La prueba válida mantiene el camino y los mensajes BGP entrantes, pero detiene de forma controlada el consumo remoto.

BIRD 3.3.0 documenta disable rx como función exclusiva de prueba y advierte contra su uso en producción. En un laboratorio aislado permite fabricar la asimetría. Antes de inducirla se registran versión, HoldTime, SendHoldTime, estado y colas normales. Durante el fallo se demuestran KEEPALIVE entrantes, ausencia de progreso de envío, cola o ventana cero y un retiro controlado bloqueado.

En la expiración se capturan causa, tiempo, intento de NOTIFICATION, cierre TCP y transición a Idle. Tras eliminar el fallo se prueban la reconexión sin bucle, la corrección de ruta, el FIB y los paquetes. La lista de soporte de FRRouting y el mando de BIRD son afirmaciones del producto; el binario desplegado necesita su propia prueba.

La autoridad exige custodia de evidencia

Quien pueda cerrar una interconexión crítica debe conservar último mensaje generado, último envío exitoso, edad y profundidad de cola, ventana TCP, retransmisiones, llegadas, reinicios del temporizador y razón final. También debe saber qué retiros no salieron, cuánto duró la vista remota y cómo convergieron las alternativas.

Los datos suelen repartirse entre demonio de rutas, sistema operativo, colectores, portal del par y NOC. Soberanía práctica significa poder unirlos y actuar. Autoridad sin evidencia es arbitraria; evidencia sin derecho de decisión no corrige la ruta.