Physical NIC disconnect and reconnect alarms caused by an unsupported SFP module

Environment

This article documents how to isolate the root cause of repeated "NIC not connected / connected" alarms on a ZStack Cloud host when the underlying cause is an unsupported SFP / optical module rather than a cabling, driver, or platform-side problem. The validated resolution is to identify the NIC, confirm the kernel rejected the SFP, and replace the third-party module with a vendor-approved module.

Symptoms

• A physical host repeatedly raises NIC-disconnect / NIC-reconnect alarms.
• The alarm reports a specific NIC (the source case used p3p2, a member of bond2).

Diagnosis

Follow steps 1, 2, and 6 below to confirm that the alarm is caused by an unsupported SFP module rather than a UI-only alarm, cabling fault, or another host-side issue.

Cause

SFP module not on the NIC vendor's compatibility list (third-party SFP not validated by the NIC vendor). On Intel 82599 NICs, the firmware rejects non-Intel SFPs with a fail to load because unsupported SFP+ module type was detected message and the NIC stops registering in the OS.

Resolution

1. Prerequisites

• Migrate VMs off the affected host, or shut them down if migration is not possible.
• Arrange a maintenance window because reseating the NIC or replacing the optical module requires a host shutdown or reboot.

2. Procedure

1. Identify the NIC that triggered the alarm

• UI: open the alarm entry and record the NIC name (the source case used p3p2) and its parent bond (the source case used bond2).
• Expected result: you have a specific NIC and bond to investigate, not a generic host-level alarm.

2. Confirm the NIC is flapping inside the host

• Command:

  ip link show | grep p3p2

• Expected result: the NIC state toggles between UP and DOWN, or reports NO-CARRIER. This confirms the OS-level view matches the UI alarm and rules out a UI-only false positive.

3. Restart the network service

• Action: migrate VMs off the affected host (or shut them down if migration is not possible) so the host can be reconfigured without affecting running workloads.
• Command:

  systemctl restart network

• Expected result: after the restart, the affected NIC is no longer visible to the OS. If the NIC does not come back, continue to step 4.

4. Attempt to recover the NIC by reseating hardware

• Action: shut the host down, reseat the NIC, and power it back on.
• Expected result: the NIC reappears in ip link. If it still does not, proceed to step 5.

5. Replace the optical module for testing and reboot

• Action: swap the optical module (SFP / SFP+) with a replacement module and reboot the host.
• Expected result: the host boots normally, but the two affected NICs (p3p1 and p3p2 in the source case) still do not appear. Continue to step 6.

6. Inspect dmesg for SFP compatibility errors

• Command:

  dmesg | grep -i sfp

• Expected result (the source case's exact message):

  fail to load because unsupported SFP+ module type was detected

• Interpretation: the kernel rejected the SFP because the firmware (Intel 82599 in the source case) only accepts vendor-approved SFPs. Both 5e:00.0 and 5e:00.1 in the source case failed to bind for this reason, which is why p3p1 / p3p2 did not register after the swap.

7. Replace the unsupported module with a vendor-approved module

• Cross-reference the host's NIC vendor with the SFP vendor. On Intel 82599 NICs, only Intel-branded SFPs are supported; third-party modules (e.g. Lenovo-branded in the source case) will not load even if they fit physically.
• Action: replace the third-party SFP with an Intel-branded SFP and reboot.
• Expected result: the NIC registers in the OS; the disconnect/reconnect alarms stop.

Verification

• Replace the third-party SFP with a vendor-approved SFP.
• Reboot the host.

  ip link show | grep p3p2

• Use the affected NIC name if different.
• Confirm the NIC shows:

	state UP

Valid MAC address

• Check the ZStack UI:

Host status: Connected NIC disconnect/reconnect alarm clears within a few minutes.

• Run:

  dmesg | grep -i sfp

• Confirm there are no errors containing:

  fail to load because unsupported SFP+ module type was detected

Risks and rollback

• Reseating the NIC requires a host shutdown, which will impact any VMs that have not been migrated off. Always migrate VMs to another host first (or shut them down if migration is not possible).

• Using a third-party SFP that is not on the NIC vendor's compatibility list will be rejected by the firmware even if it fits physically. The fix is a vendor-branded SFP.

• If the replacement does not restore the NIC, reinstall the original module and continue checking the NIC, fiber or cable, driver, and compatibility layer.

Prevention and Optimization

• Run regular inspections of the platform and the underlying hardware so that risk signals (flapping NIC, single-bucket alarms) are detected before they cascade.
• When troubleshooting a NIC fault, check hardware indicators first, then walk the stack in this order: NIC → optical module → fiber / cable → driver → compatibility. Each layer can present the same symptom.
• For Intel 82599 NICs, use Intel-branded optical modules.