Wireless Access

I'm looking for our RADIUS server have visibility into which AP a client is using. I can change the called-station-id to include the AP's mac address or name, which works for the initial connection. But we lose visiblity as a client roams between APs. Ideally, we would receive an Accounting-Stop with the old AP's called-station-id, and an Accounting-Start with the new information. Is this possible somehow?

 

Thanks!

 

Norman

The radius request contains an attribute called Aruba-Location-ID which contains the same of the access point.

Indeed. Identifying the access point seem doable (using the RADIUS attributes that are provided). The trick is that we don't get any RADIUS notification when a client roams from one AP to the next. I was hoping this would count as a new session, causing an Accounting-Stop + Accounting-Start. Or is there some other notification that is fired off on a roam?

Normelton,

 

By default OKC ( Opportunistic Key Caching) is enabled in the 802.1x profile so that devices do not have to do a full radius authentication when they roams.  This decreases roam times and improves application performance.  Many devices support OKC so finding out where  a user roams and why is not possible for these clients, because they do not query the radius server.  Radius accounting does not indicate when these users roam, either, so looking at radius cannot be used.  The question is, what are you trying to accomplish?  If you are simply looking at when a user roams, you should use the "show ap client trail-info <mac address>" command:

(MyHost) #show ap client trail-info c4:cf:f6:07:45:77

Client Trail Info
-----------------
MAC                BSSID              ESSID     AP-name         VLAN  Deauth Reason                    Alert
---                -----              -----     -------         ----  -------------                    -----
c4:cf:f6:07:45:77  d8:c7:c8:81:9e:31  ACME-TLS  Livingroom-135  1     Sapcp Ageout (internal ageout)   Sapcp Ageout (internal ageout) 

Deauth Reason
-------------
Reason                           Timestamp
------                           ---------
Sapcp Ageout (internal ageout)   Feb 28 11:21:36
Internal deauth                  Feb 28 10:38:59
STA has roamed to another AP     Feb 28 10:38:59
STA has roamed to another AP     Feb 28 09:57:20
Num Deauths:4

Alerts
------
Reason                           Timestamp
------                           ---------
Sapcp Ageout (internal ageout)   Feb 28 11:21:36
Internal deauth                  Feb 28 10:38:59
STA has roamed to another AP     Feb 28 10:38:59
STA has roamed to another AP     Feb 28 09:57:20
Num Alerts:4

Mobility Trail
--------------
BSSID              ESSID     AP-name         Timestamp
-----              -----     -------         ---------
d8:c7:c8:81:9e:31  ACME-TLS  Livingroom-135  Feb 28 11:21:36
d8:c7:c8:81:9e:31  ACME-TLS  Livingroom-135  Feb 28 10:38:59
d8:c7:c8:81:9e:31  ACME-TLS  Livingroom-135  Feb 28 10:38:59
9c:1c:12:90:5d:91  ACME-TLS  Office-225-2    Feb 28 10:38:59
9c:1c:12:90:5d:91  ACME-TLS  Office-225-2    Feb 28 09:57:20
9c:1c:12:90:5d:81  ACME-TLS  Office-225-2    Feb 28 09:57:20
9c:1c:12:90:5d:81  ACME-TLS  Office-225-2    Feb 28 09:57:02
Num Mobility Trails:7

 

Colin -

 

Thanks for your note. Our RADIUS server records users moving about the network, presenting everything on our management console. This works great on our switches, we see the switchport / building / room, etc. On our controller-less access points from a competing vendor, we see which AP they're connected to. These particular APs do a single RADIUS authentication transaction, then OKC for roaming. But when a user roams, we get a RADIUS accounting transaction informing us of the roam. We use this to keep our database up-to-date.

 

Ideally, the Aruba controller would do a single RADIUS authentication request, then keep us updated with accounting transactions during roam events.

 

It doesn't seem like this is possible (unless I'm missing something here...). Is there some other notification that can be used to observe client roams? I suppose we could hack it together from an SNMP trap or something.

 

Thanks

 

Norman

Norman,

 

A "System" issues a radius accounting "Stop" when a device leaves the "System".  With autonomous APs, I think that the "System" is contained within single APs, so APs issue starts and stops as users roam.  In a centralized system, the controller considers every access point under the same "System" so that it only issues a radius Stop when a user leaves that system of APs.  With that being said, we can enable logging so that users register roams under syslog.  Would that work?

 

 

Colin -

 

Understood. I've got syslogging turned up pretty high, let me do some testing to see if I can capture the correct message and trigger off of that.

 

Thanks!

 

Norman

do this:

 

config t
logging level debugging user-debug <mac address of user>

 You should then be able to type:

show log user-debug all

 And you should see things like this for that user:

Dec 18 13:00:37  stm[1771]: <501080> <NOTI> |stm|  Deauth to sta: 80:86:f2:3b:f4:70: Ageout AP 10.1.1.190-6c:f3:7f:ee:5c:30-2NAP03-225 STA has roamed to another AP
Dec 18 13:00:37  stm[2049]: <501105> <NOTI> |AP 2NAP03-225@10.1.1.190 stm|  Deauth from sta: 80:86:f2:3b:f4:70: AP 10.1.1.190-6c:f3:7f:ee:5c:30-2NAP03-225 Reason STA has roamed to another AP
Dec 18 13:00:48  stm[1771]: <501080> <NOTI> |stm|  Deauth to sta: 80:86:f2:3b:f4:70: Ageout AP 10.1.1.149-6c:f3:7f:ee:57:30-2NAP04-225 STA has roamed to another AP
Dec 18 13:00:48  stm[2025]: <501105> <NOTI> |AP 2NAP04-225@10.1.1.149 stm|  Deauth from sta: 80:86:f2:3b:f4:70: AP 10.1.1.149-6c:f3:7f:ee:57:30-2NAP04-225 Reason STA has roamed to another AP

 If you are syslogging to an exernal server, you should see those messages in your syslog for that specific user.  

 

To do debug for all users (pretty verbose):

 

config t
logging level debugging user

 Then to show the logs:

show log user all

 

 

Just out of curiousity, wouldn't the controller do something AirGroup-related during a 11r/OKC roam to keep location-based airgroup policies enforced?  Or is that all handled through RFC3576 directly from ClearPass and/or with non-RADIUS mechanisms?

 

Only if "airgroup cppm-server enforce-registration" was enabled.