ClickHouse Sharding and Replication in NFA

Noction Flow Analyzer (NFA) uses ClickHouse to store and analyze traffic information collected from NetFlow, sFlow, IPFIX, J-Flow, and NetStream exporters. In a typical installation, the ClickHouse database runs on the same server as NFA. This arrangement keeps deployment and administration relatively simple, and it works well when the server has enough resources for incoming data, historical storage, and analytical queries.

Larger monitoring environments can have different requirements. A growing number of exporters, longer retention periods, or more demanding reports may put increasing pressure on the database server. Some operators also want a second copy of their stored traffic data so that an individual storage-node failure doesn’t leave the dataset inaccessible.

NFA’s sharding-enabled ClickHouse architecture addresses these requirements by supporting multiple database shards and replicas. The implementation retains a single-node default configuration. Additional ClickHouse servers can be introduced when storage capacity or redundancy becomes a concern, without requiring a complete NFA application installation on every database node. The architecture covers both flow data and BGP routing information. Each uses a sharding key based on its own record attributes, while the underlying distributed storage and replication mechanisms remain the same.

Starting with the existing NFA database structure

NFA uses MySQL for Continue reading

Agents aren’t humans (but they kinda are)

AI Agents now act on the web for millions of people. To a Site, an Agent can take many forms. It may be indistinguishable from a human user carrying out a task, or it might look like one visitor carrying many Users. This removes the ability for the Site to recognize, serve, and hold accountable the user or users behind the Agent, and causes the Site to face the costs when something goes wrong. This post argues that in order for Sites to maximize the access they provide to Agents, the ecosystem must develop new mechanisms to preserve the relationship between Sites and Users. Traditionally, in Security and Fraud Prevention, that requires three things: Identity, Reputation, and Accountability, allowing Sites to answer: Is the person acting being truthful about who they are? Is that person trustworthy? And who answers for the action?

“Personal AI Agents” (“Agents” for short) are automations that take instructions from a human (“User”) and pursue a goal by controlling a cloud computer or browser. They are usually hosted and maintained by an “Operator” as part of a managed service or consumer offering. Examples include Muse from Meta and dots from OpenAI, and more are launching all Continue reading

The Control Plane: BGP EVPN/VXLAN for AI Fabrics

This post discusses the application of BGP EVPN/VXLAN in AI data center networking, particularly focusing on back-end GPU fabrics. It emphasizes that single-tenant setups may not require VXLAN overlays, while multi-tenant environments benefit from logical segmentation. Key insights include the preference for Symmetric IRB over Asymmetric and the relevance of Type 5 routes for subnet aggregation.

The post The Control Plane: BGP EVPN/VXLAN for AI Fabrics appeared first on /overlaid.

See the agents, set the terms: new visibility and control for personal agents

Personal agents are the intermediary between humans and the Internet, turning a person’s instructions into requests and actions on websites. A customer might ask a personal agent to compare products across your site, find support articles, or complete a purchase. To a site owner, all three interactions show up as automated traffic — and without a clear view of which agents are visiting and what they are doing, it can be difficult to know whether that traffic is helping your business or creating risk. Blocking agents altogether can feel like the safest choice, but it can mean losing customers. Better visibility into agent activity allows you to decide what access makes sense for your site.

Today, we’re launching new analytics to help you understand how personal agents access your site on behalf of humans, along with more granular access policies to put those decisions into practice. Together, they let you welcome agents on your own terms, and in ways that support your business.

See how agents access your site

Knowing which agent is behind a request turns unexplained automated traffic into traffic you can act on with confidence. Cloudflare maintains the largest verified bot directory in the world, and we are Continue reading

Candidate and Active Configuration on IOS XR

Traditional network devices used a single (active or running) configuration, with a snapshot of it stored in permanent memory (startup configuration). The active configuration was modified with every configuration command, making it a perfect recipe for disaster in the days of in-band configuration1.

The situation improved drastically when Juniper introduced the candidate configuration. You could make changes to a copy of the configuration, and then commit them as a single all-or-nothing transaction. While you could still cut yourself off from the device, at least it was harder to do with a single misordered command.

Read more …

Detecting incast congestion of RDMA flows

The recently released open source GitHub project, ai-monitor, is a proof of concept demonstrating that real-time sFlow telemetry can detect and characterize incast RoCEv2 RDMA flow collisions between GPUs during AI training. 
docker run -p 6343:6343/udp -p 8008:8008 sflow/ai-monitor
The pre-built sflow/ai-monitor image is the quickest way to try out the software. The diagram at the top of this page shows test RDMA flows crossing a 4 leaf / 2 spine test network to generate an incast collision. The flows are displayed using the trace-flow application that is included in the image.

The ai-monitor application uses packet samples to detect when GPU port is oversubscribed:

  1. Detect when an leaf switch egress port utilization exceeds 80%
  2. Count the number of sources sending traffic to the port - single flows are ignored
  3. Trace each of the flows back across the topology to its source GPU

The instant the threshold is crossed, the following incast_congestion event is generated by querying information maintained within the sFlow-RT analytics engine. Real-time elephant flow monitoring in AI / ML fabrics describes how standard sFlow from data center switches streams real-time telemetry that can be used to detect elephant flows with a few milliseconds.

{
 "event":  Continue reading

Introducing Zero Wire, a hub for investigating critical Internet vulnerabilities

You run security at your organization. It’s 7:00 am, and you’re having breakfast. You receive a ping: a new critical vulnerability has been disclosed. Your team scrambles to compare vendor advisories, read technical research, check which systems run the affected software, and answer familiar questions from the business: are we affected, and what are we doing about it? Another disclosure arrives before that work is finished.

AI is changing both the volume and speed of critical vulnerability discovery. It can analyze large codebases at scale and surface deeply nested flaws that may have existed for years without being found through human review. That discovery momentum will put more pressure on security teams to understand the impact of each disclosure on their infrastructure.

To help security teams prepare, today we’re introducing Zero Wire: a public vulnerability intelligence feed on Cloudflare Radar, bringing the clarity of a news wire service to critical security developments. It helps security leaders and practitioners understand significant vulnerabilities and decide what to do next.

How it works

Zero Wire lives inside Cloudflare Radar under the security section.

Each briefing brings together a plain-language explanation of the vulnerability, who should investigate it, recommended actions, and links to Continue reading

Help Me Make the BGP Labs Even Better

I decided to add “Further Reading” sections to BGP lab exercises, containing links to vendor documentation and useful related blog posts. I naively expected to offload the job to Claude, commit the results, and move on. The “related blog posts” were a piece of cake; precise links to relevant vendor documentation turned out to be more of a challenge.

TL&DR: I would love to get your suggestions for further reading as PRs in the BGP Labs repo.

Apart from FRRouting, the vendor documentation is mostly generated from whatever internal system and uses auto-generated anchors that can change at any moment – somewhat “suboptimal” for what I wanted to do.

Read more …

What a ‘Kill Switch’ Actually Means for Your Agent Fleet

In short, in the five weeks to 27th October 2026, Okta, Satya Nadella, the Cloud Security Alliance and Salesforce each put the words “kill switch” or “emergency brake” next to AI agents, and the AI Kill Switch Act, introduced in the US House on 23rd July, would require the largest model providers to be able to throttle, suspend or shut their systems down on order. Every one of those switches stops something, and none of them stops the same thing. Pull the switch on an agent in your cluster and read what is still true a minute later: the Deployment has replaced the pod, the callers are retrying, the open sessions are still open, and the key in the agent’s environment still works. A kill switch for a fleet is a set of cuts at points the agent does not control, and the only way to know which ones you hold is to pull them. This post reads the bill and the UK NCSC’s advice for what a stop has to do, runs a drill through the five switches teams reach for, then says what a governance layer like Tigera Lynx can and cannot do about it. It is written Continue reading

How we halved DNS build delay and cut memory use by 85%

When I last wrote about our DNS propagation pipeline in 2022, the Zone Builder received about 250 DNS record changes per second. Today it receives about 700, nearly three times as many, plus about 100 other events, such as zone setting changes. However, the number of events was never the real problem. The problem was the kind of work some of those events needed, and how that work grows with the size of a zone. Some zones now hold more than 20 million records, and we expect them to keep growing toward hundreds of millions.

Each event starts a clock that measures how long it takes us to turn that change into data our authoritative DNS servers can use. We call that work a build. A build reads the current database state, converts it into the format used at the edge, and writes any changes to Quicksilver.

In 2022, per-record builds were 150 times faster than full builds on average. On a test zone with one million records, per-record builds were 4,250 times faster. We ended that post with the obvious next step: do the same thing for zone settings.

Why doesn't the Zone Builder just rebuild the setting Continue reading

1 2 3 4 … 3,920