NetOps Field

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

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

Retained audit records may show when an Alteon configuration changed. Start with audit evidence, system messages, and configuration snapshots. Current SLB group membership alone does not establish when a member was added. 1. Investigation question In this fictional lab scenario, an engineer finds an unexpected Real Server in an SLB group and needs to establish when the membership changed, which account was involved, and whether it became active. The workflow combines documented capabilities with checks that still require validation on the installed release. 2. Environment Item Illustrative lab value Platform Radware Alteon ADC; hardware model intentionally unspecified SLB group Group 10 Expected members Real servers 1 and 2: 192.0.2.11 and 192.0.2.12 Unexpected member Real server 3: 192.0.2.13 External log collector 192.0.2.200, if configured All addresses are documentation examples. No production records or device output are reproduced. Public Radware knowledgebase artic...

An SNMP trap lets a device report an event without waiting for an NMS poll. Supported and enabled notifications can cover interface failures, fan or power-supply changes, authentication failures, and software-operation results. A trap reports the event. Repair, configuration changes, and remediation workflows require an NMS, ticketing or automation system, or an operator to act. How traps differ from polling The device's SNMP agent sends an asynchronous notification to a configured receiver, usually the NMS. Polling: the NMS asks the device for information. Trap: the device reports an event to the NMS without being asked at that moment. Inform: the device sends a notification and expects an acknowledgment from the receiver. RFC 3416 defines an SNMPv2 trap as unconfirmed, and Cisco describes NX-OS traps as asynchronous and unacknowledged. The switch therefore cannot confirm reception of a normal trap. An inform provides a response and retry mechanism, but does not ...