Aruba Clearpass Custom Analysis & Trending

Our large UK university campus uses Aruba Clearpass for authentication. We had a situation recently when a large number of wireless authentications were failing at certain times of the day. One of the great features of Clearpass is the Access Tracker that lists all the authentication attempts with lots of useful information. It is found on Policy Manager - Monitoring - Live Monitoring - Access Tracker

I could see in the policy manager access tracker that at the times when the issue was occurring that many of the connections were failing with a timeout. One of the very useful parts of the access tracker are its filters and I was able to filter for "Login Status equals TIMEOUT". However, what I really wanted to see was the number of login timeouts vs successful authentications graphed over time to get an understanding of the scale of the problem and its frequency.

Policy Manager has a graphing function to be found at: Policy Manager - Monitoring - Live Monitoring - Analysis & Trending. An example of the supplied filters is this, simply showing total requests, successes and failures:

However, in my case I needed to see the authentication timeouts and not just all the failures. What I needed was a data filter which are found at Policy Manager - Monitoring - Data Filters. These can filter on any of the parameters present in the access tracker and can use Boolean logic to construct more complex queries. The query can then be used to build a graph in the Analysis & Trending module.

My first filter was quite simple just looking for RADIUS authentication where the Login-Status EQUALS TIMEOUT:

and another that showed the timeouts from a group of Meru controllers by filtering on the NAS IP address of the wireless controller(s):

Then applying these filters in Analysis & Trending provided the graphical representation required:

Aruba AOS8 Cluster Grouping

On a new job working with an existing Aruba AOS 8 deployment I came across a cluster of four 7240XM controllers clustered as a single cluster but with the controllers configured with two different group IDs. This wasn't a parameter I was familiar with and the documentation wasn't much help either. In the online user guide here this is the explanation

group <group_id>

The value of the parameter is an integer and the range is 1-12. The value 0 is the unset value if you do not want to group the managed devices

This explanation from David Westcott explains it perfectly here. "The use is to assign controllers in the same physical location the same group ID. Then the cluster places User anchor controller (UAC) and Standby User anchor controller (S-UAC) for each client in different groups so that if a whole physical location goes offline then the standby connections are already established."

This is confirmed on our cluster. For this cluster controllers xxCL-01 and xxCL-03 are in group 1 whilst controllers xxCL-02 and xxCL-04 are in group 2. The last octet of the IP address corresponds to the controller name.

lc-cluster group-profile uni-cluster
  controller 172.17.101.1 priority 128 mcast-vlan 0 vrrp-ip 0.0.0.0 vrrp-vlan 0 group 1
  controller 172.17.101.2 priority 128 mcast-vlan 0 vrrp-ip 0.0.0.0 vrrp-vlan 0 group 2
  controller 172.17.101.3 priority 128 mcast-vlan 0 vrrp-ip 0.0.0.0 vrrp-vlan 0 group 1
  controller 172.17.101.4 priority 128 mcast-vlan 0 vrrp-ip 0.0.0.0 vrrp-vlan 0 group 2

Looking at the cluster from the MM GUI: Managed Network - Infrastructure - Clusters it shows that clients active on xxCL-01 are standby on xxCL-02 and vice versa. Clients active on xxCL-03 are standby on xxCL-04 and vice versa.