Resumen

  • MIX escribió el 26 de junio de 2025 que un operador preparado debería absorber el fallo de un IX mediante recursos como tránsito con margen suficiente y una estrategia de peering diversificada [1].
  • La misma nota advierte que la inestabilidad frecuente puede generar riesgo mediante la convergencia de rutas y la reconvergencia del tráfico, aunque la LAN no sea por diseño un punto único de fallo [1].
  • La documentación del route server de MIX registra el ASN 61968, listas de prefijos derivadas de IRR, controles del AS_PATH, rechazo de rutas RPKI INVALID y comunidades para controlar la distribución [2].
  • Esos controles deciden qué rutas se comparten; no crean capacidad alternativa, no sustituyen la diversidad física ni prueban que una aplicación siga disponible.
  • La evidencia debe unir diseño y ejecución: retirada, nueva selección, tráfico desplazado, margen restante y resultado visible para el usuario.

Lo que MIX sostuvo, y lo que no sostuvo

La nota de MIX no afirma que un intercambio nunca pueda interrumpirse. Afirma que una red correctamente preparada no debería depender de una sola LAN para toda su conectividad. Como ejemplos, cita capacidad de tránsito sobredimensionada y diversidad de peering [1]. El participante conserva, por tanto, una parte decisiva de la continuidad.

Un IX ofrece un entorno común para intercambiar rutas y tráfico. Los miembros siguen siendo sistemas autónomos: eligen proveedores, interconexiones privadas, preferencias BGP y límites de capacidad. Tener una segunda ruta en la tabla no demuestra que vaya a ser seleccionada a tiempo, que acepte todos los prefijos necesarios o que soporte la carga desplazada.

MIX añade que los fallos frecuentes pueden afectar la convergencia de rutas y la reconvergencia del tráfico en entornos grandes [1]. Ese es el punto que vuelve auditable la resiliencia. Muchas sesiones pueden cambiar a la vez, y las salidas alternativas pueden recibir una carga correlacionada que no aparece en una prueba de un solo enlace.

La alternativa de topología no basta

La continuidad debe probarse como una transición entre estados. Antes del cambio, el operador necesita un inventario de sesiones externas, rol comercial, rutas esperadas, local preference, comunidades, controles de máximo de prefijos y capacidad disponible. También debe identificar qué camino recibirá el tráfico si desaparece la conectividad del intercambio.

Durante el cambio, debe conservar tiempos de estado de sesión, retiradas, anuncios alternativos, decisión BGP y movimiento de tráfico. Después, debe verificar pérdida, latencia, congestión, estabilidad de rutas y éxito de las aplicaciones. Decir que el tráfico cambió de camino solo describe una intención si no hay mediciones.

La diversidad aparente también puede compartir fallos. Dos circuitos pueden depender del mismo router, suministro eléctrico, recorrido de fibra o proceso de control. Dos salidas diferentes pueden estar dimensionadas con la misma suposición demasiado optimista. La prueba tiene que cubrir esas dependencias y una carga simultánea realista.

LAN compartida y route server no son lo mismo

MIX ofrece un route server para simplificar el peering multilateral. La documentación actual identifica el ASN 61968. Los prefijos válidos se obtienen de bases IRR, el primer ASN del camino debe coincidir con el participante y se rechazan varias clases de rutas o AS inválidos. MIX también indica que las rutas RPKI INVALID se rechazan [2].

Las comunidades permiten decidir a qué participantes se anuncia una ruta. El tráfico no atraviesa el route server: fluye directamente entre vecinos de la LAN, y el ASN del servidor no aparece en el AS_PATH [2]. El RFC 7947 explica este patrón de interconexión multilateral [4].

El alcance de estos controles debe mantenerse exacto. IRR y RPKI ayudan a validar anuncios. Las comunidades expresan decisiones de exportación. Ninguno garantiza el transporte de la LAN, crea tránsito de respaldo o controla todas las sesiones bilaterales. Por eso el análisis separa el fabric, el plano de control multilateral y las rutas propias de cada miembro.

Evidencia que corresponde al intercambio

MIX debería poder reconstruir la salud y configuración de conmutadores, enlaces internos, puertos de miembros y procesos del route server. En la LAN interesan errores de interfaz, cambios de topología, comportamiento ARP o Neighbor Discovery, volumen de broadcast, protección del plano de control y alcance de puertos afectados.

En el route server interesan el estado de sesiones, el número de rutas aceptadas y rechazadas, la versión de política, la frescura de IRR y RPKI, las comunidades y la tasa de actualizaciones. Una vista externa debe alinearse con estos registros porque una consola interna puede parecer normal mientras un miembro observa pérdida parcial o rutas inestables.

Una comunicación pública puede preservar la seguridad y seguir siendo útil. Puede indicar la superficie afectada, el intervalo, la clase de control, el alcance, la reparación duradera y la prueba negativa. No necesita revelar una configuración completa.

Evidencia que corresponde al participante

El miembro debe demostrar si un cambio en el IX llegó al cliente. El expediente de rutas debe mostrar qué caminos del intercambio desaparecieron, qué tránsito, PNI u otro IX se volvió preferido, cuánto tardó y qué prefijos quedaron sin alternativa. Las vistas Adj-RIB-In, la decisión local y las rutas anunciadas permiten saber si la alternativa no existía o fue descartada por política.

El expediente de tráfico debe mostrar carga por interconexión, margen disponible, pérdida y latencia. Un modelo responsable incluye que muchos miembros pueden reconverger al mismo tiempo. Una interfaz local sin saturación no descarta congestión más arriba en el proveedor.

También hacen falta sondas externas de DNS y aplicación. BGP puede haber convergido y, aun así, un firewall con estado, una ruta de retorno o una política de ingeniería de tráfico puede impedir la transacción. La métrica final es el servicio, no solo la presencia de un prefijo.

Seguridad de ruta no equivale a disponibilidad

El rechazo de RPKI INVALID es una protección importante [2]. Los filtros IRR y las comprobaciones de camino añaden límites. El RFC 7454 ofrece prácticas de seguridad BGP y el RFC 9234 incorpora BGP Roles y Only-to-Customer [5][6].

Sin embargo, una ruta con origen correcto puede tener poca capacidad o una relación inadecuada. Una ruta autorizada puede desaparecer por un fallo de transporte. Y un registro obsoleto puede bloquear la ruta de emergencia correcta. La solución no es relajar filtros durante una crisis, sino mantener el registro y ensayar tanto la aceptación como el rechazo antes de necesitar el camino.

El registro es el libro, no el resultado

PeeringDB asocia actualmente AS16004 con MIX S.r.L. - Milan Internet eXchange [3]. Es una base útil para identidad, contacto y aprovisionamiento. No muestra qué ruta fue elegida ni qué paquete llegó.

Esta es la superficie Heng.lu: el registro actúa como libro y mecanismo de continuidad, no como soberano del comportamiento operativo. La responsabilidad se decide al reconciliar identidad, política prevista, configuración desplegada y rutas observadas. Una divergencia entre esos elementos ya merece tratamiento operativo.

Cómo cerrar la prueba

Un paquete de reconvergencia útil contiene el estado previsto, la cronología, las rutas antes y después, las mediciones de tráfico y servicio, y la prueba de reparación. Debe incluir un límite de reversión y un ensayo repetido que demuestre que la condición equivalente ya se contiene.

La conclusión puede ser precisa sin ser absoluta. MIX establece una expectativa razonable: el participante preparado debe disponer de alternativas [1]. La evidencia conjunta tiene que demostrar si funcionaron. La redundancia no es contar enlaces; es verificar que el paso de un estado a otro no produjo una pérdida inaceptable.

Fuentes

  1. https://www.mix-it.net/en/the-peering-lan-is-not-inherently-a-critical-point-of-failure/
  2. https://www.mix-it.net/en/route-server/
  3. https://www.peeringdb.com/api/net?asn=16004
  4. https://www.rfc-editor.org/rfc/rfc7947.html
  5. https://www.rfc-editor.org/rfc/rfc7454.html
  6. https://www.rfc-editor.org/rfc/rfc9234.html