❓

Routing Asimétrico con ruta del tráfico de ida distinta del de vuelta en fibra Adamo hacia Azure

Wattson 12 agosto 2023 15:41 ✎

⋮

A raíz de una incidencia en los servicios de Microsoft que estoy tratando con Adamo (Velocidad muy baja desde Adamo hacia Azure Storage), he notado que han cambiado su routing/peering y ahora la ruta que sigue el trafico de ida no es la misma que la que sigue el tráfico de vuelta.

He estado buscando información y parece que es algo que se denomina "Asymmetric Routing", aunque no estoy del todo seguro (Los links hacen referencia a Azure ExpressRoute que es un servicio concreto de Microsoft, pero creo que sirve para entender el concepto en general)

Mi pregunta es si en base a los tracerts que pego abajo esto es efectivamente Asymmetric Routing y si es algo habitual o, de lo contrario, si es contraindicado. He leido que puede afectar negativamente a VoIP o videollamadas porque introduce jitter.

Tracert Adamo → Azure (No pongo 2 tracerts porque la única diferencia después que la ruta de vuelta haya cambiado es que la latencia en Espanix ha subido de 8 a 30, que entiendo que también tiene relación).

1 <1 ms <1 ms <1 ms 192.168.1.1
2 5 ms 3 ms 3 ms cli-5b7e7e02.wholesale.adamo.es [91.126.126.2]
3 * * * Tiempo de espera agotado para esta solicitud.
4 31 ms 32 ms 30 ms microsoft.baja.espanix.net [193.149.1.29]
5 36 ms 32 ms 33 ms ae20-0.icr03.par30.ntwk.msn.net [104.44.231.228]
6 35 ms 36 ms 38 ms be-104-0.ibr01.par30.ntwk.msn.net [104.44.23.100]
7 36 ms 36 ms 35 ms be-9-0.ibr02.pnq01.ntwk.msn.net [104.44.16.145]
8 34 ms 39 ms 36 ms be-3-0.ibr03.ams06.ntwk.msn.net [104.44.29.215]
9 36 ms 36 ms 66 ms ae150-0.icr06.ams06.ntwk.msn.net [104.44.32.93]
10 * * * Tiempo de espera agotado para esta solicitud.

Tracert Microsoft Azure → Adamo del 27/07

traceroute to 74.X.X.X (74.X.X.X), 64 hops max
  1   *  *  * 
  2   *  *  * 
  3   *  *  * 
  4   *  *  * 
  5   *  *  * 
  6   *  *  * 
  7   104.44.23.238 (be-124-0.ibr02.ams21.ntwk.msn.net)  24.602ms  24.277ms  24.496ms 
  8   104.44.28.102 (be-14-0.ibr01.fra21.ntwk.msn.net)  46.242ms  46.159ms  46.077ms 
  9   104.44.16.125 (be-2-0.ibr04.ams06.ntwk.msn.net)  24.705ms  24.248ms  24.388ms 
 10   104.44.28.178 (be-13-0.ibr02.par21.ntwk.msn.net)  46.362ms  46.311ms  46.243ms 
 11   104.44.16.18 (be-7-0.ibr03.bl7.ntwk.msn.net)  24.745ms  24.302ms  24.400ms 
 12   104.44.29.217 (be-34-0.ibr01.bio70.ntwk.msn.net)  46.123ms  46.025ms  46.063ms 
 13   104.44.29.152 (be-7-0.ibr01.par30.ntwk.msn.net)  46.311ms  45.825ms  48.155ms 
 14   193.149.1.82 (adamo.baja.espanix.net)  24.065ms  34.503ms  23.922ms 
 15   104.44.231.229 (ae20-0.mad30-96cbe-1a.ntwk.msn.net)  47.714ms  47.505ms  47.406ms 
 16   74.X.X.X (cli-XXXXX.wholesale.adamo.es)  32.577ms !X  30.688ms !X  30.787ms !X

Tracert Microsoft Azure → Adamo del 12/08

traceroute to 74.X.X.X (74.X.X.X), 64 hops max
  1   *  *  * 
  2   *  *  * 
  3   *  *  * 
  4   *  *  * 
  5   *  *  * 
  6   *  *  * 
  7   104.44.235.157 (ae26-0.ier01.amb.ntwk.msn.net)  1.105ms  4.843ms  1.778ms 
  8   154.14.37.245 (ae22.cr3-ams1.ip4.gtt.net)  1.057ms  0.991ms  0.863ms 
  9   89.149.143.182 (et-1-0-35.cr7-mad4.ip4.gtt.net)  35.846ms  28.575ms  33.676ms 
 10   154.14.153.90 (ip4.gtt.net)  29.630ms  29.630ms  34.227ms 
 11   74.X.X.X (cli-XXXXXX.wholesale.adamo.es)  33.985ms  41.948ms  31.915ms

Parece como si Microsoft ahora no supiese que puede llegar a Adamo a través de Espanix directo y entonces lo manda por proveedor de tránsito.

Oihalitz 12 agosto 2023 15:54

⋮

Yo para algunos clientes suelo usar enrutamiento asimétrico, sobretodo cuando me dicen que tienen que subir una cantidad grande de archivos.

El enrutamiento amiento asimétrico a mi siempre me ha dado bastante dolores de cabeza

✖

Wattson 12 agosto 2023 16:12

⋮

Puede servir para usar una ruta de mayor capacidad aunque no sea la más óptima? Y que ventajas podría tener hacerlo asimétrico en vez de cambiar el routing en ambos sentidos? Gracias

✖

Oihalitz 12 agosto 2023 16:23

⋮

Yo uso path para que entre, gracias a que Path tiene el mejor antiddos del mercado, y que salga por aire, ya sea porque en ese momento tenga el puerto de path saturado, o que el cliente requiera una mejor ruta

rbetancor 12 agosto 2023 16:30

⋮

El routing asimétrico no es nada raro en el mundo de los operadores … ya que tú solo puedes decidir cual es el siguiente "salto" al que entregas tu tráfico … nada más, hay técnicas para "influenciar", por donde te entra el tráfico, pero es solo eso, influenciar, no puedes controlarlo al 100% (Nota para NetAdmins: lo sé, estoy simplificando un huevo y medio, no hace falta sacar la daga)

Lo que estás viendo en esas trazas, simplemente evidencia que Adamo tiene una política de routing (y ni siquiera tiene que ser específica para Azure) y que M$ tiene otra diferente, nada raro bajo el horizonte.

✖

Wattson 12 agosto 2023 18:55

⋮

Entiendo que la decisión de a donde enviar el tráfico depende de cada red y del posible acuerdo entre las partes.

En este caso concreto Microsoft esta utilizando una ruta diferente pero parece que contradiciendo su propia política para interconexion en IXP learn.microsoft.com/en-us/azure/internet…exchange-all

Por favor corrígeme si me equivoco pero entiendo, según el diagrama, que Microsoft debería tener una sesión BGP para que el tráfico fuera por el puerto de interconexion y no por GTT u otros Transit Carrier.

Gracias por responder. Me resulta muy útil para entender mejor este tema.

✖

rbetancor 12 agosto 2023 19:13

⋮

No te equivocas … pero ¿sabes acaso el estado del puerto en IX en ese momento que hiciste las pruebas? … o alguna ruta interna de M$ hacia ese IX … es la "magia" del routing … se evalua H2H (Hop 2 Hop) … así que salvo configuraciones altamente complicadas o políticas de routing dinámicas (según carga, servicio, puertos, distancia, etc.), poco puedes inferir sobre el routing de dos pares y se tiende a simplificar, pensando que lo que te sale en el tracert … es "la ruta" …

✖

Wattson 12 agosto 2023 19:27

⋮

Gracias. Quiero pensar que al haber una incidencia abierta por problemas de velocidad en esa interconexion esto puede ser simplemente un paso más dentro del troubleshooting.

Otra pregunta: Podría el ISP origen evitar o influenciar que MSFT no le mande tráfico por un link concreto si dicho ISP deja de anunciar sus prefijos a MSFT en BGP o me estoy liando?

✖

rbetancor 12 agosto 2023 20:08

⋮

andressis2k 13 agosto 2023 10:55

⋮

100% de acuerdo.

El routing asimétrico es el pan de cada día. Miles y miles de rutas tienen diferentes caminos de subida y bajada y ello no representa ningún problema.

Lo que has leido que podría llegar a suponer un problema por introducir jitteres el ECMP. (equal-cost multi path) Es decir, si Adamo y Microsoft tienen 2 conexiones (pongamos en Espanix (Madrid) y en AMSIX (Amsterdam) y decidieran aplicar el mismo coste a ambas. En ese caso, unos paquetes irían por Madrid (con una latencia) y otros por Amsterdam (con otra diferente). Eso si podría ser fuente de problemas

Pero no es para nada el caso que nos aplica

El motivo de que Microsoft esté entregando mediante GTT puede ser:

a) Adamo ha dejado de anunciarles la ruta por Espanix, para evitar saturación de alguna de las partes: En ese caso, Microsoft por narices tiene que utilizar otras rutas

b) Adamo le ha indicado a Microsoft que prefiere no recibir tráfico por la sesión de Espanix. Para esto se utiliza un atributo llamado MED (Multi-Exit-Discriminator). El 90% de los grandes proveedores se lo pasan por el forro. "Yo soy Microsoft y tu un mindundi. Me vas a decir tu a mi por donde tengo que enrutar…"

c) Microsoft ha decidido, porque si, dejar de mandarle tráfico a Adamo a través de Espanix. En este caso, no hay nada que Adamo pueda hacer para que el tráfico vuelva por ahí

Flipo un poco con que Adamo sólo tenga un puerto 10G en Espanix:

peeringdb.com/net/1989

Viendo eso, te diría que es más que probable la A

✖

Mani 13 agosto 2023 12:06

⋮

¿Dónde se puede mirar la cantidad de puertos que tienen los operadores y su transferencia? Me gustaría comparar entre operadores y cuál tiene más ancho de banda disponible en los centros de tráfico.

✖

andressis2k 13 agosto 2023 14:30

⋮

En la web que he linkado antes: peeringdb.com

Es la más utilizada mundialmente para establecer relaciones de peering. Eso sí, cada operador rellena su ficha. Es decir, alguien podría poner que tiene 10 puertos 100G en Espanix sin tenerlos. Pero generalmente es muy fideligno a la realidad (a nadie le interesa mentir ahí)

También puede haber miembros que, aun teniendo puertos en algún IX, no los anuncien. Por ejemplo, Telefónica se sabe que está en Espanix, pero sólo ellos (y Espanix) saben cuántos puertos y de qué capacidad

En cuanto a los niveles de tráfico, no suele ser un dato público. Sólo el operador y el punto de intercambio tienen acceso a esas métricas

✖

Mani 13 agosto 2023 16:13

⋮

Wattson 14 agosto 2023 16:22

⋮

Gracias por la respuesta.

Había una incidencia con el tráfico de entrada de Microsoft hacia Adamo, que no pasaba de 300KB/s en ningún momento del día.

Me imagino que hayan dejado de anunciar la ruta para hacer troubleshooting y de hecho ahora la velocidad es de 10MB/s.

Lo que entiendo es que tanto a Adamo como a Microsoft les interesaría que la ruta directa funcionara bien porque sino alguno de los dos está pagando tráfico adicional a GTT.

Sobre el puerto 10GB, es poco comparado con cualquier otro, no sé si es porque también están en Catnix y hacen peering allí con los mismos que en Espanix que estén presentes.