I was sitting in Cisco’s NFD40 session when Richard Licon casually mentioned that Cisco is now the number three contributor to SONiC. Behind only Microsoft and NVIDIA. On switches Cisco itself builds and sells.<\/p>\n\n\n\n
I had to rewind that one.<\/p>\n\n\n\n
This is the company that built a multi-decade business on selling you the silicon, the box, the operating system, the management tools, and the certifications you needed to operate any of it. The company whose lock-in playbook is so well-documented it’s basically a meme. So hearing a Cisco TME pitch SONiC support as a feature, on the same hardware that runs NXOS, is genuinely worth a pause.<\/p>\n\n\n\n
Two stories are happening at the same time here. Cisco is consolidating its data center silicon strategy onto a single family called Silicon One. On top of that silicon, Cisco is openly supporting both NXOS and SONiC as first-class operating systems. Those two moves together tell you something about where the network silicon and OS market is heading. They also tell you something about where Cisco thinks it can still win.<\/p>\n\n\n\n
Silicon One is Cisco’s homegrown ASIC family. The data center business unit now uses it across the entire Nexus line in three role-tuned variants.<\/p>\n\n\n\n
The G series<\/strong> is built for AI scale-out. High bandwidth, high port count (high “radix” in the silicon vocabulary), low latency, and a fully shared packet buffer that all ports can use. The G200 is a 51.2T chip. The newer G300 doubles that to 100T with support for 64 ports of 1.6 terabit. These power the 9300 SG2 and SG3 platforms.<\/p>\n\n\n\n The P series<\/strong> is built for what Cisco calls “scale across,” meaning interconnecting data centers over distance. The P200 runs at 51.2T, includes integrated line-rate encryption (both MACsec and IPsec), uses a virtual output queue architecture, and ships with 16 GB of HBM deep buffer in addition to the on-die packet buffer. Faraz Taifehesmatian called it “switching efficiency with router features.” That’s the right framing. These power the new N300 SP2R and the SP2R line card for modular chassis, and they also handle ACI spine duty.<\/p>\n\n\n\n The E series<\/strong> rounds it out for traditional enterprise data center workloads. Lower bandwidth, but feature-dense, including the kind of large ACL scale and segmentation features that midsized shops actually use. The 9300 SE1 and SE1U sit here.<\/p>\n\n\n\n The takeaway from Richard’s pitch was the framing: a “common architecture, common framework” across three role-tuned silicon variants. You get silicon diversity where the workload actually demands it, but you don’t get a snowflake per use case. That is a meaningful operational simplification for the people who design and support these networks.<\/p>\n\n\n\n Here is where it gets interesting. Both Richard and Faraz confirmed during the session that the new G300 platforms support both NXOS and SONiC. Not “you can technically install SONiC” with an asterisk, but proper first-class support from Cisco. And not just on a few specialized SKUs. Across the platform.<\/p>\n\n\n\n Then Richard dropped the contributor stat. Cisco, behind Microsoft and NVIDIA, is the number three upstream contributor to the SONiC project. That is not the posture of a company dabbling.<\/p>\n\n\n\n Scott Robohn pushed on this exact tension during the session. We are moving to Ethernet partly to escape the Mellanox and InfiniBand lock-in, he noted, but if every vendor opens up to a new NOS, are we just trading one form of lock-in for ecosystem fragmentation?<\/p>\n\n\n\n Richard’s answer was the most honest framing I’ve heard from Cisco on this question. SONiC is for customers who already have the team to operate it. NXOS is the fallback when they don’t. The on-ramp is open, and the off-ramp leads back home.<\/p>\n\n\n\n SONiC<\/strong> (Software for Open Networking in the Cloud) is an open-source network operating system originally built by Microsoft for Azure. It runs as a Linux distribution with containerized network services on top, and it talks to switching ASICs through a vendor-neutral abstraction layer called SAI<\/strong> (Switch Abstraction Interface). Hyperscalers and large neoclouds like it because it removes their dependence on any single vendor’s NOS. Most enterprises don’t run it because, as the rest of this post explains, it expects a very different operating model than NXOS.<\/p>\n<\/blockquote>\n\n\n\n The cynical reading is that Cisco found religion. The honest reading is that Cisco read the market.<\/p>\n\n\n\n The hyperscaler and neocloud customers buying switches today have a real choice. They can buy a whitebox from Edgecore or Celestica, install community SONiC, and run their own stack. Cisco was watching that segment walk out the door. Offering SONiC support on Silicon One hardware lets Cisco compete for those deals without forcing the customer to learn NXOS.<\/p>\n\n\n\n Importantly, Cisco still keeps the parts of the stack that pay the bills. They keep the silicon margin. They keep the system margin. They keep the optics margin (and Richard pointed out optics are now the highest line on most AI BoMs). They keep the support contract. What they give up is the NOS lock. That is a calculated trade, not a charitable one.<\/p>\n\n\n\n The on-ramp design is doing real work too. If a customer starts on SONiC and hits something they cannot troubleshoot on their own, Cisco’s pitch is “come back to NXOS, we have you covered.” The customer is still on Cisco hardware, still in the support relationship, and still buying Cisco optics. The NOS choice is reversible. The hardware decision is not.<\/p>\n\n\n\n That is not cynical. That is a good strategy. It is worth naming clearly.<\/p>\n\n\n\n This part matters because it explains why Cisco can offer SONiC and still expect most of its customers to land on NXOS.<\/p>\n\n\n\n SONiC is not a network operating system in the traditional sense. It is a Debian-based Linux distribution with containerized network services on top. Routing runs in FRR. Switch state lives in Redis. The orchestration layer is called swss. Talking to the ASIC happens through SAI and a daemon called syncd.<\/p>\n\n\n\n When a real problem hits, you are not just troubleshooting a switch. You are operating a small distributed system on every box. That means reading journalctl, exec’ing into containers, querying Redis tables, and tracing the syncd-to-ASIC path. Most enterprise network teams have a CCIE somewhere on the bench. Few of those teams also have a Linux SRE deep enough to debug a stuck container at 2 a.m.<\/p>\n\n\n\n The CLI is intentionally thin too. SONiC has one, but it isn’t really the operating model. Microsoft built SONiC to be configured via JSON and pushed through automation in a config-as-code workflow. If your team’s change management today is “SSH to the switch and paste from a runbook,” you are swimming upstream from day one.<\/p>\n\n\n\n Then there is feature parity. SONiC was built for hyperscaler Layer 3 leaf-spine fabrics. The features midsized shops actually rely on (vPC, integrated EVPN\/VXLAN templates, finer QoS marking, ACI integration, ISSU patterns, dot1x edge cases) are spotty across distributions. Cisco’s NXOS ships those built in, including the QoS-for-AI templates Richard demoed. Most teams do not want to build that from scratch.<\/p>\n\n\n\n And the talent pipeline matters. Cisco has decades of documentation, the Cisco Press library, an entire certification ladder, and a hiring pool that already knows the platform. SONiC documentation is improving but it is fragmented across the community, Microsoft, and each vendor’s distribution. There is no SONiC cert that a hiring manager recognizes yet. If your senior engineer leaves, replacing them on NXOS is a known problem. Replacing them on SONiC is a search.<\/p>\n\n\n\n NXOS<\/strong> is Cisco’s traditional network operating system for the Nexus line. Monolithic, CLI-driven, and tightly integrated with Cisco’s silicon and management stack. The thing your CCIEs already know.<\/p>\n\n\n\n SONiC<\/strong> is the open-source alternative described above. Distributed, container-based, Linux-native, and built for config-as-code operations.<\/p>\n\n\n\n SAI (Switch Abstraction Interface)<\/strong> is the vendor-neutral API SONiC uses to talk to ASICs. It is what makes “any SONiC on any compatible silicon” possible in the first place.<\/p>\n<\/blockquote>\n\n\n\n If you run a mid-sized network, two things are probably true after reading this. You are not running SONiC, and you are not going to. NXOS is still the right answer for your shop, and Cisco knows it. Even Richard and Faraz essentially said as much from the stage.<\/p>\n\n\n\n But the fact that Cisco is doing this matters anyway. It tells you that silicon and the operating system are decoupling at the high end of the market. Over the next refresh cycle or two, expect more vendors to offer NOS choice on their hardware. Some of those options will eventually be mature enough that midsized teams can consider them.<\/p>\n\n\n\n When that day comes, the question for you is not “should I switch to SONiC?” The question is “what is my vendor’s story for OS portability, and what does it cost me if I want to change my mind in five years?” Even if you stay on the integrated stack the whole time, that question is worth asking.<\/p>\n\n\n\n Cisco is now in a position to actually answer it. That, more than the SONiC support itself, is the part I find genuinely interesting.<\/p>\n","protected":false},"excerpt":{"rendered":" Cisco is now the third-largest contributor to the SONiC project, following Microsoft and NVIDIA. This shift indicates a change in its strategy, as Cisco promotes both NXOS and SONiC on its Silicon One hardware. While NXOS remains preferred for traditional networks, Cisco’s SONiC support reflects evolving market demands and competitive methodologies.<\/p>\n","protected":false},"author":1,"featured_media":1869,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"Silicon and network OS are decoupling at the high end. Cisco's SONiC support on Silicon One is the latest sign. You're probably not switching, but the question to ask your next vendor just changed. #nfd #ciscochampion","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[399,88,165],"tags":[264,89,176],"class_list":["post-1865","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","category-blog","category-tech-field-day","tag-ai","tag-blog","tag-tech-field-day"],"yoast_head":"\nAnd Now, SONiC<\/h2>\n\n\n\n
\n
What is SONiC?<\/h4>\n\n\n\n
Why Is Cisco Actually Doing This?<\/h2>\n\n\n\n
Why SONiC Is Harder Than NXOS for Smaller Teams<\/h2>\n\n\n\n
\n
NOS Lineup<\/h4>\n\n\n\n
Final Thoughts<\/h2>\n\n\n\n