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]

Understood re:2700.  Note 2800 are still fine on 17.6 which we have found to be very stable so far.   17.6 is the next extended support release too so only a matter of time before it gets the star.

And as we've seen with 17.3 the star releases can actually end up having serious problems although they are a good overall guideline.

[ksoltani]

in the Wlc cisco go to Configuration Tag and profiles --->Wlan 

check the option P2P Blocking Action

[Bernd Nies]

That's not it. P2P blocking was disabled in IOS XE 17.3.3 and worked then. It stopped working with update to IOS XE 17.3.4c because he WLC does not answer the ARP requests from the clients or APs when a WLAN client wants to connect another WLAN client.

[Bernd Nies · Accepted solution]

Summary: This was finally the fix that brought intra WLAN client comminication back to life after the update:

=======================================|=====================================
C9800-40, IOS XE 17.3.3  (working)     | C9800-40, IOS XE 17.3.5a (working)
C9800-40, IOS XE 17.3.4c (not working) |  
=======================================|=====================================
                                       | vlan configuration 115,118-119,900
                                       |   arp broadcast
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
interface Vlan119                      | interface Vlan119
  description mDNS snooping            |   description mDNS snooping
                                       |   no ip proxy-arp
  ...                                  |   ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wireless profile policy WLAN_Office    | wireless profile policy WLAN_Office
  vlan office                          |   vlan 119
  ...                                  |   ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Rich R]

Interesting - thanks @Bernd Nies 

Is this something they're saying is "by design" or they intend to fix?

[Bernd Nies]

They didn't tell so far.

[marvin.reyes1]

TL/DR: Solution is to enable ARP Broadcast on the VLAN (Configuration>Layer2>VLAN) -OR- Use the VLAN ID rather than Name from the dropdown menu in the policy configuration (Configuration>Tags&Profiles>Policy | Edit Policy Profile>Access Policies: VLAN/VLAN Group)

I recently encountered this issue, and we were running 17.3.5a already, with P2P disabled. After trying a number of things, I found this post and tried implementing the solution - which worked! Effectively, configure arp broadcast on the VLAN(s) in question, create the VLAN interface and configure no proxy arp, and then set the Policy Profile to use the VLAN ID rather than the named VLAN from the dropdown.
I was curious at which point this issue was actually resolved, so I set everything back to the way it was and tried changing these settings, one at a time.

I started with enabling ARP Broadcast in the VLAN configuration and this immediately resolved the issue, with no other settings changed. So I reverted that change and went straight to the Policy Profile configuration and set the VLAN to "160" rather than "Wireless_Clients" and this also resolved the issue on its own. Therefore, I would say the quick fix is to simply enable ARP broadcast on the VLAN on the WLC if you *must* use it. Otherwise, it may be best practice - depending on your wireless environment - to simply use the VLAN ID rather than a dropdown option. It removes some control from the WLC, but in turn, removes that overhead.
Note: you still need the L2 VLAN in place, for local-mode environments, like in my case (but do not need to have ARP broadcast enabled if you are using the VLAN ID in the policy profile).