On Juniper PTX routers or QFX swithese, you may see “SIB got link errors” across multiple or all SIBs toward a single FPC.

In most cases this indicates a fault on the target FPC, not simultaneous SIB hardware faults.

Depending on platform and code path, the forwarding manager handler name and the offline reason reported by chassisd can vary :

(e.g., fm_qfx10_ev_sib_state_handler vs. fm_sng_ev_sib_state_handler, and offline_reason might be Bad Voltage or None). 

A. Common SIB link‑error pattern (points to a single FPC)
   Repeated logs like: CHASSISD_FM_ERROR: ... SIB got link errors (SIB#X, Packet Forwarding Engine 0 on FPC Y) for many or all SIBs but always toward the same FPC (e.g., FPC2). 

Example of link error log:

Feb  8 22:20:26 2026  router CHASSISD_FM_ERROR: fm_sng_ev_sib_state_handler: SIB got link errors (SIB#0, Packet Forwarding Engine 0 on FPC 2)

Feb  8 22:20:26 2026  router CHASSISD_FM_ERROR: fm_sng_ev_sib_state_handler: SIB got link errors (SIB#1, Packet Forwarding Engine 0 on FPC 2)

This strongly implicates the FPC as the common fault domain. 

Corresponding CHASSIS minor alarms per SIB: 

Alarm set: SIB , color=YELLOW, class=CHASSIS, reason=SIB FPC Link Error (often SIB0–SIB8 in PTX5000). 

B. Handler variants by platform/code path

   QFX10k or PTX which share same HW design with QFX10: fm_qfx10_ev_sib_state_handler 
   PTX5000 example handler: fm_sng_ev_sib_state_handler. 

   Both represent the same symptom class (SIB link errors toward an FPC). 

C. Additional error context sometimes seen
   • Spray fabric chip messages (PF chip): pfchip_spray_req_scan_error_reg / pfchip_spray_gnt_scan_error_reg on SIBs at the same time window as the link errors. 1
   • TCP keepalive timeouts between RE and the affected FPC (helpful to confirm control‑plane impact): tcp_timer_keep:Local(0x80000001:6987) Foreign(0x80000012:48623) (note: device encodes FPC ID — e.g., 0x80000010 = FPC0, 0x80000012 = FPC2). 

D. FPC control‑plane impact and restart
   Shortly after link‑error storm:

   CHASSISD_IPC_CONNECTION_DROPPED: Dropped IPC connection for FPC 2 CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(2)

   The FPC then restarts. 

Evidence / log examples

Example 1:

SIB link errors toward FPC2 (SIB0–SIB8), PF‑chip spray errors, RE< - >FPC keepalive timeout, IPC drop, FPC2 restart; offline_reason=None. 1
Feb  1 22:25:26 router CHASSISD_FM_ERROR: fm_sng_ev_sib_state_handler: SIB got link errors (SIB#0..8, Packet Forwarding Engine 0 on FPC 2)
Feb  1 22:25:26 router alarmd[3164]: Alarm set: ... reason=SIB 0..8 FPC Link Error
Feb  1 22:25:26 router spmb0 SIB*_PF_*: pfchip_spray_*_scan_error_reg: ... (spry_rgd quadrant logs)
Feb  1 22:25:27 router /kernel: tcp_timer_keep:Local(0x80000001:6987) Foreign(0x80000012:48623)
Feb  1 22:25:31 router chassisd[2628]: CHASSISD_IPC_CONNECTION_DROPPED: Dropped IPC connection for FPC 2
Feb  1 22:25:31 router chassisd[2628]: CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(2)
Feb  1 22:25:31 router chassisd: fpc_disconnect_generic: fpc 2 ... offline_reason=None

Example 2:

SIB link errors toward FPC2; FPC offlined with Bad Voltage.

Mar 4 02:52:57 <hostname> chassisd[8482]: CHASSISD_FM_ERROR: fm_qfx10_ev_sib_state_handler: SIB got link errors (... on FPC 2)
Mar 4 02:53:39 ch_ipc_dispatch: fru FPC offline_reason = Bad Voltage
Mar 4 02:53:39 fpc_disconnect_generic: fpc 2 state Offline ... offline_reason=Bad Voltage
(Content from earlier KB text; retained here for completeness.)

Interpretation / root cause
• If all (or many) SIBs simultaneously report link errors toward the same FPC, the highest‑likelihoodroot cause is the target FPC hardware (not the SIBs). The SIBs are diverse FRUs; a simultaneous,identical failure across them is statistically unlikely compared to a single FPC fault. Your casevalidated this: SIB0–SIB8 all flagged link errors toward FPC2, followed by RE↔FPC keepalive failures and an IPC drop, and the issue was resolved by RMA of FPC2. 1

• Handler name differences (fm_sng_ev_* vs fm_qfx10_ev_*) reflect platform/code paths, not a different underlying problem class.

 Offline reason may vary:
 ◦ Some cases show offline_reason=Bad Voltage (FPC proactively offlined).
 ◦ Some cases show offline_reason=None, yet the pattern still implicates the FPC hardware. 

This is due to hardware failure of the FPC and faulty FPC needs to be RMAed.