Monitoring, Analytics, and Troubleshooting
What to look at, in what order
Troubleshooting questions are usually 'which command or tool' and 'what does it prove'. Organise them: physical (interface counters, optics, CRC errors), Layer 2 (MAC table, ARP, VLAN membership), Layer 3 (route table, FIB, adjacency), overlay (tunnel state, VNI mapping, EVPN routes), policy (ACL hits, role assignment), and control plane (CPU, BGP/OSPF neighbours, BFD).
AOS-CX monitoring tools: NAE agents that watch a condition and raise an alert, event logs and syslog, SNMP polling and traps, sFlow for sampled packet-level visibility without mirroring every frame, streaming telemetry to a collector, and Aruba Central or Fabric Composer for fabric-wide dashboards. Analytics adds baselining, so 'unusual' is measured against the site's own history rather than a generic threshold.
Traps
- Not checking NTP first: correlating logs across five devices with skewed clocks wastes time.
- Reading a control plane that is up as proof the data plane works. BGP up with VNI down is a mapping or MTU problem.
- Forgetting that sFlow is sampled - an empty report may mean a low sample rate, not no traffic.
- Running show-tech on a box that is already CPU-starved and making it worse.
- Trusting a single counter: CRC errors with no drops points to cable/optics; drops with clean CRC points to congestion or policy.
- Treating monitoring as free - NAE agents consume switch CPU and memory.
Worked example
A server cannot reach another server in the same tenant on a different leaf. BGP EVPN is Established and the VNI exists. Check the tunnel: up. Check the type 2 route for the destination MAC: missing. Check the VLAN-to-VNI mapping: VLAN 40 points at the wrong VNI. Fix the mapping and the route appears. Underlay, session, route, mapping - that order is the rule.