Cisco bundles smart-licensing subscriptions with premium hardware and SmartNet renewals, tied to IOS-XE/NX-OS. VyOS is an open-source, Linux-based network OS with a Junos-like set-style CLI, strong at routing, firewalling, VPN, and edge roles on commodity hardware or VMs. It’s a different fit from SONiC, and choosing the right one is the first decision.
VyOS vs SONiC, pick by role
- VyOS is a software router/firewall/VPN OS. It runs on x86 (bare metal or VM) and excels at edge, branch, WAN, VPN concentrator, and router roles. It is not a data-center top-of-rack switch NOS.
- SONiC is a data-center switch NOS for whitebox/Broadcom-ASIC leaf/spine fabrics.
So: replacing Cisco routers / edge / WAN / VPN → VyOS. Replacing Cisco data-center fabric switches → SONiC. Don’t try to make VyOS be a ToR switch or SONiC be an edge router. This guide covers the routing/edge case.
What VyOS does well, and the hardware reality
VyOS handles BGP/OSPF (via FRR under the hood), policy routing, NAT, stateful firewall, IPsec/WireGuard/OpenVPN, and QoS. Because it’s software on x86, you’re typically running it on a server or VM with appropriate NICs, not on Cisco switching silicon. For L2 switching at scale you still need switch hardware; VyOS is about the L3/edge functions. Confirm your throughput needs map to x86 + NIC capabilities (or use VyOS on a suitable appliance).
The translation
- IOS/NX-OS config → VyOS set-style config (
set protocols bgp ...,set interfaces ...,set firewall ...). It reads much like Junos, conceptually close, but a rebuild, not a paste. - Routing (BGP/OSPF) → FRR-backed VyOS routing, translate neighbors, policies, route-maps to VyOS prefix-lists/route-maps.
- ACLs → VyOS firewall rule-sets.
- VPNs → VyOS IPsec/WireGuard/OpenVPN.
- SmartNet support → community support or a VyOS subscription (LTS releases) if you want a safety net.
Working through the config, device by device
Do the translation per device, from the routing design rather than the raw IOS text. VyOS uses a structured, commit-based, set-style configuration, so the workflow is: stage the config, review the diff, commit, and save. Because IOS bundles everything into one flat file, take the chance to separate concerns cleanly, interfaces, routing protocols, policy, firewall, NAT, and VPN, into their VyOS sections. Watch the constructs that do not map one to one: some Cisco route-map matching, QoS shaping, and ACL semantics need rethinking against VyOS firewall and policy models rather than a mechanical port. Keep each device’s set-style config in version control so its intended state is reproducible and every change is diffable, which also becomes your rollback artifact.
The throughput math you can’t skip
This is the section people skip and regret. On Cisco, forwarding, QoS, and high-rate ACLs run in switching silicon; on VyOS they run in software on x86, so performance is CPU-bound and shaped by core count, NIC choice, and the features you enable. Deep stateful firewalling and IPsec in particular consume cycles, so a box that looks oversized on paper can fall short once you turn on everything the site needs. Size for your real traffic profile with features on, not the theoretical line rate, and prove it under load in the lab. For any place that still needs L2 switching at scale, keep dedicated switch hardware; VyOS is replacing the L3/edge functions, not the top-of-rack. If a site needs an appliance form factor, VyOS on a suitable appliance is an option, but the same throughput math applies.
The migration flow (change-sensitive, go slow)
- Inventory devices and roles, configs, routing (BGP/OSPF/policy), ACLs, VPNs, and the topology/uplinks. Separate edge/routing (VyOS candidates) from switching fabric (SONiC/other).
- Translate configs to VyOS set-style, per device.
- Stage in a lab, bring up routing on VyOS, verify BGP/OSPF convergence, VPN tunnels, and failover; compare against the Cisco baseline. Prepare rollback configs and ensure out-of-band (OOB) access.
- Cut over per site / per device during change windows, verify routing, reachability, and VPN connectivity after each before proceeding.
- Keep the Cisco config and device ready so rollback via OOB is immediate.
Lab staging and per-site rollback
Stage VyOS for one representative site and diff its routing behavior against the live Cisco device in a lab: advertised and received routes, failover, firewall pass/block, and VPN tunnel establishment. Only once a site’s config behaves like its Cisco counterpart do you schedule the cutover. Keep the original Cisco device powered and on standby, its saved config intact, and out-of-band access in place that does not ride the link you are moving. Cut over one site per change window, verify routing, reachability, and VPN connectivity, and if anything fails its checks, fail back to the Cisco device over OOB before touching the next site. Repurpose freed Cisco hardware only after a site is proven, so rollback stays available through the risky window. Rehearse the fail-back in the lab so the runbook is real rather than aspirational.
Signing off each site
Acceptance bar: routing converges and traffic flows correctly under failure, run routing-convergence tests, VPN connectivity (site-to-site and remote), failover, and a throughput/soak test on x86 under production-like load. Per site, before the next.
Our take
Cisco → VyOS is a strong exit from smart-licensing for routing, edge, WAN, and VPN roles, on commodity x86, pair it with SONiC (or keep switch hardware) for the data-center fabric, since VyOS isn’t a ToR NOS. Translate IOS to set-style config, lab-validate, and cut over per site with OOB rollback. Model your per-device savings in the calculator above, and treat them as illustrative until you’ve validated throughput on your target hardware and confirmed which roles VyOS is replacing.