Hola. Mi nombre es Gabriel, soy analista de redes aquí en Made4IT y hoy les voy a hablar de una situación interesante que involucra a CDN GGC Google y la ingeniería de tráfico que captamos aquí en el equipo de consultoría hace un 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 la mano, lo primero que hice fue acceder a Made4Flow para ayudar a comprender lo que sucedió usando mi gráfico favorito, la «Interfaz por ASN«.
Tuve cuidado de tomar un intervalo de tiempo contemplando exactamente el evento del 3 al 4 precisamente para entender qué ASN ya no eran «servidos» por el caché local.

Con eso en la mano, noté 2 cosas de inmediato:
– El ASN “Orange” aquí ya no es “servido” por este CDN, esto es un hecho debido a la disminución de tráfico evidente en la gráfica…
– Los ASN «azules» (un conjunto de ASN específicos configurados de forma personalizada en nuestro software) también mostraron una disminución significativa en el gráfico. El ASN «Azul» es quien aloja el caché.
El ASN “Orange” siendo también un cliente de Made4IT nos permitió una prueba más eficiente dentro de su red. ASN “Azul” y ASN “Orange” como socios nos dieron total libertad para llevar a cabo la resolución de problemas y validar lo necesario en ambos lados.
Después de algunas comprobaciones, utilizamos la propia herramienta del proveedor de contenido para validar qué «nodo/caché» estaba «sirviendo» este tráfico que dejó de provenir del CDN local del ASN «Azul».
Este tráfico ya no proviene del ASN «Azul» CDN, sino que debe provenir de algún lugar, ¿está de acuerdo?

En la imagen de arriba, 2 cosas me llamaron la atención:
– Un Nodo en Guarulhos, refiriéndose a la red de este proveedor de contenido, es quien pasó a entregar el tráfico que antes debía provenir del 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:
– El nodo de anuncios directos (caché de alojamiento ASN) acepta hasta /27 para influencia directa en la ingeniería de tráfico y la elegibilidad de entrega de contenido.
– Anuncios indirectos (ASN adyacentes al ASN que aloja el caché), el nodo solo acepta hasta /24 para influencia directa en la ingeniería de tráfico y la elegibilidad de entrega de contenido.
Muy bien, para el tráfico ASN “Azul” ya tenía la posible causa del problema. Al tratar de inducir a este nodo local a entregar más tráfico, terminaron anunciando bloques /25 al nodo de caché, lo que implica que la red del proveedor de contenido “serviría” 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 3 ASN, algo que se creó de forma personalizada en el software Made4Flow. Curiosamente, 2 de estos ASN estaban «inyectando» prefijos /25 en el nodo CDN, donde el comportamiento encontrado fue exactamente el mismo que el informado anteriormente para el ASN «Orange.

Con toda esta información en la mano, nos propusimos poner manos a la obra y ajustar los anuncios respetando lo que el proveedor de contenido solicita (y tiene documentado) para su CDN. Después de los ajustes necesarios, vea el resultado:

Conclusión:
Sabemos que para que un nodo CDN funcione hay varios factores y que implica que los protocolos funcionen de forma orquestada, como BGP, DNS, TCP, entre otros… CDN fuera de rango aceptable.
Cuando anunciamos los bloques /25 de ASN adyacentes al ASN que aloja el nodo/caché, el «jugador» comenzó a entregar tráfico a ese ASN/Prefijo a través de sus nodos CDN desde Guarulhos, lo que implica un aumento de tráfico indirecto en nuestro cliente ASN “Azul” y pérdida de rendimiento y eficiencia del nodo local.

Los usuarios detrás de esta red se vieron directamente afectados ya que su contenido comenzó a ser entregado por una infraestructura 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.
Para la ingeniería de tráfico que contempla CDNs, siempre respete la documentación del reproductor en cuestión y utilice sus herramientas para detectar qué “nodo” está “sirviendo” el tráfico. Por lo general, los reproductores de CDN también tienen un portal para monitorear el rendimiento del caché con métricas y datos muy importantes al respecto, use estas herramientas a su favor.

¿Te pareció interesante y quieres ver un poco más sobre cómo funciona el software que usamos en esta conversación o quieres hablar con un especialista para solucionar problemas como este en tu red? Habla con nuestro equipo
– Gabriel Henrique, analista de redes en Made4IT, ha estado trabajando con tecnología e ISP durante más de 10 años.