Perform Nexus Health and Configuration Check

Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
Health and Configuration Check Procedure
Health and Configuration Check Modules
Reports and Caveats
FAQs
Feedback

Introduction
This document describes the procedure and requirements to perform automatic health and configuration
checks for Nexus 3000/9000 and 7000 platforms.

Prerequisites
Requirements

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 perforn health and config check. 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.

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 can walk you through 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

Health Check CLI(s) Used to Perform Health

Index Brief Description of the Module
Module Check

NX-OS Release Checks if the device runs a Cisco

1. show version
Check recommended NX-OS software release

2. Nexus EoS/EoL Verifies if any of the components show version

 Product Check (hardware/software) has reached End-of- show module
Life (EOL) or End-of-Sale (EOS) show inventory

show version
show module
show inventory
Checks if the device is potentially affected
3. Field Notice Check show running-config
by a known PSIRT/CVE or Field Notice.
and, any command needed to
check the file against a given
FN/PSIRT.

show processes cpu

Checks the symptoms for the elevated
NX-OS CPU Health show processes cpu sort
4. CPU utilization. It is reported when the
Check show processes cpu history
current/historical CPU usage is >60%.
show system resources

show version
Checks if memory usage on the device is
NX-OS Memory
5. over the system memory thresholds show processes memory
Health Check
(default or user configured values).
show system resources

Checks if any of the interfaces reported show interface

NX-OS Interfaces drops in either RX or TX direction. The
6. show interface brief
Check module prints 5 interfaces with the highest
error rates in each direction. show queuing

Checks if CoPP is disabled, or incorrectly

configured (for example, all CPU-bound show copp status
traffic that hits default-class), or have
show policy-map interface
7. CoPP Health Check outdated CoPP policy (for
control-plane
example, carried over from older
releases), or >1000 drops reported in non- show running-config
default classes.

show system internal mts buffer

Detects if there are any inter-process
Inter-process summary
communication (referred as
8. Communication
MTS) messages stuck for more than 1
(MTS) Health Check show system internal mts buffer
day. details

Checks if any of the modules (linecard, show moduleshow inventory

Nexus Module
9. fabric, and so on) reported diagnostic show diagnostic result module all
Health Check
failures or in powered down / failed state detail
 show inventoryshow
PSU & FAN Health Detects if any of the power supplies is not environment <options>
10.
Check in operational state. show logging log
show logging nvram

Layer3 Peer Router:

show running-config (to check if
OSPF, EIGRP and BGP
adjacencies formed)

Validates the device configuration meets Peer-Gateway / Peer-switch:

vPC Best Practices
11. vPC best practices, like peer-router, peer-
Check
switch, and peer-gateway configurations. show running-config
show spanning-tree

show vpc brief

show interface brief

show running-configshow
interface

show ip arp <options>

Detects inconsistent MTU configurations, show mac address-table

like Layer2 Interface and Layer3 SVI
have mismatch MTU configs, Incorrect show ip route detail <options>
12. MTU Check
MTU on OTV Join Interfaces, or Jumbo
MTU not enabled on interfaces where it is show ip eigrp neighbors
needed and so on. <options>

show ip ospf neighbors

<options>

show bgp <options>

Layer2 feature
Checks if any L2 feature enabled but not
13. Configuration Health show running-config
used
Check

Checks if type1/type 2 incompatibility show running-config

NX-OS vPC
14. errors reported of Virtual Port-Channels
Compatibility Check
(vPC). show vpc <options>

Checks the attached outputs for an show spanning-tree detail

Spanning Tree indication of Spanning Tree Protocol show spanning-tree internal
15. Protocol Health instabilities or in unexpected state. errors
Check Module reports vlans where most recent show spanning-tree internal
 topology changes occurred together with event-history <options>
some additional information: show spanning-tree active
show logging log
timestamp, interface and Root bridge ID. show mac address-table
notification mac-move
Currently, this health check module show system internal <L2FM,
supports only RSTP; the support for MST MTM, L2DBG options>
is planned for the future versions.

Detects if any of the configured port-

PortChannel Health
16. channel members is in unhealthy state: (I), show port-channel summary
Check
(s) (D) or (H)

SFP Validation Detects any transceivers which reported

17. show interface brief
Check "SFP Validation Failed" error

Layer3 Feature
Checks if any L3 feature enabled but not
18. Configuration Health show running-config
used
Check

Default Route via Checks if the device has a default route show running-config
19. Management VRF configured in the Default vrf pointing
Check through Management vrf. show accounting log

show running-config
Unsupported show ip pim interface vrf all
Checks for unsupported PIM adjacency
20. Multicast Routing internal
over vPC
over vPC Check show ip pim neighbor vrf all
detail

Checks for a possible adjacency issues show running-config

observed on the device.For example:
show ip interface brief vrf all
• multiple neighbors detected on
interface configured as P2P show ip ospf neighbors detail vrf
21. OSPF Health Check • router ID not configured manually all private
or that used a loopback IP
• adjacencies not in FULL state show ip ospf interface vrf all
• adjacencies which reached FULL private
state recently and indicates potential
instability show logging log

Checks for a possible adjacency issues show running-config

EIGRP Health observed on the device. For example:
22. show logging log
Check
• AS number not configured
 • No active neighbors detected show ip eigrp neighbors detail
• High Values of SRTT, RTO or Q vrf all
Cnt detected
• High number of dropped EIGRP show ip eigrp detail vrf all
packets detected
• Lesser than 15 mins uptime of
adjacency, and indicates potential
instability
• Adjacency went down in last 7 days

show running-config
BGP Peers Health
23. Checks for BGP adjacency in IDLE state.
Check show bgp vrf all all summary

Checks for the non-default timer

configurations, as these configurations can
First-Hop
result in a sub-optimal performance.
24. Redundancy show running-config
Protocol (FHRP) This health check module covers ONLY
Hot-Standby Routing Protocol (HSRP)

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 [email protected]) 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.

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: Are 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.

Q9: How do I share comments or feedback about the Proactive health and configuration Check?

A9: Please share them through email to [email protected]

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 [email protected].