Resumen

  • AMS-IX atribuyó los incidentes del 22 y 23 de noviembre de 2023 a tramas LACP que salieron de la relación de un puerto de cliente y perturbaron los LAG y las sesiones BGP de otros participantes en la plataforma compartida.
  • La recuperación exige distinguir entre estabilizar el fabric, desplazar tráfico por rutas alternativas y restaurar de extremo a extremo; la responsabilidad operativa debe demostrarse mediante invariantes de aislamiento, conformidad del aprovisionamiento, pruebas entre fabricantes, alarmas, evidencia de reversión y alternativas de conectividad ejercitadas.

Un incidente de aislamiento, no solo una caída de tráfico

El episodio de AMS-IX en Ámsterdam fue un fallo delimitado de infraestructura de interconexión. Su relevancia no deriva únicamente de la reducción visible del tráfico, sino de que un protocolo concebido para coordinar enlaces entre sistemas adyacentes llegó a influir en relaciones que no debían recibir esas tramas. Una señal de control local escapó de su ámbito, modificó el estado de agregación de otros participantes y contribuyó a la inestabilidad de sesiones BGP. Bajo presión de recursos, el problema se extendió además por superficies de control de Juniper y Extreme.

Esa secuencia coloca el aislamiento del fabric en el centro de la evaluación. El equipo de un cliente puede ser la fuente de una trama, pero el operador de un punto de intercambio controla la política que determina qué tramas se admiten, filtran o reenvían en los puertos conectados a la infraestructura compartida. También controla el sistema de aprovisionamiento que materializa esa política, las versiones desplegadas, la generación de listas de control de acceso, la observabilidad y la comunicación durante el incidente. Los fabricantes, a su vez, determinan cómo sus implementaciones procesan filtros, estados de protocolo y mensajes de error.

Los participantes conectados controlan sus propias salidas alternativas, su capacidad disponible y la autoridad operativa para retirar o desviar sesiones.

La pregunta adecuada, por tanto, no es cuál de esos actores puede recibir una culpa abstracta. La evidencia pública no permite establecer negligencia, ilegalidad, incumplimiento contractual, intención maliciosa ni responsabilidad jurídica. La pregunta técnicamente verificable es otra: ¿qué control tenía cada actor, cómo se comportó ese control en ejecución y qué evidencia permitiría demostrar que la misma clase de propagación ya no puede repetirse?

La cronología oficial y sus dos intervalos

AMS-IX informó de un primer intervalo afectado entre las 19:08 y las 23:04 CET del 22 de noviembre de 2023. Durante ese periodo se produjo un flapping activo de LACP y BGP en la plataforma de peering de Ámsterdam. El segundo intervalo oficial se extendió desde las 09:38 hasta las 10:25 CET del 23 de noviembre. Mantener ambos periodos separados importa porque una estabilización inicial no equivale por sí sola a la eliminación de la condición que podía reactivar el comportamiento.

En el punto más bajo comunicado por AMS-IX, el tráfico de la plataforma descendió a 2,1 Tb/s. La organización también indicó que las sesiones BGP IPv4 cayeron de 885 a 550 y las sesiones IPv6 de 800 a 450. Son cifras importantes porque muestran una pérdida amplia de estado de interconexión dentro de la plataforma, pero su significado debe permanecer acotado. No representan cantidades de usuarios, aplicaciones o empresas afectadas. Tampoco expresan pérdidas económicas ni prueban que todo el tráfico europeo sufriera una interrupción.

Una sesión BGP no equivale a un usuario y una reducción del caudal agregado no identifica por sí sola qué servicios dejaron de funcionar. Una red puede retirar una sesión en el intercambio y conservar conectividad por tránsito, peering remoto u otro punto de intercambio. Otra puede mantener una sesión aparente mientras experimenta pérdida, latencia o convergencia inestable. La métrica de la plataforma es, por ello, evidencia directa de lo ocurrido en el punto de intercambio, pero solo evidencia indirecta de la experiencia de extremo a extremo.

El segundo intervalo del 23 de noviembre refuerza la necesidad de evaluar la recuperación como una secuencia. Un gráfico de tráfico que vuelve a subir puede señalar que el fabric recuperó capacidad, que participantes desplazaron tráfico hacia otros caminos o que ambos procesos ocurrieron en paralelo. No demuestra por sí solo que cada cliente final, red dependiente o aplicación recuperara su estado normal.

La restauración debe analizarse por capas: estabilidad de los switches, recuperación de los LAG, restablecimiento de sesiones BGP, disponibilidad de rutas, capacidad de los caminos alternativos y experiencia efectiva de los destinos observados.

La trama que no debía atravesar la frontera

Según la atribución de AMS-IX, la condición iniciadora fue una fuga de LACP desde un switch provider-edge de Juniper. Un equipo de cliente generaba paquetes LACP aunque estaba conectado mediante un puerto que no operaba con LACP. El switch Juniper propagó esas tramas de control de alcance local en lugar de confinarlas a la relación adyacente. Al recibirlas, grupos de agregación pertenecientes a otros clientes reaccionaron, y esa reacción se tradujo en flapping tanto de LACP como de BGP.

LACP coordina la formación y el mantenimiento de grupos de enlaces entre sistemas vecinos. Las tramas tienen significado dentro de esa relación concreta: describen identidad, estado y disposición de los enlaces que pueden participar en una agregación. Si aparecen en otra relación, el receptor puede interpretarlas como información válida sobre su propio grupo. El riesgo no es solamente transportar unos bytes inesperados. El riesgo es introducir una señal de control ajena en una máquina de estados que puede añadir, retirar o reorganizar enlaces físicos bajo una interfaz lógica.

El detalle del puerto no LACP es esencial. AMS-IX señaló que existían mitigaciones mediante ACL para LACP, pero la conexión relevante no estaba configurada como enlace LACP. Si la protección se generaba o aplicaba solo al reconocer explícitamente ese tipo de puerto, quedaba una brecha: una trama LACP podía originarse donde el sistema de aprovisionamiento no esperaba verla. La invariante correcta no debería depender de la intención declarada del cliente.

Toda trama link-local que no tenga derecho a cruzar una frontera de cliente debe ser contenida en esa frontera, tanto si el puerto es agregado de forma dinámica como si es estático o no agregado.

Este punto diferencia una regla documental de un control ejecutable. Un registro de participante, un perfil de servicio o una plantilla pueden afirmar que un puerto no utiliza LACP. Esa información es valiosa para atribuir identidad e intención. Sin embargo, no impide que el equipo conectado emita una trama LACP, ya sea por configuración, transición de estado, defecto o cualquier otra condición no publicada. La protección efectiva existe únicamente si la canalización de aprovisionamiento, la ACL instalada y el comportamiento real del switch bloquean o confinan esa trama.

No es necesario especular sobre por qué el equipo del cliente generó los paquetes para evaluar la frontera. El cliente y su dispositivo exacto no fueron identificados en el informe público. Tampoco se conocen su modelo, configuración, historial de cambios o motivación. El análisis puede reconocer que la fuente de las tramas estaba en el lado del cliente sin convertir esa observación en una acusación. Una infraestructura compartida se diseña precisamente para evitar que un comportamiento inesperado en un puerto modifique el estado de otros participantes.

De LACP al flapping de BGP

Cuando un LAG cambia repetidamente de estado, la interfaz lógica que transporta tráfico y sesiones de enrutamiento puede dejar de ser estable. Los enlaces físicos pueden entrar o salir del grupo, y el camino disponible para los paquetes de una sesión BGP puede desaparecer, reaparecer o experimentar pérdida suficiente para que expiren temporizadores. AMS-IX documenta que LACP puede provocar flapping de BGP después de una conmutación de topología y recomienda temporizadores cortos. Esa documentación ayuda a entender la superficie operativa, aunque no identifica por sí sola el defecto exacto del incidente.

Las cifras publicadas —de 885 a 550 sesiones IPv4 y de 800 a 450 sesiones IPv6— muestran que la inestabilidad no quedó limitada a una única relación bilateral. La alteración alcanzó una parte sustancial del estado BGP observado en la plataforma. No obstante, las cifras no permiten saber cuántas sesiones cayeron por una reacción directa de LACP, cuántas por pérdida de conectividad durante la presión de recursos, cuántas fueron retiradas deliberadamente por operadores conectados ni cuántas cambiaron varias veces durante el intervalo.

La separación entre causa iniciadora y respuesta downstream es fundamental. Un participante puede desactivar una sesión para evitar un camino degradado. Esa retirada contribuye a reducir el recuento de sesiones en el intercambio, pero puede ser una maniobra protectora, no otro fallo del fabric. Del mismo modo, la reducción del tráfico puede combinar pérdida involuntaria con desvío deliberado hacia tránsito u otro peering. Una lectura responsable de las métricas no mezcla ambos fenómenos.

BGP añade además una dimensión temporal. La sesión de control, la disponibilidad de las rutas y el tráfico de datos no se recuperan necesariamente al mismo instante. Tras una reconexión se intercambian mensajes, se reconstruye el estado y se seleccionan caminos. Redes aguas abajo pueden conservar decisiones anteriores o elegir alternativas con distinta capacidad. Por eso, una plataforma que deja de generar el estímulo inicial todavía puede producir consecuencias observables mientras los participantes convergen.

Presión de recursos y una cascada entre fabricantes

El informe de AMS-IX describió una segunda etapa en la que la presión de recursos y los búferes llenos generaron errores de timeout de RSVP. Los dispositivos Juniper afectados enviaron mensajes RSVP Path Error que, según AMS-IX, crearon problemas adicionales en switches Extreme SLX. Esta parte de la cronología es un amplificador posterior a la fuga de LACP y al flapping, no la condición iniciadora.

La distinción evita dos generalizaciones incorrectas. La primera sería afirmar que RSVP causó el incidente desde el comienzo. La evidencia congelada no sostiene esa conclusión: AMS-IX atribuyó el inicio a la propagación de tramas LACP. La segunda sería presentar la cascada observada como una propiedad de todas las redes MPLS o de todos los despliegues RSVP. Los estándares permiten explicar el propósito de la señalización, los mensajes de error y los mecanismos de recuperación, pero no prueban que otra red, con otro diseño, versiones o políticas, reaccionaría del mismo modo.

En una plataforma compleja, la presión de recursos puede cambiar la conducta observable de controles que parecen correctos en condiciones normales. Un filtro puede estar presente mientras otro componente se queda sin capacidad. Una cola llena puede retrasar o perder mensajes de mantenimiento. Los timeouts pueden provocar nuevas señalizaciones, y esas señalizaciones pueden generar trabajo adicional en dispositivos vecinos. El resultado es un bucle operativo en el que la perturbación inicial y la respuesta del plano de control se refuerzan.

AMS-IX indicó que la ACL LACP de salida en Juniper no estaba plenamente operativa. También señaló que la ACL de salida en Extreme SLX no se comportó como se esperaba. Permanecía sin aclarar públicamente si el comportamiento del SLX respondía a un defecto de software o a un cambio de sintaxis después de una actualización. Esa incertidumbre debe conservarse. Sin versiones exactas, configuración instalada, representación compilada de las ACL, resultados de laboratorio o conclusiones de los fabricantes, no es posible asignar el fallo a una causa concreta del producto.

La coexistencia de Juniper y Extreme convierte el episodio en una cuestión de conformidad entre superficies de control. No basta con comprobar que una plantilla produce una ACL en una familia de equipos. Hay que demostrar que la intención de aislamiento conserva el mismo significado al compilarse para plataformas distintas, que las actualizaciones no alteran silenciosamente la sintaxis y que un evento bajo presión no abre una ruta inesperada para tramas o mensajes.

Las pruebas unitarias de una plantilla tampoco son suficientes. La propiedad relevante es extremo a extremo: una trama generada en un puerto de cliente no debe alcanzar otro puerto de cliente; un mensaje de control inesperado no debe desestabilizar grupos ajenos; y la recuperación de un plano no debe provocar una avalancha dañina en otro. Esa propiedad debe verificarse con tráfico realista, estados transitorios, búferes sometidos a carga y combinaciones de versiones equivalentes a las desplegadas.

El papel de las ACL y del aprovisionamiento

Una ACL puede ser correcta en el repositorio y estar ausente, incompleta o semánticamente alterada en el switch. Por eso la responsabilidad no termina en la declaración de la política. Debe cubrir toda la cadena: clasificación del puerto, generación de la configuración, validación previa, aplicación en el dispositivo, confirmación del estado efectivo y vigilancia posterior.

El caso del puerto no LACP muestra el riesgo de vincular la seguridad únicamente a una característica solicitada. Si el sistema crea un filtro LACP solo para conexiones que declaran usar LACP, la política confunde expectativa con capacidad. El equipo conectado puede emitir tramas que no corresponden al perfil registrado. El fabric necesita una regla de frontera independiente de esa expectativa: permitir únicamente los protocolos y destinos de control autorizados para la relación y bloquear la propagación lateral del resto.

La conformidad también debe comprobar diferencias de dirección. Un filtro de entrada puede impedir que ciertas tramas ingresen al plano compartido; uno de salida puede evitar que alcancen a otros participantes. La evidencia pública señala problemas relacionados con ACL de salida en Juniper y Extreme, pero no revela el conjunto completo de reglas, su orden ni su interacción con el reenvío. Una verificación sólida debe observar ambos lados de la frontera y demostrar qué ocurre con la trama, no limitarse a confirmar que existe una línea de configuración.

AMS-IX anunció varias acciones posteriores: aplicar ACL a enlaces no LACP, mejorar la creación de ACL en la pila de aprovisionamiento, revisar los filtros LACP de salida en Juniper y Extreme, investigar alertas para BPDU de Slow Protocols y revisar las reglas de comunicación en la lista técnica. Esas medidas apuntan a los controles correctos. Sin embargo, son compromisos comunicados por el operador, no una verificación independiente de reparación duradera.

La diferencia entre compromiso y prueba no implica desconfianza automática. Define el estándar de evidencia. Una acción puede considerarse implementada cuando existe configuración actual, cobertura de todos los tipos de puerto, resultados de pruebas y telemetría. Puede considerarse resistente cuando supera regresiones entre fabricantes y actualizaciones. Puede considerarse operativamente útil cuando las alarmas se ejercitan y llegan a una persona con autoridad para actuar. Y puede considerarse reversible cuando existe evidencia de rollback y se ha ensayado sin abrir una nueva brecha.

Desplazar tráfico no es reparar la plataforma

Durante el episodio, redes conectadas tomaron medidas para reducir su exposición. Las observaciones congeladas de Total Uptime describen un desplazamiento de tráfico y su posterior restauración. NFOrce informó del cierre de sesiones como medida para mitigar pérdida de paquetes. EDPnet publicó una cronología de impacto del servicio, una afirmación sobre capacidad alternativa y actualizaciones de recuperación. Estos registros contemporáneos ayudan a reconstruir cómo algunos participantes respondieron, pero no permiten extrapolar el mismo resultado a todos.

Esas acciones muestran el valor operativo de los caminos de escape. Una red con tránsito independiente, peering remoto u otra interconexión puede retirar sesiones inestables y mover tráfico. Pero tener una relación contractual alternativa no garantiza que sea utilizable durante una emergencia. Debe existir capacidad suficiente, propagación de rutas adecuada, acceso operativo y autoridad para ejecutar el cambio. Si una organización necesita una aprobación lenta para retirar sesiones, el camino técnicamente disponible puede no servir dentro del intervalo de daño.

La capacidad alternativa también tiene una dimensión económica. Mantener tránsito o peering remoto capaz de absorber una parte significativa de la carga cuesta dinero. Algunas redes pueden justificar esa redundancia por su criticidad; otras pueden depender más intensamente de un intercambio local. El análisis no debe presentar la diversidad como una opción gratuita ni asumir que todos los participantes tienen la misma arquitectura. Sí puede exigir que las dependencias se conozcan y que las afirmaciones de continuidad se prueben con carga realista.

Cuando Total Uptime, NFOrce o EDPnet desplazan tráfico o cambian sesiones, reducen el daño para sus propios clientes y modifican al mismo tiempo los gráficos de AMS-IX. Esa interacción vuelve insuficiente una lectura única del caudal de la plataforma. Una caída puede reflejar pérdida y evacuación; una subida posterior puede reflejar retorno de tráfico y recuperación. Para demostrar restauración de extremo a extremo se necesitan datos de rutas, alcance, pérdida y experiencia de servicio, no solo el agregado del intercambio.

La responsabilidad del participante conectado no sustituye la del operador del fabric. Una red debe probar sus alternativas, pero no debería necesitar usarlas porque una trama link-local de otro cliente cruza una frontera. De forma simétrica, un fabric bien aislado no elimina la necesidad de alternativas, porque existen otras clases de fallo. Resiliencia significa contener perturbaciones internas y ofrecer a los participantes opciones independientes cuando la contención o la plataforma fallan.

Lo que aportan las mediciones de RIPE Atlas

El análisis de RIPE Atlas observó que algunos caminos enrutaron alrededor del daño mientras otros fallaron o cambiaron. Esa diversidad es precisamente la información útil: Internet no responde a una interrupción con un comportamiento universal. La capacidad de rodear el problema depende de la topología, de las relaciones de enrutamiento, de las rutas disponibles, del punto desde el que se mide y del destino seleccionado.

RIPE Atlas aporta visibilidad externa a la plataforma, pero tiene límites. Sus sondas y mediciones no representan a cada usuario, red o aplicación. Un camino observado puede cambiar sin que la aplicación falle; otro puede conservar una ruta nominal mientras su rendimiento empeora. Las mediciones permiten identificar patrones y comparar alcance, pero no completan por sí solas el inventario de impacto.

La combinación más útil es triangular tres capas. Los datos de AMS-IX describen el estado del intercambio: caudal y sesiones. Los avisos de operadores conectados describen decisiones y efectos en redes concretas. Las mediciones de RIPE Atlas muestran cómo ciertos caminos de extremo a extremo cambiaron o dejaron de responder. Ninguna capa debe utilizarse para afirmar más de lo que observa, pero juntas permiten distinguir mejor entre perturbación del fabric, mitigación downstream y recuperación de alcance.

Esa triangulación también ayuda a evaluar futuras reparaciones. Si un ejercicio controlado de fallo mantiene estables las sesiones ajenas, impide que tramas locales crucen puertos y conserva caminos alternativos observables, la evidencia es más fuerte que una mera declaración de configuración. Si las métricas internas parecen normales pero las mediciones externas pierden destinos, la restauración todavía no está completa.

Registros de intención frente a realidad en ejecución

Un punto de intercambio mantiene registros de participantes, sistemas autónomos, interfaces, servicios y configuraciones previstas. Esos registros son esenciales para saber quién estaba conectado, qué relación se había autorizado y qué política debía aplicarse. También permiten reconstruir cambios y asignar la investigación al dominio correcto.

Pero un registro no reenvía paquetes ni bloquea tramas. La realidad operativa durante el incidente estuvo determinada por el código y la configuración efectiva de los switches, el comportamiento de las ACL, el estado de los LAG, las sesiones BGP que permanecieron utilizables y los caminos alternativos que podían transportar tráfico. El caso demuestra por qué la intención documentada debe tratarse como evidencia, no como sustituto de la ejecución.

Una auditoría útil debe comparar ambas capas. Primero, qué decía el inventario sobre el puerto: tipo, servicio, protocolo esperado y filtros previstos. Segundo, qué configuración generó el sistema para cada plataforma. Tercero, qué configuración estaba realmente instalada. Cuarto, cómo procesó el hardware una trama LACP en ese estado. Quinto, qué alarmas se activaron y qué cambios operativos siguieron. La discrepancia entre cualquiera de esas capas identifica una brecha concreta de control.

Este enfoque evita dos errores opuestos. El primero es culpar automáticamente al actor que originó el paquete sin analizar por qué el fabric lo propagó. El segundo es atribuir todo el episodio a un fabricante sin saber qué plantilla, versión o sintaxis estaba desplegada. La rendición de cuentas técnica consiste en mapear control, comportamiento y evidencia, conservando las incógnitas donde los datos públicos no permiten cerrarlas.