I85PREP
⌘ K
Aruba Campus Access Professional study materials
Aruba Campus Access Professional study resources

Monitoring Blind Spot After Controller Failover

Aruba Campus Access Professional · Put your knowledge to work in context.

All case studies

Monitoring Blind Spot After Controller Failover

A campus uses Aruba Central for monitoring and management of CX switches and APs, with a local Mobility Conductor managing a cluster of controllers. After a conductor failover, NOC dashboards show APs as up but switch uplink utilization and client counts are stale for about 30 minutes, and some alerts never fire. The team also notices that syslog from a new switch VLAN is missing in the SIEM. No configuration changes were made to the switches.

1. What is the most likely reason for stale telemetry after failover, and how do you confirm it?

Read the worked answer

Likely cause. Telemetry/streaming from the managed devices depends on a connection to the management plane (Central and/or the conductor). After a conductor failover, devices may need to re-establish streaming sessions; if the failover changed the management IP or the devices' target, streams can stall until reconnect/timeout. Stale-but-"up" AP status suggests the last-known state is being displayed while live telemetry is not arriving.

Confirmation steps.

  1. Check device connectivity/streaming status in Central for affected APs/switches (last-seen timestamps).
  2. On a switch, verify the management/telemetry target and that the connection is established.
  3. Check conductor cluster health and which node is active after failover; confirm management IPs/VIPs are as expected.
  4. Correlate the stale window with the failover time - a ~30-minute gap matches a reconnect/timeout cycle.

If last-seen timestamps stop at failover and resume later without config changes, it's a telemetry reconnection issue, not a device outage.

2. Why would some alerts never fire, and what would you check in the alerting pipeline?

Read the worked answer

Why alerts miss.

  • Alert rules depend on telemetry; if data is stale/missing, threshold rules never evaluate or evaluate on old data.
  • Alert delivery path may be tied to the failed node (webhook/email relay, or a service that didn't fail over cleanly).
  • Rule scope may reference objects (sites/groups) that changed identity after failover.

Checks.

  1. Confirm alert rules are enabled and scoped to the right groups/sites.
  2. Verify the notification channel (webhook/SMTP) is reachable and that test alerts deliver.
  3. Check whether alerts are evaluated on live vs. cached data and whether there's a suppression window.
  4. Review alert history around the failover for a gap.
  5. Confirm the monitoring service itself failed over and is healthy on the new active node.

Fix by making alert delivery independent of a single node and by testing alerting after any failover drill.

3. Syslog from a new switch VLAN is missing in the SIEM. How do you troubleshoot end to end?

Read the worked answer

End-to-end path: switch → syslog target → network path → SIEM collector.

  1. Switch side. Confirm syslog is configured and the source interface is the new VLAN's IP; check show logging and that messages are being generated. Verify the syslog server IP/port and that the source VLAN can reach it (routing, ACLs).
  2. Path. From the switch, test reachability to the collector; check for ACLs/firewalls blocking UDP/TCP 514 (or the configured port) from the new subnet. A new VLAN often means a new subnet that isn't permitted in firewall rules.
  3. Collector/SIEM. Confirm the collector is listening and receiving from the new source IP; check parsing/normalization so messages aren't dropped as unknown format.
  4. Timestamps/format. Ensure consistent time (NTP) and that the SIEM accepts the format.

Most likely culprit: the new VLAN's subnet isn't allowed through a firewall/ACL to the syslog collector. Confirm by testing from a host in that VLAN and by checking firewall logs. Fix the rule and verify messages appear in the SIEM.