Wireless Access

I'd like to revisit this old entry on COTD.

 

I've been reading this at CRG6.2 page 96:

"When this feature is enabled, the controller actively sends probe packets to all users with the same MAC address but different IP addresses. The users that fail to respond are purged from the system. This command enables quick detection of multiple instances of the same MAC address in the user table and removal of an “old” IP address. This can occur when a client (or an AP connected to an untrusted port on the controller) changes its IP address."

 

And COTD 2009 says it is ICMP packets sent to confirm the user presence:

http://community.arubanetworks.com/t5/Command-of-the-Day/COTD-aaa-user-fast-age/td-p/4098

 

I might be understanding it wrong since many people call "probes" to simple ICMP echo requests, but, shouldn't it be interpreted as the controller sending 802.11 management messages (PROBES) to both 802.11 clients appearing under the same mac? I mean, if it is ICMP based it would never work with Windows firewall enabled (which is by default).

 

Thanks!

In ArubaOS 6.2, ICMP is no longer used to age out users.

Based on what an aruba engineer explained to me the way it works now is that once the controller doesn't receive any 802.11 communication(station timeout under the SSID profile , default values is set to 1000 secs) back from the device then it will try to ping it (user-timeout values) and if both are non-existent the device will be remove from the user-table

Let me both review what the command actually does: it is supposed to be used when there are duplicate mac entries in the user database so the old one is deleted ASAP. Prior to v6.2, it used to PING both reported IP addresses. Now it does something else less dependant on FW rules associated to the user role.

 

Am I right?

 

But I still do not know how it is done now on v6.2 which is actually one of the two (5.0.4.11 and 6.2.0.3 are the ones) I am particularly interested. I enabled it on v6.2 because there where some issues with roles being inherited from previous authenticated users who shared the same IP on the enrollment SSID. Bit it did not help at all. Still duplicate MACs potentially leading to role miss-appropiation from yet to be enrolled users.

 

I believe it has something to do with roles being associated to the IP address on captive portal authentication, but shouldn't "aaa user fast-age" take care of the "old" enrollment entry as soon as the enrrolled device connects to the corporate SSID?

 

 

I think you should focus on your problem, and not the command.  What is your problem specifically?

 

I do have a case opened with Aruba TAC regarding the issue itself, but I wanted to know about the feature as I intended to use it as a workaround on the first place but never behaved as I expected.

 

I was given an answer on this same question by the first assigned engineer, but I did not find it detailed enough and as you suggested, soling the main issue was the priority. Hence the question here.

 

So, could you please detail the behaviour of the command as much as you can without breaking NDAs of any propietary features you might want to keep secret?

There is nothing to explain behind the command more than what was in the COTD, however, it does not cure everything.  There are ways to end up in the situation that you are in, even with the command enabled.  It is time consuming to go down that list and guess what your problem is.  That is why I asked what is your issue.

 

If you have a case already open with TAC, they can get much more detailed information about your network than you can reveal here, so they probably have the best chance of solving your problem.

May I insist on detailing a little further on the command? Is actually ICMP based only prior to v6.2 and 802.11 mgmt frames from v6.2? Which mgmt frames (http://dot11.info/index.php?title=Chapter_4_-_802.11_Management_frames)? Is it based on timeout and passive monitoring of mgmt frames or any kind of active scanning to find out if the user is still there?

 

I do not want to fix my problem here (that is what TAC is meant for), but to fully understand the command I expected would work. Could you please help me on that?

Thank you for your patience.

 

Fast-Age in general kicks in when a new ipv4 address comes in for a mac address that already exists.  In 6.2 we simply delete the ipv4 address without pinging it.

So no further probing after seeing a new incoming connection from an old mac? Makes sense. Then it should have worked as I expected. Not happy since it might mean we hit a bug or something. Anyway, thank you very much.

 

BTW, thanks for your help over the years. Your COTDs have been always very usefull.