Cloudflare atribuye a retiros de rutas la latencia en Ashburn y Columbus
Un incidente menor del 18 de octubre afectó durante 50 minutos a clientes de Cloudflare en IAD y CMH. La compañía vinculó la latencia y los timeouts a retiradas inesperadas de prefijos en enlaces de peering de un proveedor externo; lo dio por resuelto tras restaurar los anuncios.
El incidente de Cloudflare del 18 de octubre fue pequeño en alcance, pero útil para entender qué pasa cuando falla el anuncio de una ruta de red. La compañía clasificó como menor la degradación en sus instalaciones IAD y CMH, Ashburn (Virginia) y Columbus (Ohio): entre las 08:00 y las 08:50 UTC (10:00–10:50 CEST) hubo latencia elevada y timeouts para algunos clientes. El servicio quedó normalizado después de que se restauraran los anuncios de prefijos.
Cloudflare atribuyó el episodio a retiradas inesperadas de prefijos en enlaces de peering de un proveedor externo. Dicho de otra forma, una red vecina dejó de anunciar rutas que permitían alcanzar parte del tráfico por esos enlaces. La página de estado no nombra al proveedor ni detalla los prefijos afectados, así que no sabemos si el efecto se concentró en ciertos operadores, servicios o destinos. La clasificación “minor” y los dos puntos afectados no justifican llamarlo una caída global de Cloudflare.
El reporte de la compañía marca el periodo de impacto entre 08:00 y 08:50 UTC; su actualización de estado se publicó más tarde, a las 09:37 UTC. Pingoru registra la misma ventana de 50 minutos y el mismo texto de causa, al consultar el estado público de Cloudflare. El momento de cerrar el incidente y el momento de publicar la resolución son datos distintos, una diferencia que importa al reconstruir una alerta o compararla con métricas internas.
-InfraCrew dice:los dashboards pueden tardar en cerrar una alerta aunque el tráfico ya haya recuperado la ruta.-
Qué significa una retirada de prefijos
Los prefijos IP agrupan direcciones que una red anuncia a sus vecinas. Cuando un proveedor retira un anuncio de peering, la ruta deja de estar disponible por ese camino y los routers deben elegir entre alternativas que conozcan, si las tienen. Ese cambio puede desviar tráfico, aumentar latencia o dejar destinos temporalmente inaccesibles, según la topología y cuánto tarde en converger el enrutamiento. El comunicado de Cloudflare confirma los retiros y el efecto observado, pero no publica una medición de pérdida ni una explicación de convergencia.
Las ubicaciones IAD y CMH funcionan como referencias a instalaciones concretas, no como sinónimo de que todos los usuarios de Virginia y Ohio quedaran desconectados. Cloudflare habla de clientes que experimentaron mayor latencia y timeouts; no ofrece un porcentaje de tráfico ni una lista de productos afectados. La evidencia disponible describe una incidencia regional, parcial y resuelta, no una indisponibilidad general de la plataforma ni una vulnerabilidad de seguridad.
-InfraCrew dice:que un nodo salga en el aviso no convierte a toda su región en una zona caída.-
Qué puede revisar un equipo cliente
Para una organización que depende de una CDN, DNS o proxy distribuido, un evento así se ve mejor desde fuera y desde dentro. Conviene comparar probes de varios operadores, latencia por región, timeouts de origen y salud de servicios que no pasan por la misma ruta. Esa comparación ayuda a separar una degradación de interconexión de un fallo en la aplicación propia, aunque la página pública por sí sola no permite saber si una instalación concreta estuvo afectada.
Las alertas deberían comprobar el failover real y la capacidad del origen cuando la arquitectura ya dispone de regiones o proveedores alternativos. No se puede concluir que el failover de cada cliente se activara ni que hubiera una ruta alternativa válida; eso depende de DNS, políticas, sesiones y diseño contratados. El incidente tampoco deja una acción de parcheo o configuración concreta que Cloudflare exija a sus clientes.
La lectura más útil es proporcional: una retirada externa de prefijos provocó un impacto limitado en dos instalaciones durante menos de una hora, y el servicio se normalizó al restaurar los anuncios. Para el cliente, la tarea posterior es contrastar sus propias métricas y dependencias, no asumir que todo tráfico pasó por IAD o CMH ni que Cloudflare perdió su red completa. En redes distribuidas, el aviso público describe un límite observado; la telemetría de cada servicio decide si ese límite cruzó hasta la aplicación.
Diccionario de la Crew
Prefijo IP — bloque de direcciones anunciado como una unidad para que otras redes sepan cómo alcanzarlo.
Peering — interconexión directa entre redes para intercambiar tráfico sin depender por completo de un tránsito intermediario.
Convergencia — proceso por el que los routers actualizan sus rutas después de un cambio en los anuncios disponibles.
IAD / CMH — códigos de ubicación usados para las instalaciones de Cloudflare en Ashburn y Columbus.
