

Whether you are building a global network or buying groceries, some rules of sustainable living remain the same: be thoughtful about what you get, make the most out of what you have, and try to upcycle your waste rather than throwing it away. These rules are central to Cloudflare — we take helping build a better Internet seriously, and we define this as not just having the most secure, reliable, and performant network — but also the most sustainable one.
With incredible growth of the Internet, and the increased usage of Cloudflare’s network, even linear improvements to sustainability in our hardware today will result in exponential gains in the future. We want to use this post to outline how we think about the sustainability impact of the hardware in our network, and what we’re doing to continually mitigate that impact.
The total carbon footprint of a server is approximately 6 tons of Carbon Dioxide equivalent (CO2eq) when used in the US. There are four parts to the carbon footprint of any computing device:
The emissions from the Continue reading


Once a year, we pull data from our Bot Fight Mode to determine the number of trees we can donate to our partners at One Tree Planted. It's part of the commitment we made in 2019 to deter malicious bots online by redirecting them to a challenge page that requires them to perform computationally intensive, but meaningless tasks. While we use these tasks to drive up the bill for bot operators, we account for the carbon cost by planting trees.
This year when we pulled the numbers, we saw something exciting. While the number of bot detections has gone significantly up, the time bots spend in the Bot Fight Mode challenge page has gone way down. We’ve observed that bot operators are giving up quickly, and moving on to other, unprotected targets. Bot Fight Mode is getting smarter at detecting bots and more efficient at deterring bot operators, and that’s a win for Cloudflare and the environment.
We’ve seen two changes this year in the Bot Fight Mode results. First, the time attackers spend in Bot Fight Mode challenges has reduced by 166%. Many bot operators are disconnecting almost immediately now from Cloudflare challenge pages. We expect this Continue reading
Whether it is something as simple as what kind of coffee to order for your commute to the office, which route to take to avoid traffic, or in my case, whether to support the USA or England in the 2022 world cup group stage game, we all make a myriad of choices every day.
One of the most exciting announcements from the last AWS re:Invent was the Elastic Network Adapter (ENA) Express functionality that uses the Scalable Reliable Datagram (SRD) protocol as the transport protocol for the overlay virtual networks. AWS claims ENA Express can push 25 Gbps over a single TCP flow and that SRD improves the tail latency (99.9 percentile) for high-throughput workloads by 85%.
Ignoring the “DPUs could change the network forever” blogosphere reactions (hint: they won’t), let’s see what could be happening behind the scenes and why SRD improves TCP throughput and tail latency.
One of the most exciting announcements from the last AWS re:Invent was the Elastic Network Adapter (ENA) Express functionality that uses the Scalable Reliable Datagram (SRD) protocol as the transport protocol for the overlay virtual networks. AWS claims ENA Express can push 25 Gbps over a single TCP flow and that SRD improves the tail latency (99.9 percentile) for high-throughput workloads by 85%.
Ignoring the “DPUs could change the network forever” blogosphere reactions (hint: they won’t), let’s see what could be happening behind the scenes and why SRD improves TCP throughput and tail latency.
When choosing an underlay for an EVPN/VXAN network, the prevailing wisdom is that BGP is the best choice for the underlay routing protocol. And overall, I think that’s true. But OSPF can make a compelling underlay too, as it has a few logistical advantages over BGP in certain cases.
When building out EVPN/VXLAN networks, I like to break the build into four components. They are layers that are built one-by-one on top of each other.
This article is exclusively about the underlay portion. It’s a very simple routed network that has one job, and job only:
Provide routes to enable IP connectivity from any loopbacks on a device to any loopback on any other device.
That’s it.
In normal operation the routing table will be incredibly static. The only time the routing table would change is when a switch is added or removed, or a link goes down, or a switch is upgraded, etc. In regular operation it won’t change.
The underlay is important, but the underlay isn’t Continue reading
What can we learn from a Microsoft study of switch failures in its data centers? Hardware failures are more common that software failures, the law of large numbers can overwhelm your resiliency and redundancy planning, and open-source software can be admirably robust.
The post Thoughts On Switch Failures appeared first on Packet Pushers.
With the NSX 4.0.1.1 release, Migration Coordinator adds two game-changing features that help simplify workload migration in the case of lift and shift migration mode. These features build on top of the User Defined Topology mode of migration and add one more config mode. Folks familiar with the User Defined Topology will find the workflow very similar with the added benefit of simplified workload migration, leveraging HCX.
In this blog post, we will look at this new feature and how to take advantage of it. Please check out the resource links for more information on Migration Coordinator. We will start with a high-level overview before digging into the details.
Migration Coordinator was introduced with NSX-T 2.4 to enable customers to migrate from NSX for vSphere to NSX-T Data Center. It’s a free, fully supported tool that’s built into NSX-T Data Center. Migration Coordinator is flexible with multiple options enabling multiple ways to migrate based on customer requirements. The first release provided a way to migrate everything, including config, workloads, and hosts in place using the same hardware if the deployed topology matched the supported topologies. Starting with the NSX-T 3. Continue reading
Today's Full Stack Journey podcast welcomes software engineer Kat Morgan to discuss finding and following passion projects---which for Kat include KubeVirt and UOR Framework. Scott and Kat have a technical and entertaining conversation about how pursuing passion projects can inform, shape, and create career opportunities.
The post Full Stack Journey 073: Finding And Following Technical Passion Projects appeared first on Packet Pushers.