Wireless Access

1. After a client has left the user-table, is the UAC stored in memory or the cluster leader database? At least in our environment, that behavior seems to be the case or we're just lucky so far that clients always maintain their UAC assignment over the course of a couple months.

2. If it is stored, is there a way to view this information to be able to determine which controller an AP will dynamicly attempt to tunnel a client back to?

I was asking out of curiosity for a TAC case I'm currently working on - particularly replication of an issue. I know we can't manually move a client to a different controller, but would help to see the the current mapping of clients that have previously left in order to find a "test candidate end user" when none of my current devices have a UAC assignment that matches my target controller of interest.

1. As long as the number of controllers in a cluster and the SSIDs do not change, clients should be tunneled to the same controller via hash indefinitely.  That is subject to change if there is a failover, of course.

 

2.  The command here:  https://www.arubanetworks.com/techdocs/ArubaOS_85_Web_Help/content/arubaos-solutions/1cli-commands/sh-sapm-bckmap.htm?Highlight=bucketmap will tell you what UAC a device is expected to be on if its mac address ends in XX for a specific SSID.

---

@cjoseph wrote:

1. As long as the number of controllers in a cluster and the SSIDs do not change, clients should be tunneled to the same controller via hash indefinitely.  That is subject to change if there is a failover, of course.

 

2.  The command here:  https://www.arubanetworks.com/techdocs/ArubaOS_85_Web_Help/content/arubaos-solutions/1cli-commands/sh-sapm-bckmap.htm?Highlight=bucketmap will tell you what UAC a device is expected to be on if its mac address ends in XX for a specific SSID.

---

Hi Colin,

 

Thank you for the link. I'm slowly starting to grasp the bucket-concepts, but I'm not quite getting where the "if its mac address ends in XX for a specific SSID" comes into play - since the "show sapm-bucketmap essid Zone1TestEssid" doesn't reference any MAC Address directly - unless I review the "show aaa cluster essid <ssid> users" command - and compare buckets like below?

The last byte of the mac address in decimal...

EDIT: NOT

---

@cjoseph wrote:

The last byte of the mac address in decimal...

---

That what's I figured it'd be the decimal value, and that's where i'm failing on making the connection - thought maybe my conversion was wrong. With the screen shot i included above from an aruba power-point - I know that Bucket-Map Point 93 contains 00 - UAC 0 and MAC Address Client 60:45:bd:cf:c8:5a has been assigned Bucket 93. But the decimal value of the last byte of the mac address :5A - is 90. It would have made sense to me if it came as Bucket 90.

 

 

actually..... it's not directly defined from the last byte (sorry Colin!), it takes into account the last 3 bytes of the MAC address. But, we don't need to bother ourselves with the specific hash function, there is a CLI command to find the bucket of some client mac in some ESSID:

 

>> here we have some user in bucket 178 on UAC .36

(ac) #show aaa cluster essid TEST users 

Active Users for ESSID : TEST
---------------------------------
BUCKET  MAC                IP        ActiveUAC  StandbyUAC
------  ---                --        ---------  --------
178     5a:10:5e:5a:21:c9  10.0.0.9  10.1.2.36  10.1.2.35
(ac) #

>> we can also find this using this shortcut

(ac) #cluster-debug calc-sta-uac 5a:10:5e:5a:21:c9 TEST
STA Index:178
STA A-UAC:10.1.2.36
STA S-UAC:10.1.2.35
(ac) #

hth.

-jeff

Thank you both for your help with understanding a bit more about UAC assignment and it's lifetime.

 

@jgoff, this command will help us greatly in finding fellow IT Staff in our building that I can bug to use as test cases to help with replication issues for TAC. :-)

---

(ac) #cluster-debug calc-sta-uac 5a:10:5e:5a:21:c9 TEST
STA Index:178
STA A-UAC:10.1.2.36
STA S-UAC:10.1.2.35
(ac) #

hth.

-jeff

---

---

I just wrote about this subject so let me add to what has already been mentioned. The entire process is as follows. CJ can correct any details that I'm wrong on. :-)

 

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, but lets just think about one for now)

 

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. (the hash is a simple formula, I think it is public knowledge, but just in case it isn't, I will not divulge it - CJ if  you know if it is, let me know and I'll come back here and explain it).

 

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.

 

Hope that puts the pieces together,

 

 

(I posted this earlier today, went to edit it, and somehow it got deleted, so here it is again)

 

I just wrote about this subject so let me add to what has already been mentioned. The entire process is as follows. CJ can correct any details that I'm wrong on. :-)

 

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, but lets just think about one for now)

 

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. (the hash is a simple formula, I think it is public knowledge, but just in case it isn't, I will not divulge it - CJ if  you know if it is, let me know and I'll come back here and explain it).

 

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.

 

Hope that puts the pieces together,