Punto de intercambio de tráfico: desde los orígenes hasta la creación de tu propio IX

Punto de intercambio de tráfico: desde los orígenes hasta la creación de tu propio IX

"Hemos establecido una conexión telefónica entre nosotros y los chicos de SRI...", dijo Kleinrock... en una entrevista:
“Escribimos la L y preguntamos por teléfono: “¿Ves la L?”
“Sí, vemos la L”, fue la respuesta.
“Escribimos la O y preguntamos: “¿Ves la O?””.
"Sí, vemos la O."
“Entonces escribimos la G y el sistema falló”...

Sin embargo, había comenzado una revolución...

El comienzo de Internet.


Hola a todos!

Mi nombre es Alexander, soy ingeniero de redes en Linxdatacenter. En el artículo de hoy hablaremos de los puntos de intercambio de tráfico (Puntos de Intercambio de Internet, IXP): qué precedió a su aparición, qué tareas resuelven y cómo están construidos. También en este artículo demostraré el principio de funcionamiento de IXP utilizando la plataforma EVE-NG y el enrutador de software BIRD, para que comprenda cómo funciona "bajo el capó".

Un poco de historia

Si miras aquí, entonces puede ver que el rápido crecimiento en el número de puntos de intercambio de tráfico comenzó en 1993. Esto se debe a que la mayor parte del tráfico de los operadores de telecomunicaciones que existían en ese momento pasaba por la red troncal de Estados Unidos. Así, por ejemplo, cuando el tráfico iba de un operador en Francia a un operador en Alemania, primero iba de Francia a los EE.UU., y sólo después de los EE.UU. a Alemania. La red troncal actuó en este caso como tránsito entre Francia y Alemania. Incluso el tráfico dentro de un país a menudo no pasaba directamente, sino a través de las redes troncales de los operadores estadounidenses.

Esta situación afectó no sólo al costo de entregar el tráfico de tránsito, sino también a la calidad de los canales y las demoras. El número de usuarios de Internet aumentó, aparecieron nuevos operadores, aumentó el volumen de tráfico e Internet maduró. Los operadores de todo el mundo comenzaron a darse cuenta de que se necesitaba un enfoque más racional para organizar la interacción entre operadores. “¿Por qué yo, el operador A, debería pagar el tránsito a través de otro país para entregar tráfico al operador B, que se encuentra en la calle de al lado?” Ésta es, aproximadamente, la pregunta que se hicieron los operadores de telecomunicaciones en aquel momento. Así, comenzaron a aparecer puntos de intercambio de tráfico en diferentes partes del mundo en puntos de concentración de operadores:

  • 1994 – LINX en Londres,
  • 1995 – DE-CIX en Frankfurt,
  • 1995 – MSK-IX, en Moscú, etc.

Internet y nuestros días

Conceptualmente, la arquitectura de la Internet moderna consta de muchos sistemas autónomos (AS) y muchas conexiones entre ellos, tanto físicas como lógicas, que determinan la ruta del tráfico de un AS a otro.

Los AS suelen ser operadores de telecomunicaciones, proveedores de Internet, CDN, centros de datos y empresas del segmento empresarial. Los AS organizan conexiones lógicas (peering) entre sí, normalmente utilizando el protocolo BGP.

La forma en que los sistemas autónomos organizan estas conexiones está determinada por una serie de factores:

  • geográfico,
  • económico,
  • político,
  • acuerdos e intereses comunes entre propietarios de AS,
  • etcétera

Por supuesto, este esquema tiene cierta estructura y jerarquía. Por lo tanto, los operadores se dividen en nivel 1, nivel 2 y nivel 3, y si los clientes de un proveedor de Internet local (nivel 3) son, por regla general, usuarios comunes, entonces, por ejemplo, para el nivel 1 operadores de nivel los clientes son otros operadores. Los operadores de nivel 3 agregan el tráfico de sus suscriptores, los operadores de telecomunicaciones de nivel 2, a su vez, agregan el tráfico de los operadores de nivel 3 y los de nivel 1, todo el tráfico de Internet.

Esquemáticamente se puede representar así:

Punto de intercambio de tráfico: desde los orígenes hasta la creación de tu propio IX
Esta imagen muestra que el tráfico se agrega de abajo hacia arriba, es decir. desde usuarios finales hasta operadores de nivel 1. También existe un intercambio horizontal de tráfico entre AS que son aproximadamente equivalentes entre sí.

Una parte integral y al mismo tiempo una desventaja de este esquema es una cierta confusión de conexiones entre sistemas autónomos ubicados más cerca del usuario final, dentro de un área geográfica. Considere la siguiente imagen:

Punto de intercambio de tráfico: desde los orígenes hasta la creación de tu propio IX

Supongamos que en una gran ciudad hay 5 operadores de telecomunicaciones, cuyo peering, por una razón u otra, se organiza como se muestra arriba.

Si el usuario Petya, conectado al ISP de Go, quiere acceder a un servidor conectado al proveedor de ASM, entonces el tráfico entre ellos se verá obligado a pasar a través de 5 sistemas autónomos. Esto aumenta el retraso porque aumenta el número de dispositivos de red a través de los cuales pasará el tráfico, así como el volumen de tráfico de tránsito en los sistemas autónomos entre Go y ASM.

¿Cómo reducir el número de AS de tránsito por los que el tráfico se ve obligado a pasar? Así es: punto de intercambio de tráfico.

Hoy en día, la aparición de nuevos IXP está impulsada por las mismas necesidades que a principios de los años 90 y 2000, sólo que en menor escala, en respuesta al creciente número de operadores de telecomunicaciones, usuarios y tráfico, y a la creciente cantidad de contenido generado por las redes CDN. y centros de datos.

¿Qué es un punto de cambio?

Un punto de intercambio de tráfico es un lugar con una infraestructura de red especial donde los participantes interesados ​​en el intercambio mutuo de tráfico organizan el peering mutuo. Los principales participantes de los puntos de intercambio de tráfico: operadores de telecomunicaciones, proveedores de Internet, proveedores de contenidos y centros de datos. En los puntos de intercambio de tráfico, los participantes se conectan directamente entre sí. Esto le permite resolver los siguientes problemas:

  • reducir la latencia,
  • reducir la cantidad de tráfico de tránsito,
  • optimizar el enrutamiento entre AS.

Teniendo en cuenta que los IXP están presentes en muchas grandes ciudades del mundo, todo esto tiene un efecto beneficioso para Internet en su conjunto.

Si la situación anterior con Petya se resuelve usando IXP, resultará algo como esto:

Punto de intercambio de tráfico: desde los orígenes hasta la creación de tu propio IX

¿Cómo funciona un punto de intercambio de tráfico?

Como regla general, un IXP es un AS independiente con su propio bloque de direcciones públicas IPv4/IPv6.

La red IXP suele consistir en un dominio L2 continuo. A veces se trata simplemente de una VLAN que aloja a todos los clientes IXP. Cuando se trata de IXP más grandes y distribuidos geográficamente, se pueden utilizar tecnologías como MPLS, VXLAN, etc. para organizar un dominio L2.

elementos IXP

  • SKS. Aquí no hay nada inusual: bastidores, crucetas ópticas, paneles de conexión.
  • Interruptores – la base de IXP. El puerto del conmutador es el punto de entrada a la red IXP. Los conmutadores también realizan parte de las funciones de seguridad: filtran el tráfico basura que no debería estar presente en la red IXP. Como regla general, los conmutadores se seleccionan en función de los requisitos funcionales: confiabilidad, velocidades de puerto admitidas, funciones de seguridad, compatibilidad con sFlow, etc.
  • Servidor de ruta (RS) – una parte integral y necesaria de cualquier punto de intercambio de tráfico moderno. El principio de funcionamiento es muy similar al reflector de ruta en iBGP o al enrutador designado en OSPF y resuelve los mismos problemas. A medida que crece el número de participantes en un punto de intercambio de tráfico, aumenta el número de sesiones BGP que cada participante necesita soportar, es decir esto recuerda a la clásica topología de malla completa en iBGP. RS resuelve el problema de la siguiente manera: establece una sesión BGP con cada participante IXP interesado, y ese participante se convierte en cliente RS. Al recibir una actualización de BGP de uno de sus clientes, RS envía esta actualización a todos sus demás clientes, por supuesto, con la excepción de aquel del que se recibió esta actualización. Por lo tanto, RS elimina la necesidad de establecer una malla completa entre todos los miembros del IXP y resuelve elegantemente el problema de escalabilidad. Vale la pena señalar que el servidor de rutas transmite rutas de forma transparente de un AS a otro sin realizar cambios en los atributos transmitidos por BGP; por ejemplo, no agrega el número en su AS a la ruta AS. También en RS hay un filtrado básico de rutas: por ejemplo, RS no acepta redes marcianas ni los prefijos del propio IXP.

    Un enrutador de software de código abierto, BIRD (bird internet Routing Daemon), se utiliza a menudo como solución de servidor de rutas. Lo bueno de esto es que es gratuito, se implementa rápidamente en la mayoría de las distribuciones de Linux, tiene un mecanismo flexible para configurar políticas de enrutamiento/filtrado y no exige recursos informáticos. Además, se puede seleccionar como RS un hardware/enrutador virtual de Cisco, Juniper, etc.

  • Seguridad. Dado que una red IXP es una concentración de una gran cantidad de AS, la política de seguridad que todos los participantes deben seguir debe estar bien redactada. En general, aquí se aplican los mismos mecanismos que se utilizan para establecer una adyacencia BGP entre dos pares BGP separados fuera de un IXP, además de algunas medidas de seguridad adicionales.

    Por ejemplo, es una buena práctica permitir el tráfico sólo desde una dirección mac específica del participante IXP, que se negocia de antemano. Denegar tráfico con campos de tipo ethertype distintos de 0x0800(IPv4), 0x08dd(IPv6), 0x0806(ARP); esto se hace para filtrar el tráfico que no pertenece al emparejamiento BGP. También se pueden utilizar mecanismos como GTSM, RPKI, etc.

Quizás los anteriores sean los componentes principales de cualquier IXP, independientemente de su escala. Por supuesto, los IXP más grandes pueden contar con tecnologías y soluciones adicionales.
Sucede que IXP también brinda a sus participantes servicios adicionales:

  • colocado en el servidor DNS IXP TLD,
  • instalar servidores NTP de hardware, lo que permite a los participantes sincronizar con precisión la hora,
  • proporcionar protección contra ataques DDoS, etc.

¿Cómo funciona?

Consideremos el principio de funcionamiento de un punto de intercambio de tráfico usando el ejemplo de un IXP simple modelado usando EVE-NG, y luego consideremos la configuración básica de un enrutador de software BIRD. Para simplificar el diagrama, omitiremos cosas tan importantes como la redundancia y la tolerancia a fallos.

La topología de la red se muestra en la siguiente figura.

Punto de intercambio de tráfico: desde los orígenes hasta la creación de tu propio IX

Supongamos que administramos un pequeño punto de intercambio y brindamos las siguientes opciones de intercambio de tráfico:

  • mirada pública,
  • peering privado,
  • peering a través del servidor de ruta.

Nuestro número AS es 555, poseemos un bloque de direcciones IPv4: 50.50.50.0/24, desde donde emitimos direcciones IP para aquellos que quieran conectarse a nuestra red.

50.50.50.254 – Dirección IP configurada en la interfaz del servidor de ruta, con esta IP los clientes establecerán una sesión BGP en caso de peering vía RS.

Además, para el peering vía RS, hemos desarrollado una política de enrutamiento simple basada en la comunidad BGP, que permite a los participantes IXP regular a quién y qué rutas enviar:

comunidad BGP
Descripción

LOCAL_AS:PEER_AS
Enviar prefijos solo a PEER_AS

LOCAL_AS:IXP_AS
Transferir prefijos a todos los participantes de IXP

3 clientes quieren conectarse a nuestro IXP e intercambiar tráfico; Digamos que estos son proveedores de Internet. Todos quieren organizar el peering a través de un servidor de ruta. A continuación se muestra un diagrama con los parámetros de conexión del cliente:

Cliente
Número AS del cliente
Prefijos anunciados por el cliente
Dirección IP emitida al cliente para conectarse al IXP

Proveedor de servicios de Internet número 1
AS 100
1.1.0.0/16
50.50.50.10/24

Proveedor de servicios de Internet número 2
AS 200
2.2.0.0/16
50.50.50.20/24

Proveedor de servicios de Internet número 3
AS 300
3.3.0.0/16
50.50.50.30/24

Configuración básica de BGP en el enrutador del cliente:

router bgp 100
 no bgp enforce-first-as
 bgp log-neighbor-changes
 neighbor 50.50.50.254 remote-as 555
address-family ipv4
  network 1.1.0.0 mask 255.255.0.0
  neighbor 50.50.50.254 activate
  neighbor 50.50.50.254 send-community both
  neighbor 50.50.50.254 soft-reconfiguration inbound
  neighbor 50.50.50.254 route-map ixp-out out
 exit-address-family

ip prefix-list as100-prefixes seq 5 permit 1.1.0.0/16
route-map bgp-out permit 10
 match ip address prefix-list as100-prefixes
 set community 555:555

Vale la pena señalar aquí la configuración no bgp enforce-first-as. De forma predeterminada, BGP requiere que la ruta de acceso de una actualización de BGP recibida contenga el número de BGP del par desde el cual se recibió la actualización. Pero como el servidor de ruta no realiza cambios en la ruta as, su número no estará en la ruta as y la actualización se descartará. Esta configuración se utiliza para hacer que el enrutador ignore esta regla.

También vemos que el cliente ha configurado la comunidad bgp 555:555 con este prefijo, lo que según nuestra política significa que el cliente quiere anunciar este prefijo a todos los demás participantes.

Para los enrutadores de otros clientes, la configuración será similar, con la excepción de sus parámetros únicos.

Ejemplo de configuración de BIRD:

define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];

template bgp RS_CLIENT {
  local as ixp_as;
  rs client;
}

A continuación se describe un filtro que no acepta prefijos marcianos, así como los prefijos del propio IXP:

function catch_martians_and_ixp()
prefix set martians;
prefix set ixp_prefixes;
{
  martians = [ 
  0.0.0.0/8+,
  10.0.0.0/8+,
  100.64.0.0/10+,
  127.0.0.0/8+,
  169.254.0.0/16+,
  172.16.0.0/12+,
  192.0.0.0/24+,
  192.0.2.0/24+,
  192.168.0.0/16+,
  198.18.0.0/15+,
  198.51.100.0/24+,
  203.0.113.0/24+,
  224.0.0.0/4+,
  240.0.0.0/4+ ];

  if net ~ martians || net ~ ixp_prefixes then return false;

  return true;
}

Esta función implementa la política de enrutamiento que describimos anteriormente.

function bgp_ixp_policy(int peer_as)
{
  if (ixp_as, ixp_as) ~ bgp_community then return true;
  if (ixp_as, peer_as) ~ bgp_community then return true;

  return false;
}

filter reject_martians_and_ixp
{
  if catch_martians_and_ixp() then reject;
  if ( net ~ [0.0.0.0/0{25,32} ] ) then {
    reject;
  }
  accept;


}

Configuramos el peering, aplicamos filtros y políticas adecuadas.

protocol as_100 from RS_CLIENT {
  neighbor 50.50.50.10 as 100;
  ipv4 {
    export where bgp_ixp_policy(100);
    import filter reject_martians_and_ixp;
  }
}

protocol as_200 from RS_CLIENT {
  neighbor 50.50.50.20 as 200;
  ipv4 {
    export where bgp_ixp_policy(200);
    import filter reject_martians_and_ixp;
  }
}

protocol as_300 from RS_CLIENT {
  neighbor 50.50.50.30 as 300;
  ipv4 {
    export where bgp_ixp_policy(300);
    import filter reject_martians_and_ixp;
  }
}

Vale la pena señalar que en un servidor de rutas es una buena práctica colocar rutas de diferentes pares en diferentes RIB. BIRD te permite hacer esto. En nuestro ejemplo, para simplificar, todas las actualizaciones recibidas de todos los clientes se agregan a una RIB común.

Entonces, veamos lo que tenemos.

En el servidor de ruta vemos que se ha establecido una sesión BGP con los tres clientes:

Punto de intercambio de tráfico: desde los orígenes hasta la creación de tu propio IX

Vemos que recibimos prefijos de todos los clientes:

Punto de intercambio de tráfico: desde los orígenes hasta la creación de tu propio IX

En el router as 100 vemos que si solo hay una sesión BGP con el servidor de ruta recibimos prefijos tanto de as 200 como de as 300, mientras que los atributos BGP no han cambiado, como si el peering entre clientes se realizara directamente:

Punto de intercambio de tráfico: desde los orígenes hasta la creación de tu propio IX

Así, vemos que la presencia de un servidor de ruta simplifica enormemente la organización del peering en el IXP.

Espero que esta demostración le haya ayudado a comprender mejor cómo funcionan los IXP y cómo funciona el servidor de ruta en un IXP.

Centro de datos Linx IX

En Linxdatacenter, construimos nuestro propio IXP basado en una infraestructura tolerante a fallas de 2 conmutadores y 2 servidores de ruta. Nuestro IXP ahora se está ejecutando en modo de prueba e invitamos a todos a conectarse a Linxdatacenter IX y participar en las pruebas. Cuando esté conectado, se le proporcionará un puerto con un ancho de banda de 1 Gbit/s, la capacidad de realizar peering a través de nuestros servidores de ruta, así como acceso a su cuenta personal del portal IX, disponible en ix.linxdatacenter.com.

Escriba comentarios o mensajes privados para obtener acceso a las pruebas.

conclusión

Los puntos de intercambio de tráfico surgieron en los albores de Internet como una herramienta para resolver el problema del flujo de tráfico subóptimo entre operadores de telecomunicaciones. Ahora, con la llegada de nuevos servicios globales y el aumento en la cantidad de tráfico CDN, los puntos de intercambio continúan optimizando el funcionamiento de la red global. El aumento del número de IXP en el mundo beneficia tanto al usuario final del servicio como a los operadores de telecomunicaciones, operadores de contenidos, etc. Para los participantes de IXP, el beneficio se expresa en la reducción de los costos de organización del peering externo, la reducción de la cantidad de tráfico por el que los operadores de nivel superior tienen que pagar, la optimización del enrutamiento y la capacidad de tener una interfaz directa con los operadores de contenido.

Enlaces de interés

Fuente: habr.com

Compre alojamiento confiable para sitios con protección DDoS, servidores VPS VDS 🔥 Compra alojamiento web fiable con protección DDoS, servidores VPS VDS | ProHoster