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>
- interfaces – i.e. from the default VDC. It is not possible to allocate to allocate sub-interfaces to VDCs
- Each VDC appears as a separate device though some components and resources will be shared:
- 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
NX-OS vs IOS
- 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
- XML / NETCONF
- 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
Rafael A. Couto Cabral • LinkedIn Profile
Cisco | F5 | VMware Certified • PRINCE2 Practitioner
Originally posted 2019-07-27 00:39:22.