Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

Cisco CAPWAP AP stuck in Discovery

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Cisco CAPWAP AP stuck in Discovery

L1 Bithead

Hi All,

 

Has anyone had problems with CAPWAP AP's separated from the WLC by a PA-220 firewall get stuck in a DISCOVERY OperationState?

 

>show capwap client rcb
AdminState : ADMIN_ENABLED
OperationState : DISCOVERY
Name : ***
SwVer : 8.5.151.0
HwVer : 1.0.0.0
MwarApMgrIp : 10.1.1.2
MwarName : CISCO-LWAPP-CONTROLLER
MwarHwVer : 0.0.0.0
Location : ***
ApMode : FlexConnect
ApSubMode : Not Configured
CAPWAP Path MTU : 1421
CAPWAP UDP-Lite : Enabled
IP Prefer-mode : IPv4
AP Link DTLS Encryption : OFF
AP TCP MSS Adjust : Enabled
AP TCP MSS size : 1250
LinkAuditing : disabled
Efficient Upgrade State : Disabled
Flex Group Name : ***
AP Group Name : default-group
Cisco Trustsec Config
AP Inline Tagging Mode : Disabled
AP Sgacl Enforcement : Disabled
AP Override Status : Disabled

 

If I do a clear session all filter source <IP of AP> the AP will shortly come online again so it does appear to be the PA220 that's causing the problem.

 

>show capwap client rcb
AdminState : ADMIN_ENABLED
OperationState : UP

 

Even when the AP is offline I can ping the WLC just fine and interestingly if I add application capwap to the clear session filter it doesn't come back up.

 

We did create an application-override rule for the capwap traffic but that hasn't helped and since clearing on the capwap session doesn't help and there isn't any other session from that IP I am very confused.

 

Thanks in advance for any suggestions will also open a TAC case but they seem to take so long to respond these days with COVID and all.

Kevin

6 REPLIES 6

Cyber Elite
Cyber Elite

@KevinJB,

You honestly shouldn't even need an application-override entry to keep this operational and have it identified properly. CAPWAP is easily enabled solely by setting the application as capwap and setting the service to application-default without any sort of override in place. You aren't performing any sort of NAT on the traffic are you? 

Nope, there is no NAT occurring to this traffic, it gets back to the WLC via a IPSec SDWAN Tunnel. Interestingly from the debugs it would appear the WLC is receiving the join from the client, it's the reply that never makes it back to the AP. Also since this was usually affecting one AP in particular I tried shutting down that one AP yesterday, but the problem just reoccurred on a different AP later that day.

Cyber Elite
Cyber Elite

@KevinJB,

So if the CAPWAP join request doesn't get a response that AP should sit there and continue to try and restart that CAPWAP discovery and join process repeatedly. Is the WLC not responding to any of those further join requests? I would take a capture from the WLC and see if it's responding to those join requests at all or not. 

L0 Member

@KevinJB I'm having the same issue you're describing over SDWAN on a PA-220. Were you able to get it working?

Exact same situation, we had to create an application override:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVLCA0


create an objects -> applications called capwap-override

Under Advanced Tab, Scanning untick all (maybe default?) - file types, viruses and data patterns

and then under policies -> application override create:

capwap-override

Source Zone: name of zone your AP's are in

Destination Zone: zone-to-hub

Destination Address: IP of WLC

Protocol/Application:

UDP

Port: 5246-5247

Application: capwap-override

 

However after this we are still having some weird issues with wireless but having difficulty nailing down if they are related to connection reliability or more widespread so keen to hear back on your experience after making these changes.

Thanks for the information.  Since the issue for us only started after we added a 2nd internet circuit, on the SDWAN policy, we classified CAPWAP  traffic to use a Top Down traffic distribution profile instead of best availability and it is working fine now. 

 

Policies>SDWAN

 

capwap SDWAN policy

SourceZone:  zone where your AP is

Source address:   IP of your AP

Destination address:  IP of WLC or Any

Application:  capwap

 

Not sure how your connections are configured but this seemed to work for us.

 

 

 

  • 9651 Views
  • 6 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!