You already know IOS XE. You can build a trunk, bring up an EtherChannel and read a routing table without thinking about it. Then someone hands you console access to a Nexus, and about four commands in, something is wrong: the interfaces are already up, half your muscle-memory commands do not exist, and the box rejects a line you have typed a thousand times. Nothing is broken. NX-OS just makes a different set of assumptions, and this is the piece of our Data Center Fabric guide that covers the ones that catch people out first.
Every block of output below came from a Nexus 9000v running NXOS 10.6(2) in a four-node spine and leaf lab. Nothing has been retyped or tidied up. Where the lab did not test something, this article says so rather than guessing.
1. Nothing is on until you turn it on
This is the difference that reorganises everything else. On IOS XE, protocols are compiled in and waiting. Type router ospf 1 and you are in OSPF configuration mode. Type channel-group 1 mode active and LACP starts running, because LACP was never off.
NX-OS ships with almost nothing loaded. Here is a leaf before any configuration was applied to it:
show feature | include enabled
icam 1 enabled
intersight 1 enabled
license-smart 1 enabled
sshServer 1 enabled
Four features. Telemetry, cloud registration, smart licensing and SSH. No OSPF, no BGP, no LACP, no vPC, no interface-vlan. If you want any of them, you enable the process first with a feature command, and the process starts as a separate piece of software on the supervisor.
The practical upside is a much smaller attack surface and less running code on a box that is expected to stay up for years. The practical downside is that every configuration guide you follow now starts with a line you are not used to typing, and forgetting it produces the behaviour in the next section.
2. Config is rejected outright, not queued
IOS XE will frequently accept a command that cannot do anything yet and let it sit in the config until the missing piece arrives. NX-OS will not. Here is what happens when you try to build a port-channel before enabling LACP:
LEAF1(config)# interface Ethernet1/3
LEAF1(config-if)# channel-group 1 mode active
LACP process needs to be started before configuring active or passive mode
Read that carefully. There is no error banner, no percent sign, no % Invalid input detected caret. It is a plain sentence, and the command is simply gone. It did not go into the running config, it did not half-apply, and if you were pasting a block of twenty lines from a text file, the rest of the block kept going without you noticing.
That last point is the one that costs time. NX-OS does not stop a paste on the first rejection, so a config that is 90 percent applied looks exactly like a config that is 100 percent applied unless you go back and check. The habit to build is: enable the feature, verify with show feature, then paste the rest. And after any interrupted paste, re-check rather than assuming (we lost an entire twenty-line batch this way in the lab session that produced these captures, silently, when the console timed out mid-apply).
Once feature lacp is on, the identical channel-group 1 mode active line is accepted without comment. The full walkthrough is in Nexus port-channel and LACP configuration.
3. Interfaces are up by default, and they are in VLAN 1
On IOS XE, a switchport you have never touched is administratively down. You bring it up deliberately. On NX-OS, the opposite is true. This is a leaf with no interface configuration at all:
show interface status | head lines 12
--------------------------------------------------------------------------------
Port Name Status Vlan Duplex Speed Type
--------------------------------------------------------------------------------
mgmt0 -- connected routed full 1000 --
--------------------------------------------------------------------------------
Port Name Status Vlan Duplex Speed Type
--------------------------------------------------------------------------------
Eth1/1 -- connected 1 full 1000 10g
Eth1/2 -- connected 1 full 1000 10g
Eth1/3 -- connected 1 full 1000 10g
connected, in VLAN 1, with zero configuration applied. Three ports that are cabled to other switches are already forwarding in a common broadcast domain, and you have not typed anything.
Think about what that means when you rack a Nexus into an existing environment and patch it before you configure it. Spanning tree is doing its job and will stop you creating a loop, but you now have a device participating in VLAN 1 that nobody has configured yet. If your spanning tree design assumes new switches arrive dark, it does not on this platform.
Note also the two-block layout of the output. show interface status on NX-OS re-prints its header for each interface group, mgmt0 first and then the front-panel ports. Every parser you have written against the IOS XE version of this command needs revisiting.
The default is deliberate: data centre switches are built and cabled to a plan, and the platform assumes you want the link to come up so you can verify the cabling. Which brings us to the next difference, because verifying that cabling is done out of band.
4. The management VRF exists before you configure anything
This is the single biggest day-one difference, and it is invisible until it bites you. A Nexus has VRFs before you create any:
VRF-Name VRF-ID State Reason
default 1 Up --
egress-loadbalance-resolution- 3 Up --
management 2 Up --
The management VRF is not something you built. It exists at first boot, mgmt0 is a member of it, and it is completely separate from the default VRF where all your production routing lives. That is the correct design (out-of-band management should not be reachable through the data plane and should not leak the data plane's routes) but it changes the syntax of a lot of commands you use every day.
Your management default route goes in the management VRF, not the global table. Your ping to a management address needs vrf management or it will be sourced from the wrong place and fail. Your show ip interface brief shows you nothing about mgmt0 unless you ask for the right VRF:
show ip interface brief vrf management
IP Interface Status for VRF "management"(2)
Interface IP Address Interface Status
mgmt0 192.168.100.11 protocol-up/link-up/admin-up
The mental model that helps: on IOS XE, a VRF is something you add for a customer or a tenant, and everything lives in the global table until you say otherwise. On NX-OS, VRF awareness is the baseline, and default is just the name of one particular VRF rather than the absence of one. If you are coming at this from an MPLS or network virtualization background you will find this comfortable; if you are coming from campus IOS XE, it is the thing you will forget most often in your first week.
It also shows up in features you would not expect. The vPC peer keepalive, for example, runs in the management VRF out of mgmt0 by default, which means your vPC health check depends on an out-of-band network that may not be as carefully engineered as your fabric.
5. show module, and a supervisor that is not the box
There is no IOS XE equivalent of this command that means the same thing, and that is the point:
Mod Ports Module-Type Model Status
--- ----- ------------------------------------------------ --------------------- --------
1 64 Nexus 9000v 64 port Ethernet Module N9K-X9364v ok
27 0 Virtual Supervisor Module N9K-vSUP active *
Mod Sw Hw Slot
--- ----------------------- ------ ----
1 10.6(2) 0.0 LC1
27 10.6(2) 0.0 SUP1
Mod MAC-Address(es) Serial-Num
--- -------------------------------------- ----------
1 52-9a-2a-3a-01-01 to 52-9a-2a-3a-01-40 9BFOSKXNF3B
27 52-9a-2a-3a-1b-01 to 52-9a-2a-3a-1b-12 9X2OU50STOR
Mod Online Diag Status
--- ------------------
1 Pass
27 Pass
* this terminal session
Two modules. Module 1 is a linecard with 64 ports and its own MAC range. Module 27 is the supervisor, and it is active *, where the asterisk means the console session you are typing into is attached to that supervisor.
Even on this virtual chassis, NX-OS models itself as a modular system: a control plane running on a supervisor, forwarding running on separate linecards, each with its own software version, its own hardware revision and its own diagnostics. On a real Nexus 9500 there would be multiple linecards, two supervisors and a set of fabric modules, and show module is the command that tells you which of them are alive.
Why you should care as an IOS XE engineer: it changes what "the switch is up" means. The control plane and the forwarding plane can be in different states. A linecard can be booting, failed diagnostics, or running a mismatched software version while the supervisor is perfectly healthy and answering your SSH session. When something is wrong on a Nexus and the symptoms make no sense, show module is a much earlier stop on the troubleshooting path than it would ever be on a fixed-configuration IOS XE switch.
6. Saving config: use copy running-config startup-config
show version is where you start orienting yourself on any box, and on a 9000v it tells you something important in the fourth line:
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2025, Cisco Systems, Inc. All rights reserved.
Nexus 9000v is a demo version of the Nexus Operating System
Software
BIOS: version
NXOS: version 10.6(2) [Feature Release]
BIOS compile time:
NXOS image file is: bootflash:///nxos64-
NXOS compile time: 11/30/2025 12:00:00 [12/12/2025 12:10:23]
Hardware
cisco Nexus9000 C9300v Chassis
Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz with 12047612 kB of memory.
Processor Board ID 9X2OU50STOR
Device name: LEAF1
bootflash: 8598528 kB
Kernel uptime is 0 day(s), 0 hour(s), 15 minute(s), 50 second(s)
plugin
Core Plugin, Ethernet Plugin
Note the absent show run reflex you are about to need. The command that saves configuration on NX-OS is copy running-config startup-config. That is what was used to save all four switches in this lab, and it is the command to put in your notes and your runbooks.
The write memory alias is the piece of muscle memory most likely to let you down here. It has been variously present, deprecated and absent across NX-OS releases and platforms, and this lab session did not test it on 10.6(2), so this article will not tell you whether it works on your box. What it will tell you is that copy running-config startup-config is the form that has always worked, and that typing the long version costs you two seconds while assuming the short one worked costs you a config after the next reload. Use the long one.
The other half of this is that NX-OS, like IOS XE, has no automatic save. Everything you have typed is in the running config and nowhere else until you copy it. On a platform where a paste can silently half-apply, get in the habit of verifying with show feature or the relevant show command before you save, so that you are not writing a broken config to startup.
The short version, side by side
write memory is reliable shorthand.What does not change
It is worth saying plainly, because the list above can make NX-OS sound alien. Almost everything else is the same. OSPF is OSPF, and a point-to-point adjacency comes up the way you expect. BGP is BGP, with the same neighbour states and the same show output shape. Spanning tree behaves itself. Trunks, access ports, SVIs and static routes all use syntax you can guess. CDP is on and works, which is how the cabling in this lab was verified before a single routing protocol was enabled.
The differences are concentrated in the first thirty minutes on the box, which is exactly why they feel disproportionate. Get through the feature model, the management VRF and the save command, and the rest of NX-OS is a platform you already know how to drive. If you want that first thirty minutes broken down step by step, that is the subject of NX-OS fundamentals for your first Nexus, and once you are comfortable there, the rest of the data center fabric series builds a full spine and leaf VXLAN EVPN fabric on top of these same four switches.
Key Takeaways
- A stock Nexus has four features enabled. Every protocol you want, including LACP, needs a
featurecommand before its configuration will be accepted. - Rejected commands are dropped silently in the middle of a paste. Verify with
show featurebefore you move on, and re-check after any interrupted config batch. - Front-panel ports come up
connectedin VLAN 1 with no configuration, so a cabled but unconfigured Nexus is already participating in your Layer 2 domain. - The
managementVRF exists at first boot and mgmt0 lives in it. Addvrf managementto your pings, routes andshowcommands or you will be looking at the wrong table. show moduleseparates the supervisor from the linecards and has no IOS XE equivalent. It is an early stop when symptoms do not add up.- Save with
copy running-config startup-config. Do not rely onwrite memorybeing present on your release.