Invalid Checksum, CHECK_SUM_FAILED – alarms for SFP checksum error
Intro
CHECKSUM_FAILED – What to do? Checksums are a common error detection method that is used to verify the integrity of data and detect errors in data transmissions. Checksums are used in transceivers to verify the authenticity of EEPROM memory data. If data in the optical transceiver EEPROM is modified without recalculating checksums, the host system will throw sfp checksum error, for example, CHECKSUM_FAILED or Invalid Checksum.
When a checksum is not correct
Consider the following scenario: the checksums in the transceiver code are incorrect. When such a transceiver is plugged into a host device, an SFP Invalid Checksum alarm message is generated, and the device is blocked. For example, in Cisco switches, the following are typical error messages:
Error #1
LC/0/6/CPU0:Aug 18 16:27:26.412 CET: plim_1p_cge[297]: %L2-PLIM-4-ERR_HW : Device: CFP: Verify Vendor NVR1 Checksum. Error: Invalid Checksum. Software action: Abort. Recommended user action: Replace CFP
Error #2
Jul 1 2022 12:23:06.302 UTC: %PHY-4-CHECK_SUM_FAILED: SFP EEPROM data check sum failed for SFP interface Te1/0/2
What to do if a checksum error appears?
Typically, the problem is with the optical transceiver code itself – this is the primary cause of the SFP checksum error. In this case, it is recommended that the transceiver be re-coded and the checksums be recalculated and verified during the process. Feel free to Contact Us.
FAQ:
What causes a CHECK_SUM_FAILED alarm on a network switch?
The switch reads the SFP transceiver's EEPROM on insertion and recalculates the checksum. If the stored value at A0h byte 63 (CC_BASE, covering bytes 0-62) or byte 95 (CC_EXT, covering bytes 64-94) does not match, the switch logs a CHECK_SUM_FAILED alarm. The usual cause is a re-coded transceiver where the EEPROM vendor data was rewritten without recalculating both checksums. A transient mismatch can also appear during hot-swap if the switch polls the EEPROM before the I2C bus has fully initialized, though this typically clears on the next read cycle.
Will a third-party SFP always throw a checksum error?
No. A properly coded third-party SFP passes checksum validation the same way an OEM module does. The error only appears when the EEPROM programming was incomplete or the data was corrupted during a write operation. Note that passing the checksum check and passing a platform's vendor-lock check are separate things. On Cisco IOS-XE, for example, a third-party transceiver with a valid checksum will still be disabled unless you run service unsupported-transceiver.
Is a checksum error the same as an incompatible transceiver warning?
No. A checksum error means the EEPROM data is internally inconsistent, which is a data integrity failure. An incompatible transceiver warning is a platform-specific vendor-lock mechanism. On Cisco, this is a cryptographic authentication check using a signed certificate on the SFP. On Juniper and HPE, it is a vendor/part-number whitelist in the OS. An OEM transceiver with corrupted EEPROM can fail the checksum check, and a third-party transceiver with a valid checksum can still trigger the vendor-lock warning. The two alarms have different root causes and different fixes.