Before Contacting Technical Support
This chapter describes the steps to take before calling for technical support and includes the following sections:
Note If you purchased Cisco support through a Cisco reseller, contact the reseller directly. If you purchased support directly from Cisco, contact Cisco Technical Support at this URL: http://www.cisco.com/warp/public/687/Directory/DirTAC.shtm
Cisco Support Communities
For additional information, visit one of the following support communities:
Gathering Information for Technical Support
At some point, you may need to contact your customer support representative or Cisco TAC for some additional assistance. This section outlines the steps that the you should perform prior to contacting your next level of support, as this will reduce the amount of time spent resolving the issue.
Note Do not reload the module or the switch at least until you have completed Step 1 below. Some logs and counters are kept in volatile storage and will not survive a reload.
To prepare for contacting your customer support representative, follow these steps:
Collect switch information and configuration. This should be done before and after the issue has been resolved.
Configure your Telnet or SSH application to log the screen output to a text file. Use the terminal length 0 CLI command and then use the show tech-support details CLI command.
Step 2 Capture the exact error codes you see in CLI message logs using one of the following commands.
show logging log
CLI (displays the error messages)
show logging last number (displays the last lines of the log)
Step 3 Answer the following questions before calling for technical support:
On which switch or port is the problem occurring?
Cisco Nexus 1000V software, driver versions, operating systems versions and storage device firmware are in your fabric?
ESX and vCenter Server software that you are running?
What is the network topology?
Were any changes being made to the environment (VLANs, adding modules, upgrades) prior to or at the time of this event?
Are there other similarly configured devices that could have this problem, but do not?
Where was this problematic device connected (which switch and interface)?
When did this problem first occur?
When did this problem last occur?
How often does this problem occur?
How many devices have this problem?
Were any traces or debug output captured during the problem time? What troubleshooting steps have you attempted? Which, if any, of the following tools were used?
– Ethanalyzer, local or remote SPAN
– CLI debug commands
– traceroute, ping
Step 4 Is your problem related to a software upgrade attempt?
What was the original Cisco Nexus 1000V version?
What is the new Cisco Nexus 1000V version?
Obtaining a File of Core Memory Information
Cisco customer support engineers often use files from your system for analysis. One of these is a file containing memory information, and is referred to as a core dump. The file is sent to a TFTP server or to a Flash card in slot0: of the local switch. You should set up your switch to generate this file under the instruction of your customer support representative, and send it to a TFTP server so that it can be e-mailed to them.
To generate a file of core memory information, or a core dump, use the command in the following example.
n1000v# system cores tftp://10.91.51.200/jsmith_cores n1000v# show system cores Cores are transferred to tftp://10.91.51.200/jsmith_cores
Note The file name (indicated by jsmith_cores) must exist in the TFTP server directory.
It may be required to move files to or from the switch. These files may include log, configuration, or firmware files.
Cisco Nexus 1000V always acts as a client, such that an ftp/scp/tftp session will always originate from the switch and either push files to an external system or pull files from an external system.
File Server: 172.22.36.10 File to be copied to the switch: /etc/hosts
The copy CLI command supports four transfer protocols and 12 different sources for files.
bootflash: Select source filesystem core: Select source filesystem debug: Select source filesystem ftp: Select source filesystem licenses Backup license files log: Select source filesystem modflash: Select source filesystem nvram: Select source filesystem running-config Copy running configuration to destination scp: Select source filesystem sftp: Select source filesystem slot0: Select source filesystem startup-config Copy startup configuration to destination system: Select source filesystem tftp: Select source filesystem volatile: Select source filesystem
Use the following syntax to use secure copy (scp) as the transfer mechanism:
from 172.22.36.10 using the user
, where the destination would be
, use the following command:
n1000v# copy scp://firstname.lastname@example.org/etc/hosts bootflash:hosts.txt email@example.com's password: hosts 100% |*****************************| 2035 00:00
To back up the startup-configuration to a sftp server, use the following command:
n1000v# copy startup-config sftp://firstname.lastname@example.org/test/startup-configuration.bak1 Connecting to 172.22.36.10... User1@172.22.36.10's password:
Tip Backing up the startup-configuration to a server should be done on a daily basis and prior to any changes. A short script could be written to be run on Cisco Nexus 1000V to perform a save and then backup of the configuration. The script only needs to contain two commands: copy running-configuration startup-configuration and then copy startup-configuration tftp://server/name. To execute the script use: run-script filename.