Build switch monitoring by recording device identity and management context, verifying Network Time Protocol (NTP) synchronization, collecting a normal counter-and-event baseline, and proving that the collector receives the intended evidence. Choose each management protocol by purpose and protection: file transfer, interactive administration and Simple Network Management Protocol (SNMP) monitoring are different services. A responding device is not yet a validated monitoring system.
This procedure uses AOS-CX 10.13 on a standalone CX 6300 with established secure administrative access. It creates an evidence workflow, not a firmware change or a full connectivity investigation. Commands are documented observation examples; no successful output is asserted. Retain console recovery and change authorization if the monitoring design requires service changes.
Establish the Management and Collector Context
Record the switch identity, software build, management Internet Protocol (IP) address, selected virtual routing and forwarding (VRF) context, monitored interfaces and collector identity. In the example, use an authorized management network and its intended mgmt context. Confirm addressing, return routing and permitted service traffic in that design before changing credentials to repair an unexplained collection failure.
The collector needs its own acceptance criteria: which observations it retrieves, how often, which events it accepts, where records are retained and who responds to an alert. Keep secrets out of the baseline record. An existing Secure Shell (SSH) login provides protected interactive access; it does not prove that a separate monitoring protocol is listening or that its collector credentials work.
Choose Management Protocols by Purpose and Security
The public scope includes several legacy protocols. Recognizing their functions does not recommend deploying them without protection.
| Protocol | Purpose | Security distinction and supported direction |
|---|---|---|
| Trivial File Transfer Protocol (TFTP) | Simple file transfer | It provides neither built-in user authentication nor encryption. Prefer supported SSH-based file transfer for sensitive artifacts. |
| File Transfer Protocol (FTP) | File transfer with login and file operations | Ordinary unprotected FTP exposes credentials and data. Do not equate an authenticated login with encryption. |
| SSH File Transfer Protocol (SFTP) | File transfer through SSH | It provides an encrypted, authenticated transport; verify the server's host identity and use approved credentials. AOS-CX documents SFTP for supported copy operations. |
| Telnet | Interactive remote terminal access | Ordinary Telnet does not encrypt the session. Use supported SSH for administrative sessions. |
| SNMP version 2 | Management information and notifications | The common community-based SNMPv2c form does not encrypt its community string or payload. Prefer supported SNMPv3 authentication and privacy where policy and collector compatibility permit. |
SFTP is a distinct protocol, not simply a setting that encrypts an FTP session. File-transfer support is also operation-specific: the supported copy methods for a configuration artifact do not establish every possible service on the switch. This monitoring procedure does not require enabling TFTP, FTP or Telnet.
For SNMPv3, explicitly select both authentication and privacy using mutually supported algorithms that meet policy. The version name alone does not mean those protections are enabled. Do not generalize SNMPv2c's community security properties to every SNMP security model, and do not fall back to an unapproved mode merely to make a poll succeed.
Verify Time Before Comparing Events
Use the command-line interface (CLI) through the approved console or SSH access. From manager context, begin with:
switch# show version
switch# show system
switch# show ntp associations
switch# show ntp status
Compare the device and build with the inventory. Check actual synchronization and the expected time-source context, not just the presence of a configured server. Record the timestamp convention used by the collector so an event's switch time and arrival time can be interpreted correctly.
If time is not synchronized, record that limitation before correlating an apparent sequence across devices. Use the established commissioning workflow to correct time settings under the organization's authentication policy; do not silently treat uncertain timestamps as precise evidence.
Capture a Repeatable Local Baseline
For a reserved, valid example interface, collect these manager-context observations:
switch# show interface 1/1/1
switch# show interface 1/1/1 statistics
switch# show system resource-utilization
switch# show events
Record interface state, speed, traffic counters and errors alongside system resource use and relevant events. Use the actual port identifiers on the selected model. The resource display may report that polling is disabled; absence of collected data is not a zero-use measurement.
Repeat the same observations over a documented interval under representative load. Compare changes in counters rather than treating their lifetime totals as an incident rate. For an illustrative calculation, 600 additional errors over 60 seconds averages 10 per second for that interval. This is arithmetic, not an observed switch result; interpret it alongside traffic volume, uptime and any counter reset.
Preserve events and counters before clearing them. A reboot or reset can change the baseline, so record that discontinuity rather than calculating a misleading delta. For an egress-congestion question, inspect the documented queue evidence as well; overall interface traffic does not identify which service class experienced drops.
Prove Remote Collection Separately
Use an already provisioned, approved SNMPv3 monitoring identity and configure the collector to match its authentication, privacy and context settings. Verify that the relevant service is enabled in the intended switch context before polling.
In the matching 10.13 Monitoring Guide, snmp-server vrf selects the listening context; the documented initial agent state listens on no VRF. Inspect the actual device rather than projecting that initial state onto an existing deployment or another release. The guide also defines supported contexts and their precedence, so enabling several contexts is not a substitute for choosing one deliberately.
From the collector, retrieve identity and interface observations and compare them with the local baseline for the same device and interval. Confirm that the expected interface is being graphed and that fresh records continue to arrive. A configured dashboard with stale data is not acceptance.
Syslog supplies event messages that complement periodic polling. For remote logging, use the documented Transport Layer Security (TLS) capability with approved trust configuration where required, and verify destination, severity selection, VRF and receipt. A destination entry alone does not prove delivery. Notifications, polling, packet capture and active probes answer different questions; none automatically substitutes for all the others.
Structured collection through the Representational State Transfer (REST) application programming interface (API) is another supported approach. The same identity, permission, timestamp and freshness checks apply. Tool ownership and deployment scale are separate selection decisions.
Accept the Baseline and Preserve a Recovery Path
Accept monitoring when local and collector evidence agree, timestamps are interpretable, expected records remain fresh, and an authorized benign test event can be found at the receiver. Use an isolated spare interface for a planned link-state event test; do not interrupt a live uplink to manufacture an alarm. Distinguish an alert notification from the later evidence that the condition cleared.
If an authorized monitoring change fails, restore only its recorded settings through the retained recovery path and verify the prior baseline. Avoid weakening authentication or clearing evidence to obtain a green dashboard. For HPE6-A86, useful monitoring means knowing what each observation proves, how it was protected, and when it was collected.
Authoritative Sources
- AOS-CX 10.13 Fundamentals Guide
- AOS-CX 10.13 Security Guide
- AOS-CX 10.13 Monitoring Guide
- AOS-CX 10.13 Diagnostics and Supportability Guide
- AOS-CX 10.13 Quality of Service Guide
- HPE Network Switching Associate Exam