Problemas com tráfego de CDN local e anúncios BGP.
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:
Issues with local CDN traffic and BGP advertisements.
Hello. My name is Gabriel, I’m a network analyst here at Made4IT and today I’m going to tell you about an interesting situation involving CDN and traffic engineering that we caught here in the consulting team a few days ago. We received a call from a customer with a case where the traffic of a local CDN had a drastic decrease after a traffic engineering change. After extensive validations by the customer they were unable to find the root cause of this behavior and so they called our team. We started there on 11/04 with a strange decrease in Inbound traffic on the interface with the local CDN. It was very succinct and represented 1Gbps less traffic on the interface. With this info in hand, the first thing I did was access Made4Flow to help understand what happened using of course my favorite graphic, the “Interface by ASN”. I took care to take a time interval contemplating exactly the event from the 3rd to the 4th precisely to understand which ASNs were no longer “served” by the local cache. With that in hand, I noticed 2 things right away: – The “Orange” ASN here is no longer “served” by this CDN, this is due to the decrease in traffic evident in the graph..– The “Blue” ASN(s) (a set of specific ASNs custom configured in our software) also showed a significant decrease in the graph. The “Blue” ASN is who hosts the cache. The ASN “Orange” being also a Made4IT client allowed us a more efficient test within its network. ASN “Azul” and ASN “Orange” as partners gave us total freedom to carry out the troubleshooting and validate what was necessary on both sides. After some checks, we used the content provider’s own tool to validate which “node/cache” was “serving” this traffic that stopped coming from the local CDN of the “Azul” ASN. This traffic no longer comes from the ASN “Azul” CDN, but it needs to come from somewhere, do you agree? In the image above, 2 things caught my attention:– A Node in Guarulhos, referring to this content provider’s network, is the one that started to deliver the traffic that used to come from the local CDN of the “Blue” ASN –x.x.x.x.0/25 ? At the time, a very important piece of information about ads for this content provider’s CDNs came to mind. They obey a rule that says: – Direct ads (ASN hosting cache) node accepts up to /27 for direct influence on traffic engineering and content delivery eligibility.– Indirect advertisements (ASNs adjacent to the ASN hosting the cache) the node only accepts up to /24 for direct influence on traffic engineering and content delivery eligibility. Alright, for the ASN “Azul” traffic I already had the possible cause of the problem. When trying to induce this local node to deliver more traffic, they ended up announcing /25 blocks to the cache node, implying that the content provider network would “serve” this traffic via its nodes in Guarulhos. However, we still have a decrease in traffic on the “Azul” ASN, what happened? The “Blue” ASN in this case was actually 3 ASNs, something that was custom created in the Made4Flow software. Interestingly, 2 of these ASNs were “injecting” /25 prefixes into the CDN node, where the behavior found was exactly the same as the one reported above for the “Orange” ASN. With all this information in hand, we set out to get our hands dirty and adjust the ads respecting what the content provider requests (and has documented) for its CDN. After the necessary adjustments, see the result:
Problemas con el tráfico de CDN local y los anuncios de BGP.
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 CDN e ingeniería de tráfico que captamos 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 la mano, lo primero que hice fue acceder a Made4Flow para ayudar a comprender lo que sucedió usando, por supuesto, 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 se debe a la disminución en el tráfico evidente 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 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é “node/cache” 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, referente a la red de este proveedor de contenidos, es el que comenzó a entregar el tráfico que antes debía provenir de la CDN local de la ASN “Azul” –x.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 “naranja”. 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:
Como configurar CGNAT
Um passo a passo de como configurar um CGNAT
How to configure CGNAT
A step-by-step guide on how to configure a CGNAT
What is CGNAT? (Carrier Grade Network Address Translation)
What is a CGNAT?
¿Qué es CGNAT? (Carrier Grade Network Address Translation)
¿Qué es un CGNAT?
O que é CGNAT? (Carrier Grade Network Address Translation)
O que é um CGNAT?
Solicitação judicial de informações a provedores de internet
Muitos provedores tem duvida de como agir diante da solicitação de informações de clientes por autoridades, aqui definimos algumas boas praticas para que podem auxiliar os provedores em como agir no dia a dia.
Blackhole BGP – Juniper (Juniper MX5/10/40/80/104, MX204, MX240/480/960)
Para resumir a Blackhole, é uma técnica de enviar uma rota para o “buraco negro” ou simplesmente fazer o roteador descartar os pacotes direcionados a esse IP. Nesse artigo você vai aprender o passo a passo de como você pode configurar Blackhole em roteadores Juniper.
