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 y la ingeniería de tráfico que abordamos aquí en el equipo de consultoría hace unos días.
Recibimos una llamada de un cliente con un caso en el que el tráfico de un CDN local tuvo una disminución drástica después de un cambio de ingeniería de tráfico. Después de extensas validaciones 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 ocurrido, utilizando, por supuesto, mi gráfico favorito: la«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 concretos dejaron de ser «atendidos» por la caché local.

Con eso en la mano, noté 2 cosas de inmediato:
– El ASN «Laranja» ya no recibe servicio de esta CDN; esto se confirma por la evidente disminución del tráfico que se aprecia en el gráfico.
– 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 hecho de que el ASN «Naranja» fuera también cliente de Made4it nos permitió realizar una prueba más eficaz 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.
Después de algunas comprobaciones, utilizamos la propia herramienta del proveedor de contenido para validar qué «node/cache» estaba «sirviendo» este tráfico que dejó de provenir del CDN local del ASN «Azul».
Ese tráfico ya no procede de la CDN del ASN «Azul», pero tiene que venir de algún sitio, ¿no les parece?

En la imagen de arriba, 2 cosas me llamaron la atención:
– Un nodo situado 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:
– 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 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 para 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 lo que el proveedor de contenidos solicita (y ha documentado) para su CDN. Tras realizar los ajustes pertinentes, observen 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.
Al anunciar 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 en Guarulhos, lo que resultó en un aumento del tráfico indirecto en nuestro «Azul». Cliente ASN y 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.
– 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).