About the Basic Interface Parameters
Interface descriptions
An interface description is a configuration attribute that
-
assigns a recognizable name to an Ethernet or management interface,
-
enables quick identification of the interface in listings with multiple interfaces, and
-
allows unique labeling to distinguish individual interface roles or purposes.
To set the description parameter for a port-channel interface, see the “Configuring a Port-Channel Description” section.
To set the description parameter for other interfaces, see the “Configuring the Description” section.
Beacon mode
Beacon mode is a port identification feature that
-
activates the port’s link-state LED to flash green for identification,
-
is disabled by default, and
-
is enabled by setting the beacon parameter on an interface.
You can use beacon mode to easily locate a physical port on a device during installation or troubleshooting. When activated, the corresponding port's LED flashes green, indicating the exact interface. This simplifies tasks such as cable tracing or port verification in complex environments.
To identify the physical port for an interface, activate the beacon parameter for the interface.
For information on configuring the beacon parameter, see “Configuring the Beacon Mode” section.
Error-disabled states
An error-disabled state is an operational port state that
-
occurs when a port is administratively enabled, but disabled at runtime due to a detected problem,
-
results from automated protection mechanisms (such as UDLD detecting unidirectional links or excessive port flapping), and
-
requires manual intervention or specific recovery configuration to restore normal operation.
Additional information
A port enters the error-disabled (err-disabled) state when it is enabled administratively using the no shutdown command, but is disabled at runtime by any process.
When an interface is in the err-disabled state, use the show interface status err-disabled command to find information about the error.
For example, if UDLD detects a unidirectional link, the port is shut down at runtime. However, because the port is administratively enabled, the port status displays as err-disable.
Once a port goes into the err-disable state, you must manually reenable it or you can configure a timeout value that provides an automatic recovery.
![]() Note |
By default, the automatic recovery is not configured, and the err-disable detection is enabled for all causes. |
Automatic error-disabled recovery
You can configure the automatic error-disabled recovery timeout for a particular error-disabled cause and configure the recovery period.
The errdisable recovery cause command provides an automatic recovery after 300 seconds.
You can use the errdisable recovery interval command to change the recovery period within a range of 30 to 65535 seconds. You can also configure the recovery timeout for a particular err-disable cause.
If error-disabled recovery is not enabled for the cause, the interface remains in error-disabled state until you enter the shutdown and no shutdown commands.
If the recovery is enabled for a cause, the interface is brought out of the error-disabled state and allowed to retry operation once all the causes have timed out.
Guidelines
MDIX parameters
A medium-dependent interface crossover (MDIX) parameter is an interface configuration setting that
-
enables or disables automatic detection of crossover connections between network devices,
-
applies only to copper network interfaces, and
-
defaults to enabled status, ensuring compatibility without manual wiring considerations.
The no mdix auto command is supported only on N9K-C93108TC-EX, N9K-C93108TC-FX, N9K-X9788TC-FX, and N9K-C9348GC-FXP devices.
For information about configuring the MDIX parameter, see the Configuring the MDIX Parameter section.
Interface status error policies
An interface status error policy is a network policy enforcement mechanism that
-
prevents interfaces from being activated if a policy push fails,
-
stores error state information to avoid repeated disruptions, and
-
ensures policy and hardware configuration consistency.
Cisco NX-OS policy servers, such as Access Control List (ACL) Manager and Quality of Service (QoS) Manager, maintain a policy database where each policy is defined through the command-line interface.
When you configure an interface with a policy, the system ensures that the policy matches the hardware policies. If a policy is pushed that does not match hardware policy, the interface is set to an error-disabled policy state. The error state persists and information is stored to prevent the port from being brought up in the future, avoiding repeated policy violations and system disruption.
To clear the error and retry the programming, use the no shutdown command.
Interface MTU sizes
A maximum transmission unit (MTU) size is a network interface parameter that
-
determines the largest frame size an Ethernet port can process,
-
enforces the drop of frames exceeding the configured size.
Additional information
By default, each interface uses an MTU of 1500 bytes, matching the IEEE 802.3 standard for Ethernet frames.
Larger MTU sizes, called jumbo frames, improve processing efficiency. Jumbo frames are typically up to 9216 bytes.
Cisco NX-OS platforms allow MTU adjustment per interface or at different levels in the protocol stack.
CloudScale switches allow an extra 166 bytes above the configured MTU (by default) to accommodate additional encapsulations in hardware.
![]() Note |
For transmissions to occur between two ports, you must configure the same MTU size for both ports. A port drops any frames that exceed its MTU size. |
MTU configuration by interface type
MTU is configured per interface. An interface can be a Layer 2 or a Layer 3 interface.
-
Layer 2 interfaces
You can configure the MTU size with one of two values: the system default MTU value or the system jumbo MTU value.
The system default MTU value is 1500 bytes. Each Layer 2 interface uses this value by default. You can configure an interface with the default system jumbo MTU value, that is 9216 bytes.
To allow an MTU value from 1500 through 9216, first set the system jumbo MTU. Then, align interface MTUs accordingly.
Note
You can change the system jumbo MTU size. When the value is changed, the Layer 2 interfaces that use the system jumbo MTU value, automatically changes to the new system jumbo MTU value.
-
Layer 3 interfaces
Layer 3 interfaces include the Layer 3 physical interface (configured with no switchport), switch virtual interface (SVI), and sub-interface. You can configure their MTU size between 576 and 9216 bytes.
For information about setting the MTU size, see the Configuring the MTU Size section.
Guidelines
-
If you configure an ingress interface with an MTU less than 9216 on Cisco Nexus 9300-FX2 and 9300-GX devices, FTE does not capture input errors or display events. If you set the ingress MTU to 9216, FTE displays all events.
Bandwidth
Bandwidth is a network performance metric that
-
measures the maximum data transfer rate of a network connection,
-
defines the capacity of a link between devices, and
-
remains fixed at the physical layer for Ethernet ports (for example, 1,000,000 Kb).
On Ethernet ports, the physical bandwidth is always fixed (such as 1,000,000 Kb). Layer 3 protocols use a configurable bandwidth value solely for internal metric calculations. Modifying this parameter affects only the routing protocol’s behavior and does not physically alter the connection’s capacity.
For example, the Enhanced Interior Gateway Routing Protocol (EIGRP) uses the minimum path bandwidth to determine a routing metric, but the bandwidth at the physical layer remains at 1,000,000 Kb.
For information about configuring the bandwidth parameter, see the Configuring the Bandwidth.
Throughput-delayp values
Throughput-delay is an interface configuration parameter that
-
provides a value used by Layer 3 protocols to make operating decisions,
-
does not affect the actual throughput delay of an interface, and
-
is specified in tens of microseconds.
For example, the Enhanced Interior Gateway Routing Protocol (EIGRP) can use the delay setting to set a preference for one Ethernet link over another, if other parameters such as link speed are equal. The delay value is specified in the tens of microseconds.
For information on configuring the throughput-delay parameter for other interfaces, see Configuring the Throughput Delay.
Administrative status parameters
An administrative status parameter is a network interface setting that:
-
indicates whether an interface is administratively up or down,
-
enables or disables the ability of the interface to transmit data.
When the administrative status is set to down, the interface is disabled and cannot transmit data. When set to up, the interface is enabled.
For information about configuring the administrative status parameter for port-channel interfaces, see the “Shutting Down and Restarting the Port-Channel Interface” section.
For information about configuring the administrative status parameter for other interfaces, see the “Shutting Down and Activating the Interface” section.
Unidirectional Link Detection
UDLD
Unidirectional Link Detection (UDLD) is a network protocol that
-
monitors the physical configuration of fiber and copper Ethernet cables between connected devices,
-
detects the presence of unidirectional links on these connections, and
-
automatically shuts down affected LAN ports to prevent network problems.
UDLD is a Cisco-proprietary protocol designed to identify and mitigate issues that occur when traffic passes in only one direction on a connection—known as a unidirectional link. Such conditions can create network loops and cause data loss or protocol malfunctions.
The Cisco Nexus 9000 Series device periodically transmits UDLD frames to neighbor devices on LAN ports with UDLD enabled. If the frames are echoed back within a specific time frame but lack an acknowledgment (echo), the link is flagged as unidirectional. The LAN port is then shut down.
Both ends of the link must support UDLD for the protocol to identify and disable unidirectional links. You can configure the transmission interval for the UDLD frames globally or for the specified interfaces.
Additional information
UDLD performs tasks that autonegotiation cannot perform, such as detecting the identities of neighbors and shutting down misconnected LAN ports.
When you enable both autonegotiation and UDLD, Layer 1 detections work to prevent physical and logical unidirectional connections and the malfunctioning of other protocols.
A unidirectional link occurs when traffic sent by the local device is received by the neighbor, but traffic from the neighbor is not received by the local device.
If one of the fiber strands in a pair is disconnected and autonegotiation is active, the link does not remain up. In this case, the logical link is undetermined, and UDLD does not take any action. If both fibers work normally at Layer 1, UDLD checks whether they are connected correctly and whether traffic flows bidirectionally between the correct neighbors. This check cannot be performed by autonegotiation, because autonegotiation operates at Layer 1.
![]() Note |
By default, UDLD is locally disabled on copper LAN ports to avoid sending unnecessary control traffic on this type of media. |
Example
Device A and Device B are connected with fiber-optic cables. Due to a cable break, Device B can receive traffic from Device A, but Device A cannot receive traffic from Device B. UDLD detects this unidirectional condition and disables the affected port, preventing network issues.

Analogy
UDLD is like a two-way conversation in which both participants regularly confirm they can hear each other. If one participant stops responding, the conversation is paused to prevent misunderstandings—just as UDLD disables a port if bidirectional communication fails.
Default UDLD configuration states
UDLD configuration state is a system-defined setting that
-
specifies whether UDLD operates globally or on specific ports,
-
determines if UDLD runs in standard or aggressive mode, and
-
controls the message interval for UDLD protocol operation.
UDLD applies different defaults depending on port media type.
-
On Ethernet fiber-optic ports, UDLD is enabled by default.
-
On Ethernet twisted-pair (copper) ports, UDLD is disabled by default. You must enable UDLD if you want to use it.
UDLD default configuration states
The table shows the default UDLD configuration.
Feature |
Default Value |
---|---|
UDLD global enable state |
Globally disabled |
UDLD per-port enable state for fiber-optic media |
Enabled on all Ethernet fiber-optic LAN ports |
UDLD per-port enable state for twisted-pair (copper) media |
Disabled on all Ethernet 10/100 and 1000BASE-TX LAN ports |
UDLD aggressive mode |
Disabled |
UDLD message interval |
15 seconds |
For information about configuring the UDLD for the device and its port, see the “Configuring the UDLD Mode” section.
UDLD normal and aggressive modes
The UDLD mode monitors links and determines how to detect and respond to unidirectional link failures.
You can use UDLD in normal mode or aggressive mode.
-
Normal mode: UDLD normal mode exchanges packets between peers ports to detect link health.
-
Aggressive mode: UDLD aggressive mode attempts to re-establish contact with an unresponsive neighbor. If, after eight retries, the link remains unresponsive, UDLD aggressively disables the affected port to prevent undetected one-way faults from causing network issues.
Additional information
When the switch detects link errors such as an empty echo packet, unidirectional failure, TX or RX loop, or neighbor mismatch, it flags the condition but might not disable the port.
UDLD operates in normal mode by default, and aggressive mode is disabled unless you enable it.
When you enable UDLD aggressive mode globally, it activates on all fiber ports. You can also activate on a specific individual fiber port.
![]() Note |
You must configure it on individual copper interfaces. |
Use UDLD aggressive mode only between network devices that both support it. Use this mode only on point-to-point links.
In these scenarios, UDLD aggressive mode disables a port to prevent traffic loss.
-
One side of a link has a stuck port (both transmission and receive)
-
One side of a link remains up while the other side of the link is down
Guidelines
-
If you upgrade a line card during an ISSU, and some ports are part of a Layer 2 port channel with UDLD aggressive mode enabled, shutting down a remote port causes UDLD to place the local port in error-disabled state. This is the expected behavior.
To restore service after the ISSU has completed, enter the shutdown command followed by the no shutdown command on the local port.
Port channels
A port channel is a logical interface that
-
combines multiple physical interfaces to increase aggregate bandwidth,
-
provides redundancy by remaining operational as long as at least one member interface is active, and
-
balances traffic across the participating physical interfaces to optimize network performance.
Port channeling also load balances traffic across these physical interfaces. The port channel remains operational as long as at least one physical interface within the channel is active
Additional information
You can create Layer 3 port channels by bundling compatible Layer 3 interfaces.
Any configuration changes made to a port channel are automatically applied to each member interface within that channel.
For information about port channels, see Chapter 6, "Configuring Port Channels".
Port Profiles
On Cisco Nexus 9300 Series switches, you can create a port profile that contains many interface commands and apply that port profile to a range of interfaces. Each port profile can be applied only to a specific type of interface; the choices are as follows:
-
Ethernet
-
VLAN network interface
-
Port channel
When you choose Ethernet or port channel as the interface type, the port profile is in the default mode which is Layer 3. Enter the switchport command to change the port profile to Layer 2 mode.
You inherit the port profile when you attach the port profile to an interface or range of interfaces. When you attach, or inherit, a port profile to an interface or range of interfaces, the system applies all the commands in that port profile to the interfaces. Additionally, you can have one port profile inherit the settings from another port profile. Inheriting another port profile allows the initial port profile to assume all of the commands of the second, inherited, port profile that do not conflict with the initial port profile. Four levels of inheritance are supported. The same port profile can be inherited by any number of port profiles.
The system applies the commands inherited by the interface or range of interfaces according to the following guidelines:
-
Commands that you enter under the interface mode take precedence over the port profile’s commands if there is a conflict. However, the port profile retains that command in the port profile.
-
The port profile’s commands take precedence over the default commands on the interface, unless the port-profile command is explicitly overridden by the default command.
-
When a range of interfaces inherits a second port profile, the commands of the initial port profile override the commands of the second port profile if there is a conflict.
-
After you inherit a port profile onto an interface or range of interfaces, you can override individual configuration values by entering the new value at the interface configuration level. If you remove the individual configuration values at the interface configuration level, the interface uses the values in the port profile again.
-
There are no default configurations associated with a port profile.
A subset of commands are available under the port-profile configuration mode, depending on which interface type you specify.
![]() Note |
You cannot use port profiles with Session Manager. See the Cisco Nexus 9000 Series NX-OS System Management Configuration Guide for information about Session Manager. |
To apply the port-profile configurations to the interfaces, you must enable the specific port profile. You can configure and inherit a port profile onto a range of interfaces prior to enabling the port profile. You would then enable that port profile for the configurations to take effect on the specified interfaces.
If you inherit one or more port profiles onto an original port profile, only the last inherited port profile must be enabled; the system assumes that the underlying port profiles are enabled.
When you remove a port profile from a range of interfaces, the system undoes the configuration from the interfaces first and then removes the port-profile link itself. Also, when you remove a port profile, the system checks the interface configuration and either skips the port-profile commands that have been overridden by directly entered interface commands or returns the command to the default value.
If you want to delete a port profile that has been inherited by other port profiles, you must remove the inheritance before you can delete the port profile.
You can also choose a subset of interfaces from which to remove a port profile from among that group of interfaces that you originally applied the profile. For example, if you configured a port profile and configured ten interfaces to inherit that port profile, you can remove the port profile from just some of the specified ten interfaces. The port profile continues to operate on the remaining interfaces to which it is applied.
If you delete a specific configuration for a specified range of interfaces using the interface configuration mode, that configuration is also deleted from the port profile for that range of interfaces only. For example, if you have a channel group inside a port profile and you are in the interface configuration mode and you delete that port channel, the specified port channel is also deleted from the port profile as well.
Just as in the device, you can enter a configuration for an object in port profiles without that object being applied to interfaces yet. For example, you can configure a virtual routing and forward (VRF) instance without it being applied to the system. If you then delete that VRF and related configurations from the port profile, the system is unaffected.
After you inherit a port profile on an interface or range of interfaces and you delete a specific configuration value, that port-profile configuration is not operative on the specified interfaces.
If you attempt to apply a port profile to the wrong type of interface, the system returns an error.
When you attempt to enable, inherit, or modify a port profile, the system creates a checkpoint. If the port-profile configuration fails, the system rolls back to the prior configuration and returns an error. A port profile is never only partially applied.
Cisco QSFP+ to SFP+ adapter modules
A Cisco QSFP+ to SFP+ adapter module (QSA) is a network interface accessory that
-
enables the use of 10G SFP+ transceivers in 40G QSFP+ uplink ports,
-
requires all ports in a designated speed group to operate at the same speed (either 10G or 40G).
The Cisco QSFP+ to SFP+ adapter (QSA) module enables 10G operation on 40G uplink ports within Cisco Nexus M6PQ and M12PQ uplink modules, which belong to specific Cisco Nexus 9300 devices
To use QSA/QSFP modules, six consecutive ports in the M6PQ or M12PQ uplink module must operate at the same speed—either 10G or 40G.
Supported platforms and port groups
These Cisco Nexus devices and port groups support the Cisco QSFP+ to SFP+ adapter module:
-
Cisco Nexus 9396PX: 2/1–6 (first group), 2/7–12 (second group)
-
Cisco Nexus 93128PX/TX: 2/1–6 (first group), 2/7–8 (second group)
-
Cisco Nexus 937xPX/TX: 1/49–54 (only group)
-
Cisco Nexus 93120TX: 1/97–102 (only group)
-
Cisco Nexus 9332PQ: 1/27–32 (only group)
Configuring port speed for QSA modules
Use the speed-group 10000 command to configure the first port of a port speed group to set all ports in the group to 10G. The default port speed is 40G.
The no speed-group 10000 command specifies a speed of 40G.
-
Do not remove uplink modules from a Cisco Nexus 9300 platform switch that runs Cisco NX-OS Release 7.0(3)I7(5). Use the ports on uplink modules for uplinks only
-
Beginning with Cisco NX-OS Release 9.2(2), CWDM4 is supported on these line cards:
-
36-port 100-Gigabit Ethernet QSFP28 line cards (N9K-X9636C-R)
-
36-port 40-Gigabit Ethernet QSFP+ line cards (N9K-X9636Q-R),
-
36-port 100-Gigabit QSFP28 line cards (N9K-X9636C-RX)
-
52-port 100-Gigabit QSFP28 line cards (N9K-X96136YC-R)
-
After you configure the speed, the switch enables compatible transceiver modules. The switch disables incompatible modules and displays the message 'check speed-group' config.
![]() Note |
The Cisco QSFP+ to SFP+ Adapter (QSA) module does not provide 10G support for the 40G line cards for Cisco Nexus 9500 devices. You can use a QSFP-to-SFP adapter on Cisco Nexus 9200 and 9300-EX Series switches and Cisco Nexus 3232C and 3264Q Series switches. |
Cisco SFP+ adapter modules
A Cisco SFP+ adapter module is a network interface device that
-
enables high-speed connectivity by adapting SFP+ optics for use in higher-capacity switch ports,
-
supports multiple Ethernet speeds (such as 10G and 25G) with manual or automatic speed configuration.
The interface breakout module command enables you to split a 100G interface into four 25G interfaces. After you enter this command, you must copy the running configuration to the startup configuration.
Beginning with Cisco NX-OS Release 9.2(3), 10/25 LR is supported on N9K-C93180YC-EX, N9K-X97160YC-EX, N9K-C93180YC-FX, N9K-C93240YC-FX2 and N3K-C34180YC switches.
This dual speed optical transceiver operates at 25G by default and interoperates with other 25G LR transceivers. Because auto speed sensing is not supported, to use this device with a 10G transceiver, configure it manually for 10G speed.
The CVR-2QSFP28-8SFP adapter supports 25-Gigabit optics on 100-Gigabit ports of the Cisco Nexus 9236C switch.
Cisco SFP-10G-T-X modules
A Cisco SFP-10G-T-X module is a hot-swappable, 10 Gigabit Ethernet transceiver that
-
provides 10GBASE-T connectivity over standard Category 6a or 7 copper cabling,
-
supports RJ-45 connectors for interface flexibility, and
-
enables up to 30-meter reach for data center and enterprise applications.
Starting with Cisco NX-OS Release 9.3(5), 10G BASE-T SFP+ (RJ-45) is supported on N9K-C93240YC-FX2, N9K-C93180YC-EX, N9K-C93180YC-FX and N9K-C93360YC-FX2 devices.
By default, Cisco SFP-10G-T-X modules operate at 10G speeds.
When using a SFP-10G-T-X module, all neighboring ports must be either empty or must use passive copper links.
The show interface and show interface capability commands display supported speed for certain ports.
The switch may display 100 Mbps as a supported speed for certain ports when using the SFP-10G-T-X transceiver. For GLC-TE transceivers, the lowest supported speed is 1 Gbps.
An interface configured with media-type 10G-TX, while in the admin up state, remains error-disabled when using an unsupported media-type. To resolve this condition, enter these commands on the interface:
-
shutdown
-
no shutdown
The table shows the default port mapping for various Cisco Nexus switches.
Device Name |
Port Map |
---|---|
Cisco Nexus N9K-C93180YC-EX, N9K-C93180YC-FX, N9K-C93180YC-FX3 and N9K-C93180YC-FX3S |
PI/PE: 1, 4-5, 8-9, 12-13, 16, 37, 40-41, 44-45, 48 |
Cisco Nexus N9K-C93240YC-FX2 |
W/ PI Fan/PS: 2, 6, 8, 12, 14, 18, 20, 24, 26, 30, 32, 36, 38, 42, 44, 48 W/ PE Fan/PS: 6, 12, 18, 24, 30, 36, 42, 48 |
Cisco Nexus N9K-C93360YC-FX2 |
PI/PE 1, 4-5, 8, 41, 44-45, 48-49, 52-53, 56-57, 60-61, 64-65, 68-69, 72-73, 76-77, 80-81, 84-85, 88-89, 92-93, 96 |