Cisco Blogs

Why a new OS?

- January 29, 2008 - 4 Comments

I read an interesting article questioning why we created NX-OS. It’s a fair question so one I figured I’d pu together a few quick thoughts on….NX-OS is not yet another Operating System. NX-OS has as its core Cisco SAN-OS. It is a modular, multi-process, multi-threaded Operating System that has full Stateful Process Restart and Zero-Service-Disruption Upgrades.SAN- yesLAN- yesIP- YesIPv6- YesWe really see NX-OS as our strategic operating system in the data center and actively envision multiple data center products converging into this single OS over the next year or two.So a SAN administrator will find every feature they are used to, a LAN administrator familiar with the Catalyst line can pick it up and be productive in a few minutes.We also created Virtual Device Contexts- this allows multiple administrators to operate a single Nexus concurrently. One Admin could restart OSPF and the other Admin’s OSPF would not be impacted at all. Complete process segmentation and separation, basically running server virtualization on the network control plane.This lets you run a Lab-Net on top of production, model configuration changes, then cut them into production. It lets Service Providers offering hosting services allow some level of customer self-management for the top-tier customers that mandate it and also reduce failure domains. And lastly a SAN administrator and a LAN administrator can co-habitate without messing each other up.dg

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Good comments! I took your feedback to the engineering team on NX-OS 4.0 and we re-ran the command set you sent in. This is EXACTLY the type of feedback I am looking for so really appreciate you helping us build better products!sanos# sh filesystmesshow file"" works and so does ""dir""sanos# rename startup-config oldWe use the ""copy"" then ""delete"" command.sanos# sh tcp brRight. ""show tcp conn"" is the briefest we have.sanos# sh caller""show users"" does this. More syntactically correct given no dial platform.sanos# sh ntp assDon't have it and should. We have ""show ntp peers"". Working on it now. Thanks!sanos# sh ip access-listThat works fine, as well as just ""sh access-list"".Again, thanks for the feedback - 'sh ntp ass' seems to be the biggest gap identified so far. As soon as we get the Virtual Labs up online take a look through the CLI if there are any others we are missing that you find useful in day-to-day operations let me know so we can close the gap for you. Thanks for helping!Send me your address to I have some Cisco apparel for ya! :)dg"

  2. We b[r]ought IOS CLI forward"" got me excited at first, but unfortunately your more recent post clarified part of my concern -- ""we wrapped all this in an IOS-like CLI"". Unless it's improved significantly since earlier SANOS's, then its a fail for anyone who's spent more than a few weeks using IOS, this isn't much more IOS-like than most Foundry gear. Without trying hard:sanos# sh filesystmes

  3. kgraham:You make a great point that the architectural diversity across the Catalyst family is moot because IOS provides operational and management consistency. Rest assured that this lesson was not lost on the development team behind the Cisco Nexus platform or the NX-OS operating system.We chose SAN-OS because it is battle tested in the enterprise data center. It allowed us to take what we started with modular IOS and continue to extend it. For instance, we were able to take the concept of restartable process and now make them stateful.The salient point is that we did this while still maintaining management and operations consistency. We bought IOS CLI forward so the NetOps team is working in a known environment. Familiar tools such as GOLD, EEM and Call Home are still there plus we've added some cool new things link integrating WireShark to sniff the control plane.Conversely, for our storage brothers and sisters, when unified fabric i/o modules become available, they can manage storage services with the Fabric Manager interface they know and love.I know the words ew operating system"" is generally met with groans, I think folks will be pleasantly surprised with what we did with NX-OS. We gave you an internal architecture that you can build upon for the next decade, but wrapped it in familiar, comfortable packaging."

  4. Wasn't most of this what IOS Modularity was supposed to deliver? Perhaps 4.x has improved significantly, but SANOS 3.x was still an ugly attempt at mimicking IOS. It's very disappointing to see Cisco so quickly squander the value of having unified the Catalyst line under IOS.If I could run my MDS like a 6500, then I cannot wait to deploy more FibreChannel rather than doing so begrudingly with every zone. Run my 6500 like an MDS? Please, no. (Not a Cisco dig, this goes for most vendors FC switches). The demand for FCoE is due to frustration with the existing SAN environments and to fold the SAN into existing ethernet infrastructure -- /not/ the other way around.A huge part Cisco's value proposition is in the uniformity between platforms, that the 4900 or 3750 in a top-of-rack switch aggregating onto a 6500 core and dumping off to 7200's and 7600's all use common management instrumentation, a uniform CLI, configurations, etc. Only in their aggregate is this value realized and is why our enterprise shrugs off consideration of point-solutions, such as Force10 and Woven, who in a product-to-product comparison are often considerably more competitive.Architecturally, a 3750, 4500, 6500, and 7200 have very, very little in common, but from the monitoring and operational vantage point they're no different, and likewise reduce my operation expenditures (and complexity). At every point where Cisco has deviated from this, it creates a competitive situation out of what otherwise might have been an obvious Cisco purchase. I'll wait to see how this pans out, but it certainly seems like Cisco has ensured that when it comes time to retire Sup720's that it won't be a matter of a simple just bigger'n'badder"" drop-in (whether that be a module or a whole chassis) upgrade with little retooling of internal processes, training, or monitoring infrastructure. Instead, short of talking to the same account management team, the Nexus 7000 is /not/ an incumbent upgrade and deserves no more consideration than an EX8200, EFX1000, or E600."