Los grandes IXP ya no son simples switches: así funciona hoy el corazón de Internet

Durante años se ha explicado un Internet Exchange Point (IXP) como un enorme switch Ethernet al que operadores, proveedores de contenido y redes empresariales conectan sus routers para intercambiar tráfico directamente. La explicación sigue siendo útil, pero se queda corta para infraestructuras como DE-CIX, LINX o AMS-IX: detrás de la LAN de peering existen hoy arquitecturas distribuidas entre numerosos centros de datos, con EVPN, MPLS, VXLAN, automatización y enlaces de 100 y 400 GbE.

Las claves de la arquitectura de los grandes IXP en 30 segundos

  • Un IXP proporciona una infraestructura común de capa 2 sobre la que sus miembros establecen sesiones BGP.
  • Los route servers facilitan el peering multilateral, pero no transportan el tráfico de los usuarios.
  • DE-CIX completó en 2022 la migración de su plataforma Apollon a EVPN mientras mantenía el servicio operativo.
  • LINX utiliza actualmente EVPN sobre MPLS en LON1 y EVPN sobre VXLAN en LON2.
  • No existe una arquitectura única: AMS-IX sigue documentando una plataforma MPLS/VPLS para su intercambio de Ámsterdam.

La distinción es importante porque Internet no funciona como una sucesión de circuitos privados entre cada pareja de operadores. Cuando dos sistemas autónomos quieren intercambiar tráfico pueden establecer peering, evitando que esos paquetes tengan que atravesar necesariamente un proveedor de tránsito IP.

Un IXP crea precisamente el lugar técnico donde hacerlo.

Qué ocurre realmente cuando una red conecta con un IXP

Desde la perspectiva del miembro, el funcionamiento puede parecer bastante sencillo.

El operador conecta uno o varios puertos de su router a la infraestructura del IXP. Recibe direcciones IPv4 e IPv6 pertenecientes a la LAN de peering y, sobre esa red, establece sesiones eBGP con otras organizaciones.

Por ejemplo, un mismo IXP puede tener conectados simultáneamente:

ParticipanteFunción
ISP AOperador de acceso a Internet
CloudflareCDN y red de contenidos
GoogleProveedor de servicios y contenidos
ISP BOperador regional
Proveedor cloudInfraestructura y servicios online

Todos pueden encontrarse sobre la misma infraestructura Ethernet del intercambio, aunque eso no significa que todos intercambien rutas entre sí.

La decisión sigue correspondiendo a BGP.

Un operador puede mantener peering directo con Google y Cloudflare, utilizar un route server para intercambiar rutas con cientos de redes adicionales y no aceptar ninguna ruta de otro participante concreto.

El IXP proporciona la conectividad. Cada miembro define su política.

Esto también corrige otra idea bastante extendida: el IXP no decide cómo debe circular el tráfico entre sus participantes.

Son los routers de cada sistema autónomo los que toman esas decisiones utilizando BGP.

El route server elimina cientos de sesiones BGP

Los route servers son una de las piezas más importantes de los grandes puntos de intercambio.

Imagine un IXP con 800 participantes. Si una red quisiera establecer peering bilateral con todos ellos necesitaría administrar cientos de sesiones BGP independientes.

El route server simplifica este escenario.

El miembro establece una sesión con uno o normalmente dos servidores de rutas. Estos reciben las rutas anunciadas por otros participantes adheridos al servicio y las redistribuyen de acuerdo con las políticas correspondientes.

Lo importante es que el route server no se convierte en el siguiente salto del tráfico.

El funcionamiento puede resumirse así:

  1. El ISP A anuncia sus prefijos al route server.
  2. El proveedor B también anuncia sus rutas.
  3. El route server comunica las rutas de B al ISP A.
  4. El router del ISP A aprende cómo llegar a B.
  5. Cuando existe tráfico, los paquetes viajan directamente entre los routers de A y B a través de la LAN del IXP.

El route server participa en el plano de control, pero no en el plano de datos.

En muchos IXP estos sistemas tampoco son grandes routers físicos. Es habitual utilizar software como BIRD sobre servidores Linux, porque su función principal es procesar sesiones y políticas BGP.

DE-CIX, por ejemplo, utiliza BIRD dentro de su servicio GlobePEER.

El verdadero problema empieza cuando el IXP ocupa decenas de edificios

Un punto de intercambio pequeño instalado dentro de un único centro de datos puede construirse con una arquitectura relativamente sencilla.

El reto cambia por completo cuando el IXP se extiende por numerosos CPD.

Un participante puede conectarse desde un centro de datos situado al norte de una ciudad y otro hacerlo desde una instalación diferente a varios kilómetros. Desde ambos routers debe seguir existiendo una experiencia de peering prácticamente idéntica.

Una forma más clara de visualizarlo en WordPress es mediante el flujo:

CPD A

Router del ISP A → nodo de acceso del IXP

CPD B

Router del ISP B → nodo de acceso del IXP

CPD C

Router del proveedor de contenidos → nodo de acceso del IXP

Los tres nodos de acceso están unidos por la red interna distribuida del IXP.

Desde el punto de vista de los participantes, todos siguen conectados a la misma LAN de peering. Internamente, sin embargo, el operador del intercambio necesita transportar ese servicio entre diferentes edificios, enlaces y equipos de red.

Ahí entran tecnologías como MPLS, VPLS, VXLAN y EVPN.

DE-CIX migró su red a EVPN con el tráfico funcionando

DE-CIX ofrece uno de los casos más interesantes.

En diciembre de 2022 anunció que había completado la mayor actualización de red de su historia. Su plataforma Apollon evolucionó hacia Peering LAN 2.0, basada en Ethernet Virtual Private Network (EVPN).

La migración resulta especialmente llamativa porque se llevó a cabo con los intercambios funcionando.

El proceso comenzó en Phoenix y Frankfurt y posteriormente se extendió por las demás ubicaciones que utilizaban aquella arquitectura.

Antes de tocar la infraestructura real, DE-CIX reprodujo virtualmente las LAN de peering para probar el comportamiento del nuevo diseño.

Uno de los objetivos era reducir algo que en una red pequeña apenas preocupa pero que puede convertirse en un problema cuando hay miles de participantes: ARP y Neighbor Discovery.

Cuando un router quiere conocer qué dirección MAC corresponde a una IP, envía normalmente una solicitud que puede terminar llegando a numerosos equipos dentro del dominio de capa 2.

Con cientos o miles de routers conectados, ese tráfico deja de ser insignificante.

EVPN permite distribuir información IP-MAC mediante su plano de control y aplicar Proxy ARP y Proxy Neighbor Discovery, reduciendo la necesidad de inundar continuamente la LAN con estas solicitudes.

DE-CIX participó además en el desarrollo del RFC 9161, centrado precisamente en el uso operativo de Proxy ARP/ND sobre EVPN.

La compañía llegó a indicar que algunos clientes observaron reducciones de hasta un 25 % en la carga de CPU de sus routers después de la migración, debido a la reducción del ruido generado por ARP y NDP.

Cómo funciona EVPN dentro de un IXP

EVPN introduce un cambio importante respecto al Ethernet tradicional.

En un dominio Ethernet clásico, los switches aprenden principalmente qué direcciones MAC existen observando el tráfico que reciben.

Cuando no conocen el destino, pueden recurrir al flooding.

EVPN incorpora un plano de control basado en MP-BGP que permite distribuir esa información de forma explícita entre los equipos.

El funcionamiento simplificado sería:

PasoQué ocurre
1Un participante conecta su router al nodo de acceso del IXP
2El nodo aprende la MAC y otra información asociada
3EVPN distribuye esa información al resto de equipos necesarios
4Los otros nodos conocen dónde se encuentra ese participante
5El tráfico puede transportarse sin depender del aprendizaje mediante flooding tradicional

El usuario sigue viendo una LAN Ethernet.

La complejidad queda escondida dentro de la red del IXP.

LINX demuestra que EVPN puede construirse de diferentes formas

Otro buen ejemplo es LINX, el London Internet Exchange.

Su red londinense está dividida en dos grandes plataformas, LON1 y LON2, y utilizan arquitecturas distintas.

LON1 emplea EVPN sobre MPLS.

Su infraestructura actual incorpora equipos Juniper y Nokia y se distribuye por numerosos centros de datos de Londres.

LON2 utiliza otra combinación:

EVPN + VXLAN + arquitectura leaf-spine.

LINX fue uno de los primeros grandes IXP en apostar por este modelo desagregado y durante 2026 ha continuado renovando la plataforma con equipos Nokia IXR y SR Linux.

Para verlo de manera sencilla:

PlataformaOverlayTransporte
LINX LON1EVPNMPLS
LINX LON2EVPNVXLAN
DE-CIX ApollonEVPNInfraestructura propia distribuida

El servicio entregado al participante puede ser parecido, aunque internamente las arquitecturas sean diferentes.

Esto resulta especialmente interesante para administradores y arquitectos de redes porque demuestra que EVPN no obliga a utilizar un único tipo de underlay.

AMS-IX recuerda que VPLS todavía no ha desaparecido

Sería incorrecto afirmar que los tres grandes IXP europeos funcionan ya sobre EVPN.

La documentación actualmente publicada por AMS-IX para su plataforma de Ámsterdam sigue describiendo una arquitectura basada en MPLS/VPLS.

AMS-IX utiliza plataformas Juniper MX10008, Juniper ACX7100 y Extreme SLX-9540 en diferentes partes de su infraestructura, mientras el núcleo emplea también sistemas Juniper.

Los miembros pueden contratar interfaces de 10, 100 y 400 GbE.

Para ellos sigue existiendo una infraestructura Ethernet común. La red MPLS/VPLS transporta ese servicio entre las diferentes ubicaciones de AMS-IX.

El ejemplo resulta importante porque evita convertir EVPN en una respuesta universal.

Las redes de operador evolucionan progresivamente y una arquitectura existente puede continuar siendo válida durante muchos años si cumple los requisitos de capacidad, estabilidad, automatización y seguridad.

Los equipos internos tampoco son simples switches

Otra idea que conviene actualizar es que dentro de un gran IXP solo existen switches Ethernet sencillos.

El servicio proporcionado al participante es fundamentalmente de capa 2, pero eso no significa que el hardware utilizado internamente carezca de capacidades de routing.

LINX utiliza, por ejemplo, Juniper MX10008 y Nokia 7750 SR, mientras AMS-IX también emplea plataformas MX10008.

Son sistemas capaces de ejecutar MPLS, BGP, EVPN, telemetría y multitud de funciones propias de redes de operador.

La diferencia importante no está en lo que puede hacer físicamente la caja, sino en qué función realiza dentro de la arquitectura del intercambio.

El router del miembro sigue ejecutando su BGP.

La infraestructura interna se ocupa de transportar las tramas hasta el participante correcto.

EVPN reduce flooding y mejora la convergencia

Una de las ventajas más claras de EVPN aparece cuando se compara el aprendizaje tradicional de MAC con un modelo basado en plano de control.

En una LAN clásica, una dirección desconocida puede provocar tráfico de descubrimiento o inundación.

Con EVPN existe información distribuida sobre dónde reside cada MAC y, en determinados diseños, también sobre qué dirección IP está asociada a ella.

Por ejemplo:

Modelo Ethernet tradicional

Router A necesita localizar una IP → envía ARP → la solicitud puede llegar a muchos participantes → el destino responde.

Modelo EVPN con Proxy ARP

Router A necesita localizar una IP → el nodo EVPN ya conoce la asociación IP/MAC → responde localmente o dirige la solicitud de forma controlada.

El beneficio aumenta con el tamaño.

Con diez participantes apenas importa. Con cientos o miles de routers conectados a una misma plataforma, la diferencia en tráfico de control puede ser considerable.

EVPN también aporta mecanismos para multihoming, retirada rápida de direcciones MAC y una gestión más determinista de fallos.

Eso explica por qué tecnologías originalmente asociadas a grandes redes de proveedores y centros de datos han terminado encontrando un lugar natural dentro de los Internet Exchange Points.

Lo que un sysadmin o ingeniero de redes puede aprender de los IXP

Las arquitecturas de estos intercambios muestran una tendencia que también aparece dentro de centros de datos y redes de proveedores.

Ethernet sigue ahí.

Lo que ha cambiado es cómo se construye una red Ethernet distribuida y de gran escala.

En lugar de extender dominios de capa 2 utilizando exclusivamente mecanismos tradicionales, muchos operadores construyen primero una infraestructura de transporte y despliegan después los servicios necesarios mediante EVPN.

Por debajo puede existir MPLS.

También puede existir VXLAN.

En otros casos sigue utilizándose VPLS.

El resultado entregado al cliente puede seguir pareciendo exactamente el mismo: una interfaz Ethernet desde la que establecer BGP.

Para quienes estudian CCIE Service Provider o trabajan con redes de operadores, esto convierte conceptos como MP-BGP, MPLS, EVPN, VXLAN, Proxy ARP/ND y route servers en algo bastante menos académico.

Estas tecnologías están funcionando cada segundo en algunos de los nodos más importantes de Internet.

Un IXP moderno puede resumirse de una forma mucho más precisa que diciendo que es simplemente un gran switch:

por fuera ofrece una LAN Ethernet; por dentro puede funcionar como una sofisticada red de operador distribuida entre decenas de centros de datos.

Preguntas frecuentes

¿Qué es un Internet Exchange Point?

Un IXP es una infraestructura donde diferentes sistemas autónomos pueden intercambiar tráfico directamente. Los participantes conectan sus routers a una plataforma común y utilizan BGP para establecer sus políticas de peering.

¿El route server transporta el tráfico de Internet?

No. El route server facilita el intercambio de rutas BGP, pero los paquetes de los usuarios viajan directamente entre los routers de los participantes a través de la infraestructura del IXP.

¿Todos los grandes IXP utilizan EVPN?

No. DE-CIX y LINX utilizan EVPN en varias de sus principales plataformas, mientras AMS-IX continúa documentando MPLS/VPLS para su infraestructura de Ámsterdam.

¿Por qué EVPN resulta útil en un IXP?

Permite distribuir información Ethernet mediante un plano de control, reducir determinados tipos de flooding, utilizar Proxy ARP/ND y mejorar la gestión de redundancia y convergencia en infraestructuras distribuidas.

encuentra artículos

newsletter

Recibe toda la actualidad del sector tech y cloud en tu email de la mano de RevistaCloud.com.

Suscripción boletín

LO ÚLTIMO