The error messages and solutions in this document may vary depending on the code version you are running. While the general concepts apply to all versions, slight variations in outputs and results may occur. This document is not meant to replace the use of Cisco TAC, so please do not hesitate to give Cisco a call whenever in doubt.
The interface shows a status of ‘SFP validation failed’. The link will not come up. The link light on the nexus 5000 is typically dark (no LED).
Configure ‘speed 1000’ or ‘speed 10000
The first, and most common, scenario is that the wrong speed is configured on the interface. For example, if you are using a 1G SFP such as the GLC-T, you will see this error message if the speed on the port is still at default 10G. To fix this case, simply configure ‘speed 1000’ on the interface. This same situation also applies for 10G SFPs if you have speed 1000 configured on the port instead of 10000.
Configure ‘switchport mode fex-fabric’
The second scenario that sees this error message is that the wrong switchport mode is not configured on the interface. The only scenario which this can be true is when you are using a FET-10G SFP between your N2K and N5K. These FET-10G transceivers requires a ‘switchport mode fex-fabric’ to be configured on the interface to be validated.
Verify that the SFP is supported.
For a list of supported Cisco transceivers, you can use the following link:
Table 2: Cisco Nexus 5000 Series Transceiver Support Matrix
From the output above, this will tell you the actual FEX that is connected to that interface, and what number FEX you have this configured as. Make sure all the serial numbers match for the specific FEX number. If your FEX is dual-homed in a VPC (active/active), you will see the message above as ‘incompatible-topology’ if a specific VPC has two different FEXs. Go onto the N5K peer and do the same serial number trace, or in other words make sure the serial numbers on switch A go to the same fex # as the ones on switch B for dual-homed fabric extenders.
Also confirm that you are using a supported FEX topology, as per the link below (page 31, Figures, 21-24):
Following commands failed mutual-exclusion checks:
interface Ethernet 1/1
Spanning-tree port type network
switch(config-if)# switchport mode trunk
Error: Command is not mutually exclusive
When you are using config sync and are trying to configure an interface in conf t mode, you are unable to configure the interface because the command is not mutually exclusive. This may also arise when trying to sync a switch-profile using config sync, but it fails due to the same reason.
Any mutual exclusive check failure, in config t or config sync mode, means that the command already exists in the other mode. In other words, if you see the error when trying to configure in conf t mode, this means the command already exists in your switch-profile config sync mode. If you see the switch-profile commit fail due to this, it is because the command already exists in conf t mode either on the local switch, or on the peer switch. If you are not sure which switch the command exists, "show switch-profile status" will show you the status of the last commit and where it failed. Remember that when using config sync, you may only have specific configuration in one mode at a time.
When trying to add more than one interface on a Fabric Extender into a port-channel, you get an error message that states you cannot have more than 1 member in the port-channel. This will only occur when using a 2148 FEX.
This is a hardware limitation of the 2148 FEX. By design, you may only have one link in the port-channel as the error message says. However, you may have this port-channel in a vPC that has another member on a second N5K and FEX. This allows you to have a total of two links in the same port-channel across the two 2148. In all other models of FEXs, we allow more than 1 member in the port-channel per fex.