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

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

Users of a web service behind Alteon on TCP port 443 reported intermittent authentication failures. Some attempts succeeded; others returned an authentication error. Initial checks found no physical-interface errors. Server and service health checks passed, and most inspected session entries carried an E flag. Those observations did not establish whether the affected requests had completed authentication.

On Catalyst 9200 switches, Install and Bundle modes have different boot dependencies. The mode determines which software files must stay in flash and how to approach upgrades and cleanup. Install mode boots from packages.conf and extracted .pkg files. Bundle mode boots a monolithic .bin image. Cisco recommends Install mode for Catalyst 9200 switches. Install and Bundle mode comparison Item Install Mode Bundle Mode Primary boot reference flash:packages.conf flash:<IOS-XE-IMAGE>.bin Required software files packages.conf and the referenced .pkg files The selected .bin image Mode shown by show version INSTALL BUNDLE Upgrade approach IOS XE install workflow Boot-variable change to another BIN image and reload Cisco recommendation for C9200 Recommended Supported, but not the recommended op...

On Catalyst 9200 switches in Install mode, install remove inactive frees flash by removing unused installation files. Plan its timing around the image transfer and the committed software state. The command scans the installation directory, identifies packages in use, and lists files for deletion. That list can include BIN images. A newly copied image that has not been added can therefore be deleted during cleanup. Before removing software files, confirm how the switch boots. See Cisco Catalyst 9200 Install Mode vs Bundle Mode Explained for the files required by each mode. What install remove inactive removes install remove inactive The switch checks the active packages.conf and its package set to identify software files the running installation does not require. Depending on the files and install state, candidates include: Inactive package files from an older or incomplete installation Unused provisioning or configuration files IOS XE .bin image files stored in fla...

After Catalyst C9200L and C9300L switches were upgraded from IOS XE 17.9.4a to 17.18.4, an existing access-control system could no longer connect over SSH. The switches were operating normally and console access still worked. The failure was in SSH negotiation between the access-control tool and the switch. Environment Cisco Catalyst C9200L Cisco Catalyst C9300L Previous IOS XE version: 17.9.4a Upgraded IOS XE version: 17.18.4 SSH connection initiated through an existing access-control system The same access-control system had connected successfully before the upgrade. SSH failure before authentication After the upgrade, its SSH sessions failed before authentication completed. The switch logged: %SSH-3-NO_MATCH: No matching kex algorithm found The detailed log identified a Key Exchange (KEX) mismatch. The client offered: diffie-hellman-group1-sha1 diffie-hellman-group14-sha1 diffie-hellman-group-exchange-sha1 diffie-hellman-group...

During an IOS XE upgrade on a standalone Catalyst 9200L, the combined install command stopped with: Super package already added. Add operation not allowed. An earlier Add operation had already extracted the packages onto the switch, so another Add attempt was rejected. The message alone did not establish that the image was corrupt. The upgrade continued with install activate , checks after reload, and install commit . The target release was running in Install mode, with final state C (Activated and Committed). If you need to confirm why this workflow uses packages.conf and install commands, see Cisco Catalyst 9200 Install Mode vs Bundle Mode Explained . Environment Platform: Cisco Catalyst C9200L-24P-4G Topology: Standalone switch Starting release: Cisco IOS XE 17.9.4a Target release: Cisco IOS XE 17.18.4 Boot mode: Install mode Image transfer method: TFTP to local flash Hostnames, IP addresses, MAC addresses, serial numbers, and site-specific timestamps ...

An internal vulnerability assessment called for removing apparently unnecessary accounts from a Cisco Nexus switch. I found an SNMPv3 username listed as a local CLI user. From my experience with Cisco IOS, I initially treated the monitoring identity and the administrative login as separate objects. I paused the deletion to check NX-OS behavior. By default, NX-OS synchronizes SNMPv3 users with its security user database, so deleting the CLI account can also remove the SNMP user and interrupt monitoring. Environment Platform: Cisco Nexus C93180YC-FX3 Software: Cisco NX-OS 10.6(1) Context: Internal vulnerability assessment and account cleanup Change status: No account was deleted Usernames, passwords, customer information, and environment-specific details have been omitted. How I found the account I found the entries with: show running-config | include user The output included a local username and an snmp-server user entry for the same identity. The entries had this structu...