Most teams approach open networking the way they read a switch datasheet: they line up feature columns, tick off BGP, EVPN, QoS, and telemetry, and pick whatever checks the most boxes. That comparison misses the two things that actually decide the outcome, which layer of the network you are replacing and whether your team and your hardware can run a Linux network OS at all. This guide is a rubric for scoring your real environment before you look at any product, because a networking move is a hardware-and-operations shift, not an appliance swap.
Start with the layer, not the NOS
Before you shortlist anything, answer one question that splits the whole decision in two: is this the data-center fabric or the edge and routing layer? They point at different targets and there is no single tool that does both well. Then write down what you are actually running: your switch ASICs and their models, the routing and overlay features you truly depend on (BGP, OSPF, EVPN Type-2 and Type-5, QoS policies, ACLs), your device count and growth curve, and an honest read of your team’s Linux and automation skills. Those inputs, not any NOS feature list, decide the answer.
The factors that scope the target
- Layer and role. Fabric switching (whitebox or Broadcom-ASIC leaf/spine) points toward SONiC. Routing, edge, WAN, NAT, and VPN roles point toward VyOS. Do not try to make VyOS a top-of-rack switch or SONiC an edge router; scoping the target to the role comes before everything else.
- Hardware compatibility. This is the gating question for a fabric move. Confirm your switch ASIC is on the target NOS’s hardware support list before anything else, because an unsupported ASIC ends the conversation regardless of features.
- In-house Linux-NOS skills. An open NOS is a Linux system you operate, not an appliance you configure. Be realistic about whether your team can debug FRR, read a Redis-backed config, and script with Ansible at 2am. A cheaper NOS your staff cannot run is not cheaper.
- Feature needs. For each capability you rely on (EVPN underlay-and-overlay, QoS, specific ACL behavior, streaming telemetry), confirm the candidate has a real equivalent. There is no automatic converter from IOS, Junos, or EOS, so each feature is rebuilt from the intended design, not pasted across.
- Scale and operations you take on. Removing per-device licensing means assembling the observability, automation, and support the vendor used to provide. That day-two cost is real and belongs in the comparison, especially for small teams or fabrics that lean on niche vendor features.
Which NOS fits which role
Score your environment first, then use these as starting points. A whitebox or Broadcom-based leaf/spine fabric with a team that can operate Linux and wants open BGP/EVPN underlay-and-overlay usually looks first at SONiC. Routing, edge, WAN, firewall, and VPN roles on x86 or supported platforms point to VyOS, with its set-style CLI and an optional LTS subscription when you want a supported build. Where you need open routing on Linux directly, or you are already assembling your own stack, FRRouting is the routing engine that underpins both and can stand on its own. The sources you are leaving, Cisco Catalyst and Nexus, Juniper, Arista, are not swapped one-for-one; you are moving to a different operating model, and the right target falls out of your role-and-hardware scores.
Where open-networking moves go wrong
The most common error is scoping the target to the wrong layer, expecting one NOS to serve both fabric and edge. Close behind is skipping the hardware compatibility check and discovering mid-project that the ASIC is unsupported. A third is treating config as portable and trying to paste vendor CLI into an open NOS instead of rebuilding feature by feature from the design. The fourth, and the most dangerous operationally, is cutting the whole fabric at once; a storage or app migration that fails hurts one workload, but a fabric that fails can take down everything behind it, which is why “go slow” is the strategy and not a caveat.
Confirm it in a lab before you commit
Turn your top candidate into a lab proof before any production device. Rebuild a representative slice of config in the target format, mirror your real addressing, and diff route tables in both directions against the live device so you are comparing behavior, not intentions. Bring up routing, verify telemetry and SNMP, and exercise link, uplink, and MLAG failover so you can prove routing converges under failure. Prepare rollback configs and out-of-band access to every device, and rehearse the fail-back so it is a proven procedure. Then stage the rollout, lab pod, non-critical production pod, and only then the wider fabric, and model the per-device three-year cost with your own device count and the operational load you are taking on, treating the figures as illustrative until a vendor or partner quotes your configuration. Use the TCO calculator to ground that comparison.