Study guide
4.2 Network Analytics Engine (NAE) and Automated Telemetry
HPE Aruba Networking Certified Associate - Campus Access HPE6-A85
Track your progress as you read
Finished sections get a check mark.
1 Introduction: HPE6-A85 Exam Overview
HPE6-A85 Exam Facts and Current Blueprint
2 Chapter 1: Network Stack Fundamentals
1.1 OSI Reference Model and Encapsulation 1.2 TCP/IP Protocol Suite and IP Headers 1.3 Layer 2 Operation, ARP, and 802.1Q Tagging
3 Chapter 2: Physical Connectivity and Host Addressing
2.1 Ethernet Media and Transceiver Standards 2.2 Power over Ethernet (PoE, PoE+, PoE++) Standards and Budgeting 2.3 LLDP, LLDP-MED, and Voice VLAN Configuration 2.4 Host IP Addressing and DHCP Relay Operations
4 Chapter 3: Network Resiliency and Virtualization
3.1 Virtual Switching Framework (VSF) Architecture and Topologies 3.2 VSF Split Detection, Failover, and Auto-Stacking 3.3 Virtual Switching Extension (VSX) Architecture and Operations 3.4 High-Availability Gateways: VRRP and VSX Active-Gateway
5 Chapter 4: AOS-CX Architecture and Switch Operation
4.1 AOS-CX Hardware Portfolio and State Database Architecture 4.2 Network Analytics Engine (NAE) and Automated Telemetry 4.3 AOS-CX Interface Configuration and Port Control 4.4 Link Aggregation (LAG) and LACP Configuration
6 Chapter 5: Layer 2 Protocols and Spanning Tree
5.1 AOS-CX VLAN Configuration and Native VLAN Handling 5.2 Spanning Tree Protocols: STP, RSTP, and MSTP 5.3 Spanning Tree Protections and Loop Prevention 5.4 MAC Address Table Learning, Aging, and Forwarding
7 Chapter 6: Wireless Fundamentals, Standards, and RF
6.1 IEEE 802.11 Standards and Wi-Fi Generations 6.2 RF Fundamentals, Signal Propagation, and Channel Design 6.3 Aruba Access Point Hardware Portfolio and Suffix Conventions 6.4 WLAN Topologies, BSSID/ESSID, and Roaming Standards
8 Chapter 7: Aruba Wireless Architecture and Management
7.1 AOS 10 Architecture and Aruba Central Integration 7.2 Wireless Forwarding Modes: Bridge vs Tunnel Mode 7.3 Automated RF and Client Optimization: AirMatch and ClientMatch 7.4 Secure Wireless Access: WPA3, SAE, and MPSK Implementation
9 Chapter 8: IP Routing Fundamentals and OSPF
8.1 IP Routing Principles and Packet Forwarding 8.2 OSPFv2 Protocol Mechanics and Adjacency Formation 8.3 OSPF Designated Routers and Multi-Area Deployments 8.4 ECMP, Static Routing, and VRF Isolation
10 Chapter 9: Campus Network Security and Segmentation
9.1 DHCP Snooping and Dynamic ARP Inspection 9.2 Port Security and MAC Address Limiting 9.3 ClearPass Policy Management and RADIUS Change of Authorization 9.4 Dynamic Segmentation, User-Based Tunneling, and Policy Enforcement
11 Chapter 10: Authentication, Authorization, and Accounting
10.1 The AAA Framework and Architecture 10.2 802.1X Authentication and EAP Methods 10.3 MAC Authentication and Captive Portal Onboarding 10.4 Administrative Access Control: RADIUS vs TACACS+
12 Chapter 11: Network Management and Telemetry
11.1 Aruba Central Cloud Architecture and Group Configuration 11.2 Zero-Touch Provisioning (ZTP) and Aruba Activate 11.3 AI Insights and Aruba User Experience Insight (UXI) 11.4 Network Telemetry, Streaming APIs, and SNMP/Syslog
13 Chapter 12: Troubleshooting the Solution
12.1 Structured Troubleshooting Methodologies and Scope Isolation 12.2 AOS-CX Layer 2 and Interface Diagnostic Commands 12.3 Layer 3, IP Services, and End-to-End Diagnostics 12.4 Physical-Layer Troubleshooting 12.5 Troubleshooting Wireless Clients and Network Access
14 Chapter 13: Optimizing Performance: QoS, Baselines, and Comparisons
13.1 Quality of Service (QoS) Classification and Marking 13.2 Queuing Algorithms and Congestion Management 13.3 Traffic Policing, Shaping, and Broadcast Rate Limiting 13.4 Establishing a Performance Baseline 13.5 Comparing Results to the Baseline
15 Chapter 14: Plan the Solution
14.1 Analyzing the Current Environment 14.2 Interpreting an Architect's High-Level Design 14.3 Creating a Low-Level Design 14.4 Preparing for Implementation
16 Chapter 15: Validate and Operate the Solution
15.1 Validating the Solution 15.2 Performing Firmware Updates 15.3 Making Basic Ongoing Configuration Changes 15.4 Maintaining Network Documentation
4.2 Network Analytics Engine (NAE) and Automated Telemetry
Key Takeaways Explain This Topic AI
The Network Analytics Engine (NAE) is an on-box telemetry and diagnostics framework embedded directly within AOS-CX switches, eliminating the blind spots of periodic SNMP polling.
NAE combines a local Time-Series Database (TSDB) with event-driven Python scripts to monitor hardware and protocol states in real time.
When an anomaly or threshold condition occurs, NAE executes automated actions including CLI diagnostics snapshots, syslog generation, packet captures, and webhook notifications.
The AOS-CX Web UI dashboard visually correlates real-time time-series telemetry charts with system events and administrative configuration changes on a unified timeline.
NAE scripts can be deployed from Aruba Solution Exchange (ASE), customized, or authored from scratch using the native AOS-CX Python framework.
Last updated: October 2026
4.2 Network Analytics Engine (NAE) and Automated Telemetry
In traditional enterprise network operations, diagnosing intermittent network degradation—such as transient micro-burst congestion, sporadic packet drops, interface CRC errors, or Spanning Tree topology flaps—is notoriously difficult. Conventional monitoring relies primarily on Simple Network Management Protocol (SNMP) polling and centralized Syslog collectors. However, standard SNMP polling cycles typically occur at 5-minute intervals. A network anomaly lasting 10 or 15 seconds begins, causes severe application degradation, and clears entirely within the polling gap, leaving network engineers with zero diagnostic visibility.
Furthermore, when a failure occurs, administrators must scramble to log into multiple switches via CLI to capture operational state before the evidence disappears. Aruba Network Analytics Engine (NAE) fundamentally solves this problem by embedding a real-time analytics framework and automated diagnostics engine directly inside the AOS-CX operating system.
Limitations of Traditional Monitoring vs. Aruba NAE
Monitoring Dimension Traditional SNMP / Syslog Polling Aruba Network Analytics Engine (NAE)
Data Collection External NMS polls switch every 1 to 5 minutes Real-time, continuous on-box telemetry from state database
Detection Latency Polling interval delay (minutes) Event-driven / sub-second threshold detection
Transient Visibility Completely misses micro-bursts and intermittent flaps Captures millisecond-level spikes and state transitions
Root-Cause Analysis Manual CLI intervention required long after the incident Automated instantaneous diagnostic snapshot at moment of fault
Configuration Correlation Disconnected audit logs; no correlation with telemetry Unified visual timeline correlating config changes with metrics
Network Overhead High bandwidth consumption from polling thousands of OIDs Zero polling overhead; telemetry processed locally in hardware/OS
Core Architectural Components of NAE
Aruba NAE operates as a native extension of the AOS-CX state database architecture. It consists of four integrated pillars: the Time-Series Database (TSDB) , NAE Python Scripts , Monitors and Conditions , and Automated Actions . +-------------------------------------------------------------------------+
- | NETWORK ANALYTICS ENGINE (NAE) ENGINE |
- | |
- | +=================================================================+ |
- | | AOS-CX STATE DATABASE (OVSDB Telemetry Tables) | |
- | +=================================================================+ |
- | | |
- | Continuous Streaming |
- | v |
- | +-----------------------------------------------------------------+ |
- | | NAE PYTHON AGENT | |
- | | | |
- | | 1. MONITOR: Subscribes to OVSDB URIs (e.g. CRC drops, Tx load) | |
- | | 2. TSDB: Writes high-resolution metrics to local time-series db| |
- | | 3. CONDITION: Evaluates logic (e.g. Rate > 100 drops/sec) | |
- | +--------------------------------+--------------------------------+ |
- | | (When Condition Triggers) |
- | v |
- | +-----------------------------------------------------------------+ |
- | | AUTOMATED ACTIONS | |
- | | - Capture CLI State: 'show interface', 'show mac-address-table'| |
- | | - Pin Alert Marker to Web UI Timeline | |
- | | - Generate Syslog / SNMP Trap | |
- | | - Send Webhook / REST Alert to Aruba Central / ServiceNow | |
- | +-----------------------------------------------------------------+ |
- +-------------------------------------------------------------------------+
- 1. The Time-Series Database (TSDB)
Embedded directly within the switch operating system storage (available on CX 6200, 6300, 6400, 8100, 8325, and 8360 platforms).
Automatically captures and records chronological telemetry metrics, counter states, and performance statistics without requiring an external server or telemetry collector.
Retains high-resolution historical data (seconds, minutes, hours, and days) for immediate local trend analysis and anomaly detection.
2. NAE Scripts (Python Framework)
NAE analytics logic is written in standard Python 3 using the proprietary Aruba nae module.
Scripts are human-readable, modular, and open. Engineers can download pre-built scripts from the Aruba Solution Exchange (ASE) or write custom Python scripts to address environment-specific diagnostic needs.
Every script defines the parameters it intends to watch, the calculation logic for identifying an anomaly, and the precise diagnostic steps to execute when an issue is detected.
3. Monitors and Conditions
Monitors: Define the data streams to collect from OVSDB. A monitor can track physical interface metrics (input errors, CRC errors, transmit utilization, link flaps), environment metrics (fan speed, temperature, power supply status, SFP optical DOM parameters), or protocol states (OSPF neighbor transitions, BGP state changes, STP topology change notifications).
Conditions: Define mathematical rules or logical criteria applied to the monitored data. Examples include:
Threshold Crossing: Metric exceeds a static value (e.g., CPU utilization > 85%).
Rate of Change: Metric increases rapidly within a sliding window (e.g., interface discards increase by more than 50 packets per second over a 10-second interval).
State Transition: Protocol daemon changes operational state (e.g., OSPF neighbor changes from Full to Init or Down ).
4. Automated Actions and Root-Cause Diagnostics
When a monitored condition is met, the NAE agent executes pre-programmed automated actions at the exact millisecond of the fault, long before human operators are aware of an incident:
Diagnostic CLI Command Execution: The agent automatically runs diagnostic commands (such as show interface <port> extended , show mac-address-table , or show ip route ) and saves the exact terminal output into a diagnostic snapshot package stored in the TSDB.
Timeline Pinning: Places a visual alert indicator directly onto the Web UI time-series graph, highlighting the exact moment the threshold was breached.
Alerting: Predefined actions include syslog messages (ActionSyslog), captured CLI or shell output (ActionCLI, ActionShell), and custom reports. Alerts appear in the switch Web UI and can be consumed by external tools such as HPE Aruba Networking Central or a syslog/SIEM platform.
Automated Remediation: ActionCLI can run configuration commands as well as show commands (for example config , interface 1/1/1 , shutdown ), so a script can react to a condition. Use this carefully, because command strings are not validated before they run.
Web UI Visual Correlation and Root-Cause Analysis
A critical operational feature of NAE is its deep integration into the AOS-CX Web User Interface (Web UI) . When administrators access the switch dashboard, NAE presents an intuitive visual analytics interface: +-------------------------------------------------------------------------+
- | AOS-CX WEB UI - NAE ANALYTICS TIMELINE |
- | |
- | Metric: Interface 1/1/1 CRC Error Rate |
- | |
- | Errors/s |
- | 150 | |
- | 100 | [!] ALERT: CRC Spike > 100/s |
- | 50 | *---* |
- | 0 |------------------------* *---------------------------- |
- | +-------------------------+-----+---------------------------+ |
- | 10:00 10:15 10:20 10:35 |
- | ^ |
- | | |
- | [i] Config Change Event: |
- | Admin modified port speed on 1/1/1 |
- +-------------------------------------------------------------------------+
- The Unified Timeline Advantage
In the Web UI, NAE overlays three distinct categories of historical data onto a single synchronized timeline:
Time-Series Metric Line: Continuous visual graph of the monitored metric (e.g., bandwidth, transceiver optical power, buffer queue depth).
Alert Trigger Markers: High-visibility indicators (Normal, Minor, Major, Critical) showing exactly when an NAE condition was breached and when it returned to normal.
Configuration Audit Trail: A chronological record of administrative actions. If an engineer modified the port MTU, changed an interface speed, or added a VLAN 30 seconds before an error storm began, the configuration event appears directly below the telemetry spike.
This immediate visual correlation allows network engineers to instantly determine root cause—differentiating between an external physical fiber fault and an administrative configuration error in seconds rather than hours.
Pre-Built vs. Custom NAE Scripts
Aruba provides a library of NAE scripts through the Aruba Solution Exchange (ASE) and the NAE scripts repository on GitHub (both referenced in the AOS-CX 10.14 NAE Guide). Common operational use cases include:
Faulty SFP / Transceiver Monitoring: Continuously tracks Digital Optical Monitoring (DOM) Rx/Tx optical power levels. If optical signal drops below transceiver thresholds, NAE flags a degraded cable or dirty fiber connector before the link drops entirely.
Loop and Broadcast Storm Detection: Monitors Layer 2 broadcast/multicast packets and Spanning Tree Topology Change Notifications (TCNs), instantly identifying the ingress port causing a network loop.
MTU Mismatch Identifier: Detects drops associated with oversized frames and alerts administrators to mismatched MTU settings across point-to-point links.
Routing Neighbor Flap Analytics: Diagnoses intermittent OSPF/BGP session resets, capturing routing table states and neighbor hello timers at the exact moment of adjacency collapse.