BIRD on an Open Linux Switch: Mainline Linux, switchdev and Hardware L3 Offload#

Bruno Banelli, Novarq d.o.o.

• Why: This is a real engineering report on the question every open-networking skeptic asks: can a fully Linux-native stack — no SAI, no FPM, no vendor NOS — route at line rate on commodity switching silicon?
• What: BIRD 3.1.7 running on the Novarq Tactical 1000 (LAN969x/Sparx5 silicon, Debian arm64), establishing dual-stack eBGP sessions and installing routes through the standard kernel path. Results: four eBGP sessions up, IPv4 hardware offload at 9.41 Gbit/s of TCP and IPv6 at 9.28 Gbit/s with the switch CPU never seeing transit packets; route changes propagate from peer withdrawal to the Linux FIB in 0.40–0.45 s; a 256-route add/withdraw batch works cleanly (a functional test, not a capacity test).
• How: BIRD exports routes via its kernel protocol over rtnetlink; FIB notifiers drive the LAN969x driver, which programs the ASIC; switchdev carries bridge, VLAN, FDB and multicast state, with neighbour entries supplying next-hop MACs. Explicit BIRD filters keep the kernel table clean; a per-layer observability checklist (birdc, ip -d route, ip -s neigh, captures at receiver and switch CPU) verifies offload.
• Where applicable: Hardware-specific today — the L3 routing driver lives in the Novarq kernel tree, not mainline Sparx5, and two setup steps need care. The architecture and the collaboration gaps (BIRD devs, kernel/switchdev maintainers, open hardware vendors) generalize to the whole open-Linux-switching effort.