HPE Support Center
HPE 3PAR Storage - Troubleshooting COMP_STATE degraded Port
intermittent_CRC_errors_detected(Degraded)
Environment
Questions/Symptoms
Cause
Answer/Solution
Environment
HPE 3PAR Storage
top
Questions/Symptoms
Troubleshooting COMP_STATE degraded Port intermittent_CRC_errors_detected(Degraded)
The alert will look similar to following:
top
Cause
Determing cause of Port intermittent CRC errors detected alerts.
To determine whether these CRC errors are coming from a host, or from the connection from InServ to switch you will
want to use the showport lesb command.
showportlesb single n:s:p
In the example above you can see the CRC errors appear to be coming from the port. This is indicative of a couple
possible issues either a problem on the datapath between switch and InServ. Or it could be a host is having the errors
and you will need to use the eventlog to determine which host is having the issues.
Recommendation is to look at the cable between InServ and switch first as this is where problem is generally stemming
from.
In the example above you can see the CRC errors are coming from one host. To be specific from Host29. You can then
use showhost output to determine the name of Host29 This is indicative of a problem on the datapath between host and
switch Sometimes there are multiple hosts with CRC errors. To determine which host(s) the CRC errors are incrementing
on would suggest use of showportlesb hist -startt mm/dd x:x:x.
Example: showportlesb hist -startt 11/05 1:3:1
In the example above, only one host is incrementing new CRC errors. This would be the host that is causing the issues
currently.
top
Answer/Solution
FIX:
Alert regarding Port intermittent_CRC_errors detected received.
Alert received from 3PAR detailing you are receiving intermittent CRC errors on port x:x:x of your InServ.
Once you have determined where the problem lies whether between switch and host or switch and InServ, resolve the
problem with the datapath. Generally the CRC errors come from a dirty connection or failing cable. Fibre Channel cables
and connections are extremely sensitive to contamination, such as oils from your skin or dust/lint that can't be seen with
the naked eye.
If you have good Fibre cleaning kits/apparatus in-house, that would certainly be worth trying (not just alcohol and a
tissue, as those can leave residue and lint). Using a can of compressed air to blow out the FC ports/connectors and the
ends of the cables would be useful, too.
If unable to clean or the cleaning didn't resolve the issue the next recommended step would be to replace the
cable/GBICs. Replacing the cable resolves ~99% of the CRC error alerts that are received. However there is a possibility
it won't, at that point you would need to troubleshoot other parts of the datapath.
For example on a host to switch issue, move the connection to another HBA and see if the errors are still occuring. A
flaky HBA, switch etc.. could also be the issue but recommendation is to replace cable first.
To ensure the problem is resolved check out the showportlesb single x:x:x command and see if further errors are
incrementing. The showportlesb hist x:x:x command also could be used.
top
©Copyright 2021 Hewlett Packard Enterprise Development LP
Hewlett Packard Enterprise Development shall not be liable for technical or editorial errors or omissions contained herein.
The information provided is provided "as is" without warranty of any kind. To the extent permitted by law, neither HPE nor
its affiliates, subcontractors or suppliers will be liable for incidental, special or consequential damages including downtime
cost; lost profits; damages relating to the procurement of substitute products or services; or damages for loss of data, or
software restoration. The information in this document is subject to change without notice. Hewlett Packard Enterprise
Development and the names of Hewlett Packard Enterprise Development products referenced herein are trademarks of
Hewlett Packard Enterprise Development in the United States and other countries. Other product and company names
mentioned herein may be trademarks of their respective owners.