Do you have a primary, seconday and or tertiary wlc configured on each of these h-reap ap's? It looks like the ap lost connectivity to the wlc it's primary to and moves to either the secondary or tertiary. Do you have ap fallback enabled on the wlc's also to force the h-reap ap to move back to the primary wlc? Do you have network connectivity still when these h-reap ap's move and what is the ping times between the h-reap ap and teh wlc's?
Under "Access Points" on the left, choose "Global Configuration."
In the main panel off to the right you will see "AP Retransmit Config Parameters" with 2 options: "AP Retransmit Count" and "AP Retransmit Interval."
AP Retransmit Count is how many times it will try to contact a WLC before failing. Maximum is 8.
AP Retransmit Interval is how long between each try. Maximum is 5.
(AP Retransmit Count) * (AP Retransmit Interval) = How long the AP can go without talking to a WLC, in seconds.
If you are using FlexConnect Local Switching and FlexConnect Local Auth, the AP SHOULD still be able to handle clients during this timeframe.
When an AP cannot contact a WLC...
Step 1.) When the retransmit count (max 8, with a max 5 second interval, so 40 seconds max) is exceeded, the AP goes into Standalone mode (similar to Autonomous) and tries to contact a WLC via its static IP for apprx 5 minutes.
Step 2.) If unsuccessful, the AP switches to DHCP, renews the DHCP lease (to get a new IP address) and tries again to contact a WLC for apprx 3 minutes. This repeats 3 times, for a total of apprx 9-10 minutes.
Step 3.) If after step 2 the AP could still not find a controller, the AP reboots itself and starts at Step 1 all over again. Reboot takes apprx 2-3 minutes.
Note if using DHCP addresses, the process may start at Step 2.
Yes, the maximum time an AP can be out of contact with its WLC then is 40 seconds. If you're just using CAPWAP to configure and reconfigure APs which are otherwise nearly autonomous, this can be quite the annoying level of neediness.
"Who can tell me the reason for this behaviour?"
I believe this behaviour is to ensure management capability, and also to support some of the more "interesting" (for lack of a better term) reasons for CAPWAP... maybe wireless client mobility, remote switching, remote authentication, etc. In those scenarios you DO want your APs to be "needy."
Message was edited by: Mark Withers - not mesh... -
No downtime from adjusting them in my experience. It just adjusts a couple counter thresholds, so I can't imagine it would need to do anything to the radio.
However, lower values combined with unreliable network availability of the WLCs will likely result in more downtime/reboots. However, if you're doing central switching, lower values may actually REDUCE downtime by allowing the AP to reconnect more rapidly.
With static IPs and local switching, and using the WLC almost exclusively to manage AP configs... we really wish we could crank these values up to about 10x what's allowed, as any value was way too frequent for us. :(
< PRE >
(#)For this reason being that : - application that doesn't use multicast, sends one copy of each packet ( data unit of traffic at layer 3 ) to each client (" who seeks the traffic ).- application that does use multicast, sends ...
Transferring Crash file from standby:
Login to the Active WLC in HA.
(Cisco Controller) >transfer upload datatype crash
(Cisco Controller) >transfer upload filename <Desired filename>
(Cisco Controller) >transfer up...
This is the start of a display filter cross reference between Wireshark and OmniPeek.
The 1st installment is a table of advanced filters. More filters will be added as time allows.
It is a living doc, so check back for changes every so often
Please feel ...