NetOps Field

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-E...

A Catalyst 9300 stack lost its Standby BFD session for about one second. The log reason was DETECT TIMER EXPIRED , the session came back on its own, and the Main path carried traffic the whole time. The cause is still unknown. This post records what was checked, what each check could and could not show, and what to capture if it happens again. A different incident on the same platform family, with the reason ECHO FAILURE , is covered in Cisco Catalyst 9300 BFD Echo Failure: Troubleshooting Session Flaps and Restoring Stability . The two are separate incidents, and nothing from that case is applied here. Network environment The environment is de-identified and simplified. Two sites are joined by a Main and a Standby carrier circuit. Static routes depend on BFD, so a BFD session that goes Down can pull its route out of the routing table. For configuration order and verification of this design, see Cisco Catalyst 9300 HQoS and Static BFD: Configuration Order and Verification . Illust...

A few users on one office floor reported that the network was down. Their PCs could not ping the default gateway. The switch port facing the unmanaged hub they were plugged into was in the err-disabled state. This post covers how the problem was isolated, what the switch can and cannot tell you about the cause, and which Catalyst features limit the damage when an unmanaged hub misbehaves. Quick Summary Observed: 3 to 5 users in one area lost network access. The gateway was unreachable from their PCs. The access switch port connected to their hub was err-disabled. Fix that worked: Unplug every device from the hub, keep only the uplink, clear the err-disabled state, then reconnect the devices one at a time and watch the port. Not recorded: The exact err-disable reason was not captured, and the switch software version was not noted. This post does not claim a root cause for that incident. Why it matters: A hub cannot be monitored or protected, so the switch port it hang...

The link still passed traffic when %CDP-4-DUPLEX_MISMATCH reported a duplex disagreement. The reported connection used FastEthernet on a Catalyst 2960 24T and copper GigabitEthernet on a Catalyst 3650-48TQ; software versions were not recorded. The operator changed fixed 100/full to auto on FastEthernet. After a brief down/up, both ends showed a-100 / a-full , with no recurring warning or new errors in the first 10 minutes. Figure 1. Reported configuration pattern; a working physical link can still have a duplex mismatch. Starting speed and duplex The operator confirmed speed 100 and duplex full on FastEthernet. Its copper UTP GigabitEthernet peer was set to auto but operating at half duplex; half duplex had not been set manually. CDP detects and reports the disagreement. It neither negotiates Ethernet nor corrects the settings, so traffic may continue over the mismatched link. [1] Assessing traffic and errors A ping does not establish link health. Duplex mismatch ca...

A physical link can stay up and exchange BFD Control packets while the BFD session flaps because its Echo path fails. In this Catalyst 9300 case, Echo transmit counters increased while receive counters stayed at zero. Disabling Echo on the affected interface restored session stability. The cause of Echo packet loss remained unconfirmed. Conceptual symptom: BFD Control is received while the Echo return path fails. This diagram does not identify where packets are lost. Environment Item Environment Platform Cisco Catalyst 9300 Deployment Stack Headquarters IOS XE 17.12.5 Branch IOS XE 17.18.4 Affected function BFD Echo Operational workaround Disable BFD Echo on the affected interface For a separate guide covering configuration order and verification for Catalyst 9300 BFD deployments, see Cisco Catalyst 9300 HQoS and Static BFD: Configuration Order and Verification . Observed symptoms BFD Control packets were received. BFD Echo transmit counters increased. BFD Echo receive counters r...

During a Nexus security-hardening review, an ICMP unreachable-related change left no expected line in show running-config . I reviewed command syntax, defaults display, and IP interface checks to determine what that observation could establish. 1. The original observation The review covered Ethernet and VLAN interfaces. After attempting the change, I could not see the expected running-configuration line. I considered both an existing default and an unexpected interface context. The configuration display alone did not resolve which explanation applied. The verification workflow below is documentation-based; it does not establish results from an unrecorded device test. 2. Environment and evidence limits Item Scope Hardware Cisco Nexus 9500 Series Software NX-OS 7.0(3)I7(7) Interfaces reviewed Ethernet and VLAN interfaces Original observation Expected command line absent from the displayed running configuration Documentation validation Cisco Nexus 9000 NX-OS 7.0(3)I7(x) comm...

For a bandwidth-limited Catalyst 9300 hub-and-branch link, review where traffic is classified and queued, and which static routes depend on BFD. A configured policy and an Up neighbor do not establish the complete forwarding result. These independent configuration examples use Cisco's IOS XE 17.18.x documentation; they are not completed lab results. Check the exact SKU, maintenance release, interface type, licenses, and existing policies. Another model's working configuration does not establish compatibility.

The marker 5 in Nexus username ... password ? help does not identify the IOS/IOS XE MD5 implementation. The Nexus 9000 NX-OS 10.2(x) command reference describes input format, while the security guide identifies SHA-256 for local-user passwords. Interpret the marker with its OS, release, command, and stored representation. [1] [2] 1. The reported password-type options During a local-account review on a device reported as NX-OS 10.2(5), CLI help offered 0 and 5 . The question was whether Type 5 meant the same thing as in IOS. This is a documentation investigation, not a lab reproduction or password migration. The hardware model and full release suffix were not supplied. The findings apply to Nexus 9000 documentation: Cisco names the maintenance release 10.2(5)M and maintains command guidance for 10.2(x). The release notes list no new software features in 10.2(5)M. Check other Nexus families separately. [3] 2. Input format, stored value, and algorithm Tables scroll horiz...