Resumen

  • La actualización de un par de cortafuegos dejó a Router B con cero prefijos BGP durante 121 segundos, aunque las sesiones figuraban como Established y el tráfico seguía dirigiéndose al cortafuegos.
  • Las capturas y la reproducción de laboratorio del ponente apuntaron a un error al interpretar el contexto del vecino IPv6 y a un TCP Reset; la espera del End-of-RIB de IPv6 también frenó la instalación de rutas IPv4.

«Established» sonaba tranquilizador. La tabla de rutas respondió con menos tacto: cero prefijos durante 121 segundos.

Ese fue el incidente que Marian Rychtecký presentó en NANOG 98. Durante la actualización de alta disponibilidad de una pareja de cortafuegos, las sesiones BGP volvieron a Established, pero Router B no recibía prefijos. El tráfico seguía encaminándose hacia el cortafuegos. Como este aún no había instalado las rutas esperadas, los paquetes quedaron en un agujero negro durante casi dos minutos.

La cifra decisiva fue 121 segundos. End-of-RIB llegó cerca del temporizador de reconexión de 120 segundos, aunque ese temporizador era una pista, no la causa completa. La investigación de Rychtecký encontró que la recuperación de IPv4 esperaba una sesión BGP IPv6 concreta. Graceful Restart consideraba incompleto el estado negociado del vecino hasta recibir el marcador End-of-RIB. Una sesión atascada en una familia de direcciones retenía las rutas de la otra.

Las capturas de paquetes mostraron un TCP Reset en la sesión nueva. En una reproducción de laboratorio, la dirección IPv6 esperada del vecino, 2001:db8:1::2, aparecía almacenada como 2001:db8:1:. El sistema operativo no podía asignar la conexión al contexto VRF y BGP correcto, así que devolvía un reset. Durante parte de la conmutación, la conexión TCP anterior todavía parecía activa; la nueva chocaba con ese estado viejo.

La conclusión va más allá de que «Graceful Restart puede fallar». El estado BGP en verde no significaba que hubiera rutas en la tabla ni que el reenvío estuviera recuperado. La actualización del cortafuegos disparó el fallo. La lectura incorrecta del contexto del vecino y la espera entre familias explican el mecanismo. La RIB vacía y los paquetes descartados fueron el impacto.

El ponente cuenta que, en este caso, un temporizador de conexión más corto aceleró la reconexión y el intercambio End-of-RIB. Es una solución temporal registrada para esa configuración, no un valor universal: acortar una espera puede crear otra ventana de fallo. La prueba duradera debe seguir toda la cadena: reconexión TCP, End-of-RIB por familia, instalación de rutas y entrega de paquetes.

Las diapositivas omiten modelos de equipo, versiones de firmware y mediciones de pérdida del tráfico de clientes; esos datos dirían si fue un defecto aislado o un patrón entre despliegues.

Fuentes