Cisco Nexus NX-OS VLAN and Trunk Configuration Step by Step

2026年8月31日 LOG admin

Cisco Nexus switches are the workhorse of modern data centers, but their NX-OS syntax — though conceptually identical to IOS VLANs — differs in enough details to trip up campus-trained engineers. This step-by-step lab guide configures a three-switch Nexus topology: trunk ports between switches, two named VLANs, access port assignment, and allowed-VLAN filtering, followed by the verification commands that prove the config. We finish with modern best practices such as spanning-tree port type and disabling unused ports.

Why NX-OS VLAN Configuration Trips Up IOS Engineers

At the 802.1Q level, nothing changes between a Catalyst running IOS and a Nexus running NX-OS. A frame still carries a 4-byte tag inserted after the source MAC address, the native VLAN is still untagged, and the trunk still has to negotiate or be forced to trunk mode. What changes is the operating system underneath: NX-OS is a modular, Linux-based, process-isolated platform where features live as separate processes and every switch port is a routed-or-switched interface that you must explicitly put into a mode.

Three habits from IOS cause most of the confusion in real deployments. First, NX-OS has no interface range keyword — you expand a range by appending the range to the interface name itself, as in interface ethernet1/1-4. Second, features that IOS enables by default are features you must turn on with an explicit feature command in NX-OS; SVI creation, PIM, HSRP and LACP all require it. Third, NX-OS validates configuration more aggressively during entry, so a typo fails immediately rather than silently queuing at the end of a paste. Engineers who paste a 200-line IOS snippet into a Nexus usually get a partial configuration without noticing which lines were rejected.

Understanding those three differences is the difference between a trunk that comes up in five minutes and one that comes up after an hour of head-scratching — which is exactly what this lab guide is designed to prevent.

Lab Topology and Prerequisites

The lab uses three Nexus switches, but every command works on a Nexus 3000, 5000, 7000, 9000 or a virtual NX-OSv instance. The topology is deliberately minimal:

Nexus-1 — the access switch. Ethernet1/1-4 face upstream, Ethernet1/5-8 serve hosts.
Nexus-2 — an aggregation switch, connected with four parallel links on Ethernet1/1-4 to form a port channel or a vPC peer-link.
Nexus-3 — hosts the Layer 3 SVI if you want to test inter-VLAN routing. In the base lab it can be omitted.

Before you start, confirm the following on every switch:

show version | include system:
show interface status
show vlan brief
show run interface ethernet1/1

Verify that the ports are administratively up, that no existing configuration references VLAN 10 or 20, and that you have console or out-of-band access before you change anything that could cut your management path. If the Nexus is managed in-band, move the management SVI to a VLAN you are not touching, or work from the console port.

Task 1: Configure Trunk Ports

configure terminal
interface ethernet1/1-4
switchport
switchport mode trunk
no shutdown
end
copy running-config startup-config

Trunk ports carry multiple VLANs using 802.1Q tagging — the 4-byte VLAN tag is inserted into each Ethernet frame. Note the deliberate order of the commands. switchport converts the interface from its default Layer 3 routed state to a Layer 2 switch port; without it, the following switchport mode trunk line is rejected. On a Nexus every physical port is routed by default, which is the single biggest behavioural difference from a Catalyst, where ports are Layer 2 by default.

The no shutdown line matters on platforms and port profiles that ship with unused ports administratively disabled by a pre-provisioning script — a common practice in vendor-supplied initial configurations. If the link stays down after these commands, check show interface ethernet1/1 for "Administratively down" versus "not connected"; the first means the port is shut, the second means the cable or the far end is the problem.

Task 2: Create VLANs and Assign Access Ports

configure terminal
vlan 10
name USERS_VLAN10
vlan 20
name SERVERS_VLAN20
interface ethernet1/5-6
switchport
switchport mode access
switchport access vlan 10
no shutdown
interface ethernet1/7-8
switchport
switchport mode access
switchport access vlan 20
no shutdown
end
copy running-config startup-config

VLAN creation in NX-OS is almost identical to IOS: the vlan 10 command creates the VLAN if it does not exist and enters VLAN configuration mode, where name assigns a human-readable label. Names matter more than people expect. A VLAN 10 on one switch named "USERS_VLAN10" and on another named "VLAN0010" behaves identically at the protocol level, but documentation, automation scripts and troubleshooting sessions all get easier when names are consistent across the fabric.

The name you assign is stored in vlan.dat on most IOS platforms, but on NX-OS it is part of the running configuration and appears in show running-config vlan. That distinction has an operational consequence: on NX-OS, VLAN definitions are backed up and restored with the configuration, so a checkpoint or rollback restores VLAN names as well as switchport assignments. Practical VLAN ranges to remember are 1 (default), 2–1005 (normal), and 1006–4094 (extended); VLAN 1 should carry no user traffic, and VLAN 3968–4094 are reserved for internal use by the platform.

Access ports do not tag frames. The switch strips any tag on ingress, associates the frame with the configured access VLAN, and inserts the tag internally as needed; on egress toward the host the frame is untagged again. That is why an access port is safe to connect to a server, and why connecting a server that expects tagged frames to an access port silently breaks connectivity.

Task 3: Restrict VLANs on Trunks

Best practice: explicitly permit only the VLANs you need instead of relying on the default allow-all behavior.

configure terminal
interface ethernet1/1-4
switchport trunk allowed vlan 10-20
end
copy running-config startup-config

By default a trunk allows VLANs 1–3967, which means every broadcast domain you create anywhere in the fabric is flooded down that uplink until you say otherwise. Explicitly restricting the allowed list has three benefits: it contains broadcast storms, it prevents VLAN misconfiguration on one switch from leaking into a neighbouring switch's spanning-tree topology, and it makes the intent of the link readable from a single line of configuration.

Be careful with the difference between the absolute form and the additive form. switchport trunk allowed vlan 10-20 replaces the allowed list, while switchport trunk allowed vlan add 30 appends to it. On a production trunk carrying the management VLAN, issuing the absolute form with an incomplete list cuts your own management session. Cisco recommends the additive form for changes and the absolute form only during initial provisioning.

Task 4: Native VLAN, Voice VLAN and Port Security on Nexus

NX-OS supports the same Layer 2 bells and whistles as IOS, but the commands live in slightly different places. The native VLAN, which carries untagged traffic on a trunk, is configured per interface:

configure terminal
interface ethernet1/1-4
switchport trunk native vlan 99
switchport trunk allowed vlan 10-20,99
end

Two rules apply to native VLANs in a data center. Keep the native VLAN the same on both ends of every trunk — a mismatch causes a CDP/LLDP native VLAN mismatch alarm and, worse, leaks traffic between the two VLANs across the link. And do not use VLAN 1 as the native VLAN, because it is the default everywhere and therefore the easiest for an attacker to reach.

Voice VLAN, used when an IP phone sits between the switch and a PC, also works on Nexus and combines an 802.1p CoS value with an auxiliary VLAN:

configure terminal
interface ethernet1/10
switchport mode access
switchport access vlan 10
switchport voice vlan 150
end

The phone tags its own traffic in VLAN 150 and passes untagged PC traffic through to VLAN 10. If the phone is a Cisco model, it learns the voice VLAN from LLDP-MED or CDP rather than from its own configuration, which is why removing LLDP from a trunk feeding phones breaks voice VLANs unexpectedly.

Task 5: Layer 3 SVIs for Inter-VLAN Routing

A VLAN that has member ports but no Layer 3 interface is an isolated island. On NX-OS you must enable the interface-VLAN feature before you can create the SVI, a step with no IOS equivalent:

configure terminal
feature interface-vlan
interface vlan 10
no shutdown
ip address 10.10.0.1/24
description USERS_VLAN10_SVI
interface vlan 20
no shutdown
ip address 10.20.0.1/24
description SERVERS_VLAN20_SVI
end
copy running-config startup-config

Until feature interface-vlan is enabled, interface vlan 10 is rejected with an error, and this is the single most common "the command doesn't exist" complaint from engineers moving to NX-OS. The alternative to an SVI is a routed port, configured with no switchport followed by an IP address, which is the preferred design for uplinks between a Nexus and a WAN router or firewall because it removes the Layer 2 fault domain entirely.

If you are running a vPC pair, remember that the SVI must be configured identically on both peers, that the SVI MAC address is taken from the vPC domain rather than the chassis, and that adding or removing the SVI during production traffic causes a brief control-plane transition on the vPC. For vPC-specific failure modes, see the NX-OS vPC configuration walkthrough and the vPC peer-gateway and orphan port guide.

Verification Commands

show vlan brief
show interface trunk
show interface status
show mac address-table

Reading the Verification Output

Each of the four commands answers a different question, and using the wrong one is how troubleshooting sessions lose an hour.

show vlan brief confirms that VLAN 10 and 20 exist, shows their names, and lists which access ports belong to each VLAN. If a port appears under VLAN 1 instead of VLAN 10, the switchport access vlan command was either rejected or applied to a different interface.
show interface trunk is the authoritative trunk view. It lists the trunk ports, their mode (trunk vs. trunk-on), the encapsulation, the native VLAN, and the allowed VLAN list. A port missing from this output is not trunking, no matter what the interface configuration says — check for a static access configuration or an STP state of "blocking" or "err-disabled".
show interface status gives speed, duplex, VLAN and type per port in a single table. Use the | include filter to cut noise, for example show interface status | include connected.
show mac address-table proves data-plane learning. If a host is up but its MAC does not appear, the frame is not reaching the switch port — look at the cable, the NIC and the port's error counters with show interface ethernet1/5 counters errors before you touch the configuration.

Two extensions are worth knowing. show mac address-table dynamic vlan 10 scopes learning to one VLAN, and show interface trunk vlan 10 confirms that a specific VLAN is allowed on a specific trunk — useful when a VLAN works on one uplink but not on a parallel one.

Troubleshooting: The Five Failures You Will Actually Hit

1. The trunk shows "not-trunking" in the status column. One end is configured as access and the other as trunk. NX-OS does not run DTP by default, so there is no negotiation to fall back on — the mismatch simply never converges. Fix both ends.

2. A VLAN exists but hosts cannot talk across the trunk. Check the allowed VLAN list on both ends with show interface trunk. VLAN 20 created on all switches but missing from the allowed list on one uplink produces exactly this symptom: local connectivity works, cross-switch connectivity does not.

3. STP blocks the port unexpectedly. Parallel links between two switches without a port channel create a loop, and STP blocks all but one link. The fix is a port channel, and in a Nexus fabric a vPC on the access pair. Note that STP reconvergence across a trunk whose VLAN list changed is disruptive — do allowed-VLAN changes in a maintenance window.

4. Duplicate MAC addresses appear in the table. Normally caused by a bridging loop, a vPC misconfiguration where both peers forward the same frame, or a host behind two access ports. Disable the offending port first, then trace the loop.

5. The SVI comes up but routing fails. Verify feature interface-vlan is enabled, the SVI is not shut, the subnet mask matches, and that the hosts point to the SVI as their default gateway. On a routed port, confirm no switchport was applied before the IP address was assigned.

Modern NX-OS Best Practices

Add descriptions, spanning-tree port types and disable unused ports:

configure terminal
feature interface-vlan
interface ethernet1/1-4
description TRUNK_TO_CORE
switchport mode trunk
switchport trunk allowed vlan 10,20
spanning-tree port type network
interface ethernet1/5-6
description USER_ACCESS_PORTS
switchport mode access
switchport access vlan 10
spanning-tree port type edge
interface ethernet1/20-48
shutdown

spanning-tree port type network marks the trunk as a fabric-facing link and moves it to the network port role, which effectively removes it from edge port timeout logic and is the correct setting for inter-switch links in a data center where STP is a safety net rather than a design tool. spanning-tree port type edge (the equivalent of IOS portfast) brings access ports into forwarding immediately and should only ever be applied to ports facing hosts — applying it to a switch-to-switch link guarantees a loop.

Descriptions are not cosmetic. A data center switch can carry hundreds of ports, and description is what turns show interface status from a wall of port numbers into a readable map. Adopt a convention such as TO_<device>_<purpose> and enforce it in review.

Shutting unused ports is the cheapest security control available. It prevents someone from plugging a rogue device into a spare port, removes the port from CDP/LLDP advertisement, and reduces the STP topology. Pair it with switchport port-security on access ports and 802.1X where the environment supports it. On NX-OS the port-security feature is enabled with feature port-security before the interface commands are accepted.

NX-OS vs Classic IOS

The biggest differences: NX-OS uses interface ethernet1/1-4 ranges directly (no interface range keyword), requires feature commands to enable features like interface-vlan, and has modular process isolation with advanced APIs for automation. A few more contrasts are worth committing to memory:

Default interface state. Nexus ports are routed (Layer 3) by default; Catalyst ports are switched. You must issue switchport.
Configuration model. NX-OS validates during entry and supports atomic checkpoints and rollback: checkpoint then rollback running-config checkpoint <name> reverts everything at once — see the checkpoint and rollback guide.
VLAN database. There is no separate vlan database mode; VLAN 1–3967 are available and VLAN definitions live in the running configuration.
Show output. NX-OS presents tabular, filterable output by default; piping with | include, | exclude and | json is idiomatic and often the fastest verification path.
Feature licensing. Some capabilities require a license file (show license usage), which IOS generally does not.

If your environment mixes Cisco and Arista, note that the commands are close enough to be dangerous — Cisco versus Arista architecture and CLI compared covers the divergences in detail.

FAQ

Does NX-OS still use DTP? No. Dynamic Trunking Protocol is not supported on Nexus platforms. Trunks are configured statically with switchport mode trunk on both ends, which is also why mode mismatches are silent rather than negotiated.

How do I add a VLAN to a trunk without dropping the others? Use the additive form: switchport trunk allowed vlan add 30. The absolute form replaces the entire list.

Can I create a VLAN on a switch that has no member ports? Yes, and it is common practice when VLANs are provisioned centrally by automation before the hosts are racked. The VLAN appears in show vlan brief as active with no ports.

Why does my SVI not appear after configuration? Almost always because feature interface-vlan was never enabled, or because the SVI is administratively shut. Confirm with show feature | include interface-vlan and show interface vlan 10.

Do trunks need a non-default MTU? Only if you run VXLAN or jumbo frames on the fabric. Set it consistently on all fabric links: system mtu 9216 globally on NX-OS, then verify with show interface ethernet1/1 | include MTU.