NX-OS :: Overview

This is my first input on NX-OS within a series of blogs where I’m familiarising myself with the NX-OS available on Cisco Nexus platforms. As I am reading through the NX-OS and Cisco Nexus Switching book, I will be collating notes which form the basis for this blog series.

NXOS is a state of the art operating system running on Cisco Datacenter switches. Features less common to other vendors, are worth highlighting here:

  • vPC – Virtual Port Channel – uses Ether-channel technology enable upstream connectivity across two different switches, whilst completely eliminating the need for STP and therefore, increasing overall upstream link capacity
  • VDC – Virtual Device Context – it’s a virtualisation technology allowing complete management, data and control plane separation within the same physical switch. More information can be read here in regards to the actual VDC architecture:
    • Each VDC appears as a separate device though some components and resources will be shared:
      • A single instance of the Linux Kernel v2.6
      • Supervisor modules
      • Fabric modules
      • Power Supplies
      • Fan Trays
      • CMP
      • CoPP (Control Plane policies)
      • Hardware SPAN resources
    • The RIB is separate to each VDC providing a partial control-plane isolation
    • L3 protocols are specific to each VDC
    • Physical connectivity is required to allow inter-VDC communication by connecting two interfaces across the different VDCs
    • The only physical resources that can be manually assigned to a VDCs are:
      • interfaces – i.e. from the default VDC. It is not possible to allocate to allocate sub-interfaces to VDCs
        • To create VDC :: vdc <vdcName>
        • To allocate interfaces :: allocate interface <inteface>
      • Limit unicast IPv4/v6 Route memory: limit-resource u4route-mem minimum <#> maximum equal-to-min
      • Limit multicast IPv4/v6 Route memory:  limit-resource m4route-mem minimum <#> maximum equal-to-min
      • Limit Portchannels memory allocation: limit-resource port-channel minimum <#> maximum equal-to-min
      • Limit SPAN sessions: limit-resource monitor-session minimum <#> maximum equal-to-min
      • Limit VRF memory allocation: limit-resource vrf minimum <#> maximum equal-to-min
      • Changing HA policy :: ha-policy <options>
  • OTV – Overlay Transport Virtualisation – enables a layer2 network overlay on top of a L3 topology allowing for increased resiliency and distributed L2 connectivity across multiple datacenters
  • PSS – Persistent Storage Service – it’s a lightweight DB which maintains runtime information state providing excellent HA capabilities
  • FabricPath – introduces L3 forwarding at Layer2, completely eliminating STP from the network. Each switch has a complete view of the L2 topology (similarly to a link-state L2 protocol) and L2 forwarding is based on switch reachability. Each device in the FabricPath is identified by a switch-id
  • ISSU – In Service Software Updates


  • features must be enabled before they become available for implementation
  • NX-OS does not provide a user mode – only privileged, global configuration and vdc-configuration modes are available
  • NX-OS commands are slightly different whilst others, are exactly the same
  • Internal processes are executed in private memory space
  • See also comparison to other Cisco platforms

NXOS is supported on the following platforms:

  • Nexus 7k Series – suitable for Core, distribution as well as, access layer in the DC
  • Nexus 5k Series – aimed at server access layer in the DC
  • Nexus 3k Series – ultra low latency switches designed for environment to match low latency environments
  • Nexus 2k Series – these are just “dumb” switches usually deployed as ToR; they appear as remote line cards to the switch they attach to – the parent switch – either a Nexus 7k or 5k series model
  • Nexus 1000v – virtual NXOS switch deployed as a VMware virtual machine. Offers reduced feature-set in comparison to previous models
  • Other models are available for different architectures in the DC such as, Cisco MDS 9k (multilayer SAN switch), Cisco UCS, Nexus 4k (blade switch for IBM’s BladeCenter H and HT chassis

NX-OS System Files

  • The kickstart image – initial file system, Linux kernel and basic drivers
  • System image – system software, infrastructure and L4 – L7 featureset
  • Erasable Programmable Logic Device (EPLD) image – images for specific I/O modules

There are two licensing models:

  • feature based – in this case, the customer pays the license for a particular feature-set – this could be for adv. L3 routing, or VDC, etc.
  • the module based license applies to feature availability as provided by a specific i/o module.

Managing NX-OS

  • SNMP v1, v2, v3
  • Lights Out through CMP (Connectivity Management Processor)
  • Dedicated management interface
  • Telenet / SSH v2

Configuration Rollback

  • Rollback is initiated with the command rollback
  • NX-OS allows the administrator to create multiple configuration checkpoint providing the ability to rollback configuration in realtime. Essentially, the previously backed up/checkpoint configuration replaces the  existing running-configuration in realtime
  • The checkpoints are mapped to specific VDCs and NX-OS versions
  • Different modes:
    • Atomic (default) – implement rollback only if no errors occurred
    • Best Effort – implement the rollback and skip any errors; useful when rolling back across multiple software versions
    • Stop-at-first-failure – stops implementation at the first occurred error
    • Verbose-mode – provides log visibility while the switch applies the configuration

Generic show commands

  • show boot
  • show enironment
  • show hardware fabric-utilization
  • show system redundancy status
  • show system resources
  • show vrf <vrfName>
  • debug & debug-filter 


Thank you,

Rafael A. Couto Cabral • LinkedIn Profile
Cisco​ | F5 | VMware Certified • PRINCE2 Practitioner

Originally posted 2019-07-27 00:39:22.

Related Post

Comments are closed.