Operational Defect Database
BugZero found this defect 4170 days ago.
Data sources
All data on this page is proprietary to BugZero® or gathered from public sources
Hewlett Packard Enterprise | c03612164
CUSTOMER ADVISORY: HP B-series switches may experience port errors if SFPs are replaced with the port disabled
Last update date:
2/28/2024
Affected products:
Brocade 8Gb SAN Switch for HPE BladeSystem c-Class
HPE 1606 Extension SAN Switch
HPE 4400 Enterprise Virtual Array
HPE 8/24 SAN Switch
HPE 8/40 SAN Switch
HPE 8/8 SAN Switch
HPE 8/80 SAN Switch
HPE B-series SN6000B Fibre Channel Switch
HPE Converged Network Switches
HPE Encryption SAN Switch
HPE Storage SAN Director Switch
HPE StorageWorks 4/256 SAN Director Switch
Affected releases:
No affected releases provided.
Fixed releases:
No fixed releases provided.
Description:
Info
When small form-factor pluggables (SFPs) are swapped out of disabled ports on HP B-Series switches, the switch can be placed into a state where these ports are out of sync. Upgrading any ports that are out of sync with their SFP data can potentially cause these ports to be programmed inaccurately and lead to high counts of Cyclic Redundancy Check (CRC) errors, other link errors, or ports remaining in sync. This issue is subsequently observed during a firmware upgrade at the high availability (HA) failover or any subsequent failover. Switches that have already been upgraded and did not encounter any failures should not encounter this issue on any future HA failovers. This issue will not occur during normal run-time operation. This issue occurs when the SFP data is out of sync between the software copy and physical SFP data prior to upgrading firmware. The following process of replacing an SFP while a port is disabled can lead to this out-of-sync state: Port disable Remove SFP Insert new SFP Port enable When using this process to swap SFPs, there is no hardware interrupt presented to the software. Therefore, the SFP data is not refreshed automatically, and the SFP data in the software will be out of sync from the physical SFP. If there are no other events that would cause the software to refresh the SFP data prior to the next firmware upgrade, then the switch could be exposed to this issue. While not every port that has out-of-sync data will encounter this issue, potentially, this issue can occur. This issue could be encountered after upgrading to any of the following firmware levels: fabric operating system (FOS) 6.4.3, 6.4.3b, 7.0.1a, 7.0.1b, or 7.0.2. During the upgrade process, the SFP could be programmed inaccurately, leading to the observance of CRC errors and other link errors immediately after the upgrade. To be at risk for this issue, SFPs must have been replaced using the port disable/port enable process identified previously. If SFPs have not been replaced, or they were replaced while the port was enabled, then the switch is not at risk to this issue. Also, if any events occur that will cause the SFP data to be refreshed, then the switch will not be at risk to this issue. These events include the following: a switch reboot, blade power off/power on, running the sfpshow command with the -f option, changing port speed, changing fill word, or other commands that affect the programming of the port directly. To verify if a switch is exposed to the issue, use the sfpshow [<slot>/]<port> command. (Do not use the -f option, as this will force a refresh of data.) Any ports where the sfpshow data output does not match the physical attribute of the SFP physically installed (such as SFP speed, serial number, etc.) are at risk of encountering this issue. Performing a comparison of the sfpshow capabilities versus the actual running speed of the SFP to identify any discrepancies is one indicator. All versions of FOS 6.X earlier than 6.4.3 are not at risk, and all versions of FOS 7.X earlier than 7.0.1a are not at risk. Switches that have already been upgraded to FOS 6.4.3, 6.4.3b, 7.0.1a, 7.0.1b or 7.0.2 and that did not have an immediate rise in CRC errors or other link errors are not at risk to this issue. This issue will only appear at the time of firmware upgrade and will not appear during normal runtime operation of the switch.
Scope
All products that have SFPs swapped on disabled ports and then are upgraded to FOS 6.4.3, 6.4.3b, 7.0.1a, 7.0.1b, or 7.0.2 firmware.
Resolution
This issue is addressed in FOS 6.4.3c and 7.0.2a. If you are planning to upgrade to FOS 6.4.3, 6.4.3b, 7.0.1a, 7.0.1b or 7.0.2, upgrade to one of these versions instead, or follow the Workaround procedure to ensure that you do not experience this issue. Workaround Force the switch to re-read the SFPs, and then ensure that the control processors (CPs) have the up-to-date and correct SFP data in the software tables matching the physical SFP installed. This is done with the -f option on the sfpshow command, which will instruct the software to physically go out and re-read the SFP data from the physical SFP and place this data into the internal software tables. On systems with two CPs, this action is followed by a pair of commands to force the newly-read data to be saved across the standby CP. If this issue is encountered, perform the following steps: Issue an sfpshow [<slot>/]<port> -f command to all ports that are encountering errors. Issue an hasyncstop/hasyncstart command to the switch to update the standby CP where appropriate. Perform a portdisable/enable command on all of the affected ports. These steps will update the SFP data, save the data to the standby CP, and cause the port to be properly programmed. The issue will not return after performing this recovery action. To upgrade to one of the following firmware versions: FOS 6.4.3, 6.4.3b, 7.0.1a, 7.0.1b, or 7.0.2, use the following steps to avoid this issue: Issue an sfpshow [<slot>/]<port> -f command to all ports on the switch. Issue an hasyncstop/hasyncstart command to the switch to update the standby CP where appropriate. Upgrade using the normal process. These steps will update the SFP data within the software, and then force that data over the standby CP so that it also has a correct copy. The firmware upgrade will not encounter this issue as the SFP data is in sync, and the firmware upgrade may proceed as normal. When applying the workaround to 10 G ports on an HP DC SAN Director Switch 6-port 10 Gb Fibre Channel Blade, the 10 G will be recovered, but the issue could still return the next time there is an HA failover. All other port types will be permanently addressed with the workaround, but to permanently address 10 G ports on an HP DC SAN Director Switch 6-port 10 Gb Fibre Channel Blade Option, the switch must be upgraded to a firmware version that contains the fix. Proactive Updates Receive support alerts (such as Customer Advisories), driver updates, software, firmware, and customer replaceable components, in your e-mail through HP Subscriber's Choice. Sign up for Subscriber's Choice Driver, Patch, Security, and Support alerts at the following URL: http://www.hp.com/go/myadvisory
