Cisco Nexus 9508 Ejector Status Flapping: Line Card Replacement
A Cisco Nexus 9508 repeatedly logged PLATFORM-3-EJECTOR_STAT_CHANGED for Slot 1. The line card remained ok, and ports and communication were normal in the initial checks. Reseating the existing card increased the frequency of the events. After replacement with a spare in the same slot, module and port status were normal and the logs stopped.
The replacement result points to a hardware problem associated with the original line card's ejector detection path. The failed component was not identified, so a defective sensor, contact, or internal circuit remains a hypothesis.
Environment
- Incident date: November 3, 2026
- Chassis: Cisco Nexus 9508
- Operating mode: standalone NX-OS, without ACI
- Software: NX-OS
7.0(3)I7(7) - Affected slot: Slot 1
- Original line card:
N9K-X9464PX
Ejector status changes while the module stays online
Only the Right Ejector repeatedly changed between OPEN and CLOSE at short intervals. One supplied event read:
%PLATFORM-3-EJECTOR_STAT_CHANGED
Ejectors' status in slot 1 has changed,
Left Ejector is CLOSE,
Right Ejector is OPENBoth physical levers appeared closed during inspection. This was a visual observation; it did not verify the electrical state reported by the detection mechanism.
Cisco's Nexus 9000 system message reference for 7.0(3)I7(9) identifies this message as an ejector status change. The message itself does not diagnose a failed sensor or prove that a person moved the lever. Its generic recommended action is listed as None; repeated transitions that disagree with the observed lever position still require investigation.
Initial checks and their limits
The checks recorded during the incident were:
show module 1
show cores
show process logshow module 1reportedok.- Online Diagnostic Status was
Pass. - Ports and communication were normal during the initial checks.
show coreshad no recorded entries.show process loghad no recorded entries.- The ejector events continued despite those normal results.
The initial checks found no module failure, communication problem, or recorded crash evidence. They do not establish that every part of the ejector sensing path was healthy. The online diagnostic pass did not resolve the discrepancy between the visible lever position and the reported state.
What was done, in order
- Reviewed the logs and module status.
- Checked the physical seating of the ejector levers.
- Removed and reinserted the original line card.
- Observed more frequent ejector events after reseating.
- Completely removed the original card and installed a spare line card in the same slot.
- Confirmed normal module and port status after replacement; the ejector logs stopped.
No NX-OS upgrade was performed. No ejector-setting change was made. The case record does not specify a post-replacement observation duration, so it supports the reported cessation of events without establishing a measured recurrence-free period.
This sequence records the incident response. Line-card removal interrupts the connections on that card and should be planned around the affected services. For the physical handling procedure, use Cisco's Nexus 9508 NX-OS Mode Hardware Installation Guide, in the section on installing or replacing a line card.
Cause assessment after replacement
The same-slot comparison supports this assessment: the original card continued generating events after reseating, while the spare stopped them. This makes a hardware abnormality associated with the original card's ejector detection path the leading explanation.
The replacement was not a component-level failure analysis. It did not isolate a sensor, contact, or internal circuit, and it did not conclusively exclude every seating or chassis-interaction issue. Card replacement stopped the symptom; the exact failed component remains unconfirmed.
What hardware ejector enable controls
The Nexus 9000 configuration command reference for 7.0(3)I7(x) documents hardware ejector enable: with the function enabled, the card powers down when both ejectors are open. This is the documented ejector-based power-down condition; one event reporting one side OPEN is not evidence that the card has already powered down.
The no hardware ejector enable form disables that functionality. It changes protective behavior and does not repair a mechanical or electrical fault. Neither form was applied during this incident, and the running protection setting was not recorded. There is no basis to describe disabling it as the fix or to claim that it would suppress these logs.
CSCvx39125: relevant symptoms and release history
Cisco describes CSCvx39125 as an ejector interrupt storm that can crash the platform manager when an I/O module is marginally seated. The public release notes mention reseating and checking chassis grounding as workarounds. Grounding verification was not recorded for this incident.
- 7.0(3)I7(10) release notes: the bug is listed under Resolved Issues.
- 9.3(7) release notes: the bug is listed under Open Issues.
- 9.3(7a) release notes: the bug is also listed under Open Issues.
Repeated ejector events made the bug worth reviewing. However, the recorded checks found no core or process-log entries, and the case did not establish a platform-manager crash. Neither the symptom similarity nor the installed 7.0(3)I7(7) version confirms that this was CSCvx39125.
The resolved listing identifies a documented fix in the I7 branch. It does not establish a complete first-fixed matrix across branches, an affected-release verdict for this particular incident, or a recommended upgrade target. Any future software change needs its own hardware-support and upgrade-path review. Software was unchanged when the replacement stopped the events.
Checks to preserve for a similar incident
- Keep the complete event text, including both ejector fields and timestamps, before drawing a conclusion about which side changed.
- Record the chassis, slot, line-card model, NX-OS release, module diagnostics, and actual service condition.
- Compare the reported state with a physical inspection, while keeping visual position separate from electrical sensing.
- Preserve the before-and-after result of each intervention, including an unsuccessful reseat.
- After replacement, verify module and port status and monitor recurrence; record the observation interval.
Here, ok and Pass coexisted with persistent ejector events. Reseating did not solve them. Replacement in the same slot stopped the logs, supporting a suspected problem with the original line card while leaving the exact failed component unconfirmed.
Comments
Post a Comment