About the Basic Interface Parameters
Description
For the Ethernet and management interfaces, you can configure the description parameter to provide a recognizable name for the interface. Using a unique name for each interface allows you to quickly identify the interface when you are looking at a listing of multiple interfaces.
For information about setting the description parameter for port-channel interfaces, see the “Configuring a Port-Channel Description” section. For information about configuring this parameter for other interfaces, see the “Configuring the Description” section.
Beacon
The beacon mode allows you to identify a physical port by flashing its link state LED with a green light. By default, this mode is disabled. To identify the physical port for an interface, you can activate the beacon parameter for the interface.
For information about configuring the beacon parameter, see the “Configuring the Beacon Mode” section.
Error Disabled
A port is in the error-disabled (err-disabled) state when the port is enabled administratively (using the no shutdown command) but disabled at runtime by any process. 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. By default, the automatic recovery is not configured, and by default, the err-disable detection is enabled for all causes.
When an interface is in the err-disabled state, use the errdisable detect cause command to find information about the error.
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 you do not enable the error-disabled recovery for the cause, the interface stays in the 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. Use the show interface status err-disabled command to display the reason behind the error.
Interface Status Error Policy
Cisco NX-OS policy servers such as Access Control List (ACL) Manager and Quality of Service (QoS) Manager, maintain a policy database. A policy is defined through the command-line interface.
Policies are pushed when you configure a policy on an interface to ensure that policies that are pushed are consistent with the hardware policies. To clear the errors and to allow the policy programming to proceed with the running configuration, enter the no shutdown command. If the policy programming succeeds, the port is allowed to come up. If the policy programming fails, the configuration is inconsistent with the hardware policies and the port is placed in an error-disabled policy state. The error-disabled policy state remains and the information is stored to prevent the same port from being brought up in the future. This process helps to avoid unnecessary disruption to the system.
Modifying Interface MTU Size
The maximum transmission unit (MTU) size specifies the maximum frame size that an Ethernet port can process. 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.
By default, the Cloud-Scale ASIC NX-OS system always allows an extra 166B in the MTU on top of the configured value in order to fully support/accept different types of encapsulations in the hardware.
Cisco NX-OS allows you to configure MTU on an interface, with options to configure it on different level in the protocol stack. By default, each interface has an MTU of 1500 bytes, which is the IEEE 802.3 standard for Ethernet frames. Larger MTU sizes are possible for more efficient processing of data to allow different application requirements. The larger frames, are also called jumbo frames, can be up to 9216 bytes in size.
MTU is configured per interface, where an interface can be a Layer 2 or a Layer 3 interface. For a Layer 2 interface, you can configure the MTU size with one of two values, the value system default MTU value or the system jumbo MTU value. The system default MTU value is 1500 bytes. Every Layer 2 interface is configured with 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, you must adjust the system jumbo MTU to an appropriate value where interface can be configured with the same value.
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, will automatically changes to the new system jumbo MTU value. |
A Layer 3 interface, can be Layer 3 physical interface (configure with no switchport), switch virtual interface (SVI), and sub-interface, you can configure an MTU size between 576 and 9216 bytes.
For the Cisco Nexus 9372 switch, the following applies:
-
The 10-G interfaces are mapped to specific hardware ports where the default MTU is 1500.
-
The 40-G interfaces are mapped as a HiGiG port where the default MTU is 3FFF and the MTU limit check is disabled.
-
In the case of 40-G interfaces, since the MTU limit check is disabled, it ignores the packet size and traffic flows irrespective of its MTU.
-
When the configured MTU of all interfaces on the switch do not match, the switch's behavior may vary depending on the specific port that is mismatched as well as the traffic flow. The following are examples of the switch's behavior in various scenarios:
-
When a Layer 3 port receives a frame whose length exceeds the port's MTU size, the port will drop the frame.
-
When a Layer 3 port receives a frame whose length is less than the ingress port's MTU size, but greater than the egress Layer 3 port's MTU size, then the frame is punted to the supervisor of the switch.
-
If the frame is an IP packet that has the Don't Fragment (DF) bit set, then the frame will be dropped in software. Otherwise, the frame will be fragmented in software.
-
Otherwise, the frame will be fragmented in software.
-
This can cause performance issues (such as increased latency or packet loss for affected traffic flows) due to Control Plane Policing (CoPP) enabled by default on Cisco Nexus switches. For more information about Control Plane Policing, refer to the Configuring Control Plane Policing chapter of the Cisco Nexus 9000 Series NX-OS Security Configuration Guide.
-
-
When a Layer 2 port receives a frame whose length exceeds the port's MTU size, the port will drop the frame.
-
When a Layer 2 port receives a frame whose length is less than the ingress port's MTU size, but greater than the egress Layer 2 port's MTU size, and the frame is routed between VLANs by the switch, then the frame is punted to the supervisor of the switch.
-
If the frame is an IP packet that has the Don't Fragment (DF) bit set, then the frame will be dropped in software. Otherwise, the frame will be fragmented in software.
-
Otherwise, the frame will be fragmented in software.
-
This can cause performance issues (such as increased latency or packet loss for affected traffic flows) due to Control Plane Policing (CoPP) enabled by default on Cisco Nexus switches. For more information about Control Plane Policing, refer to the Configuring Control Plane Policing chapter of the Cisco Nexus 9000 Series NX-OS Security Configuration Guide.
-
-
When a Layer 2 port receives a frame whose length is less than the ingress port's MTU size, but greater than the egress Layer 2 port's MTU size, and the frame is switched within the same VLAN by the switch, then the switch will drop the frame.
-
For information about setting the MTU size, see the Configuring the MTU Size section.
Note |
On Cisco Nexus 9300-FX2 and 9300-GX devices, if ingress interface is configured with an MTU less than 9216, FTE does not capture input errors and does not display any events. However, if the ingress interface is configured with an MTU of 9216, FTE displays all the events. |
Bandwidth
Ethernet ports have a fixed bandwidth of 1,000,000 Kb at the physical layer. Layer 3 protocols use a bandwidth value that you can set for calculating their internal metrics. The value that you set is used for informational purposes only by the Layer 3 protocols—it does not change the fixed bandwidth at the physical layer. 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 for port-channel interfaces, see the “Configuring the Bandwidth and Delay for Informational Purposes” section. For information about configuring the bandwidth parameter for other interfaces, see the “Configuring the Bandwidth” section.
Throughput Delay
Specifying a value for the throughput-delay parameter provides a value used by Layer 3 protocols; it does not change the actual throughput delay of an interface. The Layer 3 protocols can use this value to make operating decisions. 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 that you set is in the tens of microseconds.
For information about configuring the bandwidth parameter for port-channel interfaces, see the “Configuring the Bandwidth and Delay for Informational Purposes” section. For information about configuring the throughput-delay parameter for other interfaces, see the “Configuring the Throughput Delay” section.
Administrative Status
The administrative-status parameter determines whether an interface is up or down. When an interface is administratively down, it is disabled and unable to transmit data. When an interface is administratively up, it is enabled and able to transmit data.
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 Parameter
UDLD Overview
The Cisco-proprietary Unidirectional Link Detection (UDLD) protocol allows devices that are connected through fiber-optic or copper (for example, Category 5 cabling) Ethernet cables to monitor the physical configuration of the cables and detect when a unidirectional link exists. When a device detects a unidirectional link, UDLD shuts down the affected LAN port and alerts the user. Unidirectional links can cause a variety of problems.
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 whenever traffic transmitted by the local device over a link is received by the neighbor but traffic transmitted from the neighbor is not received by the local device. If one of the fiber strands in a pair is disconnected, as long as autonegotiation is active, the link does not stay up. In this case, the logical link is undetermined, and UDLD does not take any action. If both fibers are working normally at Layer 1, UDLD determines whether those fibers are connected correctly and whether traffic is flowing bidirectionally between the correct neighbors. This check cannot be performed by autonegotiation, because autonegotiation operates at Layer 1.
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 and they lack a specific acknowledgment (echo), the link is flagged as unidirectional and the LAN port is shut down. Devices on both ends of the link must support UDLD in order for the protocol to successfully identify and disable unidirectional links. You can configure the transmission interval for the UDLD frames, either globally or for the specified interfaces.
Note |
By default, UDLD is locally disabled on copper LAN ports to avoid sending unnecessary control traffic on this type of media. |
The figure shows an example of a unidirectional link condition. Device B successfully receives traffic from device A on the port. However, device A does not receive traffic from device B on the same port. UDLD detects the problem and disables the port.
Default UDLD Configuration
The following 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
UDLD supports Normal and Aggressive modes of operation. By default, Normal mode is enabled.
In Normal mode, UDLD detects the following link errors by examining the incoming UDLD packets from the peer port:
-
Empty echo packet
-
Uni-direction
-
TX/RX loop
-
Neighbor mismatch
By default, UDLD aggressive mode is disabled. You can configure UDLD aggressive mode only on point-to-point links between network devices that support UDLD aggressive mode.
If UDLD aggressive mode is enabled, when a port on a bidirectional link that has a UDLD neighbor relationship established stops receiving UDLD frame, UDLD tries to re-establish the connection with the neighbor. After eight failed retries, the port is disabled.
In the following scenarios, enabling the UDLD aggressive mode disables one of the ports to prevent the discarding of traffic.
-
One side of a link has a port stuck (both transmission and receive)
-
One side of a link remains up while the other side of the link is down
Note |
You enable the UDLD aggressive mode globally to enable that mode on all the fiber ports. You must enable the UDLD aggressive mode on copper ports on specified interfaces. |
Tip |
When a line card upgrade is being performed during an in-service software upgrade (ISSU) and some of the ports on the line card are members of a Layer 2 port channel and are configured with UDLD aggressive mode, if you shut down one of the remote ports, UDLD puts the corresponding port on the local device into an error-disabled state. This behavior is correct. |
To restore service after the ISSU has completed, enter the shutdown command followed by the no shutdown command on the local port.
Port-Channel Parameters
A port channel is an aggregation of physical interfaces that comprise a logical interface. You can bundle up to 32 individual interfaces into a port channel to provide increased bandwidth and redundancy. Port channeling also load balances traffic across these physical interfaces. The port channel stays operational if at least one physical interface within the port channel is operational.
You can create Layer 3 port channels by bundling compatible Layer 3 interfaces.
Any configuration changes that you apply to the port channel are applied to each interface member of that port channel.
For information about port channels and for information about configuring port channels, see Chapter 6, “Configuring Port Channels.”
Cisco QSFP+ to SFP+ Adapter Module Support
The Cisco QSFP+ to SFP+ Adapter (QSA) module provides 10G support for the 40G uplink ports that are a part of the Cisco Nexus M6PQ and Cisco Nexus M12PQ uplink modules of specific Cisco Nexus 9300 devices.
A group of six consecutive ports in the M6PQ or M12PQ uplink module must be operating at the same speed (40G or 10G) to use the QSA/QSFP modules.
-
For Cisco Nexus 9396PX devices, 2/1-6 ports form the first port speed group and the remaining 2/7-12 ports form the second port speed group.
-
For Cisco Nexus 93128PX/TX devices, 2/1-6 ports form the first port speed group and the remaining 2/7-8 ports form the second port speed group.
-
For Cisco Nexus 937xPX/TX devices, 1/49-54 ports form the only port speed group.
-
For Cisco Nexus 93120TX devices, 1/97-102 ports form the only port speed group.
-
For Cisco Nexus 9332PQ devices, 1/27-32 ports form the only port speed group.
Use the speed-group 10000 command to configure the first port of a port speed group for the QSA. This command specifies the administrator speed preference for the port group. (The default port speed is 40G.)
-
The speed-group 10000 command specifies a speed of 10G.
-
The no speed-group 10000 command specifies a speed of 40G.
After the speed has been configured, the compatible transceiver modules are enabled. The remaining transceiver modules in the port group (incompatible transceiver modules) become error disabled with a reason of "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. |