Posts

Cisco Nexus Password Type 5: Is It the Same as IOS MD5?

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

How to Find When an Alteon Configuration Was Changed

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

Cisco Nexus SNMP Traps Explained: When They Are Sent and What Happens Next

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

Alteon Health Check Configuration & Troubleshooting Guide

A server can answer ICMP while its web service is stopped or returning application errors. Radware Alteon health checks help determine whether a Real Server is available for Server Load Balancing (SLB). Choose a check that represents the service being offered. An unsuitable method can produce incorrect availability decisions and disrupt load-balanced traffic. 1. How Alteon health checks work Alteon periodically tests Real Servers with the configured method and uses the result in service-availability decisions. Methods include ARP, ICMP, TCP, HTTP, SSL-based checks, and custom scripts. Availability and parameters depend on the AlteonOS release. Health-check methods Health Check Verification Method Limitation ICMP Checks IP-level reachability. Does not validate application availability. TCP Establishes a TCP connection. Does not verify application content. SSLH Checks SSL handshake behavior. Does not validate an HTTP application response. HTTP Evaluate...

Cisco Catalyst 9200L Local AAA Migration: Planning and Verification on IOS XE 17.18.4

After choosing AAA during a security review, we needed a migration plan that kept the existing source of login authentication. The target was a Catalyst 9200L on IOS XE 17.18.4 using local accounts, with no RADIUS or TACACS+ server. AAA was disabled. The VTY configuration was recalled as login local , pending confirmation. The proposal moves login authentication into AAA while retaining local accounts. It has not been applied or tested on the target switch.

Alteon Sessions Show Established, but HTTPS Authentication Fails Intermittently

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.

Cisco AAA and Audit Logging: Why Authorization Changed Our Decision

A security review required AAA on a Cisco device. The administrator asked why the existing management setup needed aaa new-model . We asked the security team which records they needed. Their concern was administrative access and activity, so we examined whether the existing logging features could meet the requirement. The documented coverage of login and configuration-change logs addressed parts of it. The unresolved requirement was evidence of prohibited command attempts and their authorization outcome. That requirement led us to choose AAA. Enabling aaa new-model alone does not establish that the required audit records are generated or retained.