Inside Gen 13: how we built our most powerful server yet

A few months ago, Cloudflare announced the transition to FL2, our Rust-based rewrite of Cloudflare's core request handling layer. This transition accelerates our ability to help build a better Internet for everyone. With the migration in the software stack, Cloudflare has refreshed our server hardware design with improved hardware capabilities and better efficiency to serve the evolving demands of our network and software stack. Gen 13 is designed with 192-core AMD EPYC™ Turin 9965 processor, 768 GB of DDR5-6400 memory, 24 TB of PCIe 5.0 NVMe storage, and dual 100 GbE port network interface card.

Gen 13 delivers:

• Up to 2x throughput compared to Gen 12 while staying within latency SLA

• Up to 50% improvement in performance / watt efficiency, reducing data center expansion costs

• Up to 60% higher throughput per rack keeping rack power budget constant

• 2x memory capacity, 1.5x storage capacity, 4x network bandwidth

• Introduced PCIe encryption hardware support in addition to memory encryption

• Improved support for thermally demanding powerful drop-in PCIe accelerators

This blog post covers the engineering rationale behind each major component selection: what we evaluated, what we chose, and why.

ASPA: The cryptographic upgrade for BGP path security

The Internet routing security story of the past decade has largely been about fixing route origins. RPKI Route Origin Validation (ROV) gave operators a cryptographic way to verify that the AS announcing a prefix was actually authorized to do so. That work has now reached majority coverage, with over half of all IPv4 and IPv6 routes now protected by Route Origin Authorizations (ROAs).

But origin validation only tells you where a route claims to start. It says nothing about the path it took to get to you. A route can have a perfectly valid origin and still arrive via a completely illegitimate chain of ASes, through a misconfigured transit network, a malicious route leak, or a manipulated AS_PATH. This gap is exactly what ASPA (Autonomous System Provider Authorization) is designed to close.

ASPA has moved from theory into early operational deployment, even though the core ASPA profile and verification work remain in IETF draft form as of March 2026. ARIN and RIPE NCC both support ASPA object creation in production. Major networks have begun deploying ASPA validation globally. Router implementations exist in BIRD and OpenBGPD. This article is intended to explain what ASPA is, how it works technically, what it Continue reading

netlab: Switch to Lab Directory After an SSH Session Loss

I work on a laptop that loves to power down when not used (the right thing to do), which often breaks the SSH session to my netlab server (not so good).

Reconnecting is trivial. Figuring out which lab I was working on and where it lives on the disk after a few hours? That’s the annoying part.

We solved most of that ages ago with the netlab status --all command. It shows all running labs¹ and their directories, so you can quickly jump back to where you were. However, even that gets tedious the 100th time you have to do it.

Introducing AI Assistant for Calico, Calico Load Balancer, and Seamless VM-to-Kubernetes Migration

SAN JOSE, Calif., March 23, 2026 — Tigera, the creator and maintainer of Project Calico, today announced a major expansion of its Unified Network Security Platform for Kubernetes, aimed at helping enterprises consolidate infrastructure and accelerate the migration of legacy workloads to cloud-native platforms.

The new capabilities include:

• Al Assistant for Calico: A proactive, conversational intelligence layer that replaces complex manual log analysis with natural-language troubleshooting and proactive security audits.
• Calico Load Balancer: A high-performance, eBPF-based, software-defined load balancer that replaces expensive, rigid hardware appliances with a Kubernetes-native solution.
• Seamless VM-to-Kubernetes Migration: Advanced Layer 2 (L2) networking support eliminates migration friction by allowing virtual machines to move into Kubernetes clusters without changing their original IP addresses or existing VLAN dependencies.

These innovations help organizations tackle the rising “complexity tax” in managing high-scale Kubernetes clusters and provide a high-velocity path to consolidate virtual machines and containers into a single, standardized platform.

Secure and Scale VMware VKS with Calico Kubernetes Networking

VMware vSphere Kubernetes Service (VKS) is the CNCF-certified Kubernetes runtime built directly into VMware Cloud Foundation (VCF), which delivers a single platform for both virtual machines and containers. VKS enables platform engineers to deploy, manage, and scale Kubernetes clusters while leveraging a comprehensive set of cloud services. And with VKS v3.6, that foundation just got significantly more powerful: VKS now natively supports Calico Enterprise — part of the Calico Unified Platform — as a validated, lifecycle-managed networking add-on through the new VKS Addon Framework. This integration is a key milestone in VMware’s expanded partnerships across the Kubernetes ecosystem, ensuring customers have access to best-in-class networking and security tools.

Even better, VKS natively integrates Calico Open Source by Tigera as a supported, out-of-the-box Container Network Interface (CNI). This gives organizations a powerful open source baseline right from day one:

• Pluggable Data Planes: The flexibility to run high-performance eBPF, standard Linux iptables, modern nftables, or Windows data planes based on specific workload needs.
• Wire-Speed Routing: Direct BGP peering with the underlying VMware NSX infrastructure, eliminating the performance overhead of traditional overlay networks.
• Foundational Zero-Trust: Global Continue reading

400G Over Multimode Fiber: BiDi Changes the Game

For anyone who has managed a data center fiber plant over the past decade, the arrival of 400 Gigabit Ethernet came with a painful side effect: singlemode fiber. If your…

The post 400G Over Multimode Fiber: BiDi Changes the Game appeared first on AboutNetworks.net.

Calculate “1/(40rods/​hogshead) → L/100km” from your Zsh prompt

I often need a quick calculation or a unit conversion. Rather than reaching for a separate tool, a few lines of Zsh configuration turn = into a calculator. Typing = 660km / (2/3)c * 2 -> ms gives me 6.60457 ms¹ without leaving my terminal, thanks to the Zsh line editor.

The equal alias

The main idea looks simple: define = as an alias to a calculator command. I prefer Numbat, a scientific calculator that supports unit conversions. Qalculate is a close second.² If neither is available, we fall back to Zsh’s built-in zcalc module.

As the alias built-in uses = as a separator for name and value, we need to alter the aliases associative array:

if (( $+commands[numbat] )); then
  aliases[=]='numbat -e'
elif (( $+commands[qalc] )); then
  aliases[=]='qalc'
else
  autoload -Uz zcalc
  aliases[=]='zcalc -f -e'
fi

With this in place, = 847/11 becomes numbat -e 847/11.

The quoting problem

The first problem surfaces quickly. Typing = 5 * 3 fails: Zsh expands the * character as a glob Continue reading

Calico Load Balancer: Simplifying Network Traffic Management with eBPF

Authors: Alex O’Regan, Aadhil Abdul Majeed

Ever had a load balancer become the bottleneck in an on-prem Kubernetes cluster? You are not alone. Traditional hardware load balancers add cost, create coordination overhead, and can make scaling painful. A Kubernetes-native approach can overcome many of those challenges by pushing load balancing into the cluster data plane. Calico Load Balancer is an eBPF powered Kubernetes-native load balancer that uses consistent hashing (Maglev) and Direct Server Return (DSR) to keep sessions stable while allowing you to scale on-demand.

Below is a developer-focused walkthrough: what problem Calico Load Balancer solves, how Maglev consistent hashing works, the life of a packet with DSR, and a clear configuration workflow you can follow to roll it out.

Why a Kubernetes-native load balancer matters

On-prem clusters often rely on dedicated hardware or proprietary appliances to expose services. That comes with a few persistent problems:

• Cost and scaling friction – You have to scale the network load balancer vertically as the size and throughput requirements of your Kubernetes cluster/s grows.
• Operational overhead – Virtual IPs (VIPs) are often owned by another team, so simple service changes require coordination.
• Stateful failure modes – Kube-proxy load balancing is stateful per node, Continue reading

Lift-and-Shift VMs to Kubernetes with Calico L2 Bridge Networks

HN819: Recipes for Automation – A Look Inside Eric Chou’s AI Networking Cookbook

TNO058: Detect. Prove. Predict. Turning Network Monitoring Into Operational Intelligence (Sponsored)

Why flat Kubernetes networks fail at scale

Rethinking network security hierarchies for cloud-native platforms Kubernetes networking is powerful. Its flexibility lets teams connect hundreds of microservices across namespaces, clusters, and environments. But as platforms grow, that same flexibility can turn a neat setup into a tangled, fragile system. For many organizations, networking is where friction shows up first. Engineers struggle to debug connectivity issues. Security teams wrestle with enforcing global controls. Platform architects feel the pressure to prove compliance. And most of these headaches come from a common root cause: flat network security models that don’t scale. The limits of flat networking Kubernetes NetworkPolicy gives teams a way to control traffic between workloads. By default, all policies exist at the same level with no built-in manageable priority. “As policies grow, it’s increasingly hard to predict what will happen when you make a change.” That works fine in a small, single-team cluster. But in large, multi-team environments, it quickly becomes risky. In a flat model, security is managed by exception rather than enforcement. Protecting a critical service often means listing every allowed connection and hoping nothing else accidentally overrides it. As policies grow, it’s increasingly hard to predict what will happen when you make a change. Without Continue reading

Technology Short Take 192

Welcome to Technology Short Take #192! Who’s interested in some links to data center technology-related articles and posts? If that’s you, you’re in the right place. Here’s hoping you find something useful!

Networking

• Interested in an autonomous network engineering agent powered by Claude? (Hat tip to Russ S. for sending this my way.)

Security

• Google’s Threat Intelligence Group recently published some details around Coruna, an iOS exploit kit targeting a range of iOS versions and equipped with a number of potential exploits.
• As an example of one of the challenges around “default” secuity settings, Rory McCune highlights the fact that MicroK8s does not enable role-based access control.
• Bryce Kerley explains Web PKI—the infrastructure that powers secure connections on the modern Web.
• Mike Masnick writes about the massive surveillance stack hiding inside the “age verification” checks.

Cloud Computing/Cloud Management

• I’ve had this article on AWS Lambda for the containers developer sitting in my read queue since first publication in 2023. (Sorry, Massimo.) I finally got around to reading it—really reading it, not just skimming it—and I found it to be helpful in helping me get a better grasp on Lambda.
• The AWS Load Balancer Controller recently gained Continue reading

Deprecated AS_SET: Why the IETF changed the rules of BGP aggregation.

For over three decades, BGP’s AS_SET path segment has been a legal, if problematic, feature of Internet routing. In May 2025, the IETF formally ended that era. RFC 9774 doesn’t merely discourage AS_SET: it prohibits it entirely.

This post unpacks what AS_SET is, why it was created, what went wrong, and what network operators need to do now that the IETF has made its deprecation a binding standard requirement.

Background: What is the AS_PATH attribute?

Every BGP UPDATE message carries an AS_PATHattribute – a record of the Autonomous Systems a route advertisement has traversed on its way from origin to destination. It serves two critical functions: loop prevention (a router seeing its own AS in the path discards the route) and policy (operators use AS_PATH to make routing decisions based on where traffic comes from or how it’s being forwarded.

The AS_PATH is composed of path segments, each of which is one of four types:

Type	Description	Status
AS_SEQUENCE	An ordered list of ASes the route has passed through. The most common and well-understood type.	Valid
AS_SET	An unordered set of ASes created during route aggregation. Now deprecated.	Deprecated
AS_CONFED_SEQUENCE	Ordered list of Member AS Numbers within a Continue reading

Lab: Anycast Gateways on VXLAN Segments

Most vendors “discovered” anycast gateways when they tried implementing routing between MAC-VRFs in an EVPN environment and hit all the usual tripwires (more about that later). A few exceptions (like Arista) supported them on VLAN segments for over a decade, and it was a no-brainer to extend that support to VXLAN segments.

Want to try out how that works? The Anycast Gateways on VXLAN Segments lab exercise is just what you need.

You can run the lab on your own netlab-enabled infrastructure (more details), but also within a free GitHub Codespace or even on your Apple-silicon Mac (installation, using Arista cEOS container, using VXLAN/EVPN labs).

AI Assistant for Calico: Troubleshooting at the Speed of Thought

Despite the wealth of data available, distilling a coherent narrative from a Kubernetes cluster remains a challenge for modern infrastructure teams. Even with powerful visualization tools like the Policy Board, Service Graph, and specialized dashboards, users often find themselves spending significant time piecing together context across different screens. Making good use of this data to secure a cluster or troubleshoot an issue becomes nearly impossible when it requires manually searching across multiple sources to find a single “connecting thread.”

Inevitably, security holes happen, configurations conflict causing outages, and teams scramble to find that needle-in-the-haystack cause of cluster instability. A new approach is needed to understand the complex layers of security and the interconnected relationships among numerous microservices. Observability tools need to not only organize and present data in a coherent manner but proactively help to filter and interpret it, cutting through the noise to get to the heart of an issue. As we discussed in our 2026 outlook on the rise of AI agents, this represents a fundamental shift in Kubernetes management.

Powering the agents: Workers AI now runs large models, starting with Kimi K2.5

We're making Cloudflare the best place for building and deploying agents. But reliable agents aren't built on prompts alone; they require a robust, coordinated infrastructure of underlying primitives.

At Cloudflare, we have been building these primitives for years: Durable Objects for state persistence, Workflows for long running tasks, and Dynamic Workers or Sandbox containers for secure execution. Powerful abstractions like the Agents SDK are designed to help you build agents on top of Cloudflare’s Developer Platform.

But these primitives only provided the execution environment. The agent still needed a model capable of powering it. 

Starting today, Workers AI is officially in the big models game. We now offer frontier open-source models on our AI inference platform. We’re starting by releasing Moonshot AI’s Kimi K2.5 model on Workers AI. With a full 256k context window and support for multi-turn tool calling, vision inputs, and structured outputs, the Kimi K2.5 model is excellent for all kinds of agentic tasks. By bringing a frontier-scale model directly into the Cloudflare Developer Platform, we’re making it possible to run the entire agent lifecycle on a single, unified platform.

The heart of an agent is the AI model that powers it, and that Continue reading

Driving Down The AI System Roadmap With Nvidia

N4N051: MPLS Fundamentals

IPB196: Is End-to-End Connectivity the Right Goal?