Los incidentes de LINX LON2 de 2023 convirtieron el estado real de la red en una prueba de responsabilidad

Resumen

Según LINX, el 20 de junio de 2023 falló una conexión de fibra oscura de LON2. La pérdida inicial no afectó de inmediato a los miembros, pero redujo la resiliencia de la plataforma. El 21 de junio aparecieron descartes detectados por Flowmon, fluctuaciones en enlaces entre switches, pérdida de tráfico y problemas de alcance en la LAN de peering. [1]
LINX indicó que un router recién instalado se había utilizado antes en un laboratorio. Aunque se retiraron la configuración OSPF y el identificador antiguos y se desplegó una identidad nueva mediante NETCONF, el proceso OSPF siguió usando el identificador anterior porque no había sido reiniciado o limpiado. [1]
El operador también observó direcciones MAC presentes en la tabla de software de un equipo de borde pero ausentes de su tabla de hardware. Al limpiar la sesión BGP de la familia L2VPN EVPN entre los VTEP afectados, las entradas volvieron a poblar la tabla física. [1]
La secuencia no permite atribuir todos los síntomas de junio y noviembre a una sola causa. El registro incluye degradación de fibra, estado OSPF retenido, fluctuaciones de enlaces, incoherencias de reenvío, una modificación de software posteriormente revertida y una investigación del proveedor que seguía abierta. [1]
OSPF, BGP, EVPN, VXLAN, NETCONF y el hardware desagregado no son por sí mismos una explicación del fallo. La frontera de responsabilidad está en los controles que comprueban el resultado operacional de su combinación.
El informe anual de LINX situó la disponibilidad de LON2 en el 99,997 %, por debajo de su objetivo interno del 99,998 %. Esa cifra confirma que los incidentes incidieron en el registro agregado del servicio, pero no identifica a cada miembro, ruta, sesión, paquete o consecuencia económica. [2]
Una admisión segura debe demostrar que las identidades activas son únicas, que no queda estado procedente del laboratorio, que el underlay alcanza todos los VTEP relevantes, que las rutas EVPN esperadas existen, que el hardware contiene las entradas necesarias y que las pruebas desde puntos representativos del miembro tienen éxito.
La responsabilidad está distribuida, pero no debe quedar difuminada. LINX controlaba la admisión del dispositivo, la automatización, la operación de la red de intercambio, el aislamiento de enlaces, la limpieza de sesiones y la comunicación del incidente. Los proveedores controlaban partes de la reparación y la investigación técnica. Cada miembro controlaba sus propias sesiones y decisiones de continuidad.
La conclusión no depende de la configuración deseada ni de una cifra de disponibilidad. El registro definitivo es la red en ejecución: identidad observada, estado de protocolo, programación del plano de datos y alcance extremo a extremo.

Una incidencia que comenzó como pérdida de margen

La cronología pública comienza el 20 de junio de 2023 con el fallo de una conexión de fibra oscura en LON2. LINX explicó que ese primer fallo no produjo un impacto inmediato para los miembros, aunque sí redujo la resiliencia. [1] La precisión importa. Decir que el tráfico siguió circulando no equivale a afirmar que la red permaneció en su condición normal. Una ruta redundante había dejado de estar disponible y, con ella, desapareció parte del margen que permitía absorber el siguiente problema.

En infraestructuras críticas es habitual describir la redundancia como una propiedad del diseño: dos fibras, dos equipos centrales, varios enlaces o dos plataformas físicamente separadas. Sin embargo, la redundancia real es un estado operacional. Existe únicamente cuando las rutas alternativas están disponibles, son independientes en la medida prevista, disponen de capacidad suficiente, mantienen un estado coherente y han demostrado que pueden transportar el servicio durante el fallo que se pretende cubrir.

El 21 de junio, LINX registró descartes en Flowmon y fluctuaciones de enlaces entre switches. A continuación se observaron pérdida de tráfico y problemas de alcance en la LAN de peering. Los ingenieros deshabilitaron enlaces para recuperar parcialmente el servicio y después deshabilitaron una agregación entre dispositivos centrales como solución temporal para restablecerlo de forma más amplia. El 22 de junio todavía persistían problemas para alcanzar determinadas direcciones IP. [1]

La secuencia muestra varias etapas que no deben comprimirse en una sola hora de “restauración”. Hubo una condición inicial de menor resiliencia, un deterioro posterior, una recuperación parcial, una intervención más amplia y una cola de casos residuales. Cada etapa tenía un estado de riesgo distinto. La red podía estar disponible para gran parte de los miembros y, al mismo tiempo, seguir siendo incapaz de reenviar tráfico hacia destinos concretos.

LINX señaló que, en esos casos residuales, ciertas direcciones MAC figuraban en la tabla de software de un equipo de borde, pero no en su tabla de hardware. La limpieza de la sesión BGP L2VPN EVPN entre los VTEP afectados hizo que las entradas volvieran a aparecer en la tabla física. [1] Ese dato desplaza la investigación desde el simple estado administrativo de los enlaces hacia la relación entre el plano de control y el plano de reenvío.

No es correcto convertir la cronología en una historia en la que una fibra rota provocó automáticamente todo lo demás. Tampoco está justificado hacer del identificador OSPF duplicado una explicación universal. La evidencia pública describe una interacción entre resiliencia física degradada, identidad de protocolo, topología entre switches, señalización EVPN y programación de hardware. La responsabilidad consiste precisamente en conservar esas distinciones mientras se reconstruye el funcionamiento conjunto.

El cambio de régimen cuando la red ya está degradada

Una red que ha perdido una ruta física importante debería entrar en un régimen especial de operación. El servicio puede seguir disponible, pero la tolerancia frente a nuevos cambios se reduce. En esa situación, una activación que sería ordinaria con la topología completa puede adquirir un riesgo diferente.

El primer control debe ser la visibilidad. La condición degradada no debería quedar confinada a un ticket de proveedor, un canal de mensajería o la memoria del equipo de guardia. Debe reflejarse en la fuente operacional de verdad y ser consultable por los sistemas de cambio. Si una herramienta programa la activación de un router mientras una ruta de fibra está fuera de servicio, debe poder reconocer que el entorno real ya no coincide con el diseño nominal.

El segundo control es la relación entre dependencias. Una fibra, una agregación, un enlace entre switches, una loopback de VTEP y una sesión EVPN pertenecen a capas distintas, pero pueden converger en la misma ruta que transporta el tráfico de un miembro. La gestión del cambio debe identificar qué componentes cargan ahora el tráfico protegido y qué prueba demostrará que la alternativa funciona de verdad.

El tercer control es una prueba canaria representativa. No basta con confirmar que el router responde por su interfaz de gestión o que el protocolo establece una vecindad en una topología simplificada. Si el riesgo se encuentra en la ruta que queda después de perder una fibra, la prueba debe atravesar esa ruta. Si el riesgo incluye la programación de una tabla física, el canario debe enviar tráfico cuya entrada haya sido comprobada tanto en software como en hardware.

El cuarto control es una condición de parada definida de antemano. Una identidad OSPF duplicada, una vecindad inesperada, un VTEP antiguo, una fluctuación de enlaces, un aumento de descartes o una entrada MAC que no llegue al hardware deben detener la activación. Sin criterios previos, el equipo puede verse obligado a negociar durante el incidente si una señal es suficientemente grave.

El quinto control es la autoridad de reversión. Debe estar claro quién puede aislar el dispositivo, limpiar el proceso, retirar un enlace, revertir una versión o suspender el cambio. La responsabilidad operacional no se completa con una alarma; necesita una persona o función con autoridad para actuar y una prueba que determine cuándo la acción ha terminado.

Los materiales públicos no permiten afirmar qué controles concretos aplicó LINX antes de cada paso. Estas son exigencias derivadas de la clase de riesgo documentada, no acusaciones sobre procedimientos internos que no se han publicado. La lección general es más sólida cuando se mantiene dentro de ese límite.

La frontera entre laboratorio y producción

Los laboratorios existen para reutilizar equipos, cambiar topologías, ensayar configuraciones y provocar estados que no serían aceptables en producción. Esa flexibilidad es útil, pero convierte todo dispositivo procedente del laboratorio en portador potencial de estado residual.

LINX informó de que el router instalado en LON2 había tenido anteriormente la misma identidad que otro router ya presente en producción. Según su relato, se eliminaron la configuración OSPF y el identificador antiguos y se desplegó un identificador nuevo mediante NETCONF. A pesar de ello, el proceso OSPF siguió utilizando la identidad previa porque el proceso no se había limpiado. [1]

La diferencia es fundamental. El sistema de configuración podía contener el valor nuevo. La transacción NETCONF podía haber finalizado correctamente. El repositorio podía mostrar el cambio deseado. Ninguno de esos registros demostraba que el proceso OSPF activo hubiera descartado el valor anterior.

Un dispositivo puede conservar información en varios lugares: procesos residentes, bases de adyacencias, tablas de reenvío, archivos de arranque, credenciales, caches, asociaciones de túneles o estados creados por automatización de laboratorio. No todos los equipos ni todos los sistemas operativos se comportan igual. Por eso una política de admisión no debe limitarse a una lista genérica de comandos; debe definir qué estado puede persistir en la plataforma concreta y cómo se demuestra que ha sido eliminado o sustituido.

La frontera segura comienza con una identidad inequívoca del activo: hardware, versión de software, imagen, configuración de origen, función de producción y todos los identificadores que usará. Debe quedar registrado si el equipo se reconstruyó, reinició o saneó y qué estado estaba previsto que sobreviviera.

Después viene la verificación desde la propia red. El router candidato debe declarar su identidad activa, pero sus vecinos también deben mostrar la identidad que observan. La fuente de verdad debe compararse con ambos lados. Si se cambió un identificador que un proceso solo adopta después de una limpieza, un reinicio o un reboot, esa acción debe formar parte explícita del contrato de despliegue.

La admisión también debe buscar pruebas negativas. No tiene que limitarse a confirmar que el identificador esperado existe; debe demostrar que el anterior ya no existe y que no hay duplicados en el dominio. Del mismo modo, debe confirmar la ausencia de vecinos de laboratorio, VTEP antiguos, VLAN no autorizadas, route targets imprevistos, credenciales temporales y entradas que solo aparezcan en una representación de software.

Esta disciplina no reduce el valor de la automatización. Lo amplía. NETCONF y otras herramientas pueden aplicar configuraciones de forma repetible, pero una automatización responsable define el éxito mediante poscondiciones. Un cambio no termina cuando el dispositivo acepta bytes; termina cuando la red en funcionamiento muestra la identidad, las adyacencias y el reenvío previstos.

La identidad OSPF como recurso operacional

OSPF utiliza un router ID de 32 bits para identificar al router que origina información dentro del dominio de enrutamiento. RFC 2328 establece ese papel de identificación y, por tanto, hace de la unicidad una propiedad funcional, no una preferencia estética. [11] Dos procesos que se presentan con la misma identidad pueden comprometer la interpretación de anuncios de estado de enlace y la asociación entre un origen lógico y el dispositivo que realmente opera.

La documentación técnica de Juniper clasifica la duplicación de router IDs entre las anomalías críticas que deben detectarse y destaca la necesidad de mantener identificadores únicos. [18] Esa referencia explica el principio operacional. No demuestra qué fabricante suministró el equipo de LINX ni permite atribuir el incidente a un proveedor concreto. La evidencia del caso procede del relato de LINX y debe seguir atribuida a él.

Una base de inventario puede asignar identificadores únicos y aun así no impedir que un proceso activo mantenga un valor antiguo. Esta es una expresión clara de la primacía del estado ejecutado: el registro administrativo es necesario, pero no gobierna por sí solo el protocolo que está corriendo.

Por ello, el control de identidad debe abarcar cuatro observaciones. Primero, el valor previsto en la fuente de verdad. Segundo, el valor local que informa el proceso. Tercero, la identidad que ven los vecinos. Cuarto, una comprobación de duplicados en todo el ámbito relevante. Si alguna de estas vistas discrepa, el dispositivo no está preparado para transportar tráfico.

La misma lógica se aplica a otros recursos de identidad: ASN, direcciones de loopback, direcciones de la LAN de peering, VTEP, MAC, interfaces y sesiones BGP. Cada identificador debe tener un mecanismo de asignación, una comprobación de unicidad, una autoridad de cambio y una forma de reconciliar el registro con la realidad.

No todos esos recursos producen el mismo tipo de fallo. Un ASN incorrecto, una loopback duplicada y un router ID repetido tienen consecuencias distintas. Sin embargo, comparten una exigencia de gobierno: el operador debe saber quién asignó el valor, qué sistema lo impone, cómo se detecta el conflicto y qué evidencia demuestra que la corrección llegó al proceso activo.

En este sentido, el inventario funciona como libro mayor y no como soberano. Puede describir con precisión la intención, pero la red determina qué identidad existe operacionalmente. La autoridad del registro nace de su reconciliación continua con el código y el estado en ejecución.

EVPN y VXLAN: separar capas sin separar la responsabilidad

LINX presentó LON2 como una arquitectura leaf-spine desagregada basada en EVPN sobre VXLAN. Sus materiales describen la evolución de la plataforma y el uso de automatización en una red de intercambio distribuida entre varios emplazamientos. [3][4][5][6]

VXLAN permite transportar segmentos Ethernet sobre una red IP mediante encapsulación entre puntos terminales de túnel. RFC 7348 define ese mecanismo. [13] EVPN utiliza BGP para distribuir información de alcance del overlay; RFC 7432 define EVPN y RFC 8365 describe su aplicación a overlays de virtualización, incluido VXLAN. [14][15] BGP aporta el marco de intercambio de información entre sistemas de enrutamiento, aunque el comportamiento concreto de una familia EVPN debe evaluarse dentro de su arquitectura. [12]

En una simplificación útil, el underlay debe proporcionar alcance IP estable entre los VTEP. El plano EVPN distribuye información que permite localizar direcciones MAC o IP y asociarlas con destinos del overlay. El dispositivo debe convertir después esa información en entradas que el hardware pueda utilizar para reenviar paquetes.

La separación mejora la escala y la automatización, pero genera varias superficies de comprobación. El underlay puede estar establecido mientras un VTEP concreto no es alcanzable por la ruta esperada. La sesión BGP puede estar activa mientras falta una ruta EVPN necesaria. La tabla de software puede mostrar una dirección MAC y el circuito físico de reenvío puede carecer de ella. Una consola de gestión puede ofrecer una imagen razonable mientras el paquete toma una decisión diferente.

El incidente de LON2 proporciona un ejemplo concreto y acotado. LINX afirmó que algunas direcciones MAC aparecían en la tabla de software de un equipo de borde, pero no en la tabla de hardware. Tras limpiar la sesión BGP L2VPN EVPN entre los VTEP afectados, la tabla física volvió a poblarse. [1]

Ese hecho no prueba que EVPN o VXLAN sean intrínsecamente inseguros. Tampoco demuestra un defecto universal del protocolo BGP. Muestra que, en el caso descrito, una vista del plano de control no bastaba para acreditar el reenvío. La prueba de cierre debía llegar al plano de datos.

RFC 9062 resulta pertinente porque aborda requisitos de operación, administración y mantenimiento para EVPN y la necesidad de mecanismos que permitan relacionar el estado del plano de control con el comportamiento del plano de datos. [17] La RFC no identifica el defecto de implementación de LON2. Sí respalda la necesidad de una disciplina de verificación que detecte divergencias entre lo aprendido y lo efectivamente reenviado.

Los mecanismos de detección rápida, como BFD, pueden ayudar a observar fallos de conectividad con mayor rapidez en determinados diseños, pero su presencia tampoco certifica toda la cadena de servicio. RFC 5880 define BFD; no convierte una sesión activa en prueba de que cada entrada MAC o cada destino del miembro sea alcanzable. [16]

La arquitectura, por tanto, debe ser evaluada como una cadena. Identidad OSPF, alcance de loopbacks, adyacencias, sesiones EVPN, rutas, asociaciones VNI, tablas MAC, programación física y pruebas de paquetes describen partes distintas de una misma realidad. Separar capas es una decisión técnica; separar su responsabilidad hasta que nadie sea dueño del resultado extremo a extremo es un fallo de gobierno.

Cuando la tabla de software promete más que el hardware

Una tabla de software suele representar lo que el sistema operativo de red cree haber aprendido o calculado. La tabla de hardware representa el estado que el ASIC u otro componente de reenvío puede utilizar para decidir el destino de un paquete. En condiciones normales ambas vistas deberían ser coherentes para las entradas relevantes.

La presencia de una dirección en software puede producir una sensación de normalidad. El operador consulta la tabla, encuentra la MAC y concluye que el aprendizaje se ha completado. Sin embargo, si la entrada no se programó en hardware, el paquete no necesariamente seguirá la ruta que sugiere la consola.

Esto explica por qué un control de admisión debe contener reconciliación, no solo inspección. La pregunta no es “¿existe la MAC?”, sino “¿aparece en todas las capas donde debe existir y el tráfico real confirma esa programación?”. Para una selección representativa de direcciones, la evidencia debería vincular la ruta EVPN, la entrada de software, la entrada física y una prueba de reenvío.

La selección debe cubrir las combinaciones que pueden revelar un fallo: distintos leaf, VTEP, dominios de bridge, VNI y rutas físicas. Un canario que utiliza un camino simplificado puede pasar aunque la combinación problemática permanezca sin probar. Esto es especialmente importante cuando la red ya funciona con una fibra degradada y el tráfico está atravesando alternativas que normalmente tendrían menos carga o menor exposición.

El cierre tampoco puede descansar en una sola prueba de ping. Una LAN de peering transporta tráfico diverso. Las verificaciones deben ser bidireccionales y, cuando proceda, cubrir distintos tamaños de paquete, protocolos y destinos. Deben incluir los casos que fallaron, no únicamente una muestra genérica de salud.

El hecho de que una limpieza de sesión repueble una tabla es una observación de recuperación, pero no siempre equivale a una explicación causal completa. El expediente debe registrar qué sesión se limpió, qué entradas cambiaron, qué tráfico volvió a funcionar, qué hipótesis justificó la acción y si la estabilidad persistió. De otro modo, una intervención eficaz puede convertirse en ritual sin que la organización sepa qué condición corrigió.

Los episodios de junio y noviembre no son una única historia causal

La actualización de LINX registra problemas adicionales de alcance el 29 de junio y otro episodio el 5 de noviembre, después de trabajos de mantenimiento realizados por el proveedor de fibra oscura. También menciona una modificación de software destinada a abordar el comportamiento de la tabla MAC de hardware, su posterior reversión tras la incidencia de noviembre y la continuidad de la investigación del proveedor. [1]

Estas observaciones refuerzan la necesidad de controles duraderos, pero no autorizan a fusionar todos los episodios en una sola causa cierta. Dos incidencias pueden presentar el mismo síntoma externo —por ejemplo, pérdida esporádica de alcance— y proceder de mecanismos internos diferentes. También pueden compartir parte de una cadena sin compartirla entera.

El identificador OSPF retenido es una observación concreta de junio. La ausencia de determinadas MAC en hardware es otra observación concreta. La secuencia de noviembre incluye mantenimiento de fibra, una modificación de software, reversión e investigación pendiente. La narración responsable conserva cuál de estos elementos fue observado, cuál fue una hipótesis y qué acción estaba destinada a cada uno.

Durante una recuperación urgente, es razonable ejecutar varias intervenciones: aislar enlaces, limpiar sesiones, reiniciar procesos, cambiar software o reiniciar equipos. El servicio puede volver antes de que sea posible aislar la acción decisiva. Esa prioridad operacional no elimina la obligación posterior de distinguir recuperación de causalidad.

Cada medida correctiva debe asociarse a una hipótesis verificable. Si se cree que un proceso OSPF conserva una identidad antigua, la predicción es que, tras limpiarlo, todos los participantes observarán una identidad única. Si se sospecha una divergencia de programación, la predicción es que las entradas aparecerán de forma coherente en software y hardware y que las pruebas de paquetes tendrán éxito. Si la preocupación es la fibra degradada, debe restaurarse la diversidad física y superarse una prueba controlada de fallo.

Una investigación abierta del proveedor significa que el trabajo técnico no ha concluido. No demuestra negligencia, incumplimiento contractual ni ocultación. Mantener esa frontera no debilita la responsabilidad: obliga a formular conclusiones que la evidencia realmente puede sostener.

El 99,997 % no describe a cada miembro

El informe anual de LINX señala que LON2 alcanzó una disponibilidad del 99,997 % en 2023, por debajo del objetivo interno del 99,998 %, y atribuye la diferencia a varias interrupciones. [2] La proximidad entre ambas cifras puede parecer pequeña, pero la cuestión operacional no es únicamente cuántos nueves contiene el porcentaje.

Toda cifra agregada depende de un denominador, una ventana temporal, una definición del servicio, puntos de observación y reglas para excluir mantenimiento. Sin esos elementos, el porcentaje no permite saber qué experiencia tuvo un miembro concreto.

Una plataforma puede mantener la mayoría de sus puertos activos mientras un subconjunto de destinos deja de ser alcanzable. El tráfico total puede seguir siendo elevado porque los participantes no afectados enmascaran la caída de otros. Las sesiones con route servers pueden permanecer establecidas aunque exista un problema selectivo en el reenvío. Una alarma física puede estar verde mientras faltan entradas en hardware.

Por eso la disponibilidad de una red EVPN de peering debe poder descomponerse en evidencias más cercanas al servicio: alcance entre puntos representativos del miembro, continuidad de las sesiones pertinentes, pruebas del overlay, observación de rutas, consistencia de tablas y confirmación del reenvío. Los route servers simplifican determinadas relaciones de peering, pero no sustituyen la validación del camino de datos ni revelan por sí solos el diseño de continuidad de cada participante. [7][8][9]

Los términos de un servicio pueden definir obligaciones y límites contractuales, pero la existencia de un documento contractual no permite inferir daños, créditos o responsabilidades para un incidente concreto sin el expediente correspondiente. [10] Del mismo modo, un porcentaje anual no puede transformarse en una estimación de transacciones perdidas o perjuicios financieros por miembro.

Esto no exige divulgar topologías privadas, datos confidenciales o todos los tickets. Un operador puede conservar evidencia restringida y publicar conclusiones acotadas: qué clase de servicio se vio afectada, cómo se midió, qué alcance se verificó, qué permaneció desconocido y con qué confianza se cerró la incidencia.

Un registro de admisión que pueda ser auditado

La admisión segura de un router usado en laboratorio necesita un registro reproducible. Otra persona cualificada debería poder reconstruir qué dispositivo entró, con qué estado, bajo qué condiciones y con qué pruebas.

El primer bloque identifica el activo. Debe incluir hardware, software, imagen, checksums pertinentes, configuración de origen, función de producción, interfaces, identificadores de protocolo y dependencias físicas. También debe señalar el procedimiento de saneamiento y qué información persistente podía sobrevivir.

El segundo bloque verifica la identidad. El registro debe contener el router ID OSPF previsto, el valor que informa el proceso activo y los valores observados por los vecinos. Debe incorporar una búsqueda de duplicados en el dominio. Si el cambio requiere limpiar un proceso, reiniciarlo o reiniciar el equipo, esa transición debe quedar registrada junto con el restablecimiento correcto de las adyacencias.

El tercer bloque valida el underlay. Las loopbacks de los VTEP deben ser alcanzables por las rutas esperadas. Interfaces, métricas y agregaciones deben coincidir con la topología autorizada. La prueba debe incluir la condición de fallo relevante: si una ruta de fibra está ausente, el camino restante debe transportar el tráfico previsto sin descubrir una dependencia oculta.

El cuarto bloque valida el overlay. El equipo debe anunciar y aprender la información EVPN esperada. Route targets, dominios de bridge y asignaciones de VNI deben compararse con la fuente de verdad. Una ruta inesperada, una MAC antigua o un VTEP de laboratorio deben bloquear la entrada en producción.

El quinto bloque reconcilia reenvío. Las entradas seleccionadas deben aparecer en las vistas de software y hardware cuando la plataforma las exponga. Después debe enviarse tráfico por las combinaciones relevantes de leaf y VTEP. Una tabla de software sin prueba física es insuficiente, precisamente porque el relato de LINX documenta esa clase de divergencia.

El sexto bloque contiene pruebas negativas. No debe existir un router ID duplicado, una vecindad no prevista, un VTEP residual, una VLAN no autorizada, un route target ajeno, una entrada restringida a software ni una credencial de laboratorio. Las comprobaciones negativas suelen recibir menos atención porque son más difíciles de automatizar, pero la frontera de admisión existe en gran parte para probar la ausencia de residuos peligrosos.

El séptimo bloque vincula monitorización y autoridad. Flowmon, estado de enlaces, sesiones, alertas de programación física y sondas orientadas al miembro deben identificar el dispositivo y sus dependencias. Cada alerta necesita un propietario y cada condición crítica una autoridad de rollback.

El octavo bloque define el canario. Debe ser limitado, pero representativo de la arquitectura. Una prueba que evita EVPN, el camino alternativo o la tabla física no ensaya la superficie relevante. La carga puede limitarse; la fidelidad del recorrido no.

El noveno bloque compara intención y observación. Debe preservar checksums, salidas de comandos, vistas de vecinos, resultados de sondas, telemetría, tiempos y decisión final. Si se aceptó una excepción, tiene que constar su propietario, duración, justificación y control compensatorio.

El objetivo no es producir más documentación. Es hacer que “despliegue correcto” sea una conclusión demostrable. Una lista de comprobación cumplimentada sin relación con el estado real sería otra representación administrativa que podría divergir de la red.

La restauración debe demostrarse desde el borde

Una alarma del núcleo puede indicar que un enlace está estable. OSPF puede mostrar adyacencias. BGP puede mostrar una sesión EVPN establecida. La tabla física puede contener una entrada. Ninguna de estas observaciones aisladas demuestra que un miembro alcance el destino esperado.

La restauración necesita una perspectiva de fuera hacia dentro. Las sondas deben originarse en puntos orientados al miembro o en ubicaciones externas representativas y atravesar los caminos afectados. Deben verificar alcance bidireccional y repetir el patrón que falló.

La segmentación es esencial. Si el 22 de junio persistían problemas para direcciones IP específicas, una prueba general de salud podía aprobar mientras esos casos seguían abiertos. El cierre tenía que comprobar la clase exacta del fallo mediante la combinación apropiada de MAC, ARP o vecindad IP, rutas EVPN, estado físico y paquetes.

Los informes de miembros también forman parte de la evidencia, aunque no son la única fuente. Un participante puede observar un problema que la telemetría central no detecta. A la inversa, un fallo de aplicación o de la red del miembro puede parecer una incidencia del intercambio. Marcas temporales compartidas, información de rutas y pruebas desde ambos lados ayudan a distinguirlos.

El registro debe conservar la diferencia entre recuperación parcial y completa. Deshabilitar enlaces puede recuperar gran parte del servicio sin resolver todos los casos. Un único tiempo de restauración puede ocultar la etapa durante la cual la red funcionaba en términos generales, pero ciertos destinos continuaban inaccesibles.

Un cierre responsable declara qué se restauró, desde qué puntos se verificó, qué muestra se utilizó y qué seguía bajo investigación. No promete una recuperación universal a partir de una observación estrecha.

La información pública disponible sobre LON2 no identifica a todos los miembros, sus sesiones, sus prefijos ni sus diseños de continuidad. PeeringDB proporciona contexto público sobre el intercambio, pero no sustituye el expediente del incidente ni prueba el comportamiento de cada participante durante esos episodios. [20]

Responsabilidad distribuida sin inventar culpables

LINX operaba la red de intercambio y controlaba el proceso por el que el router entró en ella. Sus superficies directas incluían la admisión del dispositivo, la automatización, la secuencia de mantenimiento, la monitorización, el aislamiento de enlaces, la limpieza de sesiones y la comunicación sobre el servicio.

Los proveedores de fibra controlaban las tareas físicas comprendidas en su ámbito. Los proveedores de equipos o software controlaban el análisis de defectos y las correcciones disponibles. El expediente público solo permite atribuirles lo que LINX declaró. Una investigación abierta no es una resolución de responsabilidad jurídica.

Los miembros controlaban sus puertos, sus sesiones BGP y sus opciones de continuidad. Algunos podían usar route servers, acuerdos bilaterales, LON1, LON2, otros intercambios o tránsito. La documentación general de los servicios de LINX explica esas posibilidades, pero no revela la arquitectura de cada miembro durante el incidente. [4][7][8]

Tener más de un servicio tampoco garantiza independencia. Dos conexiones pueden compartir una ruta física, un equipo, un edificio o una dependencia operacional. No se puede asumir que cada participante disponía de una alternativa efectiva ni que todos sufrían la misma exposición.

La responsabilidad puede solaparse. La pregunta útil no es solo quién “causó” el incidente, sino quién controlaba cada decisión y cada evidencia:

¿Quién sabía que la fibra estaba degradada?
¿Quién podía posponer la activación?
¿Quién verificó la identidad OSPF activa?
¿Quién tenía autoridad para limpiar el proceso?
¿Quién comparó las tablas de software y hardware?
¿Quién probó el alcance desde el borde?
¿Quién podía revertir la modificación?
¿Quién comunicó los casos residuales?

Una matriz de este tipo asigna acciones sin convertir el análisis técnico en una conclusión de negligencia. También revela vacíos. Si cada propietario certifica su componente, pero nadie es responsable de la prueba extremo a extremo, todos pueden cerrar su ticket mientras el servicio sigue fallando.

La comunicación pública debe respetar la misma separación. Los informes de LINX sostienen afirmaciones atribuidas sobre lo observado y ejecutado. Las RFC explican protocolos. La documentación de fabricantes aporta orientación general. Ninguna de esas fuentes revela por sí sola contratos privados, pérdidas completas o una norma jurídica de diligencia.

Un modelo de evidencia para incidentes recurrentes

La gestión de recurrencias requiere paquetes de evidencia versionados. Cada medida correctiva debería identificar una hipótesis, un cambio observable esperado y una prueba de confirmación.

Para la identidad OSPF retenida, la hipótesis es que el proceso activo siguió usando el router ID anterior. El resultado esperado es una identidad única después de la transición necesaria. La evidencia combina el estado local, la visión de los vecinos, la búsqueda de duplicados y la correcta reconstrucción de adyacencias.

Para la divergencia de MAC, la hipótesis se refiere a la sincronización o programación entre el plano de control y el reenvío. El resultado esperado es la presencia coherente de las entradas seleccionadas y el paso correcto de paquetes. La evidencia enlaza tablas de software, tablas físicas, estado EVPN y sondas.

Para la fibra degradada, la hipótesis se refiere a la pérdida de diversidad y al comportamiento del tráfico en los enlaces restantes. El resultado esperado es la restauración del camino físico y una prueba de conmutación satisfactoria. La evidencia incluye mapas de rutas, estado óptico, capacidad, agregaciones y pruebas controladas.

Para una modificación de software, la hipótesis debe describir el síntoma que pretende corregir. Haber instalado una versión no demuestra que el defecto haya desaparecido. Una reversión posterior es evidencia relevante, pero tampoco prueba por sí sola que el cambio causara todos los síntomas. Deben conservarse versiones, tiempos de activación, observaciones antes y después, hora de rollback y resultados posteriores.

Todos los paquetes necesitan una línea temporal común. Sin sincronización, un equipo puede relacionar un evento de protocolo con una pérdida de tráfico que ocurrió antes o después. Debe distinguirse el tiempo del suceso, el tiempo de observación y el tiempo de la intervención.

Este modelo permite comparar episodios sin aplanarlos. Si un caso posterior reproduce la misma divergencia física bajo condiciones equivalentes, aumenta la confianza en un mecanismo compartido. Si solo reaparece el síntoma externo, la confianza debe mantenerse más baja. La organización puede aprender sin fingir certeza.

Métricas que reflejen el funcionamiento de la red

La tasa de despliegues exitosos y el tiempo medio de recuperación son útiles, pero incompletos. Una herramienta puede declarar éxito mientras un proceso conserva estado antiguo. Un promedio de recuperación puede mejorar aunque algunos destinos permanezcan inaccesibles.

Un programa de admisión debería medir fallos de poscondición:

frecuencia con la que la identidad prevista difiere de la identidad activa;
dispositivos que requieren una limpieza o reinicio no planificados;
duplicados detectados antes de activar tráfico;
vecinos, rutas o VTEP residuales;
discrepancias entre tablas de software y hardware;
fallos de sondas representativas durante el canario.

También debe medirse la exposición en estado degradado: cuánto tiempo funciona la red sin la diversidad prevista, cuántos cambios se ejecutan durante ese periodo, quién acepta el riesgo y qué pruebas representativas acompañan a cada cambio.

La verificación del borde merece métricas propias. Conviene registrar cuánto tardó la restauración amplia, cuánto tardaron los casos residuales y qué proporción de la superficie afectada se probó desde puntos representativos.

La integridad de la evidencia es otra medida operacional. Un cierre puede evaluar si contiene telemetría sincronizada, topología, identidad, estado de protocolo, reenvío físico, sondas, responsables y límites de confianza. La finalidad no es premiar el volumen documental, sino identificar qué conclusiones el operador no pudo demostrar.

Estas métricas pueden degenerar en teatro si el equipo optimiza el número de comprobaciones sin mejorar la red. El antídoto es comparar los controles con incidentes reales, revisar muestras de manera independiente y preguntar si las divergencias se detectaron antes de que lo hicieran los miembros.

Lo que el expediente público no demuestra

Las fuentes disponibles no identifican a todos los miembros, prefijos, sesiones, emplazamientos o volúmenes de tráfico afectados. Tampoco proporcionan una duración completa para cada problema de alcance.

No publican la configuración privada, el estado completo del proceso, la transacción detallada de automatización, toda la base de reenvío ni el expediente del proveedor.

No demuestran que el router ID duplicado fuera la única causa de cada síntoma de junio y noviembre.

No demuestran que EVPN, VXLAN, OSPF, BGP, NETCONF, la automatización o el hardware desagregado sean inherentemente inseguros.

No permiten identificar a un proveedor concreto como causante del incidente salvo en la medida exacta en que LINX atribuyó determinadas tareas o investigaciones.

El 99,997 % de disponibilidad no demuestra un total de impacto por cliente ni autoriza a calcular pérdidas económicas.

El registro tampoco establece negligencia, incumplimiento contractual, ocultación o una infracción de un estándar legal por parte de LINX, de un proveedor o de una persona.

Estos límites no son reservas decorativas. Determinan la confianza de las conclusiones. La mejor forma de defender una tesis técnica es mantenerla dentro de la evidencia: el estado pretendido y el estado en ejecución divergieron; el plano de software y el hardware no coincidieron en los casos descritos; la red operó con menor resiliencia; y la verificación tuvo que alcanzar el camino real de paquetes.

La red en ejecución es el registro final

La lección de LON2 no es que un laboratorio sea peligroso por definición ni que las arquitecturas modernas sean demasiado complejas. Es que el paso de intención a operación debe demostrarse.

Un repositorio puede contener un router ID nuevo. NETCONF puede entregarlo. El inventario puede asociar correctamente un dispositivo con una función. El plano EVPN puede mostrar una MAC aprendida. Una sesión BGP puede estar activa. Un panel anual puede mostrar una disponibilidad muy próxima al cien por cien. Todos esos registros pueden ser ciertos mientras el paquete sigue una realidad diferente.

El registro final es la red en funcionamiento: identidades únicas observadas en el dominio, adyacencias actuales, loopbacks alcanzables, estado EVPN coherente, entradas programadas en hardware, rutas físicas estables y pruebas completas desde puntos representativos del miembro.

Ese estándar no compite con la automatización. La hace más fiable. La respuesta a un proceso que conserva estado no es abandonar las herramientas y regresar a una operación puramente manual. Es ampliar el contrato del despliegue para que incluya el reinicio necesario, la verificación remota y el bloqueo automático ante cualquier discrepancia.

En un punto de intercambio, la obligación es especialmente clara. El operador no controla la política de cada red participante, pero sí puede demostrar el estado de la infraestructura compartida. Puede registrar que una ruta está degradada, rechazar identidades duplicadas, reconciliar control y reenvío, probar caminos representativos y declarar honestamente qué permanece sin resolver.

El relato de LINX es valioso porque ofrece detalles suficientes para formular esa disciplina sin convertirlos en una acusación simplista. Identifica la pérdida inicial de resiliencia, la identidad OSPF retenida, la diferencia entre tablas de software y hardware, las medidas temporales, los episodios posteriores y la investigación todavía abierta. [1][2]

Los nombres de arquitectura no garantizan continuidad. Una ruta redundante que nunca se ha ejercitado es una promesa. Una identidad nueva que solo existe en la configuración es una promesa. Una MAC presente únicamente en software es una promesa. La responsabilidad comienza cuando el operador puede demostrar, mediante el estado real de la red, que esas promesas se convirtieron en reenvío efectivo de paquetes.