Clients are prompted to re-login to the LightSpeed content filter while roaming from an AP to another

Summary

This article explains why the clients would have to re-login to the LightSpeed content filter while roaming between AP's and how to resolve this issue.

Question

Why users are prompted to re-login to the LightSpeed content filter while roaming from an AP to another

Customer Environment

ZD/APs running 9.12 802.1x WLAN. CloudPath Server used for Client Onboarding and Authentication, LightSpeed Content Filter Firewall used for Accounting,

Root Cause

The problem was isolated to the attribute being used to monitor client as it roams from one AP to another. The attribute used by the Content Filter/Accounting-Server should be unique as "t=Acct-Session-ID" and not like "t=Framed-IP-Address"(which is common in both packets). Using this, Accounting Server should be able to differentiate the two unique Acct-Session-ID’s 596B2BDE-1CCD7 and 596B2BDE-1CD0F and should only Stop the session for 596B2BDE-1CCD7 which is no longer active.

Troubleshooting Steps

History:
Clients were reporting an issue of getting logged out on their content filter/firewall when they are roaming between AP’s. Customer was using Cloud Path for client onboarding and LightSpeed Server for Accounting. LightSpeed does client health check-ups initially and provided internet access to the users. It later rely on accounting packets received from ZD to permit users to continue to browse internet. Once an accounting stop is received, client is logged out and have to re-login to be able to browse.

Debugging:
What we noticed from the debug, on every roam event, there is an Acct-Start with new Session-ID for the new AP and an immediate stop packet for the old access point with Old Session-ID. Moment the Stop packet is received, the client is logged out. The behaviour was replicable at every roam event.

From the captures, we see that client when roamed from an AP1 to another AP2, there is a new Accounting-Start message for the AP2, with a New Acct-Session-ID (596B2BDE-0001CD0F) and a Unique Multi-Session-ID (Acct-Multi-Session-Id: 743e2b932abd98e0d9df9a6758f50a39e56a).
User-added image

<Snipped from ZD debug logs>
Apr 17 14:02:17 ZD3000 stamgr: stamgr_sta_roaming_handover():accounting start
Apr 17 14:02:17 ZD3000 stamgr: accounting_sta_start():accounting start, the station ipv4 adress is fb41010a, the ipv6 address is 0-0-0-0
Apr 17 14:02:17 ZD3000 stamgr: stamgr_sta_is_valid_ip():User(98:e0:d9:df:9a:67) IPv6 address invalid.
Apr 17 14:02:17 ZD3000 stamgr: accounting_sta_start():98:e0:d9:df:9a:67 accounting start, started 0
Apr 17 14:02:17 ZD3000 stamgr: stamgr_dm_sta_insert_entry():sta 98:e0:d9:df:9a:67 sess-id 596B2BDE-1CD0F inserted
Apr 17 14:02:17 ZD3000 stamgr: accounting_sta_start():Insert sta 98:e0:d9:df:9a:67 with sess-id 596B2BDE-1CD0F

Subsequently when the Accounting Stop is sent, there is a Different Acct-Session-ID (596B2BDE-0001CCD7) associated for AP1 along with Unique Multi-Session-ID (Acct-Multi-Session-Id: 743e2b932abd98e0d9df9a6758f50a39e56a).

User-added image

<Snipped from ZD debug logs>
Apr 17 14:02:17 ZD3000 stamgr: stamgr_sta_roaming_handover():setting acct_termination_cause to LOST_SERVICE
Apr 17 14:02:17 ZD3000 stamgr: stamgr_STA_put():free sta: 0x0ab48e00, sta_info: 0x0b00fca0, MAC: 98:e0:d9:df:9a:67
Apr 17 14:02:17 ZD3000 stamgr: ap_free_sta_struct():ap_free_sta_struct: calling accounting_stop for station= 98:e0:d9:df:9a:67
Apr 17 14:02:17 ZD3000 stamgr: accounting_sta_stop_impl():Accounting for 98:e0:d9:df:9a:67 is stopped.
Apr 17 14:02:17 ZD3000 stamgr: stamgr_dm_sta_remove_entry():sta sess-id 596B2BDE-1CCD7 removed
Apr 17 14:02:17 ZD3000 stamgr: accounting_sta_stop_impl():report accounting stop for 98:e0:d9:df:9a:67 with cause 3

This is an expected behavior for an AP to send an Accounting-Stop for user association for AP1 which is no longer active. However it is the responsibility of the content filter to look for an appropriate Session-ID when Accounting-Stop is seen and should terminate only the session associated to the Accounting-Stop and continue to allow the New client session with newer Session-ID.

Workaround

Alternatively we can enable roaming-acct-interim-update on the WLAN from ZD's CLI. "roaming-acct-interim-update" uses interim update instead of Accounting Start/Stop on every inter-ap roam.

Note:This option is disabled by default.

CLI to enable roaming-acct-interim-update on the WLAN.
ruckus# config
You have all rights in this mode.
ruckus(config)# wlan "WLANX"
The WLAN service 'WLANX' has been created. To save the WLAN service, type 'end' or 'exit'.
ruckus(config-wlan)# roaming-acct-interim-update
The command was executed successfully. To save the changes, type 'end' or 'exit'.

Please run #show command to confirm if changes are applied:

ruckus(config-wlan)# show
<snipped>
NAS-ID Type= wlan-bssid
      Roaming Acct-Interim-Update= Enabled
      PAP Message Authenticator = Enabled
      Send EAP-Failure = Disabled

Article Number:
000006353

Updated:
June 19, 2017 10:44 AM (over 7 years ago)

Tags:
Configuration, Troubleshooting, Known Issues and Workarounds, ZoneDirector

Votes:
0

This article is:
helpful
not helpful