Resumen

  • Una tarea de limpieza envió pending_delete sin valor. La API Addressing interpretó la solicitud como referida a todos los prefijos BYOIP, y el proceso eliminó tanto prefijos como enlaces de servicio dependientes.
  • Se retiraron alrededor de 1.100 prefijos. Cerca de 800 pudieron anunciarse de nuevo; unos 300 habían perdido también su configuración de servicio en el borde y necesitaron una restauración global posterior. La ruta era solo una capa de la recuperación.

La segunda espera

El post mortem de Cloudflare sobre el 20 de febrero de 2026 puede resumirse como una incidencia BGP. Lo revelador ocurre después: en algunos prefijos de clientes volvió el anuncio, pero los sistemas de borde ya no tenían el enlace que indicaba qué producto debía procesar el tráfico. Volvió la ruta antes que el servicio.

Una dirección pública no es una aplicación. Un prefijo puede estar registrado a nombre del cliente, autorizado para que un proveedor lo anuncie, cargado en la base de direcciones de ese proveedor, anunciado mediante BGP, vinculado a un producto y configurado en cada máquina de borde. Son estados relacionados, no equivalentes. Una ruta visible no prueba que el paquete llegue al servicio correcto.

Cloudflare explica que una tarea periódica debía automatizar la retirada de prefijos que los clientes solicitaban eliminar de BYOIP. El proceso consultó la API con pending_delete sin valor. Según la implementación publicada, solo se buscaban elementos pendientes de eliminación si el valor de ese parámetro no estaba vacío. Con una cadena vacía, la API devolvía todos los prefijos BYOIP. La tarea trató cada resultado como candidato a eliminación y suprimió objetos dependientes, incluidos enlaces de servicio.

No fue un ataque, según la empresa. La versión de Addressing API se desplegó a las 17:46 UTC y la tarea comenzó a ejecutarse diez minutos más tarde. El equipo identificó y detuvo el proceso a las 18:46. En ese intervalo se retiraron unos 1.100 prefijos: Cloudflare calcula que eran el 25% de sus 4.306 prefijos BYOIP anunciados mundialmente. El informe también menciona una vista de 6.500 prefijos hacia un par; ese total corresponde a otro denominador y no debe confundirse con el inventario global BYOIP.

El despliegue iterativo impidió que el nuevo comportamiento alcanzara a todos los clientes antes de detenerse. Es una forma de acotar el impacto, no un plan completo de recuperación.

Anunciar no significa atender

La documentación de Cloudflare separa la publicidad BGP —que atrae el tráfico hacia su red— del enlace de servicio, que asigna ese tráfico a CDN, Spectrum o Magic Transit. Para algunos usos del CDN existe además el mapa de direcciones. Si una automatización elimina la ruta y sus enlaces, volver a anunciar el prefijo puede hacer que el tráfico llegue a la red del proveedor sin reconstruir el recorrido del producto en el borde.

Por eso la recomendación del panel solo servía para una parte de los casos. A las 19:19 UTC, Cloudflare pidió a los clientes que volvieran a anunciar sus prefijos. Hacia las 20:20 se habían recuperado unos 800. Cerca de 300 no podían arreglarse con un simple cambio en el panel porque su configuración de servicio también había desaparecido de los sistemas de borde. El cliente no podía recrear un enlace ausente de la configuración disponible para su cuenta. Los ingenieros tuvieron que recuperar ese estado y distribuir una configuración global, tarea que terminó a las 23:03 UTC.

La empresa comunicó una duración total de seis horas y siete minutos.

El informe público no detalla cuántos clientes, países, ingresos perdidos o créditos de SLA estuvieron implicados. Sí muestra diferentes trayectorias: retirada de ruta, eliminación parcial de enlaces o desaparición completa de la asociación con el servicio. Una sola «caída BYOIP» escondía distintos responsables y plazos de recuperación.

El sitio one.one.one.one mostró errores HTTP 403. Cloudflare aclara que el servicio de resolución DNS pública de 1.1.1.1, incluido DNS sobre HTTPS, siguió funcionando. El error visible del sitio probaba el impacto en una superficie alojada con BYOIP; no que el resolvedor hubiese dejado de contestar.

La configuración también es infraestructura

Cloudflare describe Addressing API como un conjunto de datos autoritativo cuyos cambios se reflejaban en la red mundial. Las solicitudes de clientes activaban bases de datos y flujos que cambiaban anuncios y enlaces de producto. La misma información persistida representaba la configuración deseada y activaba acciones operativas. La empresa dijo que esto dificultó revertir los cambios: los ingenieros dependían de instantáneas de la base de datos en lugar de comparar el estado previsto con el que realmente funcionaba.

La carencia de pruebas fue concreta. Los datos de staging y los simulacros no bastaron. Se comprobó el recorrido de autoservicio que seguiría el cliente, pero no que un servicio de tareas independiente modificara sus datos sin una solicitud explícita. El flujo que inicia una persona puede ser seguro mientras una tarea programada que reutiliza la misma API no lo sea. Probar solo la interfaz deja fuera al principal de automatización.

Las medidas anunciadas por Cloudflare iban más allá de corregir el parámetro: normalizar esquemas API; separar configuración declarada y estado operativo; aplicar instantáneas mediante despliegues graduales gobernados por métricas de salud; detener o revertir automáticamente una propagación dañina; y activar cortacircuitos ante retiradas demasiado rápidas o amplias. También planteó vigilar la salud de los servicios de clientes. El post mortem anunció esos trabajos, pero no demuestra que se hayan completado después.

La propuesta de BYOIP permite mantener una identidad de direccionamiento propia usando la red de un proveedor. El acuerdo operativo es menos sencillo: el cliente puede poseer el bloque y autorizar su anuncio, mientras el proveedor controla el sistema que retira la ruta, asigna el producto y distribuye configuración a los nodos de borde. Un activo portable puede depender de un estado que su dueño no logra restaurar por sí solo.

Eso no desacredita el enrutamiento gestionado. Obliga a definir continuidad en el límite del servicio. Cloudflare explica que una respuesta API satisfactoria confirma que se registró la solicitud; la propagación de la ruta lleva más tiempo. También recomienda tener listos los enlaces de servicio antes de anunciar un prefijo productivo. El acuse de recibo y el servicio operativo son pruebas distintas.

Qué debería demostrar una promesa de continuidad

El cliente necesita saber qué estado falló y quién tiene autoridad para repararlo, no solo si el proveedor puede anunciar un prefijo. El calendario de recuperación debería separar cuatro hitos: detener la tarea dañina; volver a observar la ruta desde fuera; restaurar los enlaces y la configuración en el borde; y comprobar que el tráfico de la aplicación funciona. Cada hito tiene responsable y reloj propios.

El caso ofrece una prueba de aceptación concreta: simular que la ruta volvió pero falta el enlace de servicio. ¿Puede el proveedor detectarlo? ¿Puede restaurar la configuración de una cuenta sin revertir riesgosamente la base global? ¿La salud del producto, y no solo el número de rutas, detiene una expansión? ¿Qué puede cambiar el cliente durante una congelación de escrituras y cuánto dura?

Una ruta de respaldo puede formar parte del plan del cliente, pero no sustituye siempre la reparación del proveedor. Cloudflare advierte que los anuncios solapados y la preferencia de rutas deben gestionarse con cuidado. La alternativa solo sirve si se prueban conjuntamente autorización de origen, encaminamiento y servicio. Atraer paquetes a una red sin el estado de la aplicación solo desplaza la avería.

La conclusión se puede medir: una dirección identifica un recurso; una ruta anuncia alcanzabilidad; un enlace elige dónde se procesa el tráfico; y un servicio activo es el resultado. El informe de continuidad no debe reducir esas capas a una sola luz verde. Que volviera el prefijo fue un avance; no el fin de la recuperación.

Fuentes