Things I Wish I Knew Before Working With SONiC NOS - A CCIE’s Perspective
When you’ve spent years mastering traditional network operating systems – Cisco IOS, NX-OS, Junos – moving to a disaggregated platform like SONiC (Software for Open Networking in the Cloud) is a jarring experience. As a CCIE, I thought I had the core competencies to pick up any network OS. SONiC humbled me. It’s a powerful platform, but one that demands a very different mindset and skillset. If you’re about to start your SONiC journey, here are the key skills I wish I had developed beforehand.
1. Linux Fundamentals Beyond the Basics
SONiC is built on Linux, and I mean REALLY built on it. Unlike traditional NOSs, where the underlying OS is hidden, SONiC exposes you to everything – systemd, containers, bash scripts, and more. Basic Linux isn’t enough. You need to be comfortable with:
- Navigating the filesystem
- Reading logs in /var/log/
- Troubleshooting systemd services (systemctl status, journalctl)
- Managing containerized services via Docker (docker exec, docker logs)
If you haven’t touched a Linux CLI outside of enabling SSH or ping, you’ll be lost fast.
2. Understanding the Containerized Architecture
SONiC is microservice-based. Each networking function (BGP, LLDP, DHCP relay) runs in its own Docker container. That means:
- Logs are container-specific.
- Networking namespaces can isolate traffic.
- Failures can be isolated to a specific container without affecting the rest of the system.
I had to unlearn my “monolithic OS” instincts, after all, I grew up with Cisco IOS where everything is centralized. Troubleshooting is very different when routing decisions are being made in one container and interfaces are managed in another.
3. Working with Redis and the SONiC DB Model
SONiC uses a Redis DB as the intermediary between configuration, state, and the underlying hardware abstraction layer. There are multiple logical DBs – CONFIG_DB, STATE_DB, APPL_DB – each serving a distinct purpose. You need to know:
- How to query DB entries (redis-cli -n <db> keys *)
- The schema (SONiC YANG models help)
- How the swss processes consume data from Redis
I wish I had taken more time upfront to understand SONiC’s DB schema and orchestration pipeline, that would have saved me a lot of head scratching.
4. Git and Source Code Navigation
SONiC is open source. When something breaks or doesn’t behave as expected, there’s a good chance your searches will point towards public GitHub issues, you may even read the source code, or if you are daring, build/debug the system yourself. It helps to have a solid grasp of:
- Git basics (clone, diff, branch)
- Reading Python/C++ code (especially in swss, syncd, orchagent)
- Building images via SONiC build system
BTW, if you receive support on SONiC from a manufacturer, integrator or partner, you’ll likely never have to the above, but I’m always trying to learn new things.
5. DevOps and Automation Mindset
SONiC was originally built for cloud-scale operators. Manual configuration is discouraged. Embrace:
- Terraform resource blocks
- Ansible playbooks
- Config management through config_db.json
- Image management and ZTP
- CI/CD pipelines for network changes
If you’re still editing configs via CLI line-by-line, you’re doing it wrong.
Conclusion
SONiC isn’t just a NOS – it’s really a platform that enables future network capabilities. It rewards engineers who think like SREs and penalizes those who cling to legacy workflows. I’ve grown a lot from my experiences with SONiC, but if I could go back, I’d prep more in Linux, containers, and automation. SONiC is the future of open networking – just be ready to level up when you get there.
Josh Saul
VP Product Marketing
Josh Saul has pioneered open source network solutions for more than 25 years. As an architect, he built core networks for GE, Pfizer and NBC Universal. As an engineer at Cisco, Josh advised customers in the Fortune 100 financial sector and evangelized new technologies to customers. More recently, Josh led marketing and product teams at VMware (acquired by Broadcom), Cumulus Networks (acquired by Nvidia), and Apstra (acquired by Juniper).
