Curator Reveals Detailed Architecture of Its Network Filtering System After October 2026 Outage

On October 8, 2026, Curator experienced its first major outage in a decade when its entire traffic filtering network became unavailable for 38 minutes. The incident coincided with a separate physical attack on a Yandex data center in Sasovo, though the two events appear unrelated. In its official post-mortem, Curator provided an in-depth look at the architecture of its distributed filtering platform, covering traffic paths, BGP routing, VRF segmentation, and centralized configuration management.

Curator currently maintains nine filtering sites in Russia. Each site consists of multiple filtering nodes connected through high-performance switches to upstream operators. Every node communicates with the switch using two logically separated routing contexts: VRF external and VRF internal. Separate BGP sessions run in each context to exchange routing information.

Unfiltered traffic arrives via VRF external, is processed by the node, and returns cleaned through VRF internal. This separation guarantees that traffic passes through the protection layer in sequence before reaching its destination. The switches also maintain BGP sessions with upstream providers and BGP-connected customers, while all devices connect to an OOB router for independent management access.

Each filtering node runs a custom firewall developed internally by Curator. The firewall operates directly in the Linux kernel and uses proprietary rule syntax optimized for extremely high traffic volumes. Rules are treated as critical configuration because an error can affect not only user traffic but also the routing and monitoring protocols that keep the filtering system itself operational.

A watchdog process on every node continuously checks the health of BGP sessions between the node and the switch. Loss of a monitored session causes the watchdog to remove the node from rotation. While effective for isolating individual failures, this mechanism can cascade if the same condition appears simultaneously across all nodes.

Configuration changes are distributed by the CControl system, which pushes both customer-specific protection parameters and infrastructure settings to all nodes. Centralization eliminates manual per-node updates but creates the risk that a single incorrect change can impact the entire fleet at once.

The outage highlighted the delicate balance required in high-scale filtering networks: performance and rapid configuration must be weighed against the potential for widespread impact when centralized mechanisms fail. Curator stressed the importance of component isolation, staged rollouts, and independent recovery paths to limit the blast radius of future incidents.