Mozilla lanzó el motor de reconocimiento de voz DeepSpeech 0.6.

Mozilla lanzó el motor de reconocimiento de voz DeepSpeech 0.6.

«Establecimos 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.»
«Luego escribimos la G y el sistema se colapsó»…

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

El comienzo de Internet.


¡Hola a todos!

Me llamo Alexander, soy ingeniero de redes en Linxdatacenter. En el artículo de hoy, hablaré sobre los puntos de intercambio de tráfico (Internet Exchange Point, IXP): lo que precedió a su aparición, qué problemas resuelven y cómo se construyen. También en este artículo, demostraré el principio de funcionamiento de un IXP utilizando la plataforma EVE-NG y el enrutador de software BIRD, para que haya una comprensión de cómo funciona «bajo el capó».

Un poco de historia

Si miramos : uno de los indicadores más importantes sobre DEX)., podemos notar que el crecimiento explosivo del número de puntos de intercambio de tráfico comenzó en 1993. Esto se debe a que la mayoría del tráfico de los operadores de telecomunicaciones existentes en ese momento pasaba por la red backbone de EE. UU. Así, por ejemplo, cuando el tráfico iba de un operador en Francia a un operador en Alemania, primero iba a EE. UU. desde Francia y solo luego de EE. UU. a Alemania. La red backbone actuaba como tránsito entre Francia y Alemania. Incluso el tráfico dentro de un solo país a menudo no iba directamente, sino a través de las redes de los operadores estadounidenses.

Esta situación afectaba no solo el costo de la entrega de tráfico en tránsito, sino también la calidad de los canales y la latencia. La cantidad de usuarios de Internet estaba aumentando, surgían nuevos operadores, el volumen de tráfico aumentaba, Internet estaba madurando. Los operadores de todo el mundo comenzaron a entender que necesitaban un enfoque más racional para organizar la interacción entre operadores. «¿Por qué debería yo, el operador A, pagar por el tránsito a través de otro país para entregar el tráfico al operador B, que está en la calle de al lado?». Aproximadamente esta era la pregunta que se hacían los operadores de telecomunicaciones en ese momento. Así, en distintas partes del mundo, comenzaron a aparecer puntos de intercambio de tráfico en los puntos de concentración de operadores:

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

Internet y nuestros días

Conceptualmente, la arquitectura del internet moderno consiste en múltiples sistemas autónomos (autonomous system, AS) y numerosas conexiones entre ellos, tanto físicas como lógicas, que determinan la ruta del tráfico de un AS a otro.

Los AS generalmente son operadores de telecomunicaciones, proveedores de internet, CDN, centros de datos y empresas del segmento empresarial. Los AS organizan conexiones lógicas (peering) entre sí, generalmente mediante el protocolo BGP.

La manera en que los sistemas autónomos organizan estas conexiones está determinada por varios factores:

  • geográficos,
  • económicos,
  • políticos,
  • acuerdos e intereses comunes entre los propietarios de los AS,
  • etc.

Por supuesto, en este esquema hay una cierta estructura y jerarquía. Así, los operadores se dividen en tier-1, tier-2 y tier-3, y si los clientes de un proveedor de internet local (tier-3) suelen ser usuarios comunes, para los operadores de nivel tier-1, los clientes son otros operadores. Los operadores tier-3 agregan el tráfico de sus abonados, los operadores tier-2, a su vez, agregan el tráfico de los operadores tier-3, y los tier-1 manejan todo el tráfico de internet.

Esquemáticamente, esto se puede representar así:

Mozilla lanzó el motor de reconocimiento de voz DeepSpeech 0.6.
En la imagen se puede ver que el tráfico se agrega de abajo hacia arriba, es decir, de los usuarios finales a los operadores tier-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 la cierta desorganización de las conexiones entre los sistemas autónomos situados más cerca del usuario final, dentro de la zona geográfica. Veamos la imagen a continuación:

Mozilla lanzó el motor de reconocimiento de voz DeepSpeech 0.6.

Supongamos que en una gran ciudad hay 5 operadores de telecomunicaciones, entre los cuales, por diversas razones, el peering se organiza como se muestra arriba.

Si un usuario llamado Petya, conectado al proveedor de internet Go, quisiera acceder a un servidor conectado al proveedor ASM, el tráfico entre ellos tendría que pasar por 5 sistemas autónomos. Esto aumenta la latencia, ya que se incrementa la cantidad de dispositivos de red por los que 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 la cantidad de AS de tránsito que el tráfico debe atravesar? La respuesta es: un punto de intercambio de tráfico.

Hoy en día, la aparición de nuevos IXP se debe a las mismas necesidades que al principio de los años 90 y 2000, solo que en una escala más pequeña, en respuesta al creciente número de operadores de telecomunicaciones, usuarios y tráfico, así como a la creciente cantidad de contenido generado por redes CDN y centros de datos.

¿Qué es un punto de intercambio de tráfico?

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 emparejamiento recíproco. Los principales participantes de los puntos de intercambio de tráfico son los operadores de telecomunicaciones, proveedores de Internet, proveedores de contenido y centros de datos. En los puntos de intercambio de tráfico, los participantes se conectan directamente entre sí. Esto resuelve las siguientes tareas:

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

Dado que los IXP están presentes en muchas grandes ciudades del mundo, esto también tiene un efecto positivo en Internet en general.

Si se resuelve la situación descrita anteriormente con Petya usando IXP, sería más o menos así:

Mozilla lanzó el motor de reconocimiento de voz DeepSpeech 0.6.

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

Por lo general, IXP es un AS separado con su propio bloque de direcciones públicas IPv4/IPv6.

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

Elementos de IXP

  • Sistemas de Cableado Estructurado. No hay nada inusual aquí: racks, cruces ópticos, paneles de parcheo.
  • Los conmutadores son la base del IXP. El puerto del conmutador es el punto de entrada a la red IXP. Además, los conmutadores realizan algunas funciones de seguridad: filtran el tráfico no deseado que no debería estar presente en la red IXP. Por lo general, los conmutadores se seleccionan según los requisitos funcionales: fiabilidad, velocidad de los puertos soportados, funciones de seguridad, soporte para sFlow, etc.
  • Servidor de rutas (RS) es una parte integral y necesaria de cualquier punto de intercambio de tráfico moderno. En términos de funcionamiento, se asemeja mucho a un route reflector en iBGP o a un designated router en OSPF, y resuelve los mismos problemas. A medida que crece el número de participantes en el punto de intercambio de tráfico, también aumenta el número de sesiones BGP que cada participante necesita mantener, lo que recuerda la clásica topología full-mesh en iBGP. El RS resuelve el problema de la siguiente manera: establece una sesión BGP con cada participante interesado del IXP, y este se convierte en cliente del RS. Al recibir una actualización BGP de uno de sus clientes, el RS envía esta actualización a todos sus demás clientes, por supuesto, excluyendo al que recibió la actualización. De este modo, el RS elimina la necesidad de establecer una malla completa entre todos los participantes del IXP y resuelve elegantemente el problema de escalabilidad. Cabe destacar que el servidor de rutas transmite de manera transparente las rutas de un ASN a otro, sin modificar los atributos BGP transmitidos, por ejemplo, sin añadir su número ASN en la ruta AS-path. Además, el RS realiza un filtrado básico de rutas: por ejemplo, el RS no acepta redes martianas ni prefijos del propio IXP.

    Como solución, el servidor de rutas a menudo utiliza un enrutador de software de código abierto: BIRD (daemon de enrutamiento de Internet Bird). Es bueno porque es gratuito, se despliega 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 muchos recursos computacionales. También se puede elegir un enrutador hardware/virtual de Cisco, Juniper, etc., como RS.

  • Seguridad. Dado que la red IXP es una concentración de un gran número de ASN, la política de seguridad que deben seguir todos los participantes debe estar bien definida. Por lo general, se aplican los mismos mecanismos que se utilizan al establecer la vecindad BGP entre dos pares BGP individuales fuera del IXP, y también se utilizan algunas medidas de protección adicionales.

    Por ejemplo, una buena práctica es permitir el tráfico solo desde una dirección MAC específica de un participante del IXP, que se acuerda de antemano. Prohibir el tráfico con campos de ethertype diferentes de 0x0800 (IPv4), 0x08dd (IPv6), 0x0806 (ARP); esto se hace para filtrar el tráfico que no tiene lugar en el emparejamiento BGP. También se pueden aplicar mecanismos como GTSM, RPKI, etc.

Sin duda, lo mencionado anteriormente son los componentes principales de cualquier IXP, independientemente de su escala. Por supuesto, en los IXP grandes se pueden emplear tecnologías y soluciones adicionales.
A veces, el IXP también proporciona servicios adicionales a sus participantes:

  • alojan servidores DNS TLD en el IXP,
  • instalan servidores NTP hardware, permitiendo a los participantes sincronizar el tiempo con precisión,
  • ofrecen protección contra ataques DDoS, etc.

Principio de funcionamiento.

Analizaremos el principio de funcionamiento de un punto de intercambio de tráfico utilizando un IXP simplificado, modelado con EVE-NG, y luego revisaremos la configuración básica del enrutador de software BIRD. Para simplificar el esquema, omitiremos cosas importantes como la redundancia y la tolerancia a fallos.

La topología de la red se presenta en la figura a continuación.

Mozilla lanzó el motor de reconocimiento de voz DeepSpeech 0.6.

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

  • emparejamiento público,
  • emparejamiento privado,
  • emparejamiento a través de un router de rutas.

El número de nuestra AS es 555, poseemos un bloque de direcciones IPv4 – 50.50.50.0/24, desde el cual asignamos direcciones IP a quienes deseen conectarse a nuestra red.

50.50.50.254 es la dirección IP configurada en la interfaz del router de rutas. Con esta IP, los clientes establecerán sesiones BGP en caso de emparejamiento a través de RS.

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

Comunidad BGP
Descripción

LOCAL_AS:PEER_AS
Transmitir prefijos solo a PEER_AS

LOCAL_AS:IXP_AS
Transmitir prefijos a todos los participantes del IXP

Tres clientes desean conectarse a nuestro IXP y intercambiar tráfico; supongamos que son proveedores de Internet. Todos ellos desean realizar el emparejamiento a través del router de rutas. A continuación se presenta un esquema con los parámetros de conexión de los clientes:

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

ISP #1
AS 100
1.1.0.0/16
50.50.50.10/24

ISP #2
AS 200
2.2.0.0/16
50.50.50.20/24

ISP #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

Cabe señalar la configuración no bgp enforce-first-as. Por defecto, BGP requiere que el número AS del par BGP que envía la actualización esté presente en el as-path de la actualización BGP recibida. Sin embargo, dado que el servidor de rutas no modifica el as-path, su número estará ausente en el as-path y la actualización será descartada. Esta configuración se aplica para que el enrutador comience a ignorar esta regla.

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

La configuración para los enrutadores de otros clientes será similar, a excepción de sus parámetros únicos.

Ejemplo de configuración 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 martianos, 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 emparejamiento, aplicamos los filtros y políticas correspondientes.

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;
  }
}

Cabe mencionar que en el servidor de rutas es una buena práctica agrupar rutas de diferentes pares en diferentes RIB. BIRD permite hacer esto. En nuestro ejemplo, para simplificar, todas las actualizaciones recibidas de todos los clientes se agrupan en una única RIB.

Entonces, vamos a verificar lo que hemos logrado.

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

Mozilla lanzó el motor de reconocimiento de voz DeepSpeech 0.6.

Observamos que estamos recibiendo prefijos de todos los clientes:

Mozilla lanzó el motor de reconocimiento de voz DeepSpeech 0.6.

En el enrutador AS 100 vemos que, con solo una sesión BGP con el servidor de rutas, estamos recibiendo prefijos tanto de AS 200 como de AS 300, y los atributos BGP no han cambiado, como si el emparejamiento entre clientes se hubiera realizado directamente:

Mozilla lanzó el motor de reconocimiento de voz DeepSpeech 0.6.

Así, vemos que la existencia del servidor de rutas simplifica significativamente la organización de emparejamiento en IXP.

Espero que esta demostración te haya ayudado a entender mejor cómo funcionan los puntos de intercambio de tráfico y cómo opera el servidor de rutas en IXP.

Linxdatacenter IX

En Linxdatacenter hemos construido nuestro propio IXP basado en una infraestructura de alta disponibilidad compuesta por 2 conmutadores y 2 servidores de rutas. Actualmente, nuestro IXP está en modo de prueba, e invitamos a todos los interesados a conectarse a Linxdatacenter IX y participar en las pruebas. Al conectarte, se te proporcionará un puerto con una capacidad de 1 Gbit/s, la posibilidad de emparejamiento a través de nuestros servidores de rutas, así como acceso a la cuenta personal del portal IX, disponible en la dirección ix.linxdatacenter.com.

Escribe en los comentarios o mensajes privados para obtener acceso a las pruebas.

Salida

Los puntos de intercambio de tráfico surgieron en los albores de Internet como una herramienta para resolver el problema del paso no óptimo del tráfico entre operadores de telecomunicaciones. Con la aparición de nuevos servicios globales y el aumento del tráfico de CDN, los puntos de intercambio siguen optimizando la operación de la red global. El aumento en el número de IXPs en el mundo beneficia tanto a los usuarios finales como a los operadores de telecomunicaciones, operadores de contenido, etc. Para los participantes de IXP, los beneficios se traducen en reducción de costos para la organización de emparejamientos externos, disminución del tráfico por el que se debe pagar a los operadores superiores, optimización de la enrutación y la posibilidad de tener un enlace directo con los operadores de contenido.

Enlaces útiles

Fuente: habr.com

Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS 🔥 Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS | ProHoster