Chapter 9: Monitoring, Automation, and the Network Analytics Engine (NAE)

SNMP, sFlow, Syslog, and mirror sessions are the four traditional pillars. Each answers a different operational question, and AOS-CX supports all four natively so you can integrate with existing NMS, flow collectors, SIEMs, and packet brokers.

SNMPv2c vs SNMPv3

SNMP is poll-based: the manager sends a GET for an OID, the agent replies. Traps and informs are unsolicited messages pushed when an event occurs. AOS-CX runs v2c and v3 simultaneously.

switch(config)# snmp-server vrf mgmt
switch(config)# snmpv3 user netops auth sha auth-pass-plaintext "S3curePass!" priv aes priv-pass-plaintext "Pr1vKey!"
switch(config)# snmp-server host 10.10.10.50 trap version v3 user netops

sFlow Sampling

sFlow samples 1-in-N packets at the ASIC, exports the first ~128 bytes plus periodic counters to a collector, and gives statistically representative top-talker data with very low CPU. Aruba guidance: 1-in-4096 for 1 GbE access; 1-in-8192 to 1-in-16384 for 10/25 GbE uplinks.

Syslog Severity

RFC 5424 numbers severities 0 (Emergency) through 7 (Debug). Lower number = more severe. Forward severity 5 (Notice) and lower to a SIEM; Debug is reserved for troubleshooting. Set clock timezone and NTP first or your timeline correlation is broken.

Mirror Sessions

When sampling is not enough — security investigations, IDS feeds — mirror sessions copy 100% of traffic from source interfaces to a destination port (or GRE-tunneled remote endpoint, ERSPAN-equivalent).

AOS-CX exposes its entire configuration and operational state through a versioned REST API. To enable read-write and bind it to the management VRF:

switch(config)# https-server rest access-mode read-write
switch(config)# https-server vrf mgmt

The API lives at https://<switch-ip>/rest/v10.04/ (the version suffix follows your firmware). An interactive Swagger UI at /api/ documents and exercises every endpoint live.

Session-Cookie Authentication

You POST credentials to /login; a 200 response sets a cookie that subsequent calls reuse until you POST /logout. requests.Session in Python handles the cookie jar automatically.

import requests, json
base_url = "https://10.10.10.5/rest/v10.04"
creds = {"userName": "admin", "password": "ArubaNet!"}
session = requests.Session()
session.post(f"{base_url}/login", data=json.dumps(creds), verify=False)
# subsequent session.get/post calls carry the cookie automatically
session.post(f"{base_url}/logout", verify=False)

CRUD on the Configuration Tree

Objects are addressable as URIs under /system. GET reads, POST creates, PUT replaces, PATCH merges, DELETE removes. The selector query parameter selects configuration, status, or default views.

# Create VLAN 200
new_vlan = {"id": 200, "name": "Guest", "admin": "up", "type": "static"}
session.post(f"{base_url}/system/vlans", data=json.dumps(new_vlan), verify=False)
# Returns 201 Created

pyaoscx and Ansible

The pyaoscx SDK wraps REST in idiomatic Python objects (Vlan, Interface, Vrf, etc.) and handles cookies and materialization. The arubanetworks.aoscx Ansible Collection provides declarative modules built on top of pyaoscx for fleet orchestration.

NAE runs Python directly on AOS-CX to monitor, alert, and remediate — no external server, no polling latency, no separate license. The hierarchy is tidy:

NAE Script Skeleton

from Manifest import Manifest

Manifest = {'Name': 'interface_link_monitor', 'Version': '1.0'}
ParameterDefinitions = {
    'interface_id': {'Type': 'string', 'Default': '1/1/1'}
}

class Agent(NAE):
    def __init__(self):
        uri = '/rest/v10.04/system/interfaces/{}?attributes=link_state'.format(
            self.params['interface_id'].replace('/', '%2F'))
        self.m1 = Monitor(uri, 'Link State')
        self.r1 = Rule('Interface Down')
        self.r1.condition('{} == "down"', [self.m1])
        self.r1.action(self.action_alert)

    def action_alert(self, event):
        ActionSyslog('Interface DOWN', severity=SYSLOG_WARNING)
        ActionCLI('show interface {}'.format(self.params['interface_id']))

HPE publishes a public, tested library of NAE scripts at github.com/aruba/nae-scripts covering BGP/OSPF flaps, DHCP snooping anomalies, high CPU, MAC churn, PoE budget, microbursts, and STP topology changes.

For multi-switch fleets, HPE offers two complementary tools: Aruba Central (cloud-managed) and NetEdit (on-prem). Both validate config and detect drift, but only Central does ZTP.

Aruba Central ZTP Onboarding

1. Pre-provision the device in Central with serial number + MAC address.
2. Apply HPE GreenLake licensing.
3. Place in a template group with a JSON variables file keyed by serial/MAC.
4. Power on at the remote site. The factory-default switch DHCPs, contacts activate.arubanetworks.com, gets redirected to your tenant by serial, pulls its template+vars, applies config, and establishes an IPSec tunnel back to Central.
5. Verify in Central UI ("up") and on the device with show system.

UI Group vs Template Group

NetEdit (On-Prem)

For air-gapped or regulated environments, Aruba NetEdit is the on-premises virtual appliance that talks to AOS-CX over REST. Capabilities: configuration validation, multi-switch atomic transactions (all-or-nothing rollback), golden-config compliance, visual diffs, and change history. Critically: no ZTP from activate.arubanetworks.com — that capability is exclusive to Central.

• Traditional telemetry: SNMPv3 authPriv for OID polling and traps; sFlow for top-talker visibility; Syslog filtered by severity to a SIEM; mirror sessions for full packet capture.
• REST API: Login = session cookie, CRUD = standard HTTP verbs, automation = pyaoscx + Ansible Collection.
• NAE: On-box Python defining Script -> Agent -> Monitor -> Condition -> Action. License-free, time-series visualization, library at github.com/aruba/nae-scripts.
• Aruba Central: Cloud-managed ZTP via activate.arubanetworks.com, group-based config, drift detection, AI Insights.
• NetEdit: On-prem alternative with atomic multi-switch transactions and golden-config compliance — no ZTP.