Open Source Routing and Switching for Whitebox Networks

Whitebox networking sounds simple from a distance.

Buy merchant-silicon switches, install an open network operating system, and stop depending on a traditional hardware vendor for every feature.

In practice, the hardware is only one layer.

The real decision is the operating model: who owns the network operating system, routing stack, switch abstraction, automation, validation, observability, and support path.

The whitebox stack in one picture

Whitebox networking separates the layers that traditional vendors usually bundle together.

That separation gives control, but it also moves responsibility back to the operator.

You are no longer buying only a switch.

You are assembling a network platform.

What belongs where

The common mistake is comparing every open source network package as if each one is a full replacement for a commercial switch operating system.

They are not the same kind of thing.

Layer	Projects to know	What they are for
Switch network operating system	SONiC, DENT, ONL-derived stacks	Running switching hardware as a network device.
Routing protocol suite	FRRouting, BIRD	BGP, OSPF, IS-IS, EVPN, route policy, peering.
Virtual switching	Open vSwitch	VM, container, hypervisor, overlay, and programmable virtual switching.
ASIC abstraction	SAI	Vendor-neutral API between NOS and switching silicon.
Edge/router platform	VyOS	Router, firewall, VPN, cloud, lab, and edge deployments.

The question is not "which one is best?"

The better question is:

Which layer am I trying to own, and which layer do I still need supported by someone else?

SONiC: the serious whitebox data center NOS

SONiC is the most important name to know in open whitebox data center switching.

It is a Linux-based open source network operating system that runs on switches from multiple vendors and ASICs.

Its appeal is clear: one software model across different hardware platforms, with a community around data center switching, BGP, RDMA, telemetry, and fabric operations.

Where it fits:

leaf-spine data center fabrics
large-scale routing and switching environments
teams that want hardware choice without giving up a full NOS model
environments where BGP, EVPN/VXLAN, telemetry, and automation matter

What to respect:

hardware support is still specific, not magical
platform validation matters before purchase
upgrades need lab testing
optics, buffering, QoS, warm reboot, and telemetry behavior must be verified
enterprise support may come from an ecosystem vendor, not the community alone

SONiC is not "Linux plus a few packages."

It is a full switching NOS, and it should be treated with the same discipline as any production switch operating system.

FRRouting: the routing engine behind many open designs

FRRouting, often called FRR, is a routing protocol suite for Unix and Linux platforms.

It supports the protocols network engineers expect in real environments: BGP, OSPF, IS-IS, BFD, PIM, EVPN, and more depending on release and build.

FRR is important because many open network stacks use it as the routing control-plane engine.

Where it fits:

BGP speakers
route reflectors
lab fabrics
Linux routers
EVPN control plane
network appliances
whitebox NOS routing services

What to respect:

FRR is not the whole switch operating system
kernel integration and datapath behavior still matter
route scale and convergence must be tested
configuration style differs from vendor NOS muscle memory
operational tooling around logs, reload, config validation, and rollback is essential

FRR is often the control-plane brain.

It still needs a reliable body around it.

Open vSwitch: virtual switching, not a leaf switch NOS

Open vSwitch is a production-quality, multilayer virtual switch.

It is common in virtualization, cloud, network function virtualization, lab, tunneling, and automation-heavy environments.

Where it fits:

hypervisor switching
virtual machine networking
container and lab networking
tunneling and overlay experiments
OpenFlow and programmable switching use cases
virtual network function test beds

Where it does not fit directly:

replacing a full physical switch NOS by itself
running a merchant-silicon hardware switch without the required platform layer
solving optics, ASIC, port, buffer, and hardware lifecycle problems

Open vSwitch is a strong tool in the open networking toolbox.

It is not the same category as SONiC.

DENT: Linux-first switching for distributed edge

DENT is a Linux Foundation project focused on a Linux-based network operating system for disaggregated switching, especially distributed enterprise and edge use cases.

Its design direction is different from the hyperscale data center story.

DENT leans into Linux kernel networking, switchdev, and a simplified open NOS model.

Where it fits:

retail and distributed enterprise edge
campus and branch switching experiments
Linux-native network operations
environments that want switchdev-style integration

What to respect:

ecosystem maturity and hardware fit must be checked carefully
edge switching requirements are different from data center leaf-spine
support model matters if the site count is large
operational simplicity is the value, not feature maximalism

DENT is worth watching when the target is not a large data center fabric but a repeatable edge switching model.

SAI: the abstraction layer most people forget

Switch Abstraction Interface, or SAI, is not a routing daemon and not a user-facing NOS.

It is an API intended to give software a vendor-neutral way to program switching ASICs and forwarding elements.

That matters because whitebox networking depends on decoupling hardware from software.

Without a stable abstraction boundary, every switch silicon family becomes a custom integration problem.

Where it fits:

NOS to ASIC integration
multi-ASIC ecosystem development
SONiC-style hardware abstraction
vendor-neutral forwarding programming

What to respect:

abstraction does not remove hardware differences
features still depend on ASIC capability and SDK behavior
counters, buffers, QoS, ECMP, ACLs, and telemetry must be validated on the target platform

SAI is part of why whitebox switching is possible at scale.

It is also why platform testing cannot be skipped.

VyOS and BIRD: routing platforms outside the switch NOS lane

VyOS is an open source network operating system for routing, firewall, VPN, bare metal, cloud, and edge use cases.

It is often a better fit when the device is a router or firewall-like appliance rather than a top-of-rack hardware switch.

BIRD is a routing daemon widely associated with route servers, internet exchanges, route policy, and large routing-table environments.

Where they fit:

Project	Best fit
VyOS	router, firewall, VPN, virtual router, cloud edge, lab edge
BIRD	route server, route reflector-like policy use, BGP-heavy environments

What to respect:

these are not physical switch ASIC operating systems
packet forwarding path matters as much as routing table correctness
support and release model should match production risk
for high-throughput appliances, data-plane acceleration must be validated

These tools are valuable, but they answer a different problem from "run this whitebox switch as a data center leaf."

ONL: important historically, limited as a current platform bet

Open Network Linux, or ONL, was important in the early whitebox ecosystem as a Linux distribution for bare-metal switches and an Open Compute Project reference network operating system.

Today, treat it carefully.

The Open Compute Project page describes the ONL project as moved to maintenance mode pending archival.

That does not erase its historical value.

It does change how you should think about new production bets.

Where it fits:

understanding the whitebox history
legacy or inherited stacks
platform-layer reference work
lab work where the hardware support path is already known

What to avoid:

choosing maintenance-mode software as the center of a new enterprise switching strategy without a very specific reason
assuming old whitebox ecosystem energy equals current operational support

A practical selection map

Use the target environment to narrow the stack.

Environment	Sensible starting point	Why
Hyperscale-style data center leaf-spine	SONiC plus FRR	NOS model with strong routing control-plane alignment.
Enterprise data center whitebox pilot	SONiC with supported hardware SKU	Reduces hardware/software uncertainty.
Distributed edge switching	DENT, if hardware and support fit	Linux-native model aimed at edge switching.
Virtualized cloud host switching	Open vSwitch	Designed for virtual switching and automation.
Router, firewall, VPN, cloud edge	VyOS	Router platform rather than switch NOS.
Route server or routing-policy-heavy node	BIRD or FRR	Choose based on policy model, team familiarity, and ecosystem.
ASIC abstraction work	SAI	API layer, not an operator-facing NOS.

Do not start with the software name.

Start with the device role.

The operational checklist

Whitebox success depends on lifecycle controls.

Before choosing a package, answer these questions:

Area	Question
Hardware	Which exact switch, ASIC, port speeds, optics, and fans are supported?
Install	Is ONIE install, rescue, and reinstall tested?
Routing	Which protocol features are required on day one?
Switching	Are VLANs, MLAG, EVPN/VXLAN, QoS, ACLs, and telemetry validated?
Automation	Can configuration be generated, diffed, reviewed, deployed, and rolled back?
Observability	Are logs, counters, interface state, route state, and hardware drops visible?
Upgrade	Can you test image upgrade, rollback, and config migration before production?
Support	Who takes the call when the ASIC, NOS, optics, and routing daemon disagree?

The last question is the one that separates a lab from a platform.

What to avoid

Avoid these traps:

buying hardware before validating NOS support
treating community support as a production support contract
mixing multiple NOS models without a lifecycle reason
assuming BGP working in a lab proves switch dataplane readiness
ignoring optics, buffering, counters, and warm reboot behavior
building a fabric with no golden config, rollback, or telemetry baseline
chasing open source purity when the business needs predictable operations

Open networking is not free operations.

It trades vendor lock-in for engineering ownership.

That can be a good trade, but only when the ownership is real.

References

The useful primary references are:

The bottom line

Whitebox networking is strongest when the design is narrow and honest.

Use SONiC when you need a serious open switching NOS.

Use FRRouting or BIRD when the routing stack is the center of the problem.

Use Open vSwitch for virtual switching.

Use VyOS for router, firewall, VPN, and edge roles.

Use DENT where Linux-native distributed edge switching fits.

And use SAI as the abstraction concept that makes much of this ecosystem possible.

The winning design is not the one with the most open source names in the diagram.

It is the one your team can operate, upgrade, troubleshoot, and support under pressure.