{"id":19231,"date":"2022-05-17T11:42:00","date_gmt":"2022-05-17T11:42:00","guid":{"rendered":"https:\/\/made4it.com.br\/blog\/issues-with-local-cdn-traffic-google-ggc-and-bgp-ads\/"},"modified":"2026-07-01T15:15:42","modified_gmt":"2026-07-01T15:15:42","slug":"issues-with-local-cdn-traffic-google-ggc-and-bgp-ads","status":"publish","type":"post","link":"https:\/\/made4it.com.br\/en\/blog\/issues-with-local-cdn-traffic-google-ggc-and-bgp-ads\/","title":{"rendered":"Issues with local CDN traffic (Google GGC) and BGP ads"},"content":{"rendered":"\n

Hello. My name is Gabriel; I’m a network analyst here at Made4it, and today I’m going to talk about an interesting situation involving Google’s GGC CDN and traffic engineering that our consulting team handled a while back. We received a call from a customer with a case where traffic from a local CDN GGC Google had a drastic decrease after a traffic engineering change.<\/strong> 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. <\/p>\n\n

\"\"<\/a><\/figure>\n\n

With that information in hand, the first thing I did was go to the Made4Flow <\/strong> <\/a>to help me understand what happened, using, of course, my favorite graph, the\u201cInterface by ASN\u201d<\/em>. I made sure to select a time range covering exactly the event from the 3rd to the 4th, specifically to understand which ASNs were no longer being \u201cserved\u201d by the local cache. <\/p>\n\n

\"\"<\/a><\/figure>\n\n

With that in hand, I noticed 2 things right away:– The \u201cOrange\u201d ASN is no longer being \u201cserved\u201d by this CDN; this is evident from the clear drop in traffic shown in the graph…– The \u201cBlue\u201d ASN(s) (a set of specific ASNs configured customarily in our software) also showed a significant decrease in the graph. The \u201cBlue\u201d ASN is the one hosting the cache. <\/em>The fact that ASN \u201cOrange\u201d is also a Made4it customer allowed us to conduct a more efficient test within its network. Since ASN \u201cBlue\u201d and ASN \u201cOrange\u201d are partners, they gave us complete freedom to troubleshoot and <\/em>validate whatever was necessary on both sides. After some checks, we used the content provider\u2019s own tool to determine which\u201cnode\/cache\u201d<\/em>was \u201cserving\u201d the traffic that was no longer coming through ASN \u201cBlue\u2019s\u201d local CDN. This traffic stopped coming from the \u201cAzul\u201d ASN\u2019s CDN, but it has to be coming from somewhere, don\u2019t you agree? <\/p>\n\n

\"\"<\/a><\/figure>\n\n

In the image above, two things caught my attention:– A node in Guarulhos, part of this content provider\u2019s network, is now delivering the traffic that was previously supposed to come from the local CDN of the \u201cAzul\u201d ASN– x.x.x.0\/25?<\/strong><\/em><\/p>\n\n

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 announcements (ASN hosting the cache): The node accepts up to \/27 for direct influence on traffic engineering and eligibility for content delivery.<\/strong> – Indirect announcements (ASNs adjacent to the ASN hosting the cache): the node accepts only up to \/24 for direct influence on traffic engineering and eligibility for content delivery.<\/strong>Great, for traffic from ASN \u201cAzul,\u201d I already had the possible cause of the problem. When they tried to get this local node to deliver more traffic, they ended up announcing \/25 blocks to the cache node, causing the content provider\u2019s network to \u201cserve\u201d this traffic via its nodes in Guarulhos. However, we still have a decrease in traffic on the \u201cAzul\u201d ASN, what happened? The \u201cBlue\u201d ASN in this case was actually three ASNs, a configuration that was custom-built within the Made4Flow software. Interestingly, two of these ASNs were \u201cinjecting\u201d \/25 prefixes into the CDN node, where the behavior observed was exactly the same as that reported above for the \u201cOrange\u201d ASN. <\/p>\n\n

With all this information in hand, we set out to get to work and adjust the ads in accordance with the content provider\u2019s requirements (which are documented) for its CDN. After making the necessary adjustments, here\u2019s the result: <\/p>\n\n

\"\"<\/a><\/figure>\n\n

Conclusion:<\/strong>We know that for a CDN node to function, there are several factors involved, and that it requires protocols\u2014such as BGP, DNS, and TCP, among others\u2014to work in an orchestrated manner\u2026 however, in this case, our problem was an unexpected behavior when an announcement was made to the CDN node outside the acceptable range.When we announce the \/25<\/strong> blocks of ASNs adjacent to the ASN hosting the node\/cache, the \u201cplayer\u201d began delivering traffic to that ASN\/prefix via its CDN nodes in Guarulhos<\/strong>, resulting in an increase in indirect traffic on our client ASN \u201cAzul\u201d and a loss of performance and efficiency for the local node.<\/p>\n\n

Users of this network were directly affected because their content began to be delivered via infrastructure located more than 1,000 km away, increasing latency, load times, and the overall user experience. After adjustments in traffic engineering respecting the content provider’s documentation and good BGP practices, the node started to behave again as expected. When designing traffic flow for CDNs, always follow the documentation provided by the specific CDN and use its tools to determine which \u201cnode\u201d is \u201cserving\u201d the traffic. CDN providers typically also offer a portal for monitoring cache performance, complete with critical metrics and data; use these tools to your advantage. <\/p>\n\n

Did you find this interesting and want to learn a little more about how the software we use in this process works, or would you like to talk to an expert to resolve issues like this on your network? Contact our team<\/a> at<\/strong> \u2014 Gabriel Henrique, a Network Analyst at Made4it, has been working with technology and ISPs for over 10 years.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

Hello. My name is Gabriel; I’m a network analyst here at Made4it, and today I’m going to talk about an interesting situation involving Google’s GGC CDN and traffic engineering that our consulting team handled a while back. We received a call from a customer with a case where traffic from a local CDN GGC Google 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 that information in hand, the first thing I did was go to the Made4Flow to help me understand what happened, using, of course, my favorite graph, the\u201cInterface by ASN\u201d. I made sure to select a time range covering exactly the event from the 3rd to the 4th, specifically to understand which ASNs were no longer being \u201cserved\u201d by the local cache. With that in hand, I noticed 2 things right away:– The \u201cOrange\u201d ASN is no longer being \u201cserved\u201d by this CDN; this is evident from the clear drop in traffic shown in the graph…– The \u201cBlue\u201d ASN(s) (a set of specific ASNs configured customarily in our software) also showed a significant decrease in the graph. The \u201cBlue\u201d ASN is the one hosting the cache. The fact that ASN \u201cOrange\u201d is also a Made4it customer allowed us to conduct a more efficient test within its network. Since ASN \u201cBlue\u201d and ASN \u201cOrange\u201d are partners, they gave us complete freedom to troubleshoot and validate whatever was necessary on both sides. After some checks, we used the content provider\u2019s own tool to determine which\u201cnode\/cache\u201dwas \u201cserving\u201d the traffic that was no longer coming through ASN \u201cBlue\u2019s\u201d local CDN. This traffic stopped coming from the \u201cAzul\u201d ASN\u2019s CDN, but it has to be coming from somewhere, don\u2019t you agree? In the image above, two things caught my attention:– A node in Guarulhos, part of this content provider\u2019s network, is now delivering the traffic that was previously supposed to come from the local CDN of the \u201cAzul\u201d ASN– 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 announcements (ASN hosting the cache): The node accepts up to \/27 for direct influence on traffic engineering and eligibility for content delivery. – Indirect announcements (ASNs adjacent to the ASN hosting the cache): the node accepts only up to \/24 for direct influence on traffic engineering and eligibility for content delivery.Great, for traffic from ASN \u201cAzul,\u201d I already had the possible cause of the problem. When they tried to get this local node to deliver more traffic, they ended up announcing \/25 blocks to the cache node, causing the content provider\u2019s network to \u201cserve\u201d this traffic via its nodes in Guarulhos. However, we still have a decrease in traffic on the \u201cAzul\u201d ASN, what happened? The \u201cBlue\u201d ASN in this case was actually three ASNs, a configuration that was custom-built within the Made4Flow software. Interestingly, two of these ASNs were \u201cinjecting\u201d \/25 prefixes into the CDN node, where the behavior observed was exactly the same as that reported above for the \u201cOrange\u201d ASN. With all this information in hand, we set out to get to work and adjust the ads in accordance with the content provider\u2019s requirements (which are documented) for its CDN. After making the necessary adjustments, here\u2019s the result: Conclusion:We know that for a CDN node to function, there are several factors involved, and that it requires protocols\u2014such as BGP, DNS, and TCP, among others\u2014to work in an orchestrated manner\u2026 however, in this case, our problem was an unexpected behavior when an announcement was made to the CDN node outside the acceptable range.When we announce the \/25 blocks of ASNs adjacent to the ASN hosting the node\/cache, the \u201cplayer\u201d began delivering traffic to that ASN\/prefix via its CDN nodes in Guarulhos, resulting in an increase in indirect traffic on our client ASN \u201cAzul\u201d and a loss of performance and efficiency for the local node. Users of this network were directly affected because their content began to be delivered via infrastructure located more than 1,000 km away, increasing latency, load times, and the overall user experience. After adjustments in traffic engineering respecting the content provider’s documentation and good BGP practices, the node started to behave again as expected. When designing traffic flow for CDNs, always follow the documentation provided by the specific CDN and use its tools to determine which \u201cnode\u201d is \u201cserving\u201d the traffic. CDN providers typically also offer a portal for monitoring cache performance, complete with critical metrics and data; use these tools to your advantage. Did you find this interesting and want to learn a little more about how the software we use in this process works, or would you like to talk to an expert to resolve issues like this on your network? Contact our team at \u2014 Gabriel Henrique, a Network Analyst at Made4it, has been working with technology and ISPs for over 10 years.<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[31],"tags":[1514,1515,1022,1024],"class_list":["post-19231","post","type-post","status-publish","format-standard","hentry","category-nao-categorizado","tag-cdn","tag-cdn-local","tag-cdn-traffic-2","tag-google-traffic"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t