Buenos días. Me llamo Gabriel, soy analista de redes aquí en Made4it y hoy les voy a contar una situación interesante relacionada con la CDN GGC de Google y la ingeniería de tráfico que abordamos aquí en el equipo de consultoría hace algún tiempo.

Recibimos una llamada de un cliente con un caso en el que el tráfico de un CDN local GGC Google tuvo una disminución drástica después de un cambio de ingeniería de tráfico. Después de validaciones exhaustivas por parte del cliente, no pudieron encontrar la causa raíz de este comportamiento, por lo que llamaron a nuestro equipo.
Empezamos allí el 04/11 con una extraña disminución en el tráfico entrante en la interfaz con el CDN local. Fue muy breve y representó 1 Gbps menos de tráfico en la interfaz.

Con esta información en mi poder, lo primero que hice fue acceder a la Made4Flow para ayudarme a comprender lo que había sucedido, utilizando, por supuesto, mi gráfico favorito, el«Interfaz por ASN»
. Me aseguré de seleccionar un intervalo de tiempo que abarcara exactamente el evento ocurrido entre el día 3 y el día 4, precisamente para comprender qué ASN dejaron de ser «atendidos» por la caché local.

Con eso en la mano, noté 2 cosas de inmediato:
– El ASN «Naranja» ha dejado de recibir servicio de esta CDN, lo cual se confirma por la evidente disminución del tráfico que se observa en el gráfico…
– El o los ASN «Azul» (un conjunto de ASN específicos configurados de forma personalizada en nuestro software) también han mostrado una disminución significativa en el gráfico. El ASN «Azul» es el que aloja la caché.
El hecho de que el ASN «Naranja» fuera también cliente de Made4it nos permitió realizar una prueba más eficiente dentro de su red. Al ser socios, el ASN «Azul» y el ASN «Naranja» nos dieron total libertad para llevar a cabo la resolución de problemas y validar lo que fuera necesario en ambos lados.
Tras realizar algunas comprobaciones, utilizamos la herramienta del propio proveedor de contenidos para verificar qué«nodo/caché»estaba «suministrando» ese tráfico que había dejado de llegar a través de la CDN local del ASN «Azul».
Este tráfico dejó de llegar desde la CDN del ASN «Azul», pero tiene que venir de algún sitio, ¿no le parece?

En la imagen anterior, me llamaron la atención dos cosas, a saber:
– Un nodo en Guarulhos, perteneciente a la red de este proveedor de contenidos, es el que ha pasado a gestionar el tráfico que antes debía proceder de la CDN local del ASN «Azul»
– x.x.x.0/25?

En ese momento, me vino a la mente un dato muy importante sobre los anuncios de los CDN de este proveedor de contenido. Obedecen una regla que dice:
– Anuncios directos (ASN que aloja la caché): el nodo acepta hasta /27 para ejercer una influencia directa en la ingeniería de tráfico y cumplir los requisitos para la entrega de contenidos.
– Anuncios indirectos (ASN adyacentes al ASN que aloja la caché): el nodo solo acepta hasta /24 para ejercer influencia directa en la ingeniería de tráfico y determinar la elegibilidad para la entrega de contenido.
Bien, en cuanto al tráfico del ASN «Azul», ya tenía la posible causa del problema. Al intentar inducir a este nodo local a entregar más tráfico, acabaron anunciando bloques /25 al nodo de la caché, lo que implicó que la red del proveedor de contenidos «sirviera» este tráfico a través de sus nodos en Guarulhos.
Sin embargo, todavía tenemos una disminución en el tráfico en el ASN «Azul», ¿qué pasó?
El ASN «Azul», en este caso, era en realidad tres ASN, algo que se creó de forma personalizada en el software Made4Flow. Curiosamente, dos de esos ASN estaban «inyectando» prefijos /25 en el nodo de la CDN, donde el comportamiento observado fue exactamente el mismo que el descrito anteriormente en relación con el ASN «Naranja».

Con toda esta información a nuestra disposición, nos pusimos manos a la obra para ajustar los anuncios de acuerdo con los requisitos que el proveedor de contenidos exige (y ha documentado) para su CDN. Tras realizar los ajustes necesarios, este es el resultado:

Conclusión:
Sabemos que para que un nodo de CDN funcione intervienen diversos factores y que ello implica protocolos que funcionan de manera coordinada, como BGP, DNS, TCP, entre otros… Sin embargo, en este caso, nuestro problema fue una anomalía en el comportamiento al realizarse un anuncio al nodo de la CDN fuera del rango aceptable.
Al anunciar los bloques /25 de ASN adyacentes al ASN que aloja el nodo/caché, el «player» comenzó a entregar el tráfico a dicho ASN/prefijo a través de sus nodos de CDN situados en Guarulhos, lo que supuso un aumento del tráfico indirecto en nuestro cliente ASN «Azul» y una pérdida de rendimiento y eficiencia del nodo local.

Los usuarios de esta red se vieron directamente afectados, ya que su contenido pasó a ser distribuido a través de una infraestructura situada a más de 1000 km de distancia, lo que aumentó la latencia, el tiempo de carga y la experiencia general del usuario.
Luego de ajustes en la ingeniería de tráfico respetando la documentación del proveedor de contenido y las buenas prácticas de BGP, el nodo volvió a comportarse como se esperaba.
En lo que respecta a la ingeniería de tráfico con CDN, respete siempre la documentación del reproductor en cuestión y utilice sus herramientas para detectar qué «nodo» está «suministrando» el tráfico. Normalmente, los reproductores de CDN también disponen de un portal para supervisar el rendimiento de la caché con métricas y datos de gran importancia al respecto; utilice estas herramientas en su beneficio.

¿Le ha parecido interesante y desea conocer un poco más cómo funciona el software que utilizamos en este proceso, o tal vez desea hablar con un especialista para resolver problemas como este en su red? Póngase en contacto con nuestro equipo en
. Gabriel Henrique, analista de redes en Made4it, lleva más de 10 años trabajando en el ámbito de la tecnología y los proveedores de servicios de Internet (ISP).