
This post is also available in 简体中文, 日本語, Español.

Since my previous blog about Secondary DNS, Cloudflare's DNS traffic has more than doubled from 15.8 trillion DNS queries per month to 38.7 trillion. Our network now spans over 270 cities in over 100 countries, interconnecting with more than 10,000 networks globally. According to w3 stats, “Cloudflare is used as a DNS server provider by 15.3% of all the websites.” This means we have an enormous responsibility to serve DNS in the fastest and most reliable way possible.
Although the response time we have on DNS queries is the most important performance metric, there is another metric that sometimes goes unnoticed. DNS Record Propagation time is how long it takes changes submitted to our API to be reflected in our DNS query responses. Every millisecond counts here as it allows customers to quickly change configuration, making their systems much more agile. Although our DNS propagation pipeline was already known to be very fast, we had identified several improvements that, if implemented, would massively improve performance. In this blog post I’ll explain how we managed to drastically improve our DNS record propagation speed, and the Continue reading
I migrated my blog to Hugo two years ago, and never regretted the decision. At the same time I implemented version control with Git, and started using GitHub (and GitLab for a convoluted set of reasons) to host the blog repository.
After hesitating for way too long, I decided to go one step further and made the blog repository public. The next time a blatant error of mine annoys you fork it, fix my blunder(s), and submit a pull request (or write a comment and I’ll fix stuff like I did in the past).
I migrated my blog to Hugo two years ago, and never regretted the decision. At the same time I implemented version control with Git, and started using GitHub (and GitLab for a convoluted set of reasons) to host the blog repository.
After hesitating for way too long, I decided to go one step further and made the blog repository public. The next time a blatant error of mine annoys you fork it, fix my blunder(s), and submit a pull request (or write a comment and I’ll fix stuff like I did in the past).
I recently got fiber to my house. Yay! So after getting hooked up I started measuring that everything looked sane and performant.
I encountered two issues. Normal people would not notice or be bothered by either of them. But I’m not normal people.
I’m still working on one of the issues (and may not be able to disclose the details anyway, as the root cause may be confidential), so today’s issue is traceroute.
In summary: A bad MPLS config can break traceroute outside of the MPLS network.
$ traceroute -q 1 seattle.gov
traceroute to seattle.gov (156.74.251.21), 30 hops max, 60 byte packets
1 192.168.x.x (192.168.x.x) 0.302 ms <-- my router
2 194.6.x.x.g.network (194.6.x.x) 3.347 ms
3 10.102.3.45 (10.102.3.45) 3.391 ms
4 10.102.2.29 (10.102.2.29) 2.841 ms
5 10.102.2.25 (10.102.2.25) 2.321 ms
6 10.102.1.0 (10.102.1.0) 3.454 ms
7 10.200.200.4 (10.200.200.4) 2. Continue readingCalico Open Source is an industry standard for container security and networking that offers high-performance cloud-native scalability and supports Kubernetes workloads, non-Kubernetes workloads, and legacy workloads. Created and maintained by Tigera, Calico Open Source offers a wide range of support for your choice of data plane whether it’s Windows, eBPF, Linux, or VPP.
We’re excited to announce our new certification course for Azure, Certified Calico Operator: Azure Expert! This free, self-paced course is the latest in our series of four courses. If you haven’t had a chance to complete our previous courses, I highly recommend enrolling in them in the following order (or as you prefer).
Whether you have little to no experience with cloud concepts, have entry-level DevOps and engineering experience, are keen to learn more about Azure or are already an Azure expert looking for a cloud networking and security solution, you will benefit from this course.
The course provides an introduction to Azure cloud, learnings about managed, self-managed and hybrid cluster deployment using Calico in Azure, and offers hands-on labs to help you explore most of Continue reading
This installment of Russ White’s BGP course discusses how the BGP protocol calculates the best path for a route. Topics include: -Routes to discard -Weighting -Shortest AS path -Origin type -Multi-Exit Discriminator (MED) -Oldest eBGP Path -Tiebreakers You can subscribe to the Packet Pushers’ YouTube channel for more videos as they are published. It’s a […]
The post Learning BGP Module 2 Lesson 4: Best Path – Video appeared first on Packet Pushers.
A challenge of large-scale telecom networks is increasing the variety of proprietary hardware and launching new services that may demand the installation of new hardware. This challenge requires additional floor space, power, cooling, and more maintenance. With evolving virtualization technologies in this decade, NFV focuses on addressing the telecom problems by implementing network functions into software that can run on server hardware or hypervisors.
Furthermore, by using NFV, installing new equipment is eliminated and it will be related to the health of underlay servers and the result is lower CAPEX and OPEX.
There are many benefits when operators use NFV in today’s networks. One of them is Reducing time-to-market to deploy new services to support changing business requirements and market opportunities for new services.
Decoupling physical network equipment from the functions that run on them will help telecom companies to consolidate network equipment types onto servers, storage, and switches that are in data centers. In NFV architecture, the responsibility for handling specific network functions (e.g. IPSEC/SSL VPN) that run in one Continue reading
Bilateral Peering is when two networks negotiate with each other and establish a direct BGP peering session. In one of the previous posts, Settlement Free Peering was explained, in this post, both Bilateral and Multilateral Peering will be explained and both are deployment modes of Settlement Free Peering.
This is generally done when there is a large amount of traffic between two networks. Tier 1 Operators just do Bilateral Peering as they don’t want to peer with anyone, other than other Tier 1 Operators. The rest of the companies are their potential customers, not their peers.
As mentioned above, Bilateral Peering offers the most control, but some networks with very open peering policies may wish to simplify the process, and simply “connect with everyone”. To help facilitate this, many Exchange Points offer “multilateral peering exchanges”, or an “MLPE”.
Content Delivery Network companies replicate content caches close to a large user population. They don’t provide Internet access or transit service to the customers or ISPs but distribute the content of the content providers. Today, many Internet Service Providers started their own CDN businesses as well. An example is Level 3. Level 3 provides its CDN services from its POP locations which are spread all over the World.
Content distribution networks reduce latency and increase service resilience (Content is replicated to more than one location). More popular contents are cached locally and the least popular ones can be served from the origin
Before CDNs, the contents were served from the source locations which increased latency, thus reducing throughput. Contents were delivered from the central site. User requests were reaching the central site where the source was located.

Figure 1 – Before CDN

Figure 2 – After CDN
Amazon, Akamai, Limelight, Fastly, and Cloudflare are the largest CDN providers which provide services to different content providers all over the world. Also, some major content providers such Continue reading
I’m usually telling networking engineers seriously considering whether to automate their networks to cleanup their design and simplify the network services first.
The only reasonable way forward is to simplify your processes – get rid of all corner cases, all special deals that are probably costing you more than you earned on them, all one-off kludges to support badly-designed applications – and once you get that done, you might realize you don’t need a magic platform anymore, because you can run your simpler network using traditional tools.
While seasoned automation practitioners agree with me, a lot of enterprise engineers face a different reality. Straight from a source that wished to remain anonymous…
I’m usually telling networking engineers seriously considering whether to automate their networks to cleanup their design and simplify the network services first.
The only reasonable way forward is to simplify your processes – get rid of all corner cases, all special deals that are probably costing you more than you earned on them, all one-off kludges to support badly-designed applications – and once you get that done, you might realize you don’t need a magic platform anymore, because you can run your simpler network using traditional tools.
While seasoned automation practitioners agree with me, a lot of enterprise engineers face a different reality. Straight from a source that wished to remain anonymous…