Frr commercial

SONiC: The King of the Cloud Data Center Originally created by Microsoft to run Azure, SONiC (Software for Open Networking in the Cloud) is the undisputed heavyweight champion of the modern data center.

Architecture: SONiC is built entirely around containers and a centralized Redis database. Every component (BGP, LLDP, SNMP) runs in its own Docker container. If the BGP container crashes, the switch keeps forwarding packets using the routes stored in the Redis DB while the container restarts.

The "SAI" Advantage: SONiC's superpower is the Switch Abstraction Interface (SAI). SAI is an API that allows SONiC to talk to almost any vendor's switching silicon (Broadcom, Mellanox, Cisco, etc.) without changing the core OS.

Best For: Massive Scale-Out Leaf-Spine networks, Kubernetes environments, and cloud providers. If you are building a data center fabric to support thousands of servers and need deep telemetry and automation, SONiC is the industry standard.

DANOS: The Carrier Edge Workhorse Created by AT&T (based on their acquisition of Vyatta), DANOS (Disaggregated Network Operating System) was built specifically for the telecom edge.

Architecture: Unlike SONiC’s database-centric model, DANOS is built around high-performance packet processing in software, heavily utilizing DPDK (Data Plane Development Kit). It is designed to handle complex routing features that simple data center switches usually struggle with.

Telecom Features: Data centers usually just need simple IP routing. Telecoms need deep, complex protocols: MPLS, L2VPN/L3VPN, Carrier-Grade NAT, Hierarchical QoS (throttling specific types of traffic), and cell-tower timing protocols (PTP). DANOS excels here.

Best For: Cell tower aggregation routers, Broadband Network Gateways (the router your home ISP uses to authenticate your modem), and provider edge routers.

XDP

There is no direct XDP equivalent to DANOS—meaning there isn't a single, monolithic "install this ISO and get a Cisco-like CLI" project that runs pure XDP under the hood.

Because XDP (eXpress Data Path) and eBPF are essentially ways to run highly secure, custom C code directly inside the Linux kernel's network driver, the ecosystem is built more like a toolkit than a finished consumer appliance.

However, there are major open-source projects using XDP to build insanely fast routers and load balancers. Here are the biggest ones you should know about, especially given your work with Kubernetes.

1. Cilium (The K8s Heavyweight)

If you are looking for an open-source, production-ready XDP router, Cilium is the undisputed king right now.

While it is primarily known as a Kubernetes CNI (Container Network Interface), it is fundamentally an eBPF/XDP-based distributed router and firewall.

• How it works: Cilium replaces kube-proxy entirely. It attaches XDP programs to your host's network interfaces. When a packet arrives destined for a Kubernetes service, the XDP program routes it or load-balances it before the standard Linux networking stack even wakes up.
• BGP Integration: Cilium now has native BGP support built right in. It can establish peering sessions (just like MetalLB and FRR do) to advertise K8s services, but it handles the actual packet forwarding via eBPF/XDP for massive performance gains.

2. Katran (Meta's Layer 4 Load Balancer)

Open-sourced by Meta (Facebook), Katran is not a full-featured BGP router, but it is the most famous XDP project in existence.

• Meta uses Katran to load-balance traffic to their data centers. It uses XDP to process millions of packets per second on standard Linux servers, entirely stateless.
• If you wanted to build a high-speed VIP (Virtual IP) director without Kubernetes, Katran is the reference architecture.

3. Polycube (The Network Function Framework)

Backed by the Linux Foundation, Polycube is probably the closest thing to a "general purpose" XDP network OS.

• It is a framework that provides ready-to-use network functions (like routers, firewalls, NAT, and bridges) built entirely on eBPF and XDP.
• You can run a daemon on a Linux server and use the Polycube CLI (or REST API) to spin up a virtual XDP-based router, attach physical interfaces to it, and define routing tables.

How people actually build XDP Routers (FRR + XDP)

If a company wants to build an edge router using XDP today, they don't usually look for a pre-built project. They build a hybrid, using the exact tools you are already using.

They split the router into two planes: 1. The Control Plane (FRR): They run FRR to handle the complex BGP math. 2. The Data Plane (XDP): They write a small XDP C program attached to the network card. Its only job is to look at a packet's destination IP, look up the MAC address in an "eBPF Map" (a high-speed memory table), and send it out the right port.

The Glue: FRR has a feature called the FPM (Forwarding Plane Manager). Instead of FRR pushing routes into the standard Linux routing table via Zebra, you configure Zebra to stream those routes to a custom daemon via FPM. That daemon translates the FRR routes and injects them directly into the XDP program's eBPF Map.

The Bottom Line

If you want to play with XDP routing in a lab or a cluster, drop MetalLB and standard kube-proxy, and deploy Cilium with its strict XDP mode enabled. It will give you a hands-on look at how much faster eBPF dataplanes are compared to standard Linux kernel routing.