Aruba bucketmap, UAC Computation Concept
The Aruba 8.x architecture introduced a new feature of Cluster. The Clustering is a combination of multiple managed devices (MDs) working together to provide high availability to all clients, ensuring service continuity and load-balancing feature.
The clustering feature provides :
Seamless Roaming
Client Stateful Switchover
AP and Client Loadbalancing
Cluster bucketmap/mapping table:
The Aruba Controller creates a mapping table called the bucketmap. The mapping table/bucketmap is table that provides the mapping of the station/client index to the UAC(User Anchor Controller). This table is pre-populated even before any client/user is connected to the Aruba AP.
The bucketmap is per ssid basis, each ssid has its own bucket map. The output below shows the two bucketmap for the SSID: Test and LAB_TEST
(Test) [MDC] #show aaa cluster essid-all bucketmap
Bucket map for Test, Rcvd at : Tue Sep 22 08:41:14 2020
Item Value
—- —–
Essid Test
UAC0 10.17.10.10
UAC1 10.17.10.11
Active Map[0-31] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[32-63] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[64-95] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[96-127] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[128-159] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[160-191] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[192-223] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[224-255] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Bucket map for LAB_TEST, Rcvd at : Tue Sep 22 06:59:44 2020
Item Value
—- —–
Essid LAB_TEST
UAC0 10.17.10.10
UAC1 10.17.10.11
Active Map[0-31] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[32-63] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[64-95] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[96-127] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[128-159] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[160-191] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[192-223] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[224-255] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
As you can see the bucket map include variables like: SSID, UAC. Thus this bucketmap would not change until change in cluster size or any new SSID added. We can pretty much say the bucketmap is permanent and this is what allows each client to have the same UAC wherever/to any AP it connect in the network.
Once the bucketmap is computed, the Cluster leader pushes the mapping table to all the APs.
Now that the AP has this mapping table, the AP uses this to decide what should be the UAC for the client that has connected to it. When a user connects to an AP, the AP runs the hashing algorithm on the user mac address ( the algorithm uses the last 3 bytes of the client mac address) and spits out a Station index. This station index is a value between 0 – 255 and is referred against the mapping table/bucketmap to decide the UAC for the client.
Following diagram gives a brief of the process.
In the output below you see the details for the user with mac address: 20:4c:03:62:aa:d3 and IP address 10.17.11.90.
The station/client index computed for the client is: 27. The station index was referred against the bucketmap and identified that 10.17.10.10 was the UAC for this station/client.
(Test) [MDC] #show aaa cluster essid LAB_TEST users
Active Users for ESSID : LAB_TEST
BUCKET MAC IP Active UAC Standby UAC
—— — — ———- ———–
27 20:4c:03:62:aa:d3 10.17.11.90 10.17.10.10 10.17.10.11
You can also use the following command if you are aware of the client mac address and ssid name the client is connected.
(Test)[MDC] #cluster-debug calc-sta-uac 5a:10:5e:5a:21:c9 LAB_TEST
STA Index:178
STA A-UAC:10.1.2.36
STA S-UAC:10.1.2.35
Thus to summarised as explained by David Westcott in one of the Airheads forum:
When the cluster is created, the cluster leader builds a bucket map for each ESSID that is part of the cluster. The cluster leader takes the total number of cluster members and assigns a number to each one, starting with 00, 01, 02… for however many cluster MCs there are. The cluster leader then creates a bucket map for one of the ESSIDS and distributes the numbers across the bucket map. Think of the bucket map as simply two lookup tables for each ESSID with 256 positions in each lookup table. The first tables is the active or UAC pointers and the 2nd table is the standby or S-UAC pointers. (This is done for each ESSID)
When the maps are created for each ESSID, they are sent to the APs. This map will be the same, as long as you do not add an MC or remove an MC from the cluster. So the APs hold the maps. When a user tries to connect to an ESSID, the AP performs a hash on the extended unique identifier (last 6 hex digits in the MAC address) of the user MAC address, and generates an ASCII number between 0-255.
Once the AP has generated the hash for the client, it simply uses the ASCII hash value and looks up that position in both the active and standby tables in the bucket map, finds the controller number 00,01,.. and cross references it to the IP address of the MC and establishes the UAC and S-UAC tunnels for the user.
Happy Reading….