Cisco WLC 9800-L-F and Cisco suggested release images 17.12.3 & 17.9.5

[girish_gavandi]

Hello,

So, I was migrating very old wireless network devices (WLC 5508 and Ap 3602I) at a customer site. Customer purchased WLC 9800-L-F and C9136I-ROW AP. We decided to use 17.12.3 as the WLC software. The software being marked as Cisco suggested releases.

Further reference: https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/214749-tac-recommended-ios-xe-builds-for-wirele.html

Wireless network deployment at customer site is vanilla CWA deployment. Configured as per CWA Tech Notes.

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/213920-central-web-authentication-cwa-on-cata.html

There are 3 SSIDs (GUEST, VIP and EVENTS) configured for similar functionality but different access levels and privileges. All SSIDs are mapped to the same SVI interface. ISE authorization policy is defined based on called-station-id of the WLAN. All 3 SSIDs have similar config on WLC. However, upon testing it was found that all Android and iOS clients would not connect to GUEST SSID and could easily connect to VIP and EVENTS SSID. Mobile phone clients wifi page would show "connection failed" and it would not associate with the AP. But the other 2 SSIDs would have all clients connect to it as expected. No delays, no issues.

2 days of tshoot time was spent on it by my team and later 3 days with Cisco TAC. Tested every bit of configuration on WLC and ISE. In the end downgraded the WLC to next Cisco suggested release 17.9.5. Hoping this would fix any problems related to the new software. It was found that all iOS clients were connecting without any issues with GUEST SSID. Android clients still had same "connection failed" issue.

Collected more logs for the case notes and Cisco TAC is investigation the issue along with BU. It is very strange that 2 of the Cisco suggested software releases dont function even for basic CWA configuration.

It would be interesting to know the root cause. Anxiously waiting for TAC response. I shall post the update once available.

Meanwhile, if anyone has faced similar issues with 17.12.x or 17.9.x versions, please feel free to post their experience.

Regards,

Girish

[balaji.bandi]

Personally for production and validation tests i still suggest 17.9.5  with Cat 9K AP.

until you have latest Cat 9K AP which required 17.12.X i do not see any reason to go to 17.12.X

Is the Cisco TAC suggesting to 17.12.X  due to any of the issues found in your environment, that is different discussion.

17.9.5 with ISE 3.1 WLC 9800 Cat 9K AP - all good so far in production - my opinion.

[marce1000]

        >...Android clients still had same "connection failed" issue
   Start with a checkup of the WLC-9800-L=F configuration with the CLI command show tech wireless
   and feed the output from that into Wireless Config Analyzer  
   Use the full command as denoted in green ; do not use a simple show  tech for WirelessAnalyzer

   - Further engage in full client debugging according to https://logadvisor.cisco.com/logadvisor/wireless/9800/9800ClientConnectivity , these debugs can be analyzed with Wireless Debug Analyzer

  - For guest access look into : https://logadvisor.cisco.com/logadvisor/wireless/9800/9800CWA

- Look at client stats fom  https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/217738-monitor-catalyst-9800-kpis-key-performa.html#anc5   to get additional insights,

  M.

[Leo Laohoo]

We have officially dumped the train-wreck 17.9.X.  We are currently on 17.12.3 and transitioning to 17.12.4 and have installed the following APSP/SMU. 

C9800-universalk9_wlc.17.12.04.CSCwi78109.SPA.smu.bin
C9800-universalk9_wlc.17.12.04.CSCwj93876.SPA.smu.bin
C9800-universalk9_wlc.17.12.04.CSCwm48646.SPA.apsp.bin

[Rich R]

We were on 17.9.4 + SMUs + APSPs which worked fine and now on 17.12.4 + APSP1 also working fine so there's nothing fundamentally wrong with the software.

- Have you done a line by line comparison of the configs for each (working) WLAN and wireless profile policy for any differences compared to the non-working one?

- Why are you using SVI?  This should not stop it working but is not the recommended configuration for 9800 series WLCs.  Refer to Best Practices guide below.

- Are all your certificates registered public certificates (trusted by all current devices) which match the FQDN DNS names by which the site is being called? 

- Have you collected a browser trace on a device (eg Windows PC) and done packet captures to see what you see in the exchange with those clients?

- Have you turned OFF https webauth redirects (webauth-http-enable + secure-webauth-disable) - use http only for webauth? (9800 cannot cope with handling https)
See the "Configuring HTTP and HTTPS Requests for Web Authentication" section at https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-12/config-guide/b_wl_17_12_cg/m_vewlc_sec_webauth_cg.html

- Does your pre-auth ACL allow access to the CRL and OCSP servers for your certificates

[MHM Cisco World]

[Haydn Andrews]

Do the guest users recieve the captive portal? Im currently facing issue where the portal comes up but COA not being processed by WLC. TAC still investigating

[girish_gavandi]

Hi Haydn,

Guest users receive the captive portal. Not all the time. The issue is intermittent. We tried to reproduce the issue last Thursday, but no success. We will be giving it a try again this week.

Regards,

Girish

[balaji.bandi]

If this is intermittent, i would check the Routing and any other routing updates or any tpology changing which may have intermittent, depends on how the network connected ?

May be worth to send to syslog some debugs and check what is wrong.

[girish_gavandi]

Dear Balaji,

Routing is fine. The network setup is an existing. We replaced only the WLC. One SSID fails to work as expected and other work perfectly well.

We were also not able to reproduce the same issue. However, let me also mention that the issue lasted for almost a week before vanishing into thin air. Now that we cannot reproduce it, TAC is waiting for input or the case might get closed.

Regards,

Girish

[balaji.bandi]

May be if you had central syslog, you can look the logs, if this is not able to re-product, as cisco TAC one time issue. (so no evidence what causing)  - not much help here.. rather wait for another issue. or close this thread.

[girish_gavandi]

Dear Balaji,

Yes it looks like one time issue. So far no one is complaining who is connecting to faulty SSID. Will wait till this weekend for any recurrence of issue or try to re-produce the issue else will close the TAC case and end this thread too!

Regards,

Girish

[girish_gavandi]

Dear All,

After lot of failed attempts to recreate the issue, we have finally reached a stage to believe that it was a one time issue. All clients connected to all 3 SSIDs are connecting and working fine, as reported. We have closed the TAC case and also this post would mark the end of this thread as well.

It was super helpful getting all the expert suggestions from you all.

Many Thanks,

Girish

[ssaluga]

Hello Girish,

  I've got something similar going on here.  We were migrating from a 5508 (8.5.182) anchor scenario to the 9800-L-F (7.9.5).  We have 3 SSIDs, 2 of which are web-passthru and 1 is a PSK.  All clients work as expected on any of the SSIDs except for Android clients.  Android is extremely intermittent.  Android clients will sometimes get the splash page and can reach some websites but not others.  I'll be opening a TAC case soon to do further troubleshooting and update here with any progress.

Scott

[girish_gavandi]

Hi Scott,

We also had similar issue, it lasted for almost a week and now we cannot reproduce it. Seems to be working fine for all the clients who are connecting to the faulty SSID and other working SSID. We are also running version 17.9.5.

I would suggest to check for any RADAR activity and any channel changes in the log messages.

Regards,

Girish