Users with limited connectivity after connected for a period of time

[Daniel Alejandro Castro Henriquez]

Users have the following issue, after being connected for a couple of hours and having full connectivity they fall into a limited connectivity and cannot ping their default gateway. The only workaround for this is that users disconnect and reconnect to the SSID. Session timeout is disabled and  Cisco's WLC best practices are deployed for this platform. Have you ever encountered this issue?

Regards.

[Rasika Nayanajith]

what version of a software running on your WLC ? Pls provide "shwo sysinfo" output

Also what type of clients experience this, all clients or specific type of clients ?

HTH

Rasika

[Daniel Alejandro Castro Henriquez]

Hi Rasika,

Any notebook client may have the problem, independent oh its Operative System, on smartphone and tablets have no reported the issue.

Attach de info.

WLC 7510 in HA.

(Cisco Controller) >show sysinfo

Manufacturer's Name.............................. Cisco Systems Inc.
Product Name..................................... Cisco Controller
Product Version.................................. 8.0.121.0
RTOS Version..................................... 8.0.121.0
Bootloader Version............................... 7.4.100.0
Emergency Image Version.......................... 7.4.100.0

Build Type....................................... DATA + WPS

System Name...................................... WLC_FLEX_PRINCIPAL
System ObjectID.................................. 1.3.6.1.4.1.9.1.1295
Redundancy Mode.................................. SSO
IP Address....................................... 10.202.15.122
IPv6 Address..................................... ::
System Up Time................................... 164 days 13 hrs 33 mins 9 secs
System Timezone Location......................... (GMT -3:00) Buenos Aires (Agentina)
System Stats Realtime Interval................... 5
System Stats Normal Interval..................... 180

--More-- or (q)uit
Configured Country............................... US - United States
Operating Environment............................ Commercial (10 to 35 C)
Internal Temp Alarm Limits....................... 10 to 38 C
Internal Temperature............................. +21 C
Fan Status....................................... OK

RAID Volume Status
Drive 0.......................................... Good
Drive 1.......................................... Good

State of 802.11b Network......................... Enabled
State of 802.11a Network......................... Enabled
Number of WLANs.................................. 45
Number of Active Clients......................... 25636

Burned-in MAC Address............................ 64:9E:F3:65:00:20
Power Supply 1................................... Present, OK
Power Supply 2................................... Present, OK
Maximum number of APs supported.................. 6000
System Nas-Id.................................... WLC_FLEX_PRINCIPAL
WLC MIC Certificate Types........................ SHA1

[pwwiddicombe]

Some wireless WAN adapters  have "power saving" options that may be powering off the WAN adapter if there is a period of inactivity... ?

[Michael Combs]

Hi Daniel,

Even when session timeout on a WLAN is "disabled," it really just means that the session timeout is set to 24 hours. A couple considerations to mull over. For one, I'd look into possibly upgrading your WLC code to a more recent release as there have been quite a number of bug fixes. A list of TAC/HTTS recommended WLC codes by AireOS code train (i.e. 8.0, 8.2, etc.) can be found at the below URL, which is frequently updated:

https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-TAC-Recommended-AireOS.html?cachemode=refresh

The other option is to roll up our sleeves and troubleshoot this scenario directly, and pin it down either to a bug on the WLC/AP side, the client side (WLAN driver, supplicant, etc.), or a combination of the two. To do so, I'd recommend opening a TAC case for this issue and upload the following collected information once you reproduce the issue as reported:

1. Save the following CLI session output to a text file from your WLC in question (may take some time to complete):
• config paging disable
• show run-config
• show msglog
• show traplog
2. While reproducing the issue, collect an over-the-air (OTA) packet capture taken in close proximity to the client under test at all times. Make certain that the sniffer is NTP synchronized.
3. While reproducing the issue, collect a Wireshark capture off the wireless interface on the test device (say a Windows laptop or MacBook). Make certain that the PC is NTP synchronized with the other sniffer.
4. At the same time that the above packet captures are being collected, get the following debug output from the WLC, as saved to a text file:
• config sessions timeout 0
• config paging disable
• debug client <MAC-address>
• debug dhcp message enable
• show client detail <MAC-address>
• Note: execute this last command every 15 seconds or so during the test
5. Be sure to include the exact time the issue occurred, what the symptoms were, and full details about the client device that was used during the test (i.e. make/model, OS version, WLAN adapter model, WLAN adapter driver version, etc.).

Depending on what the above captures and debugs show, additional debugs or packet captures (such as a span session upstream) may need to be collected in a subsequent test. However, this will definitely get you started down the path to pinpointing the root cause for this issue. Though you could upgrade your WLC first as detailed above, then if the issue persists, collect this information and raise a TAC case accordingly.

Dealer's choice, as it best fits your requirements and procedures.