WLAN clients can't communicate since update from 17.3.3 to 17.3.4c

[Bernd Nies]

Hello,

We have Catalyst 9800-40 WLAN controllers and 90 Catalyst 9120AXI access points. Three weeks ago we upgraded from 17.3.3 to 17.3.4c. But instead of fixing a bug, it got exchanged with a new one: Since then all the WLAN clients can't communicate with each other. The WLAN is configured for central switching. Now it behaves like peer-blocking is enabled, but we had it disabled on purpose. It's an office wlan with 802.1x authentication and not a public wlan. Connectivity between wireless and wired LAN works fine.

Traffic analysis shows that the access point does not reveal the MAC addresses of other WLAN clients when one wants to reach them. Even two clients connected to the same access point can't communicate to each other.

Anyone else having this issue or are we the first one to upgrade to 17.3.4c?

Regards,

Bernd

[Rich R]

Incredible!

[marce1000]

 - Depending on business need and or urgency , you may have a go with the current recommended release : https://software.cisco.com/download/home/286316412/type/282046477/release/Amsterdam-17.3.5a

 M.

[Bernd Nies]

Meanwhile we're on 17.3.5a on the backup WLC with two APs for testing. The issue still persists there.

[marce1000]

- Add info to TAC ticket

M.

[marce1000]

 - Also while waiting for Cisco solution always useful is to have a configuration check : with show tech wireless and have the output processed by ,    https://cway.cisco.com/tools/WirelessAnalyzer/         , note that this tool needs the mentioned command in green , not the traditional and well known show tech-support command  , I know all of this  this can not be  the cause because the problem was introduced by an upgrade. But the review is useful and could provide hints and or other configuration suggestions too.

 M.

[Bernd Nies]

Hi,

Workaround seems to be using the VLAN ID instead of the UI dropdown suggested VLAN name in the wireless profile policy. That was working with IOS XE 17.3.3.

As soon as I changed it on the backup WLC (now IOS XE 17.3.5a) and tested with two notebooks connected to one AP, they could ping each other again. When moving the notebooks to an AP managed by the primary WLC without this fix, they can't ping each other again.

Regards,

Bernd

[marce1000]

 - After this , you can for instance  again have a final review of the controller configuration ,   for that use  CLI show  tech wireless , have the output analyzed by  https://cway.cisco.com/tools/WirelessAnalyzer/  , please note do not use classical show tech-support (short version) , use the command denoted in green for Wireless Analyzer

 M.

[Rich R]

Thanks for the update @Bernd Nies 

Were these VLANs locally switched or centrally switched? (I'm assuming local switching)

If locally switched then you would need to define any VLAN names in the flex profile - was that done?  The dropdown will usually only show centrally defined VLANs which are only relevant on the WLC and the AP has no knowledge of those names.  That would only work (by coincidence or design) if you defined the identical name on WLC and also in the flex profile.

Otherwise it's best to always simply use the VLAN ID rather than names for locally switched VLANs - avoids any confusion or ambiguity with names.

[Bernd Nies]

The VLANs are centrally switched. It was defined with name in the wireless profile policy and not in the flex profile. The names of course matched and it was working in 17.3.3.

vlan 119
 name wifi-office

wireless profile policy WLAN_Office_ZH
 aaa-override
 aaa-policy "Cisco ISE AAA Policy"
 autoqos mode enterprise-avc
 description "Office WLAN in Zurich, Switzerland"
 dhcp-tlv-caching
 exclusionlist timeout 180
 http-tlv-caching
 idle-timeout 3600
 ipv4 flow monitor wireless-avc-basic input
 ipv4 flow monitor wireless-avc-basic output
 ipv6 flow monitor wireless-avc-basic-ipv6 input
 ipv6 flow monitor wireless-avc-basic-ipv6 output
 passive-client
 radius-profiling
 service-policy input platinum-up
 service-policy output platinum
 session-timeout 43200
 subscriber-policy-name BUILTIN_AUTOCONF_POLICY
 vlan wifi-office
 no shutdown

Also the cli suggests to use a word and not a numerical ID:

wlc1(config-wireless-policy)#vlan ?
  WORD  Enter Vlan

Cisco referred to the following bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvn48234

But the description does not mach the issue we had. Networking between WLAN and wired LAN worked well. Only between WLAN clients the ARP requests were not answered.

[Rich R]

Interesting!

I think that bug is unrelated. It's not clear from the notes but I think that is the locally switched case I was referring to which is messy but "by design".

Definitely sounds like a new bug to me.

[Bernd Nies]

Joy was premature. It worked only from the notebook I tested yesterday. Today users report, the problem still persists. WLAN clients still can't reach each other ... The Cisco TAC odyssey continues ... Yay!

[Rich R]

Oh dear! Good luck  

Out of interest have you tested with 17.6.3?

[Bernd Nies]

No. We have a bunch of Aironet 2700 and 2800 APs in the branch offices that we would like to migrate away from old WLC 2404. IOS XE 17.3.x is the last release to support these. Plus I've learned the hard way only to use the suggested releases marked with a star in the download portal.

[marce1000]

             - What is the business need for the inter-client communication ?

 M.

[Bernd Nies]

We have all printers in WLAN because we are not allowed to install LAN cables. And we have developers doing all kind of things on their notebooks (Linux virtual machines, installing application servers for testing, etc).