You have a console session on a Nexus and no context. Maybe it is a lab node you just booted, maybe it is a switch someone racked last week and walked away from. Either way the useful question is not "how do I configure VXLAN on this", it is "what am I actually looking at". This is the orientation pass we run at the start of every session in the Data Center Fabric guide, in roughly the order you should run it, using real output from a Nexus 9000v running NXOS 10.6(2).
Everything in a code block below is verbatim from that lab. Where a claim is not backed by a capture, this article says so instead of inventing one.
Minute one: what is this box
show version is the first command on any platform, but on NX-OS it earns its place because it answers several questions at once:
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
Four things to pull out of that.
The fourth line is a warning label. Nexus 9000v is a demo version of the Nexus Operating System. This is a virtual platform. It runs the real NX-OS control plane, which is exactly why it is useful for learning the feature model, protocol behaviour and configuration syntax, and it is why every capture in this cluster is trustworthy as an illustration of how NX-OS behaves. What it is not is a performance reference. The forwarding path is software on a hypervisor, so any latency, throughput or convergence figure you measure on a 9000v tells you about the host it is running on, not about a real Nexus 9300. Read protocol state from it freely. Do not quote its timings at anybody.
The release string matters more than you think. 10.6(2) [Feature Release] is a feature release rather than a long-lived maintenance train: fair for a lab box, a red flag on a production switch. NX-OS feature availability moves between trains, so when a command in a guide does not exist on your box, check this line first.
The hardware block confirms the chassis and the name. Nexus9000 C9300v Chassis and Device name: LEAF1. On a virtual box the CPU line describes the hypervisor host.
Uptime is on the same screen. Fifteen minutes and fifty seconds here, which told us the node had recently been reprovisioned. On a switch you have inherited, an uptime of a few hours when nobody admits to a reload is a lead worth following.
Minute three: what hardware does it think it has
NX-OS models itself as a modular chassis even when it is not one, and two commands expose that model. First show module:
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
Module 1 is the linecard: 64 ports, its own model number, its own serial, its own block of 64 MAC addresses. Module 27 is the supervisor, marked active, and the asterisk means your console session is attached to it. Both are running 10.6(2) and both passed online diagnostics.
Get in the habit of reading the software column across every module. On a real chassis with two supervisors and several linecards, a module running a different Sw version to the rest is a genuine problem, and far easier to spot here than in a syslog. Likewise any status other than ok or active, or a diagnostic that is not Pass.
Then show inventory, which is the same hardware seen from the asset side:
NAME: "Chassis", DESCR: "Nexus9000 C9300v Chassis"
PID: N9K-C9300v , VID: , SN: 9HXA5N4RVXV
NAME: "Slot 1", DESCR: "Nexus 9000v 64 port Ethernet Module"
PID: N9K-X9364v , VID: , SN: 9BFOSKXNF3B
NAME: "Slot 27", DESCR: "Nexus 9000v 64 port Ethernet Module"
PID: N9K-vSUP , VID: , SN: 9X2OU50STOR
This is the command for serial numbers, which is what a TAC case, an RMA or an asset database wants. The chassis serial (9HXA5N4RVXV) is a different number from either module serial, and the slot 1 serial matches module 1 in show module, which is how you correlate the two views.
Note also the small inconsistency in slot 27: the DESCR field calls it a 64 port Ethernet module while the PID is N9K-vSUP, the supervisor. That is the virtual platform's inventory strings being sloppy, and it is a good reminder to trust show module for role and show inventory for serials rather than expecting either to be authoritative for both.
Minute six: what is actually turned on
If you take one thing from this article, take this one. NX-OS starts with almost nothing running:
show feature | include enabled
icam 1 enabled
intersight 1 enabled
license-smart 1 enabled
sshServer 1 enabled
Four features on a freshly provisioned leaf. No OSPF, no BGP, no LACP, no vPC, no interface-vlan. Every protocol is a separate process that has to be started with a feature command before its configuration is accepted, and NX-OS rejects the configuration outright rather than holding it. That difference and the rest of the day-one surprises are covered in NX-OS vs IOS XE for the first-time Nexus engineer.
For orientation purposes, this output is a compressed history of the box. Four features means nobody has configured anything yet. See fifteen on an inherited switch and you have just learned what the previous engineer was doing, and anything in that list you cannot account for is worth investigating (an enabled process runs code and consumes supervisor resources whether or not anything is configured on top of it).
Two details about the output itself. The | include enabled filter is doing real work: the unfiltered show feature lists every available feature with its state, which is a long screen. And the middle column, 1 in every line above, is the feature instance. Some NX-OS features support multiple instances, so a box running several OSPF processes shows a numbered row per instance and instances that are configured but not running are reported as enabled with a not-running qualifier. This lab did not capture an example of that, so take the mechanism and go look at your own box rather than a screenshot from here.
The audit habit is simple: run show feature | include enabled before you configure anything, after any config batch that was interrupted, and before you save. On this platform a batch that times out or trips over a rejection can leave you with a config that is 90 percent applied and looks fine.
Minute ten: which VRF are you in
A Nexus has VRFs before you make any:
VRF-Name VRF-ID State Reason
default 1 Up --
egress-loadbalance-resolution- 3 Up --
management 2 Up --
default is where your production routing will live. management is the out-of-band VRF, and it exists at first boot. (The third one, whose name is truncated in the output, is an internal VRF used for load balance resolution and is not something you configure.)
mgmt0 is a member of the management VRF, so the interface you are managing the box through is invisible to the commands you would normally reach for. You have to ask for it by 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
That three-part status field is more useful than IOS XE's two-column equivalent: protocol-up/link-up/admin-up separates the protocol state, the physical link state and the administrative state, so a glance tells you whether a down interface is shut, unplugged or up but not passing protocol.
The configuration side of this, for a box you are bringing up from scratch, is that the address, the mask and the default route all go inside the VRF context. So does your management default route: a 0.0.0.0/0 in the default VRF does nothing for reaching your jump host from mgmt0. And every diagnostic you run against a management address needs the VRF named, or it will be sourced from the wrong table and fail in a way that looks like a network problem.
Minute fifteen: is it cabled the way the drawing says
Before you configure a single routing protocol, confirm the physical topology. Two commands do it. First, the ports:
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
Those three front-panel ports are connected, in VLAN 1, with no configuration applied to them at all. That is normal NX-OS behaviour and it is very much not IOS XE behaviour, where an untouched switchport is administratively down. For orientation it is genuinely handy, because a cabled Nexus shows you its live links before you have typed anything. Just be aware that it also means the box is already participating in VLAN 1.
Note the | head lines 12 filter. NX-OS filters are their own small language (head, last, include, begin, count, diff), and head lines N is the one that keeps a 64-port show interface status readable on a console.
Then confirm what is on the other end of each link:
show cdp neighbors
Device-ID Local Intrfce Hldtme Capability Platform Port ID
LEAF2(9R6GMBSLEQ4)
mgmt0 134 R S s N9K-C9300v mgmt0
SPINE1(9JAEYKW7KNL)
mgmt0 120 R S s N9K-C9300v mgmt0
SPINE2(9Z6UKES3AZM)
mgmt0 127 R S s N9K-C9300v mgmt0
SPINE1(9JAEYKW7KNL)
Eth1/1 156 R S I s N9K-C9300v Eth1/1
SPINE2(9Z6UKES3AZM)
Eth1/2 163 R S I s N9K-C9300v Eth1/1
LEAF2(9R6GMBSLEQ4)
Eth1/3 172 R S I s N9K-C9300v Eth1/3
LEAF2(9R6GMBSLEQ4)
Eth1/4 172 R S I s N9K-C9300v Eth1/4
Total entries displayed: 7
Read that as two groups. The four Eth entries are the fabric: Eth1/1 to SPINE1's Eth1/1, Eth1/2 to SPINE2's Eth1/1, and Eth1/3 and Eth1/4 both to LEAF2 on matching ports (a pair of links between two leaves like that is the shape of a future port-channel or vPC peer link). That is the cabling plan, confirmed by the devices themselves rather than by a diagram somebody drew last year.
The three mgmt0 entries are a different story. Every switch sees every other switch on mgmt0, because the out-of-band segment is a shared unmanaged switch rather than a point-to-point link. That is normal for OOB, but it is worth recognising so you do not go looking for a cabling error that is not there. Note also that the capability flags differ between the two groups: R S s on the management ports, R S I s on the fabric ports.
With the cabling confirmed, you are ready to actually build something, which on a spine and leaf fabric means the underlay first. That is the subject of the OSPF underlay build, and if you want to revisit the protocol itself rather than the platform, the OSPF guides cover the fundamentals.
Minute twenty-five: save it properly
NX-OS does not save your configuration for you. Everything you have typed lives in the running config and nowhere else until you say otherwise, and the command is:
copy running-config startup-config
Type it in full. The write memory shorthand has come and gone across NX-OS releases and platforms, and this lab session did not test it on 10.6(2), so this article is not going to tell you it works on your box. The long form has always worked. All four switches in this fabric were saved with it, which is why the lab survives a reload.
Two habits worth building around it. First, verify before you save: run show feature | include enabled and the relevant show command for whatever you just configured, so you are not writing a half-applied config to startup. Second, save deliberately rather than reflexively. An unsaved running config is a free undo (a reload puts you back on a known-good startup config), and the moment you save you have thrown that away.
A thirty-minute checklist
In order, with no configuration typed at any point:
show version: platform, release train, hostname, uptime, and whether you are on a demo image.show module: supervisor and linecard state, per-module software version, diagnostics.show inventory: serial numbers for the chassis and each module.show feature | include enabled: what is running, and by implication what the last engineer was doing.show vrf: confirm the management VRF and see what else exists.show ip interface brief vrf management: the management address and its three-part state.show interface status: which ports are live and what VLAN they landed in.show cdp neighbors: the real topology, separated into fabric links and out-of-band.copy running-config startup-config, once you have changed something and verified it.
That is the orientation pass. Every command is read-only, so it needs no change window, and it means the next thing you type is based on what the box is rather than what you assumed. From here, the data center fabric series takes these same four switches from an empty config to a working VXLAN EVPN fabric, one layer at a time.
Key Takeaways
show versionon a 9000v says demo version in plain English. Trust it for control-plane behaviour and syntax, never for performance numbers.show modulegives you the supervisor and linecard split with per-module software versions and diagnostics;show inventorygives you the serials.- A stock Nexus has four features enabled.
show feature | include enabledis both your day-one baseline and your audit of what someone else turned on. - The
managementVRF exists before you configure anything, mgmt0 lives in it, and management addresses, routes and pings all need the VRF named. - Ports come up
connectedin VLAN 1 with no config, andshow cdp neighborsseparates real fabric links from the shared out-of-band segment. - Save with
copy running-config startup-configin full, after verifying, not before.