Russian Internet users are unable to access the open Internet

Since June 9, 2025, Internet users located in Russia and connecting to web services protected by Cloudflare have been throttled by Russian Internet Service Providers (ISPs).

As the throttling is being applied by local ISPs, the action is outside of Cloudflare’s control and we are unable, at this time, to restore reliable, high performance access to Cloudflare products and protected websites for Russian users in a lawful manner. 

Internal data analysis suggests that the throttling allows Internet users to load only the first 16 KB of any web asset, rendering most web navigation impossible.

Cloudflare has not received any formal outreach or communication from Russian government entities about the motivation for such an action. Unfortunately, the actions are consistent with longstanding Russian efforts to isolate the Internet within its borders and reduce reliance on Western technology by replacing it with domestic alternatives. Indeed, Russian President Vladimir Putin recently publicly threatened to throttle US tech companies operating inside Russia. 

External reports corroborate our analysis, and further suggest that a number of other service providers are also affected by throttling or other disruptive actions in Russia, including at least Hetzner, DigitalOcean, and OVH.

The impact

Cloudflare is seeing disruptions across Continue reading

Hedge 272: Are we addicted to the CLI?

Is the CLI the best way to configure, manage, and troubleshoot routers and other networking gear? Or should we move past the CLI towards automation and (possibly even) GUI-based tools? Mark Posser joins Russ and Tom to discuss on this episode of the Hedge.
 

 
download
 
For more reading on this topic, please check out this post by Chris Grundemann.

Orange Me2eets: We made an end-to-end encrypted video calling app and it was easy

Developing a new video conferencing application often begins with a peer-to-peer setup using WebRTC, facilitating direct data exchange between clients. While effective for small demonstrations, this method encounters scalability hurdles with increased participants. The data transmission load for each client escalates significantly in proportion to the number of users, as each client is required to send data to every other client except themselves (n-1).

In the scaling of video conferencing applications, Selective Forwarding Units (SFUs) are essential.  Essentially a media stream routing hub, an SFU receives media and data flows from participants and intelligently determines which streams to forward. By strategically distributing media based on network conditions and participant needs, this mechanism minimizes bandwidth usage and greatly enhances scalability. Nearly every video conferencing application today uses SFUs.

In 2024, we announced Cloudflare Realtime (then called Cloudflare Calls), our suite of WebRTC products, and we also released Orange Meets, an open source video chat application built on top of our SFU.

We also realized that use of an SFU often comes with a privacy cost, as there is now a centralized hub that could see and listen to all the media contents, even though its sole job is Continue reading

SwiNOG 40: A Day of Awesomeness

A few days ago, I attended a SwiNOG meeting for the first time and realized what a mistake I was making — I should have been there years ago.

Not only was the event impeccably organized (what else would you expect in Switzerland) and at the best event location I have ever experienced (it’s hard to beat this view), it was also full of short, interesting, up-to-the-point presentations (you can already view the slide decks, YouTube videos should be available shortly). Plus, I met so many old friends I haven’t seen in years, and people I communicated with for years but never met before.

It’s not like the organizers would need any more publicity (the event was sold out), but if you happen to be near Switzerland in time for the next meeting, make sure to be there.

Thanks again to the wonderful SwiNOG core team for a fantastic experience! I hope we’ll meet again at the next SwiNOG meeting!

Switching to eBPF One Step at a Time with Calico DNS Inline Policy

Calico Enterprise lets users write network policies using domain names instead of IP addresses. This is done by dynamically mapping domain names to IP addresses and matching the egress traffic against these IPs. We have discussed this feature in detail when we introduced the Inline mode for the eBPF data plane in Calico Enterprise 3.20 release! It addresses the latency and performance issues of the various modes used by Calico in iptables/nftables data planes. It is a shame that Calico users who are not yet ready to switch completely to eBPF would miss out on this big DNS policy improvement. Don’t worry! We found a way to port it to iptables to enhance our users’ experience without forcing users to make a huge leap.

In Calico Enterprise v3.21, we have extended the Inline DNS policy mode to iptables. In this mode, DNS policies are updated in real time as DNS responses are parsed by eBPF within the data plane, thus improving the performance.

Calico iptables – DNS Inline policy

In all the existing modes in the iptables data plane, the DNS response packets are sent to Felix – Calico’s userspace agent. It parses the packets and updates the Continue reading

Building agents with OpenAI and Cloudflare’s Agents SDK

What even is an Agents SDK?

The AI landscape is evolving at an incredible pace, and with it, the tools and platforms available to developers are becoming more powerful and interconnected than ever. Here at Cloudflare, we're genuinely passionate about empowering you to build the next generation of applications, and that absolutely includes intelligent agents that can reason, act, and interact with the world.

When we talk about "Agents SDKs", it can sometimes feel a bit… fuzzy. Some SDKs (software development kits) described as 'agent' SDKs are really about providing frameworks for tool calling and interacting with models. They're fantastic for defining an agent's "brain" – its intelligence, its ability to reason, and how it uses external tools. Here’s the thing: all these agents need a place to actually run. Then there's what we offer at Cloudflare: an SDK purpose-built to provide a seamless execution layer for agents. While orchestration frameworks define how agents think, our SDK focuses on where they run, abstracting away infrastructure to enable persistent, scalable execution across our global network.

Think of it as the ultimate shell, the place where any agent, defined by any agent SDK (like the powerful new OpenAI Agents SDK), Continue reading

Testing OSPF Device Configurations

A year ago, I described how we use the netlab validate command to test device configuration templates for most platforms supported by netlab. That blog post included a simple “this is how you test interface address configuration” example; now, let’s move to something a bit more complex: baseline OSPF configuration.

Testing the correctness of OSPF configurations seems easy:

  • Build a lab with a test device and a few other OSPF devices
  • Configure the devices
  • Log into the test device and inspect OSPF operational data

There’s just a tiny little fly in this ointment…

Some Thoughts On The Future “Doudna” NERSC-10 Supercomputer

Right or wrong, we still believe that we live in a world where traditional HPC simulation and modeling at high precision matters more than mashing up the sum total of human knowledge and mixing with the digital exhaust of our lives to create a globe-spanning automation that will leave us all with very little to do and a commensurate amount of wealth and power to show for it.

Some Thoughts On The Future “Doudna” NERSC-10 Supercomputer was written by Timothy Prickett Morgan at The Next Platform.

Containers are available in public beta for simple, global, and programmable compute

We’re excited to announce that Cloudflare Containers are now available in beta for all users on paid plans.

You can now run new kinds of applications alongside your Workers. From media and data processing at the edge, to backend services in any language, to CLI tools in batch workloads — Containers open up a world of possibilities.

Containers are tightly integrated with Workers and the rest of the developer platform, which means that:

  • Your workflow stays simple: just define a Container in a few lines of code, and run wrangler deploy, just like you would with a Worker.

  • Containers are global: as with Workers, you just deploy to Region:Earth. No need to manage configs across 5 different regions for a global app.

  • You can use the right tool for the job: routing requests between Workers and Containers is easy. Use a Worker when you need to be ultra light-weight and scalable. Use a Container when you need more power and flexibility.

  • Containers are programmable: container instances are spun up on-demand and controlled by Workers code. If you need custom logic, just write some JavaScript instead of spending time chaining together API calls or writing Kubernetes operators.

Continue reading

Ossification and the Internet

The Internet was deliberately designed as a simple common substrate packet-switched network that could be able to support a huge variety of digital service profiles. The Internet's service profile was defined in the connecting devices at the edge, and not in the switching equipment in the middle of the network. The network model was intentionally so sparse that it was incapable of becoming ossified! How's that turned out?

Quality of OSPFv2 NSSA Implementations

A few weeks ago, we added OSPF areas functionality to netlab. In the next release1, you’ll be able to configure stub areas, NSSA areas, inter-area route summarization and filtering (OSPF ranges), and summarization of NSSA type-7 prefixes for OSPFv2 and OSPFv3.

OSPFv2 (defined in RFC 2328) is 27 years old, and NSSA functionality (RFC 3101) was last touched 22 years ago. One would hope the implementations in network devices are mature and feature-complete. Yeah, keep dreaming 🤦‍♂️.

Autopilot, Muse, Co-author, Editor. How do you use GenAI?

Thoughts on how to use Generative A.I. to write.

If you are not using a GenAI tool, like ChatGPT, you know someone that does.
And you've definitely read hundreds of LinkedIn posts that were entirely written by GenAI.

Did you notice that your colleague who used to write a short update like:

'Met with team for the quarterly review & cupcakes! #yum #teamwork #rockstars #cake'

Suddenly, they seemed to become much more ebullient and flowery in their words, emotional range, and emoji use?

And now, without fail, every post must have a final motivational message to stir the heart (and the Like button).

👩‍⚖️ Exhibit A:

Yes, that post was written without any input from me, no prompting of what the post should contain other than:

Write a LinkedIn post about a meeting

That's it. That's the prompt!

And you don't even need to go that far!
Why waste your words and typing fingers, just go for it super-brief with:

LinkedIn post for today

And...here it is:

With those few words I've got a pretty inspiring response.

  • It's got the earnest, open tone.
  • The bland relatable work-bound troubles: 'blockers' everyone!
  • Hope for the future: 'moving in the right Continue reading

AWS Security Groups, NACL and ENI

AWS Security Groups, NACL and ENI

This is the third blog post in the AWS Networking series. If you have been following along, you can continue with the lab we have built so far. For anyone who has just landed on this page, you can still follow along as long as you are already familiar with the basics of AWS networking. If you are completely new, however, I highly recommend checking out the introductory posts linked below to get up to speed.

In this blog post, we will look at AWS Security Groups, Network ACL (NACL) and Elastic Network Interfaces (ENI).

AWS Networking Fundamentals
If you’re brand new to AWS, don’t worry. This post focuses on the basics of AWS networking. General networking knowledge is helpful but not required - I’ll try to explain things clearly so everyone can follow along.
AWS Security Groups, NACL and ENI
AWS NAT Gateway and Private/Public Subnets
When working with AWS networking, you will often hear the terms ‘public subnet’ and ‘private subnet’. However, if you go into the AWS console to create a subnet, you won’t find any option to explicitly make it one or the other.
AWS Security Groups, NACL and ENI

AWS Security Groups

So far, we have briefly touched on Security Continue reading

AWS NAT Gateway and Private/Public Subnets

AWS NAT Gateway and Private/Public Subnets

When working with AWS networking, you will often hear the terms 'public subnet' and 'private subnet'. However, if you go into the AWS console to create a subnet, you won't find any option to explicitly make it one or the other. So, what exactly makes a subnet public or private?

In this blog post, we will look at the differences between public and private subnets, see how they are defined by their routing, and understand how the AWS NAT Gateway fits into this architecture.

If you are completely new to AWS networking and want to learn the basics of setting up a VPC, feel free to check out my previous post linked below.

AWS Networking Fundamentals
If you’re brand new to AWS, don’t worry. This post focuses on the basics of AWS networking. General networking knowledge is helpful but not required - I’ll try to explain things clearly so everyone can follow along.
AWS NAT Gateway and Private/Public Subnets

Public vs Private Subnets

The key difference between a 'public' and a 'private' subnet is simply its route to the Internet. It is not an inherent setting of the subnet itself, but a behaviour defined by the route table associated Continue reading

Static Routes in netlab Lab Topologies

As much as we’d love everything in our networks to be dynamic, auto-configured, or software-defined, reality often intervenes and forces us to use static routes, so we needed a mechanism to specify them in netlab lab topologies.

A static route has two components: the destination prefix and the next hop – the device that we hope knows how to reach that destination. The next hop is usually specified as an IPv4 or IPv6 address, but may also include outgoing interface information1.

1 2 3 3,793