11.4 Network Telemetry, Streaming APIs, and SNMP/Syslog

Network Telemetry, Streaming APIs, and SNMP/Syslog

Quick Summary: Enterprise network visibility requires combining reliable legacy monitoring protocols with modern event-driven telemetry. While traditional SNMP (particularly secure SNMPv3) and Syslog remain essential for device health polling and asynchronous event logging, modern campus environments increasingly adopt push telemetry, REST APIs, and Central webhooks and streaming APIs. On AOS-CX switches, the database-centric architecture exposes switch state through the REST API and real-time WebSocket notifications.

---

The Evolution of Network Monitoring: Pull vs. Push

For decades, network operations relied exclusively on the pull model of network monitoring. In a pull architecture, a centralized Network Management Station (NMS) periodically polls managed network devices at fixed intervals (typically every 5 to 15 minutes) using protocols like SNMP to query interface counters, CPU utilization, and memory stats.

Inefficiencies of the Pull Model

• Polling Overhead: The NMS must send thousands of individual request packets across the network, requiring switches to interrupt CPU processes to respond to each poll.
• Sampling Gaps: If an interface experiences a severe 10-second traffic spike or microburst between 5-minute polling intervals, the NMS completely misses the event. The spike averages out in counter math, leaving operators blind to intermittent congestion.
• Scalability Limits: As campus networks grow to thousands of switches and APs, polling every device frequently enough to detect transient issues overwhelms both network bandwidth and management server compute resources.

The Advantages of the Push Model

In contrast, modern architectures leverage the push model via streaming telemetry and event-driven webhooks:

• Real-Time Data Streaming: Instead of waiting to be polled, the switch continuously pushes granular metrics (such as interface errors, buffer utilization, or routing table changes) to collectors as they occur.
• Zero Sampling Delay: State transitions and transient anomalies are streamed immediately upon occurrence, eliminating visibility blind spots.
• Reduced Resource Consumption: One persistent subscription replaces thousands of repeated polls, reducing switch CPU utilization and management bandwidth.

---

Simple Network Management Protocol (SNMP)

Despite the rise of streaming telemetry, the Simple Network Management Protocol (SNMP) remains a pervasive management standard across multi-vendor campus environments.

Core SNMP Architecture

• SNMP Agent: A background software daemon running on the managed switch or AP that gathers local hardware and protocol statistics.
• Management Information Base (MIB): A structured, hierarchical database of manageable objects defined in standardized text files. Objects are addressed using hierarchical dot-delimited Object Identifiers (OIDs) (e.g., 1.3.6.1.2.1.2.2.1.10 for incoming interface octets).
• Network Management Station (NMS): The central server that queries agents and receives alert notifications.

SNMP Protocol Operations

SNMP defines specific Protocol Data Units (PDUs) for data exchange:

• GetRequest / GetNextRequest / GetBulkRequest: Sent by the NMS to read one or more MIB object values (pull mechanism) over UDP port 161.
• SetRequest: Sent by the NMS to modify a writeable MIB parameter on the switch over UDP port 161.
• Trap: An unsolicited, asynchronous notification sent by the switch agent to the NMS over UDP port 162 when an event occurs (e.g., link down, power supply failure). Traps are unacknowledged; the switch does not know if the NMS received the message.
• InformRequest: An enhanced notification sent over UDP port 162 that requires the NMS to return an acknowledgment packet. If the agent does not receive an acknowledgment, it retransmits the Inform.

Evolution of SNMP Security Versions

SNMPv3 Security Levels

SNMPv3 replaces shared community strings with individual user accounts defined in the User-based Security Model (USM). It supports three distinct security levels:

1. noAuthNoPriv (No Authentication, No Privacy):
   • Uses a username match for identity verification.
   • No cryptographic hashing is performed; no encryption is applied.
   • Offers minimal security; rarely used in production enterprise networks.
2. authNoPriv (Authentication, No Privacy):
   • Authenticates the sender and guarantees packet integrity using cryptographic hash functions (HMAC-SHA-256 or HMAC-SHA-1).
   • The message payload is not encrypted and travels as readable plaintext.
   • Protects against packet tampering and spoofing, but does not protect against eavesdropping.
3. authPriv (Authentication and Privacy):
   • Provides the highest level of security and is mandated in secure enterprise campus networks.
   • Enforces HMAC-SHA authentication and integrity checking.
   • Encrypts the entire message payload using strong symmetric encryption algorithms (AES-128, AES-192, or AES-256; legacy DES is also supported but deprecated).
   • Guarantees confidentiality, integrity, and authenticity.

! AOS-CX Switch SNMPv3 Configuration Example
snmpv3 security-level auth-privacy
snmpv3 user admin-nms auth sha auth-pass plaintext <auth-pass> priv aes priv-pass plaintext <priv-pass>
snmp-server host 10.10.10.100 trap version v3 user admin-nms

---

System Logging (Syslog) Mechanics

Syslog (standardized in RFC 5424 and RFC 3164) is the universal protocol for event notification in campus infrastructure. Whenever a noteworthy event occurs on an Aruba CX switch—such as an administrator logging in, a port transitioning to the down state, or an OSPF neighbor relationship changing—the switch generates a syslog message.

Syslog Message Format

A standard syslog message contains:

• Facility Code: Categorizes the software subsystem generating the log (e.g., local0 through local7, daemon, auth).
• Severity Level: Indicates the operational severity of the event on an 8-point numerical scale from 0 to 7.
• Timestamp: Precise date and time of the event (highly dependent on accurate NTP synchronization).
• Hostname / Device IP: Identifies the originating switch.
• Message Body: Human-readable description of the event.

The 8 Syslog Severity Levels

Memorizing the numerical severity levels is a staple of campus network certifications:

Exam Rule for Severity Thresholds: When an administrator configures a syslog forwarder with a specific severity level (e.g., logging 10.10.10.50 severity warning), the switch forwards all messages at that severity level and all higher severities (numerically lower numbers). Therefore, setting the threshold to warning (4) forwards levels 0, 1, 2, 3, and 4.

Transport Considerations

By default, syslog messages are transmitted as unacknowledged datagrams over UDP port 514. In high-security or compliance-driven environments, AOS-CX supports secure syslog forwarding over TLS on TCP port 6514, ensuring encryption and guaranteed delivery to SIEM platforms (such as Splunk or Elastic).

---

Modern Telemetry: WebSocket Notifications and Central Webhooks

AOS-CX Real-Time Notifications (Telemetry Streaming)

The AOS-CX REST API supports a real-time notification subsystem: an external client opens a secure WebSocket connection to the switch (the handshake uses HTTPS, so no extra port or authentication method is needed) and subscribes to the resources it cares about (AOS-CX 10.14 REST API Guide).

• The switch then pushes JSON messages whenever subscribed configuration, state, or statistics change.
• Because the messages use the same JSON models as REST payloads, a tool can combine REST queries with notifications.
• HPE describes this as a form of telemetry streaming: changes arrive when they happen instead of at the next polling interval.

Aruba Central Webhooks

Within the cloud-native Aruba Central ecosystem, Webhooks enable event-driven push integrations with external third-party systems:

• Rather than requiring an external tool (like ServiceNow, PagerDuty, or Slack) to poll Central's REST API every minute, Central pushes an HTTP POST request containing a JSON payload immediately when an event occurs.
• Common webhook triggers include: new critical AI Insights, device state changes (switch offline), client association anomalies, or security audit violations.

---

AOS-CX REST APIs and State Database Integration

A defining architectural advantage of the AOS-CX operating system is its database-centric design. Unlike traditional network operating systems where individual software daemons communicate via complex inter-process messaging, AOS-CX stores 100% of switch configuration, operational status, and telemetry in an in-memory database called the Open vSwitch Database (OVSDB).

The Native REST API Engine

Because all switch state resides in a structured database, AOS-CX natively exposes a full-featured RESTful API:

• Broad API Coverage: Switch resources stored in the database can be read, and most can be written, through the REST API.
• Standard JSON Payloads: Request and response bodies are formatted in standard JavaScript Object Notation (JSON).
• Standard HTTP Methods:
  • GET: Read switch configuration, interface counters, or operational status.
  • POST: Create a new configuration object (e.g., creating a new VLAN or interface lag).
  • PUT / PATCH: Modify an existing configuration parameter (e.g., changing a port description or updating an IP address).
  • DELETE: Remove a configuration object (e.g., deleting a VLAN).
• AOS-CX REST API Reference (Swagger UI): Every AOS-CX switch includes a browser-based API reference built on Swagger 3.0 that documents resources, parameters, and JSON models and can execute requests. REST URIs take the form https://<switch-ip>/rest/v10.xx/<resource> (for example /rest/v10.09/system).

---

Protocol Comparison Matrix

---

Common Exam Traps

• SNMPv3 Security Level Capabilities: A classic question asks which SNMPv3 level provides encryption. Remember: authNoPriv provides authentication and integrity, but only authPriv provides encryption (privacy).
• Syslog Numbering Direction: Syslog level numbers are inversely related to severity: 0 is the most severe (Emergency), and 7 is the least severe (Debug). Questions attempting to trick you will describe level 7 as an emergency.
• Syslog Severity Inclusion: Setting logging to severity error (3) forwards messages at levels 0, 1, 2, and 3. It does not forward warnings (4) or notices (5).
• SNMP Port Roles: Do not confuse UDP port 161 (used by the NMS to poll agents) with UDP port 162 (used by agents to send Traps and Informs to the NMS).