Caída de Cloudflare 2022: cambio BGP y rendición de cuentas

Resumen

El 21 de junio de 2022, Cloudflare afirma que un cambio de configuración de red provocó una caída en 19 centros de datos que utilizaban su arquitectura Multi-Colo PoP. Esas ubicaciones representaban aproximadamente el cuatro por ciento de su red, pero gestionaban una gran parte del tráfico. Cloudflare atribuyó alrededor de la mitad de las solicitudes totales durante el evento a tráfico afectado, y señaló que el impacto para los usuarios varió según la ubicación. [1]
El cambio previsto estandarizaba las comunidades BGP informativas en los prefijos locales del sitio. En los routers espina MCP, un reordenamiento de términos de política colocó un término de prefijos deshabilitados antes de los términos que deberían anunciar rutas críticas locales del sitio. La política de rutas resultante retiró esos prefijos. [1]
La retirada eliminó más que la alcanzabilidad externa. Cloudflare afirma que sus servidores no podían comunicarse con normalidad ni alcanzar los orígenes de los clientes, y su capa de equilibrio de carga Multimog no podía mover solicitudes entre clústeres de cómputo dentro de los MCP afectados. Los clústeres más pequeños recibieron entonces tráfico comparable al de clústeres más grandes y se sobrecargaron. [1]
Los ingenieros también tuvieron dificultades para acceder a las ubicaciones afectadas y deshacer el cambio. Fue necesario recurrir a procedimientos de respaldo. Durante la restauración, los ingenieros a veces sobrescribieron las reversiones de otros, lo que provocó que el problema reapareciera esporádicamente antes de que se recuperara la última ubicación. [1]
El proceso de Cloudflare ya incluía un ticket de cambio, una simulación, revisión por pares y despliegue por fases. El fallo de control fue más específico: ninguna de las primeras etapas de despliegue probó una ubicación MCP. La primera prueba representativa llegó cuando la etapa final alcanzó todas las espinas MCP. [1]
Las comunidades BGP son metadatos que utiliza la política de enrutamiento. No demuestran que una política de exportación esté correctamente ordenada ni que los prefijos requeridos sigan anunciándose. La validación de origen RPKI responde si un AS de origen está autorizado para un prefijo; no validaría este orden interno de términos, la selección del canario ni el procedimiento de reversión. [10][11][12][14][15][16]
La rendición de cuentas debe pedir, por tanto, evidencia operativa: la configuración candidata exacta antes y después, un conjunto de prefijos requeridos verificable por máquina, simulación de la política de rutas, un canario específico para MCP, comportamiento de confirmación de commit, alcance de gestión independiente, un único responsable autorizado de la reversión, registros de cambio por ubicación y observaciones de rutas externas conciliadas con los registros de los routers.
Los colectores públicos de rutas pueden ayudar a establecer anuncios y retiradas visibles externamente, pero no pueden revelar todas las rutas privadas locales del sitio ni las decisiones internas de política. Los registros del operador siguen siendo necesarios. [17][18][19]
El registro público no establece intención maliciosa, negligencia, una violación regulatoria, todos los prefijos afectados, todas las pérdidas de clientes ni si toda la remediación declarada sigue desplegada. Esos límites deben permanecer explícitos.

Un cambio revisado puede seguir siendo un cambio no probado

Las organizaciones de infraestructura suelen usar etiquetas de proceso como abreviatura del control. Un cambio estaba registrado en un ticket. Una simulación se completó. Varios ingenieros lo revisaron. El despliegue fue por fases. Cada afirmación puede ser cierta mientras el riesgo operativo siga sin probarse.

El relato de Cloudflare sobre su caída del 21 de junio de 2022 hace esa distinción con una claridad inusual. El cambio pasó por un ticket de solicitud de cambio, incluyó una simulación, recibió revisión por pares y siguió un procedimiento de despliegue escalonado. Las primeras etapas no provocaron una caída. El fallo apareció cuando el despliegue alcanzó las 19 ubicaciones que utilizaban una arquitectura que Cloudflare llamó Multi-Colo PoP, o MCP. Ninguna de las etapas anteriores había probado una ubicación MCP.

La primera etapa que representaba la topología de enrutamiento relevante fue también la etapa que aplicó la configuración a todas las espinas MCP. [1]

Eso no es un argumento de que los tickets, las revisiones, las simulaciones o las fases sean inútiles. Es evidencia de que cada control necesita una afirmación definida. Un ticket registra autorización e intención. Una revisión registra que personas nombradas examinaron alguna representación del cambio. Una simulación registra lo que una herramienta calculó contra un modelo o estado del dispositivo especificado. Un despliegue escalonado limita el alcance solo cuando cada etapa es representativa de un dominio de fallo distinto y lo bastante pequeña para detenerse antes de la siguiente.

La pregunta de rendición de cuentas no es, por tanto, «¿Existía el proceso?». Es «¿Qué demostró cada paso del proceso?». En este incidente, el despliegue inicial demostró que el cambio no perturbaba las ubicaciones que usaban la arquitectura anterior. No demostró que la política preservaría los anuncios requeridos en las espinas MCP. Un resultado verde de una ubicación no representativa no podía responder a la pregunta decisiva.

Esta brecha importa porque la configuración de red es autoridad operativa ejecutable. Un término de política de rutas no describe meramente adónde debe ir el tráfico. Su orden determina qué rutas anuncia o retiene un router. Una vez aplicado, la configuración cambia el grafo de alcanzabilidad que utilizan servidores, pares, orígenes, operadores y sistemas de recuperación. La diferencia entre una adición de metadatos inofensiva y una caída grave puede ser una rama de política evaluada antes que otra.

El informe de Cloudflare no debe reducirse al eslogan de que una configuración incorrecta provocó una caída. La lección útil es más estrecha y exigente: los controles de cambio deben vincularse a la arquitectura, a los invariantes de rutas, a los dominios de fallo y al acceso de recuperación. Un procedimiento escalonado que omite la arquitectura relevante puede crear la apariencia de prudencia sin aportar evidencia sobre el sistema que realmente fallará.

El cambio previsto era informativo; el cambio efectivo fue de alcanzabilidad

Cloudflare dijo que estaba estandarizando las comunidades BGP asociadas a un subconjunto de prefijos anunciados, concretamente añadiendo comunidades informativas a prefijos locales del sitio. Las comunidades BGP son atributos que los operadores utilizan para etiquetar rutas e influir en la política de enrutamiento. La especificación de comunidades estándar define una forma de agrupar destinos para que las decisiones de enrutamiento puedan aplicarse a una clase de rutas y no a un prefijo cada vez. Las comunidades grandes extienden el formato para necesidades operativas modernas. [1][11][12]

Las adiciones previstas no se describieron como un intento de retirar rutas de servicio. Cloudflare las caracterizó como información inofensiva en los routers ordinarios mostrados en su informe. La diferencia consecuente apareció en los routers espina MCP. Una diferencia de configuración reordenó términos en una política de exportación agregada. Un término asociado a prefijos deshabilitados se movió antes de los términos que anunciaban rutas locales del sitio para servicios y funciones internas. Dado que los términos de política se evalúan secuencialmente, la coincidencia anterior impidió que la lógica de anuncio posterior hiciera su trabajo.

[1]

Esta es la diferencia entre intención semántica y comportamiento efectivo. El autor de un cambio puede pretender adjuntar metadatos. Un revisor puede ver adiciones de comunidades. Un ticket puede usar un título que diga «estandarizar comunidades». Ninguna de esas representaciones controla el router. El router evalúa la política resultante en orden. Si la configuración generada o renderizada cambia ese orden, el efecto operativo es lo que ejecute el motor de política.

BGP en sí proporciona el mecanismo de alcanzabilidad. Las redes anuncian prefijos para decir a sus pares que las direcciones son alcanzables a través de una ruta. Retiran rutas cuando esa alcanzabilidad deja de estar disponible o no debe anunciarse. Un prefijo retirado puede desaparecer de rutas seleccionadas, haciendo que las direcciones asociadas no sean alcanzables por esa ruta. La especificación BGP-4 define estas semánticas de anuncio y retirada; no conoce la intención comercial de un operador para un término de política concreto. [10]

Esa distinción crea un requisito de evidencia. La aprobación de cambios debe vincularse a la configuración candidata exacta que evaluará el router, no solo a una solicitud de nivel superior o a una plantilla generada. El registro de revisión debería mostrar:

La política renderizada exacta antes y después del cambio.
El orden de evaluación de cada término afectado.
El conjunto de rutas que se espera aceptar, rechazar, anunciar y retirar.
El origen de cada prefijo de ese conjunto.
Los roles de dispositivo y las arquitecturas en las que se ejecutará la política.
Una simulación o prueba de laboratorio con entradas de rutas representativas.
Las rutas de gestión y reversión que siguen siendo alcanzables si la salida de la política es incorrecta.

Sin esos vínculos, la revisión puede verificar la solicitud y pasar por alto el efecto compilado. La rendición de cuentas de infraestructura sigue la configuración que consume el sistema en ejecución.

Los prefijos locales del sitio formaban parte de la ruta de servicio

El término «local del sitio» puede sonar secundario, como si las rutas afectadas fueran entradas de mantenimiento sin consecuencias para el cliente. El informe de Cloudflare muestra lo contrario. Los prefijos permitían la comunicación entre sus máquinas y permitían a los servidores alcanzar los orígenes de los clientes. Su retirada interrumpió esas rutas. [1]

Cloudflare también vinculó los prefijos con Multimog, un sistema interno de equilibrio de carga utilizado en las ubicaciones MCP. Multimog ya no podía reenviar solicitudes entre servidores en los MCP porque la alcanzabilidad relevante desapareció. Los clústeres de cómputo de diferentes tamaños recibieron entonces cargas de tráfico similares. Los clústeres más pequeños se sobrecargaron. [1]

Este mecanismo es importante porque explica por qué un subconjunto de retiradas de rutas pudo tener un efecto de servicio mucho mayor del que sugiere un simple recuento de prefijos ausentes. Un prefijo puede soportar una dependencia compartida por muchos servicios. Si transporta alcanzabilidad de origen, comunicación interna de clúster o una ruta de equilibrio de carga, su retirada cambia cómo se distribuye el trabajo en el sistema. Un servicio puede seguir recibiendo tráfico en el borde y perder las rutas internas necesarias para procesar o reenviar ese tráfico de forma segura.

El evento, por tanto, pone a prueba cómo clasifica un operador la criticidad de las rutas. Un registro de prefijos no debe detenerse en la propiedad o la autorización de origen. Debe registrar el rol operativo:

¿El prefijo está orientado a Internet, solo para gestión, local del sitio, orientado al origen del cliente o entre clústeres?
¿Qué routers y políticas lo anuncian?
¿Qué servicios dependen de él?
¿Qué comprobaciones de monitoreo demuestran que es alcanzable?
¿Qué ubicaciones comparten la misma plantilla de política?
¿Qué ocurre si la ruta desaparece pero el tráfico entrante continúa?
¿El acceso de gestión utiliza la misma familia de rutas o política?
¿Qué ruta alternativa se espera que soporte la dependencia?

Este registro no es soberano sobre la red. No hace que una ruta exista. Crea un libro mayor comprobable del estado esperado. Los operadores pueden comparar el libro mayor con la base de información de rutas, la base de información de reenvío, los colectores externos, las sondas activas y los resultados a nivel de servicio. Un registro exacto, único, controlado por cambios y vinculado al comportamiento observado hace detectable una retirada antes de que los clientes se conviertan en el sistema de monitoreo.

El efecto Multimog también muestra por qué la capacidad necesita contexto de topología. Cloudflare dijo que las ubicaciones MCP afectadas contenían clústeres de diferentes tamaños. Cuando falló el reenvío interno, los clústeres más pequeños recibieron tráfico comparable al de los clústeres más grandes. Un panel de capacidad que mostrara la capacidad total del sitio podía, por tanto, sobrestimar la capacidad utilizable. El fallo de la ruta eliminó el mecanismo de equilibrio que hacía accesible la capacidad agregada.

Una revisión basada en evidencia preguntaría si cada MCP tenía un modo degradado probado. ¿Podía drenarse el tráfico externamente cuando Multimog perdía la alcanzabilidad local del sitio? ¿Podían los clústeres más pequeños protegerse con controles de admisión? ¿Incluía el canario de la política de rutas sondas de acceso al origen, reenvío entre clústeres y acceso de gestión, y no solo la salud de la sesión BGP? El informe público identifica la dependencia, pero no publica todos los controles de protección.

Diecinueve ubicaciones expusieron una concentración dentro de una red distribuida

Cloudflare dijo que las 19 ubicaciones MCP eran aproximadamente el cuatro por ciento de su red y que, aun así, la caída afectó alrededor del 50 por ciento de las solicitudes totales. También subrayó que el impacto varió por ubicación: algunos usuarios no podían alcanzar propiedades que utilizaban Cloudflare mientras otras ubicaciones siguieron operando con normalidad. [1]

Esas cifras deben permanecer atribuidas y no deben convertirse en un recuento de personas, clientes, sitios web o pérdidas financieras. Sí respaldan una lección de topología. Una red puede estar distribuida geográficamente mientras el tráfico permanece concentrado en un conjunto reducido de ubicaciones de alta capacidad. Contar ubicaciones no es lo mismo que medir la proporción de tráfico, las dependencias de clientes, la capacidad de interconexión o la conectividad de origen que transportan.

El programa MCP pretendía mejorar la resiliencia en las ubicaciones más ocupadas. Cloudflare describió una arquitectura de estilo Clos con una capa de enrutamiento adicional y una malla de conexiones espina. La arquitectura permitía habilitar o deshabilitar partes de una red interna para mantenimiento o manejo de fallos. Son objetivos legítimos de resiliencia. El incidente no demuestra que la arquitectura fuera inherentemente defectuosa. [1]

Sí muestra que una ruta de política común puede conectar ubicaciones físicamente separadas. Si la misma política de rutas renderizada llega a todas las espinas MCP en un único paso final de despliegue, la plantilla de política se convierte en un dominio de fallo compartido. La diversidad física no elimina esa dependencia de control común.

Este es un patrón recurrente de rendición de cuentas de red. Los operadores pueden tener múltiples routers, instalaciones, operadores y rutas, pero una sola plantilla de automatización, sistema de credenciales, política de rutas, controlador o etapa de despliegue puede seguir creando un fallo de modo común. La diversidad debe medirse en la superficie de control que causó el incidente.

Para el despliegue MCP, un mapa de cambio útil incluiría:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Dimensión	Evidencia necesaria
Ubicación física	Identificadores de instalación y ciudad para cada canario y grupo de despliegue
Arquitectura	PoP anterior frente a MCP, rol de espina, tren de software, familia de hardware
Política	Política renderizada exacta y orden de términos para cada rol
Rol de ruta	Prefijos requeridos locales del sitio, de origen de cliente, de gestión y de servicio
Participación de tráfico	Participación normal de solicitudes y ancho de banda por grupo de despliegue
Gestión	Rutas de acceso primarias e independientes
Reversión	Estado de confirmación de commit, temporizador, responsable y resultado por dispositivo
Observación	Comprobaciones de rutas, alcanzabilidad, equilibrio de carga, capacidad y clientes

La tabla impide confundir una primera etapa de bajo riesgo con una representativa. Un canario debe ser pequeño, pero debe ejercitar la característica y la arquitectura que se están cambiando. Si el único sitio representativo transporta demasiado tráfico para usarlo como canario, eso es en sí mismo un riesgo arquitectónico y operativo que requiere un gemelo de laboratorio, una evaluación en sombra, un dominio representativo más pequeño o invariantes estáticos más fuertes antes de producción.

Perder la alcanzabilidad de gestión cambió el problema de recuperación

Cloudflare dijo que la retirada de rutas dificultó a los ingenieros llegar a las ubicaciones afectadas y revertir la configuración. Se usaron procedimientos de respaldo para tomar el control. [1]

Este detalle pertenece al centro del análisis. Un cambio de red no es reversible de forma segura solo porque exista un comando de reversión. El operador debe poder autenticarse, alcanzar el dispositivo, determinar el estado correcto y coordinar la reversión mientras la red está degradada. Si el tráfico de gestión depende de las rutas que se están cambiando, la ruta de recuperación comparte el dominio de fallo.

El acceso independiente no requiere necesariamente una red global totalmente separada para cada dispositivo. Sí requiere un diseño razonado que sobreviva al fallo que se está probando. Las opciones pueden incluir servidores de consola en una red de gestión enrutada por separado, enlaces de operador fuera de banda, automatización local que pueda ejecutar una reversión temporizada, funciones de confirmación de commit del dispositivo, acceso protegido por terminal o un canal de control cuya alcanzabilidad no dependa de la política candidata.

Cada opción tiene límites. Un operador fuera de banda puede compartir instalación o fuente de energía. Un servidor de consola puede depender del mismo proveedor de identidad o servicio DNS. Un temporizador de confirmación de commit puede cancelarse demasiado pronto o no restaurar todo el estado dependiente. La automatización local puede aplicar la línea base incorrecta. La rendición de cuentas requiere ejercicios que demuestren que la ruta seleccionada funciona bajo la condición exacta de pérdida.

La prueba relevante para este incidente es directa: retirar o suprimir el conjunto de rutas que proporciona la alcanzabilidad local del sitio y de gestión ordinaria en un entorno MCP representativo y verificar que los operadores puedan inspeccionar el estado y restaurar la configuración aprobada. El ejercicio debe medir el tiempo de acceso, el tiempo para identificar el invariante fallido, el tiempo para iniciar la reversión, el tiempo para restaurar los anuncios requeridos y el tiempo para confirmar la recuperación del servicio.

Una captura de pantalla de un inicio de sesión correcto en un día normal no basta. La prueba debe eliminar la dependencia que falló. La evidencia del sistema en ejecución supera a un diagrama que etiqueta una ruta como «fuera de banda».

El informe público no identifica todos los procedimientos de respaldo que Cloudflare utilizó, lo cual es razonable por motivos de seguridad y operación. La topología y las credenciales sensibles no deben publicarse. Una organización puede, aun así, conservar evidencia auditable bajo controles de acceso: marcas de tiempo de ejercicios, alcances de dispositivos, atestaciones independientes, sondas de rutas, criterios de éxito y excepciones.

La autoridad de reversión falló como control de coordinación

El cronograma de Cloudflare dice que las reversiones finales se retrasaron porque los ingenieros de red pisaron los cambios de otros. Algunas reversiones deshicieron reversiones anteriores, haciendo que el problema reapareciera esporádicamente. [1]

Esto no es una mera nota al pie de error humano. Identifica una propiedad de serialización ausente en la respuesta a incidentes. Durante una caída de alto impacto, varios ingenieros pueden tener acceso válido y motivos firmes para actuar. Si el sistema de cambios no proporciona un estado deseado autoritativo, propiedad visible, bloqueo por dispositivo y un registro compartido de progreso, el trabajo paralelo puede producir oscilación.

La lección de producción no es que solo una persona deba responder. La investigación, la observación de rutas, la comunicación con clientes, las pruebas de servicio y la preparación de reversión pueden avanzar en paralelo. La mutación del mismo estado de enrutamiento necesita coordinación. El sistema debería dificultar que un interviniente reintroduzca la configuración que otro interviniente ha eliminado.

Los controles útiles incluyen:

Un comandante de incidente y un responsable de cambios de red declarados.
Un commit de estado deseado congelado para la recuperación.
Bloqueos de dispositivo o de dominio de política durante la reversión.
Un único orquestador que registre cada reversión intentada y completada.
Temporizadores de confirmación de commit que restauren automáticamente el estado anterior si se pierde la confirmación de gestión.
Observadores de solo lectura que verifiquen la recuperación de rutas y servicios sin cambiar la configuración.
Una regla de que los cambios manuales de emergencia se reconcilien con la configuración autoritativa antes de que se reanude la automatización normal.
Traspaso explícito cuando la propiedad cambia entre equipos o regiones.

Estos controles deberían producir un libro mayor por ubicación. Para cada MCP, el registro debería mostrar el identificador de la configuración incorrecta, el comando o commit de reversión, el ejecutor, la hora de inicio y fin, el acuse del dispositivo, el resultado de la tabla de rutas, la alcanzabilidad de gestión, la sonda de servicio y cualquier cambio posterior que tocara la misma política. El libro mayor hace visible la interferencia y respalda una declaración fiable de que el último sitio está restaurado.

La remediación de Cloudflare incluyó reversión automatizada con confirmación de commit y una mejor imposición de escalonamiento. [1] Un mecanismo de confirmación de commit es especialmente relevante cuando un cambio de ruta puede eliminar el acceso de gestión. El router puede restaurar automáticamente el estado anterior salvo que el operador confirme el nuevo estado después de que pasen las comprobaciones de alcanzabilidad e invariantes.

La confirmación de commit no es magia. El tiempo de espera debe ser lo bastante largo para la validación, pero lo bastante corto para limitar el impacto. El estado anterior debe ser seguro en sí mismo. La confirmación no debe automatizarse únicamente a partir de una señal débil. Los cambios multidispositivo necesitan semánticas coordinadas para que un router no revierta mientras otro permanece en la configuración candidata. El mecanismo sigue necesitando ejercicios y evidencia.

El proceso existía; sus obligaciones de prueba estaban incompletas

El informe de Cloudflare dice explícitamente que el cambio tenía un ticket, simulación, despliegue escalonado y varios revisores pares. [1] Eso hace que el incidente sea útil para organizaciones que ya poseen un vocabulario maduro de gestión de cambios.

Una respuesta postmortem débil añadiría otra aprobación. Más firmas pueden ralentizar la entrega sin probar la condición ausente. La evidencia apunta a cuatro preguntas más fuertes.

Primero, ¿qué entrada usó la simulación? Si renderizó la política solo para una arquitectura anterior, no podía revelar el efecto de orden de términos en MCP. Una simulación debe incluir todos los roles de política afectados por la lógica de generación, especialmente los roles con plantillas o herencia diferentes.

Segundo, ¿qué afirmaciones evaluó la simulación? Una configuración sintácticamente válida puede retirar prefijos requeridos. La validación debe comparar las salidas de rutas, no solo los resultados de análisis. La herramienta debe fallar si cualquier prefijo requerido local del sitio, de gestión, orientado al origen o de servicio cambia inesperadamente.

Tercero, ¿cómo se definieron los grupos de despliegue? Un orden geográfico por sí solo no expondría un fallo específico de arquitectura si todas las primeras geografías usaran el diseño anterior. Los grupos deben reflejar hardware, software, topología, rol de política, versión del plano de control, participación de tráfico y ruta de gestión.

Cuarto, ¿qué detenía la progresión? Un despliegue escalonado es eficaz solo si tiene ventanas de observación explícitas y compuertas automáticas. El sistema necesita evidencia de que el canario conservó las rutas requeridas, la alcanzabilidad de origen, el equilibrio de carga interno, el acceso de gestión y el éxito del servicio antes de que comience el siguiente grupo.

La revisión por pares tiene obligaciones similares. Los revisores necesitan la diferencia renderizada para todos los roles, las salidas de rutas esperadas, la matriz de canarios, el plan de reversión y evidencia de que la ruta de recuperación es independiente. Pedir a los revisores que infieran esto de un ticket de alto nivel invita a la misma brecha.

El objetivo no es la perfección burocrática. Es vincular el proceso al mecanismo de fallo. Para la política BGP, la afirmación operativa es que los prefijos especificados permanecen anunciados a los pares especificados mientras cambian los atributos previstos. Esa afirmación puede probarse mecánicamente.

Los invariantes de rutas convierten la intención en una prueba

Un invariante de ruta es una afirmación que debe seguir siendo cierta antes, durante y después de un cambio. Los ejemplos incluyen:

Cada espina MCP anuncia el conjunto aprobado de prefijos locales del sitio.
Los prefijos de gestión siguen siendo alcanzables desde puntos de acceso independientes designados.
Las sondas de conectividad al origen del cliente tienen éxito desde cada clúster de cómputo.
El equilibrio de carga interno puede mover solicitudes entre clústeres de diferentes tamaños.
No se anuncia ningún prefijo público inesperado.
No se retira ningún prefijo protegido.
El número y los atributos de las rutas cambiadas coinciden con el alcance aprobado del cambio.

El conjunto de prefijos requeridos debe proceder de un registro operativo exacto vinculado a la propiedad del servicio. No debe ser una lista informal copiada en un ticket de una sola vez. La identidad del prefijo, el rol, el origen, los pares esperados, los metadatos de seguridad y el historial de cambios necesitan propiedad duradera.

Antes del commit, la simulación de política puede evaluar el candidato frente a rutas representativas y contextos de pares. Después de un commit de canario, el sistema puede comparar la base de información de rutas del router y la vista de rutas anunciadas con el invariante. Las sondas activas pueden probar rutas de servicio. Los colectores externos pueden aportar una vista separada para anuncios públicos. [17][18][19]

La comparación debe distinguir los cambios esperados de los inesperados. Si el propósito es añadir comunidades, la presencia de rutas debe permanecer estable mientras los atributos cambian dentro del conjunto aprobado. Una retirada de prefijos locales requeridos es entonces un fallo inmediato de compuerta, no un síntoma que espera errores HTTP globales.

Los invariantes de rutas también mejoran la comunicación de incidentes. En lugar de decir «la red se está recuperando», los operadores pueden informar de que los anuncios requeridos están restaurados en un número definido de ubicaciones, la alcanzabilidad de gestión ha vuelto, el reenvío interno pasa y el éxito de las solicitudes de clientes está dentro de un rango declarado. Cada afirmación tiene evidencia y un límite.

Existe el riesgo de falsa confianza. El conjunto de invariantes puede estar incompleto. Una ruta puede estar presente pero reenviar incorrectamente. Una vista del plano de control puede diferir del plano de datos. Por eso las comprobaciones de rutas deben emparejarse con sondas de reenvío y servicio. El conjunto de pruebas debe actualizarse cuando un incidente revele una dependencia que no estaba representada.

Las comunidades BGP no causaron la caída por sí solas

Sería inexacto resumir el incidente como «las comunidades BGP rompieron Cloudflare». Las comunidades son metadatos asociados a rutas. Los operadores las usan para políticas, etiquetado, ingeniería de tráfico y señalización operativa. RFC 1997 y RFC 8092 definen formatos de comunidad; no dictan el orden de política de Cloudflare. [11][12]

Las adiciones de comunidades previstas formaban parte del contexto del cambio. El mecanismo de la caída fue el orden efectivo de los términos de política en las espinas MCP y la retirada resultante de prefijos requeridos. [1] La distinción importa porque la remediación debe abordar el control fallido, no estigmatizar un mecanismo estándar.

Las comunidades pueden mejorar la rendición de cuentas cuando su significado está documentado, es único y se aplica de forma coherente. Pueden identificar clases de rutas, manejo previsto, estado de mantenimiento, geografía o relación con el cliente. Pero las etiquetas solo son útiles si la evaluación de la política preserva el resultado requerido. Una comunidad que diga «local del sitio» no mantiene una ruta anunciada cuando un término anterior la rechaza.

El mismo principio se aplica a los nombres y comentarios de cambios. Las etiquetas legibles por humanos apoyan la revisión, pero la política en ejecución determina la alcanzabilidad. Un operador debe poder trazar desde una definición de comunidad hasta el conjunto de rutas, las ramas de política, los anuncios esperados y los resultados observados. Si el rastro termina en la documentación, la evidencia operativa está incompleta.

RPKI es importante y no es la reparación directa

RPKI ofrece una forma de vincular recursos de direcciones IP a AS de origen autorizados. La validación de origen de rutas permite a un router clasificar un anuncio según si el origen y la longitud del prefijo son coherentes con una autorización de origen de ruta. RFC 6480 describe la arquitectura y RFC 6811 describe la validación de origen. [15][16]

Esos controles abordan una pregunta diferente de la del fallo de junio de 2022. RPKI puede ayudar a determinar si el AS de Cloudflare estaba autorizado para originar un prefijo público. No determina si un término de política de exportación interna debe anunciar un prefijo local del sitio, si los términos están correctamente ordenados, si un canario MCP es representativo o si el acceso de reversión es independiente.

Una ruta autorizada puede retirarse por accidente. Un origen válido no demuestra disponibilidad. A la inversa, una ruta interna local del sitio puede no ser nunca visible en RPKI público ni en colectores externos. Presentar RPKI como una solución universal oscurecería el fallo de control real.

RPKI sigue perteneciendo al modelo de evidencia porque la autorización de recursos de red, la política de rutas y la continuidad operativa interactúan. Un operador debe mantener registros de recursos numéricos y metadatos de seguridad exactos y, por separado, validar el comportamiento de la política y la alcanzabilidad del servicio. La integridad del registro y la evidencia del código en ejecución son complementarias, no sustitutas.

Este límite también es útil para la rendición de cuentas pública. Un postmortem puede indicar si un incidente implicó autorización de origen, una fuga de rutas, un secuestro, una retirada de política interna u otro mecanismo de enrutamiento. Una clasificación precisa evita tratar todo evento relacionado con BGP como el mismo fallo y respalda la remediación correcta.

La observación externa de rutas es valiosa pero incompleta

El servicio de información de enrutamiento de RIPE NCC recopila datos BGP de pares, y RIS Live expone flujos de actualizaciones. BGPStream de CAIDA proporciona herramientas para trabajar con datos de enrutamiento de múltiples colectores. Estos sistemas pueden ayudar a investigadores y operadores a observar anuncios, retiradas, cambios de ruta y restauración visibles para los puntos de observación participantes. [17][18][19]

Para un incidente de prefijo público, las observaciones externas pueden responder preguntas importantes:

¿Cuándo desapareció un prefijo de colectores seleccionados?
¿Qué pares o regiones observaron la retirada?
¿Cuándo regresaron los anuncios?
¿Cambiaron las rutas o atributos después de la restauración?
¿Coincidió el evento con el cronograma público del operador?

El postmortem de junio de 2022 trata de prefijos locales del sitio y comportamiento interno del MCP, así como del fallo de servicio experimentado externamente. Los colectores públicos pueden no ver todas las rutas relevantes. No exponen términos de política privados, configuraciones candidatas de routers, alcanzabilidad de gestión interna ni estado de Multimog. La ausencia de una señal externa no demuestra que el sistema privado estuviera sano.

Esta limitación no debe usarse para descartar la evidencia externa. Define la tarea de conciliación. Los operadores pueden conservar registros de routers, commits de configuración, instantáneas de rutas anunciadas, resultados de sondas activas y telemetría de servicio. Los colectores públicos proporcionan una capa independiente. Un cierre creíble explica dónde coinciden las vistas, dónde difiere la visibilidad y por qué.

La evidencia debe tener marcas de tiempo con un reloj coherente. Las actualizaciones de enrutamiento, los commits de configuración, las declaraciones de incidentes, las reversiones, las sondas de alcanzabilidad y los errores de clientes pueden, de lo contrario, aparecer fuera de orden. La sincronización horaria y los registros inmutables son controles de rendición de cuentas porque preservan la secuencia necesaria para evaluar la respuesta.

Las cifras de impacto necesitan sus propios límites

Cloudflare dijo que las 19 ubicaciones MCP representaban aproximadamente el cuatro por ciento de su red, pero que la caída afectó al 50 por ciento de las solicitudes totales. También publicó un gráfico de volumen de solicitudes y una vista de ancho de banda de salida. [1]

Las cifras muestran concentración de tráfico en sitios de alta capacidad. No establecen que la mitad de todos los usuarios de Internet, la mitad de los clientes de Cloudflare o la mitad de todos los sitios web quedaran totalmente indisponibles. El tráfico de solicitudes no es un recuento de población. Algunas ubicaciones siguieron operando con normalidad, y los efectos en los clientes dependieron de la geografía y de la ruta de servicio.

Un relato de impacto responsable debe separar:

Solicitudes que fallaron.
Solicitudes que se retrasaron o se reintentaron.
Ubicaciones que perdieron rutas requeridas.
Clústeres que se sobrecargaron.
Orígenes de clientes que quedaron inalcanzables desde sitios afectados.
Servicios que continuaron desde ubicaciones no afectadas.
Tiempo hasta la primera recuperación y tiempo hasta la reversión final.
Errores residuales después de la restauración de rutas.

El informe público aporta información sólida sobre varias de estas dimensiones, pero no un inventario completo cliente por cliente. El artículo no debe fabricar precisión.

Para incidentes futuros, un operador puede mejorar la divulgación publicando denominadores e incertidumbre. Si el 50 por ciento de las solicitudes se vieron afectadas, defina el intervalo de medición, el criterio de éxito, el tratamiento de reintentos, la geografía y si la cifra incluye tráfico desviado a otros sitios. Las métricas claras permiten a los clientes comparar la declaración con sus propios registros.

La rendición de cuentas sigue al control, no a la exposición de marca

Cloudflare controlaba la política de rutas, el procedimiento de despliegue, la agrupación MCP, el alcance de la simulación, los materiales de revisión por pares, el acceso de gestión, la automatización y la coordinación de reversión. Su postmortem acepta que la caída fue su error y no un ataque. [1] Esos hechos hacen de Cloudflare el operador central en el análisis de rendición de cuentas.

Eso no significa que toda consecuencia sea legalmente atribuible ni que todos los ingenieros compartieran la misma responsabilidad. El registro público no establece culpa individual ni negligencia. La gobernanza debe asignar controles a equipos y sistemas:

El responsable de la arquitectura de red definió los roles MCP y los dominios de fallo.
El responsable de política definió los términos de exportación y el manejo de comunidades.
El responsable de automatización renderizó y distribuyó la configuración.
El responsable del cambio seleccionó las etapas y las ventanas de observación.
Los revisores evaluaron la evidencia suministrada.
El comandante del incidente coordinó la recuperación.
Los equipos de dispositivo y plataforma suministraron mecanismos de reversión y confirmación de commit.
Los equipos de servicio monitorearon la alcanzabilidad de origen, Multimog, la carga de clúster y las solicitudes de clientes.
La dirección estableció la concentración de tráfico aceptable y el riesgo de cambio.

Los proveedores de routers y software influyen en los mecanismos de seguridad disponibles, pero el informe público de Cloudflare no atribuye el reordenamiento de términos a un defecto del proveedor. Los organismos de estándares definen el comportamiento del protocolo, pero no operan la política de Cloudflare. Los clientes dependían del servicio, pero no controlaban la configuración interna de rutas locales del sitio.

Los clientes siguen teniendo responsabilidad sobre su arquitectura de dependencias. Una organización cuyo servicio público depende de una CDN o de una ruta DNS autoritativa debe comprender esa dependencia, probar accesos alternativos cuando sea factible y definir la comunicación cuando el proveedor esté inalcanzable. Esa responsabilidad no transfiere el control de los routers de Cloudflare al cliente ni hace evitable toda dependencia.

Los reguladores y los grandes compradores pueden solicitar evidencia sin prescribir la topología privada. Pueden preguntar si el proveedor utiliza canarios representativos de arquitectura, invariantes de rutas, acceso de gestión independiente, reversión serializada y ejercicios. Los contratos pueden definir divulgación y evidencia de recuperación. Deben evitar exigir configuraciones sensibles en público cuando una revisión protegida puede cumplir el propósito.

Un paquete de evidencia práctica

El cierre postincidente más sólido no es una garantía de que el mismo error exacto no pueda repetirse. Es un paquete acotado que muestre qué cambió y cómo funcionan los nuevos controles.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Control	Evidencia retenida	Prueba operativa	Límite importante
Autorización de cambios	Ticket, aprobadores, alcance, clasificación de riesgo	El ticket vincula a la configuración candidata renderizada exacta	La aprobación no demuestra el comportamiento de rutas
Revisión de política	Orden de términos antes/después para cada rol de router	La herramienta de revisión identifica coincidencias y acciones cambiadas	El revisor puede pasar por alto un modelo de rutas incompleto
Invariante de prefijos requeridos	Lista de prefijos versionada con rol y propietario	El candidato y el canario conservan todos los anuncios protegidos	Una ruta presente no demuestra reenvío
Canario de arquitectura	Rol MCP, hardware, software, tráfico y registro de ruta de gestión	El canario ejercita la misma ruta de política que los grupos posteriores	Un canario puede no representar todos los MCP
Simulación de rutas	Rutas de entrada representativas y salidas esperadas	Sin retiradas ni anuncios inesperados	La simulación puede diferir del comportamiento del dispositivo
Confirmación de commit	Temporizador, estado anterior, criterios de confirmación	La pérdida de gestión o un fallo de invariante dispara la reversión	La coherencia multidispositivo sigue siendo difícil
Acceso independiente	Topología, dependencia y registro de ejercicio	Los operadores alcanzan y restauran dispositivos tras una pérdida ordinaria de rutas	Pueden quedar dependencias compartidas ocultas de energía, identidad o DNS
Propiedad de reversión	Responsable del incidente, estado de bloqueo, libro mayor por dispositivo	Investigadores paralelos no pueden sobrescribir el estado de recuperación	El trabajo manual de emergencia puede saltarse la automatización
Observación externa	Evidencia de RIPE RIS, BGPStream u otros colectores	Los cambios de rutas públicas coinciden con el cronograma del operador	Las rutas privadas y todos los pares no son visibles
Verificación de servicio	Sondas de origen, reenvío interno, carga de clúster y solicitudes	La restauración de rutas produce servicio completado	Las sondas sintéticas pueden pasar por alto rutas específicas de clientes
Durabilidad de la remediación	Evidencia de despliegue y resultados recurrentes de ejercicios	La puesta en escena y la reversión específicas de MCP siguen superándose	Una prueba única no demuestra cumplimiento permanente

El paquete separa los registros de la prueba operativa. Un registro de prefijos es útil porque preserva singularidad, propiedad, rol, pares esperados, metadatos de seguridad e historial de cambios. No es la autoridad que hace fluir los paquetes. La simulación de política es útil porque predice el comportamiento; el canario y el estado de rutas en vivo aún necesitan observación. Un postmortem público es útil porque describe el evento; no demuestra que todos los compromisos posteriores sigan activos.

Los detalles sensibles pueden protegerse. Las direcciones de gestión exactas, credenciales, topología y configuración de routers pueden crear riesgo de seguridad si se publican. Auditores independientes, reguladores o clientes bajo confidencialidad pueden revisarlos. La divulgación pública puede resumir los resultados de control, las marcas de tiempo, el alcance y los límites no resueltos.

Los límites de comparación importan

Cloudflare ha experimentado otros incidentes de enrutamiento y configuración. Tratarlos como una única caída genérica debilitaría el análisis.

El evento de junio de 2019 implicó una fuga de rutas externa. No es el fallo de puesta en escena MCP de 2022.

La caída de Cloudflare de julio de 2020 fue una caída por reglas de router. Su mecanismo directo difiere de la retirada de prefijos locales de 2022.

El evento de marzo de 2025 implicó una ROA defectuosa. Las rutas de 2022 fueron retiradas por política interna; el registro público no describe una ROA defectuosa como causa.

El fallo del archivo de características de Cloudflare de 2025 no fue un evento de política de exportación BGP.

Los casos comparten una lección abstracta: pequeños insumos de control pueden adquirir alcance global. La evidencia y las reparaciones específicas difieren. La rendición de cuentas de red exige nombrar el protocolo, la capa, la autoridad, la ruta de propagación y el límite de recuperación que realmente fallaron.

Lo que el registro público no demuestra

El postmortem de Cloudflare es detallado, pero es un relato de primera parte. Proporciona la fuente pública más sólida para el mecanismo y el cronograma, mientras deja privado material importante.

El registro público no revela todos los prefijos retirados, las configuraciones completas de routers, el ticket de cambio completo, los comentarios de los revisores, el código de automatización, la topología privada, el diseño del acceso de gestión ni todas las dependencias de servicio. No muestra la base de información de rutas completa ni el estado de reenvío de cada dispositivo.

Los gráficos públicos de tráfico no identifican a todos los clientes, usuarios, tipos de solicitud, orígenes ni consecuencias financieras afectados. El artículo no infiere créditos de servicio, ingresos perdidos, sanciones regulatorias, incumplimiento contractual ni negligencia del cliente.

El postmortem dice que el incidente fue un error de Cloudflare y no un ataque. No establece intención maliciosa, ocultación, conducta delictiva ni culpa individual. Por sí solo no establece un estándar legal de cuidado.

La sección de remediación registra trabajo planificado e inmediato. No demuestra que todos los canarios específicos de MCP, el rediseño de política, la automatización de escalonamiento o el mecanismo de confirmación de commit sigan desplegados y sean efectivos hoy. La documentación actual puede explicar arquitectura y controles, pero no debe tratarse retroactivamente como prueba del estado exacto de 2022.

RIPE RIS y BGPStream pueden proporcionar observaciones de enrutamiento independientes, pero la evidencia pública disponible no ofrece una reconstrucción completa de colectores de cada retirada local del sitio. La visibilidad externa tiene límites.

Estas incógnitas no impiden el análisis de rendición de cuentas. Definen las preguntas que los poseedores de evidencia deben responder e impiden que el artículo convierta un postmortem técnico en una acusación sin fundamento.

Preguntas para operadores, juntas, clientes y revisores

Los operadores de red deberían preguntar:

¿Qué políticas de rutas difieren por arquitectura o rol de router?
¿La simulación renderiza todos los roles afectados?
¿Qué prefijos deben permanecer anunciados durante el cambio?
¿Las listas de prefijos requeridos están versionadas, tienen propietario y están vinculadas a las dependencias de servicio?
¿Un simulador de políticas evalúa entradas de rutas representativas y orden de términos?
¿El primer canario es pequeño y representativo de la arquitectura?
¿Qué ventana de observación y compuerta automática detienen la progresión?
¿Pueden los operadores alcanzar los dispositivos después de que la política candidata retire las rutas de gestión ordinarias?
¿La confirmación de commit restaura un estado multidispositivo coherente?
¿Quién es dueño de la mutación durante la reversión del incidente?
¿Pueden los equipos de solo lectura observar rutas y servicio sin cambiar la configuración?

Las juntas y comités de riesgos deberían preguntar:

¿Qué proporción del tráfico depende del dominio de control común más ocupado?
¿La distribución geográfica oculta una dependencia compartida de política o automatización?
¿Qué dependencias de gestión, identidad, DNS, energía y operadores comparten las rutas primarias y de recuperación?
¿Qué evidencia demuestra ejercicios recurrentes en lugar de una remediación única?
¿Cómo se definen y concilian las métricas de impacto en clientes con la evidencia de rutas y servicio?

Los clientes deberían preguntar:

¿Qué servicios dependen de la alcanzabilidad, DNS, CDN, seguridad, acceso o rutas de origen de Cloudflare?
¿Puede continuar la comunicación crítica si el proveedor y su ruta de estado están deteriorados?
¿Los proveedores alternativos o las rutas de origen directo están probados técnica y operativamente?
¿Qué compensaciones de seguridad surgen de la derivación o la conmutación por error?
¿Qué registros establecen el impacto propio del cliente sin asumir una caída universal?

Los revisores y auditores deberían preguntar:

¿Inspeccionaron la política renderizada exacta, no solo la solicitud?
¿El canario coincidía con la topología MCP y la política de espina?
¿Se incluyeron las rutas locales del sitio y de gestión en los invariantes?
¿Coincidieron las mediciones independientes y los registros del router?
¿Podían dos ingenieros sobrescribir las reversiones del otro?
¿Cada afirmación de remediación está vinculada a un resultado de prueba actual y a un registro de excepciones?

Estas preguntas no asumen que el fallo cero sea posible. Prueban si una clase conocida de error de enrutamiento está acotada, es observable y recuperable.

Conclusión: una etapa solo es tan buena como el sistema que representa

La caída de Cloudflare de junio de 2022 comenzó con un cambio controlado. El cambio tenía un ticket, simulación, revisión por pares y múltiples etapas de despliegue. Aun así, retiró prefijos locales críticos cuando alcanzó una arquitectura que ninguna de las primeras etapas había probado. La retirada rompió la alcanzabilidad de servidores y orígenes, desactivó la redistribución interna de carga, sobrecargó clústeres más pequeños y deterioró la ruta de gestión necesaria para la recuperación. Las reversiones concurrentes causaron entonces recurrencia esporádica. [1]

El incidente convirtió la puesta en escena de cambios BGP en una prueba de rendición de cuentas. Una etapa no es evidencia solo porque venga antes que otra. Debe representar la topología relevante, el rol de política, el software, las entradas de rutas, la concentración de tráfico y la dependencia de gestión. Sus criterios de éxito deben incluir las rutas y los servicios que deben permanecer disponibles.

El modelo de reparación es concreto. Vincule la aprobación a la configuración renderizada. Mantenga un libro mayor exacto de prefijos requeridos y sus roles operativos. Simule la salida de la política. Use un canario específico de MCP. Observe anuncios, reenvío, conectividad de origen, equilibrio de carga interno y acceso de gestión. Proteja la reversión con confirmación de commit y un único responsable autorizado del cambio. Concilie los registros privados de routers con mediciones públicas independientes donde la visibilidad lo permita.

Las comunidades BGP, RPKI, los colectores de rutas, los tickets y los diagramas contribuyen con evidencia. Ninguno sustituye el resultado operativo. Las comunidades etiquetan rutas; el orden de política controla las decisiones. RPKI valida la autorización de origen; no demuestra disponibilidad ni corrección de la política interna. Los colectores observan vistas externas seleccionadas; no revelan todas las dependencias privadas. Los tickets registran intención; no mantienen anunciado un prefijo.

Esa capa de realidad es la lección duradera. Una red distribuida es resiliente cuando sus rutas en ejecución, políticas de control, acceso de gestión y mecanismos de reversión preservan el servicio ante un fallo representativo. La prueba no es el nombre del proceso. Es la ruta que permaneció alcanzable, el canario que detuvo el despliegue y la recuperación que un equipo pudo completar sin que otro la deshiciera.

Fuentes

Cloudflare, «Cloudflare outage on June 21, 2022»:https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/
Cloudflare, Informe de impacto 2022:https://cf-assets.www.cloudflare.com/slt3lc6tev37/fBTOgkechN3IcaoT3kbA3/c9b74ee483d28c795d3c7891d8d36034/2022_Cloudflare_Impact_Report.pdf
Cloudflare, «Cloudflare Backbone: A Fast Lane on the Busy Internet Highway»:https://blog.cloudflare.com/cloudflare-backbone-internet-fast-lane/
Cloudflare, «The backbone behind Cloudflare's Connectivity Cloud»:https://blog.cloudflare.com/backbone2024/
Cloudflare, «Load Balancing without Load Balancers»:https://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p/
Cloudflare, Arquitectura de referencia de CDN:https://developers.cloudflare.com/reference-architecture/architectures/cdn/
Cloudflare, Direcciones IP y red anycast:https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/
Cloudflare, Política de interconexión:https://www.cloudflare.com/peering-policy/
PeeringDB, registro de red de Cloudflare:https://www.peeringdb.com/net/4224
IETF / RFC Editor, RFC 4271, Border Gateway Protocol 4:https://www.rfc-editor.org/rfc/rfc4271
IETF / RFC Editor, RFC 1997, BGP Communities Attribute:https://www.rfc-editor.org/rfc/rfc1997
IETF / RFC Editor, RFC 8092, BGP Large Communities Attribute:https://www.rfc-editor.org/rfc/rfc8092
IETF / RFC Editor, RFC 8326, Graceful BGP Session Shutdown:https://www.rfc-editor.org/rfc/rfc8326
IETF / RFC Editor, RFC 7454, BGP Operations and Security:https://www.rfc-editor.org/rfc/rfc7454
IETF / RFC Editor, RFC 6811, BGP Prefix Origin Validation:https://www.rfc-editor.org/rfc/rfc6811
IETF / RFC Editor, RFC 6480, RPKI Architecture:https://www.rfc-editor.org/rfc/rfc6480
RIPE NCC, Manual de RIS Live:https://ris-live.ripe.net/manual/
RIPE NCC, Routing Information Service:https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
CAIDA, BGPStream:https://bgpstream.caida.org/
Cloudflare, «What is BGP?»:https://www.cloudflare.com/learning/security/glossary/what-is-bgp/

La caída de Cloudflare en 2022 convirtió la implementación por fases de cambios BGP en una prueba de rendición de cuentas