From Arista Networks to SONiC

This one is not a like-for-like swap, so set expectations early. Arista EOS is a mature, batteries-included NOS. SONiC is a disaggregated, container-based NOS that runs on whitebox and supported OEM switches and pushes you toward open standards and your own automation. Teams move for the economics: no per-device EOS subscription, hardware bought on its own merits, and a NOS the community develops in the open. Below is the path for a data-center leaf-spine fabric, which is where SONiC is strongest.

Step zero: validate hardware against the HCL

Before anything else, check the SONiC Hardware Compatibility List. SONiC abstracts the ASIC through SAI (Switch Abstraction Interface), so what matters is whether your switch’s ASIC has a supported SAI implementation. Broadcom Tomahawk and Trident platforms are well covered; some Mellanox/NVIDIA Spectrum gear runs SONiC as a first-class target. If a model is not on the HCL with the features you need, stop here. Running SONiC on unsupported silicon is not a migration, it is a research project.

Understand the config model

EOS config is a flat CLI text file. SONiC splits config differently:

• config_db.json holds interfaces, VLANs, port channels, breakout, and device metadata.
• Routing (BGP, BGP-EVPN) lives in FRR, the routing stack SONiC ships.
• You apply changes with config reload or targeted config CLI commands, then persist with config save.

A snippet of config_db.json for an interface and VLAN:

{
  "PORT": { "Ethernet0": { "admin_status": "up", "mtu": "9100", "speed": "25000" } },
  "VLAN": { "Vlan10": { "vlanid": "10" } },
  "VLAN_MEMBER": { "Vlan10|Ethernet0": { "tagging_mode": "untagged" } }
}

Translate the fabric features

Work feature by feature, not line by line.

• BGP underlay: EOS router bgp blocks become FRR bgpd config. The concepts (eBGP unnumbered, ECMP, BFD) all exist in FRR, the syntax differs.
• EVPN-VXLAN overlay: EOS VXLAN interface plus router bgp ... address-family evpn maps to SONiC VXLAN tunnel config in config_db plus FRR EVPN. Type-2 and Type-5 routes behave the same on the wire, so interop with remaining Arista nodes during a phased cutover holds up.
• MLAG: this is the sharpest divergence. Arista MLAG is its own implementation. On SONiC you are typically moving to MC-LAG via the SONiC implementation, and the peer-link and keepalive semantics are not identical. Test dual-homed server failover hard.

A small FRR underlay example:

router bgp 65001
 bgp router-id 10.0.0.1
 neighbor PEER peer-group
 neighbor PEER remote-as external
 neighbor Ethernet0 interface peer-group PEER
 address-family ipv4 unicast
  network 10.0.0.1/32
 exit-address-family

Lab against the live fabric

Build a two-leaf, two-spine lab that mirrors your production addressing and run it alongside the real fabric, advertising into a test VRF. Validate convergence times, BFD timers, EVPN MAC mobility, and ECMP hashing. SONiC’s behavior under link flap and the MC-LAG failover path are the two things most likely to bite you, so script those tests and capture the timings.

Plan ZTP and per-switch cutover

Use Zero Touch Provisioning so each switch pulls its config_db.json and FRR config from your provisioning server at boot. Keep the previous EOS or SONiC image installed so sonic-installer set-default plus a reboot is your rollback. Cut over one switch at a time, drain it first by raising BGP metrics or shutting uplinks gracefully, swap the NOS, re-advertise, and watch route counts and traffic before moving to the next.

What doesn’t have a direct equivalent

Some EOS pieces do not map cleanly, and naming them early prevents surprises mid-cutover. MLAG is the sharpest, as above: the move to MC-LAG changes peer-link and keepalive behavior, so treat dual-homed failover as a first-class test, not a checkbox. The management plane is the other big gap. EOS ships a coherent operational surface and CloudVision layers fabric-wide telemetry, change control, and a streaming state database on top; SONiC expects you to assemble equivalent visibility from gNMI, Prometheus, and your own tooling. Budget engineering time to build that observability and your automation before the fabric depends on it, because the day-two operations, not the underlay config, are where the real work lives. Niche EOS features (deep multicast, some advanced QoS, and a long tail of knobs) may have no turnkey SONiC counterpart, so inventory which of them you actually use and confirm SAI/FRR support for each rather than assuming parity.

Where Arista still wins

Do not pretend otherwise. EOS is more feature-complete at the edges: deep multicast, advanced QoS, and a long tail of knobs that just work. CloudVision gives you fabric-wide telemetry, change control, and a streaming state database that SONiC asks you to assemble from gNMI, Prometheus, and your own tooling. And one vendor owns the whole stack, so support is a single phone call. If your team is small or your fabric leans on niche EOS features, the operational cost of running SONiC yourself can outweigh the license savings.

Weighing it up

Arista to SONiC trades subscription cost and vendor lock-in for owning your NOS operations. Validate the HCL first, translate BGP/EVPN into FRR and the fabric plumbing into config_db.json, lab the MC-LAG and convergence paths, then cut over per switch with ZTP and a rollback image. The savings are real, but so is the tooling you now run yourself. Model both sides in the calculator above before committing the fabric.