Cisco - Cheatsheet

Automated Health and Configuration Check is supported only for the Nexus platforms that run standalone NX-OS software, and not the switches that run ACI software.

These hardware platforms are supported:

Nexus 3000/9000 series switches that run unified NX-OS software image: 7.0(3)Ix or newer
Nexus 7000/7700 series switches that run NX-OS software version 7.x or newer

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Health and Configuration Check Procedure

Please collect show tech-support details or show tech-support logs from the Nexus switch for which you would like to perform health and config check. The show tech-support details is preferred, as it provides higher value with more checks done. Please make sure the logs are captured either in .txt or .gz/.tar format. Currently the show tech-support or show tech-support details file captured in ASCII and UTF-8 text formats are supported.

Open a regular TAC Service Request at Cisco Support Case Manager with these set of keywords (Technology / Sub-Technology / Problem Code):

Tech: Data Center and Storage Networking

Sub-Tech: (choose an appropriate platform)
Nexus 3000 (N3000 series only) - Health and Config Check (AUTOMATED)
Nexus 3000 (N3100-N3600 series) - Health and Config Check (AUTOMATED)
Nexus 7000 Series Switch - Health and Config Check (AUTOMATED)
Nexus 9200 - Health and Config Check (AUTOMATED)
Nexus 9300 (Non EX/FX/R Series) - Health and Config Check (AUTOMATED)
Nexus 9300 (EX/FX/R Series) - Health and Config Check (AUTOMATED)

Nexus 9400 series switches - Health and Config Check (AUTOMATED)
Nexus 9500 (Non EX/FX/R Series) - Health and Config Check (AUTOMATED)
Nexus 9500 (EX/FX/R Series) - Health and Config Check (AUTOMATED)

Nexus 9800 series switches - Health and Config Check (AUTOMATED)

Problem Code: Health and Config Check

Once the SR opened, a Cisco Guided Workflow walks you through the steps to upload the show tech-support details or show tech-support logs.

After the required output uploaded, Cisco analyzes the logs and provides a report (in PDF format) attached to an email sent to you. The report contains a list of issues detected, relevant steps to troubleshoot the problems, and recommended actions plan.

If there are questions in regards to the health check failures reported, users are advised to open a separate service request(s) with appropriate keywords to get further expert assistance. It is strongly recommended to refer the Service Request (SR) number opened for the Automated Health and Config Check along with the report generated to expedite the investigation.

Health and Configuration Check Modules

Automated Nexus Health and Configuration Check Version 1, August 2022 release, performs the checks listed in the Table 1.

Table 1: Health Check Modules and Associated CLIs used by the Modules

Index	Health Check Module	Brief Description of the Module	CLI(s) Used to Perform Health Check
1.	NX-OS Release Check	Checks if the device runs a Cisco recommended NX-OS software release	`show version`
2.	Nexus EoS/EoL Product Check	Verifies if any of the components (hardware/software) has reached End-of-Life (EOL) or End-of-Sale (EOS)	`show version show module show inventory`
3.	Field Notice Check	Checks if the device is potentially affected by a known PSIRT/CVE or Field Notice.	`show version show module show inventory show running-config` and, any command needed to check the file against a given FN/PSIRT.
4.	NX-OS CPU Health Check	Checks the symptoms for the elevated CPU utilization. It is reported when the current/historical CPU usage is >60%.	`show processes cpu show processes cpu sort show processes cpu history show system resources`
5.	NX-OS Memory Health Check	Checks if memory usage on the device is over the system memory thresholds (default or user configured values).	`show version show processes memory show system resources`
6.	NX-OS Interfaces Check	Checks if any of the interfaces reported drops in either RX or TX direction. The module prints 5 interfaces with the highest error rates in each direction.	`show interface show interface brief show queuing`
7.	CoPP Health Check	Checks if CoPP is disabled, or incorrectly configured (for example, all CPU-bound traffic that hits default-class), or have outdated CoPP policy (for example, carried over from older releases), or >1000 drops reported in non-default classes.	`show copp status show policy-map interface control-plane show running-config`
8.	Inter-process Communication (MTS) Health Check	Detects if there are any inter-process communication (referred as MTS) messages stuck for more than 1 day.	`show system internal mts buffer summary show system internal mts buffer details`
9.	Nexus Module Health Check	Checks if any of the modules (linecard, fabric, and so on) reported diagnostic failures or in powered down / failed state	`show moduleshow inventory show diagnostic result module all detail`
10.	PSU & FAN Health Check	Detects if any of the power supplies is not in operational state.	`show inventoryshow environment <options> show logging log show logging nvram`
11.	vPC Best Practices Check	Validates the device configuration meets vPC best practices, like peer-router, peer-switch, and peer-gateway configurations.	Layer3 Peer Router: `show running-config` (to check if OSPF, EIGRP and BGP adjacencies formed) Peer-Gateway / Peer-switch: `show running-config show spanning-tree show vpc brief show interface brief`
12.	MTU Check	Detects inconsistent MTU configurations, like Layer2 Interface and Layer3 SVI have mismatch MTU configs, Incorrect MTU on OTV Join Interfaces, or Jumbo MTU not enabled on interfaces where it is needed and so on.	`show running-configshow interface show ip arp <options> show mac address-table show ip route detail <options> show ip eigrp neighbors <options> show ip ospf neighbors <options> show bgp <options>`
13.	Layer2 feature Configuration Health Check	Checks if any L2 feature enabled but not used	`show running-config`
14.	NX-OS vPC Compatibility Check	Checks if type1/type 2 incompatibility errors reported of Virtual Port-Channels (vPC).	`show running-config show vpc <options>`
15.	Spanning Tree Protocol Health Check	Checks the attached outputs for an indication of Spanning Tree Protocol instabilities or in unexpected state. Module reports vlans where most recent topology changes occurred together with some additional information: timestamp, interface and Root bridge ID. Currently, this health check module supports only RSTP; the support for MST is planned for the future versions.	`show spanning-tree detail show spanning-tree internal errors show spanning-tree internal event-history <options> show spanning-tree active show logging log` `show mac address-table notification mac-move` `show system internal <L2FM, MTM, L2DBG options>`
16.	PortChannel Health Check	Detects if any of the configured port-channel members is in unhealthy state: (I), (s) (D) or (H)	`show port-channel summary`
17.	SFP Validation Check	Detects any transceivers which reported "SFP Validation Failed" error	`show interface brief`
18.	Layer3 Feature Configuration Health Check	Checks if any L3 feature enabled but not used	`show running-config`
19.	Default Route via Management VRF Check	Checks if the device has a default route configured in the Default vrf pointing through Management vrf.	`show running-config show accounting log`
20.	Unsupported Multicast Routing over vPC Check	Checks for unsupported PIM adjacency over vPC	`show running-config show ip pim interface vrf all internal show ip pim neighbor vrf all detail`
21.	OSPF Health Check	Checks for a possible adjacency issues observed on the device.For example: multiple neighbors detected on interface configured as P2P router ID not configured manually or that used a loopback IP adjacencies not in FULL state adjacencies which reached FULL state recently and indicates potential instability	`show running-config show ip interface brief vrf all show ip ospf neighbors detail vrf all private show ip ospf interface vrf all private show logging log`
22.	EIGRP Health Check	Checks for a possible adjacency issues observed on the device. For example: AS number not configured No active neighbors detected High Values of SRTT, RTO or Q Cnt detected High number of dropped EIGRP packets detected Lesser than 15 mins uptime of adjacency, and indicates potential instability Adjacency went down in last 7 days	`show running-config show logging log show ip eigrp neighbors detail vrf all show ip eigrp detail vrf all`
23.	BGP Peers Health Check	Checks for BGP adjacency in IDLE state.	`show running-config show bgp vrf all all summary`
24.	First-Hop Redundancy Protocol (FHRP)	Checks for the non-default timer configurations, as these configurations can result in a sub-optimal performance. This health check module covers ONLY Hot-Standby Routing Protocol (HSRP)	`show running-config`

Reports and Caveats

The Health and Config Check SR is automated and handled by the Virtual TAC Engineer.
The report (in PDF format) is usually generated within 24 business hours after all necessary logs attached to the SR.
The report is automatically shared over email (sourced at jhwatson@cisco.com) with all contacts (primary as well as secondary) associated with the service request.
The report is also attached to the Service Request to allow its availability at any later point in time.
Be advised that the issues listed in the report are based on the logs provided and within the scope of the health check modules listed previously in Table 1.
The list of health and configuration checks performed is non-exhaustive and users are advised to perform further health checks as needed.
For Nexus 7000 with multiple Virtual Device Context (VDC) a show tech-support details file can be needed from each VDC for best results.

FAQs

Q1: Can I upload show tech-support details for more than one switch in the same SR to get Health Check report for all the switches?

A1: This is an automated case handling and the health checks are performed by the Virtual TAC Engineer. The health check is done for only the first show tech-support details uploaded.

Q2: Can I upload more than one show tech-support details for the same device say, captured few hours apart, to get health check done for both?

A2: This is an automated and stateless case handling performed by the Virtual TAC Engineer and the Health and Config Check is done for the first the show tech-support details file uploaded to the SR, irrespective of whether the files uploaded are from the same switch or different switches.

Q3: Can I get health checks done for the switches whose show tech-support details files compressed as a single rar/gz file and uploaded to the SR?

A3: No. if multiple show tech-support details are uploaded as a single rar/zip/gz file, only the first file in the archive is processed for health checks.

Q4: I do not see the health and configuration check that covers the Nexus 5000/6000 platforms. Is it covered at later point in time?

A4: No. As of now, there is no plan to cover Nexus5000/6000 platforms in near future.

Q5: What can I do if I have questions about one of the health check failures reported?

A5: Please open a separate TAC Service Request to get further assistance on the specific health check result. It is highly recommended to attach the health check report and refer the Service Request (SR) Case number opened for the automated health and config check.

Q6: Can I use the same SR opened for the Automated Health and Config Check to troubleshoot the issues found?

A6: No. As the proactive health check is automated, please open a new Service Request to troubleshoot and resolve the issues reported. Please be advised that the SR opened for health check is closed with in 24 hours after the health report published.

Q7: Does the automated health and config check run against the show tech-support details file for the switch that runs versions older than the one mentioned previously?

A7: The automated health and configuration check is built for the platforms and software releases mentioned below. For devices that run older versions, it is best effort and there is no guarantee on the accuracy of the report.

Nexus 3x00 series switches that run unified NX-OS software image: 7.0(3)Ix or newer
Nexus 7000/7700 series switches that run NX-OS software version 7.x or newer
Nexus 9x00 series switches that run unified NX-OS software image: 7.0(3)Ix or newer

Q8: How do I close the SR opened for Health Check?

A8: The SR is closed within 24 hours after the first Health Check report is sent. No action needed from the user towards SR closure.

Q10. What is the recommended method to capture show tech-support or show tech-support details from a switch?

A10: It is highly recommended to capture the output of show tech-support or show tech-support details command by directing it to bootflash: (as shown in the next example) rather than capturing it to a log file in the terminal application (for example, SecureCRT, PuTTY). Please remember the log file captured by the terminal application could be in UTF-8-BOM format (or similar) which is NOT supported by the automated health check. The Automated Health & Config check supports file only in ASCII or UTF-8 formats.

Example CLIs to redirect the output to bootflash: and compress the file.

SwitchA# show tech-support details >> bootflash:show-tech-support-details-SwitchA-2023Jan01.txt SwitchA# gzip bootflash:show-tech-support-details-SwitchA-2023Jan01.txt

Feedback

Any feedback on the operations of these tool is highly appreciated. If you have any observations or suggestions (for example, about the ease of use, scope, quality of the reports generated) please share them with us at Nexus-HealthCheck-Feedback@cisco.com.

Revision History

Revision	Publish Date	Comments
9.0	07-Nov-2023	Update
8.0	08-Jun-2023	Recertification. Informational update.
7.0	07-Jun-2023	Informational update.
5.0	09-Jan-2023	Updated.+
4.0	19-Oct-2022	Informational update
3.0	04-Sep-2022	Revision
2.0	25-Jul-2022	Initial Release
1.0	25-Jul-2022	Initial Release

Managing Configs

Saving the Running Configuration to the Startup Configuration

You can save the running configuration to the startup configuration to save your changes for the next time you that reload the device.

Procedure

	Command or Action	Purpose
Step 1	show running-config Example: `show running-config`	(Optional) Displays the running configuration.
Step 2	copy running-config startup-config Example: `copy running-config startup-config`	Copies the running configuration to the startup configuration. In effect, this saves the config so it persists after reboots.

Cisco - Cheatsheet

Get Information

Perform Nexus Health and Configuration Check

Contents

Introduction

Prerequisites

Requirements