Olá. Meu nome é Gabriel, sou analista de redes aqui na Made4IT e hoje vou contar sobre uma situação interessante envolvendo CDN e engenharia de tráfego que pegamos aqui no time de consultoria alguns dias atrás.
Recebemos um acionamento de um cliente com um case onde o tráfego de uma CDN local teve um decremento drástico após uma alteração de engenharia de tráfego. Depois de validações extensas pelo cliente não conseguiram achar a causa primária deste comportamento e então acionaram nosso time.
Começamos lá no dia 04/11 com um decremento estranho no tráfego de Inbound na interface com o CDN local. Foi bem sucinto e representou 1Gbps de tráfego a menos na interface.
Com essa info em mãos, a primeira coisa que fiz foi acessar o Made4Flow pra auxiliar a entender o que aconteceu usando claro meu gráfico favorito, o “Interface por ASN”.
Tomei o cuidado de pegar um intervalo de tempo contemplando exatamente o evento do dia 03 ao dia 04 justamente para entender quais ASNs exatamente deixaram de ser “servidos” pelo cache local.
Com isso em mãos, de cara já notei 2 coisas:
– O ASN “Laranja” aqui deixou de ser “servido” por essa CDN, isso é fato pelo decremento de tráfego evidente no gráfico..
– O(s) ASN(s) “Azul” (um conjunto de ASNs específicos configurados de maneira personalizada em nosso software) também mostraram um decremento significativo no gráfico. O ASN “Azul” é quem hospeda o cache.
O ASN “Laranja” sendo também cliente da Made4IT nos permitiu um teste mais eficiente dentro de sua rede. O ASN “Azul” e ASN “Laranja” por serem parceiros nos deram total liberdade para conduzir o troubleshooting e validar o que fosse necessário em ambos os lados.
Depois de algumas verificações, usamos a ferramenta do próprio provedor de conteúdo para validar qual “node/cache” estava “servindo” esse tráfego que deixou de vir pela CDN local do ASN “Azul”.
Esse tráfego deixou de vir da CDN do ASN “Azul” mas, precisa vir de algum lugar concordam?
Na imagem acima, 2 coisas me chamaram a atenção sendo:
– Um Node em Guarulhos, referente a rede desse provedor de conteúdo, é quem passou a entregar o tráfego que antes deveria vir na CDN local do ASN “Azul”
– x.x.x.0/25 ?
Na hora me acendeu a luz para um dado importantíssimo sobre anúncios para as CDNs desse provedor de conteúdo. Eles obedecem uma regra que diz:
– Anúncios diretos (ASN que hospeda o cache) o node aceita até /27 para influência direta na engenharia de tráfego e elegibilidade para entrega de conteúdo.
– Anúncios indiretos (ASNs adjacentes ao ASN que hospeda o cache) o node aceita apenas até /24 para influência direta na engenharia de tráfego e elegibilidade para entrega de conteúdo.
Beleza, para o tráfego do ASN “Azul” eu já tinha a possível causa do problema. Ao tentarem induzir esse nodo local a entregar mais tráfego, acabaram por anunciar blocos /25 ao node do cache implicando na rede do provedor de conteúdo “servir” este tráfego via seus nodes em Guarulhos.
Porém, ainda temos um decremento de tráfego no ASN “Azul”, o que aconteceu ?
O ASN “Azul” nesse caso na verdade era 3 ASNs, algo que foi criado de maneira customizada no software Made4Flow. Curiosamente, 2 desses ASNs estavam “injetando” prefixos /25 no node da CDN, aonde o comportamento encontrado foi exatamente igual ao relatado acima do ASN “Laranja.” Com todas essas informações em mãos, partimos colocar a mão na massa e ajustar os anúncios respeitando o que o provedor de conteúdo solicita (e tem documentado) para sua CDN. Após os devidos ajustes, vejam o resultado:
Conclusão:
Sabemos que para um node de CDN funcionar existem diversos fatores e que envolve protocolos trabalhando de maneira orquestrada sendo eles o BGP, DNS, TCP, dentre outros… porém, nesse caso, nosso problema foi um desvio de comportamento quando feito um anúncio ao node da CDN fora do range aceitável.
Ao anunciarmos os blocos /25 de ASNs adjacentes do ASN que hospeda o node/cache, o “player” passou a entregar o tráfego para esse ASN/Prefixo via seus nodes de CDN lá de Guarulhos, implicando em um aumento de tráfego indireto no nosso cliente ASN “Azul” e perda de performance e eficiência do node local.
Os usuários atrás dessa rede foram diretamente afetados uma vez que seu conteúdo passou a ser entregue por uma infraestrutura a mais de 1000kms de distância, incrementando latência, tempo de carregamento e experiência geral do usuário.
Após os ajustes na engenharia de tráfego respeitando a documentação do provedor de conteúdo e boas práticas de BGP, o node passou a se comportar novamente como esperado.
Para engenharia de tráfego contemplando CDNs, sempre respeitar a documentação do player em questão e usar as ferramentas do mesmo para detectar qual “node” está “servindo “ o tráfego. Normalmente players de CDN também dispõe de portal para acompanhamento da performance do cache com métricas e dados importantíssimos sobre o mesmo, usem essas ferramentas ao seu favor.
– Gabriel Henrique, Analista de Redes na Made4IT, trabalha a mais de 10 anos com tecnologia e ISPs.
