08-19-2014 07:34 AM
So it turns out your Controller needs the 6.4 code to support the new 205 WAPs. the code was released in June, so I am currious if anyone currently has this code and if so have they encountered any issues. Thanks
08-19-2014 08:53 AM
08-19-2014 10:39 AM
It's been mostly good to us. We've had some minor problems with wired AP ports, a few WiFi issues
that only affect a small handful of consumer-grade clients, and if you go to the HA setup, you
may have to run without inter-controller heartbeats turned on for a few revs. (we have TAC working
on all these issues.) Also AirWave is still catching up to it in places so have TAC retune your settings
especially WRT AMON vs SNMP.
That said, I've not much to compare it to since this was our first rev of code.
08-20-2014 12:05 PM
ACDX #420 | ACMP
[If you found my post helpful, please give kudos!]
08-20-2014 12:14 PM
Yes AMP 8.0.x
They went in and tweaked way too much stuff for me to keep track and made sure everything was using the most well-worn channels (no "prefer AMON", ensured the configs are being collected through a screenscrape shell.) IIRC fetcher rate limits, VisualRF resource allocatuons, and a few settings on the system prefs were the more "tuning" oriented items.
08-20-2014 07:12 PM
may have to run without inter-controller heartbeats turned on for a few revs.
I noticed the night I turned on HA that there was an event where the heartbeats seemed to fail for no reason. Is it best to turn off the heartbeat command in the ha profile for now?
08-20-2014 08:08 PM
We found we needed to turn off the heartbeats because APs kept getting failover requests from the controllers, and TAC is looking over our setup and the data we've gathered from it to see why; It doesn't look like, if there is acual packet loss, it should be enough to trigger the events. At the same time, replication of our setup at the TAC has not managed to recreate the behavior in the lab.
If you turn off the heartbeats, you still get HA failover with redundant pre-constructed tunnels from the APs, but only missing AP-to-controller heartbeats will trigger events, on a per-AP basis.
So basically it depends on whether you continue to experience these events and you can rule out actual packet loss triggering the events. If so, either turn off the inter-controller heartbeats for a stable workaround and report it to the TAC so you can be further diagnosed. If you can afford to play around, try adjusting the timer/threshold (that didn't help us, though.) If you are playing with the timers while experiencing events, you may want to turn off preemption so you don't get two events for every actual event, supposing you don't mind APs staying on the standby indefinitely.
If you are investigating packet loss issues, the heartbeats are sent outside IPSEC tunnels on UDP 8211 and are easy to sniff and a modern tshark/wireshark will be able to see their sequence numbers.
08-21-2014 05:33 AM - edited 08-21-2014 06:12 AM
We tried 6.4.1 with our production environment, 7201 master, 6000-m3 backup, and some 3600 locals at some remote sites.
We've had some weird issues at each site. One 3600 would not warm boot on the 6.4.1 code....but hang. The AP125s didn't seem to "like" the code and we had mesh problems with them. Weird dropouts with wifi sets across campus. We had random authetication issues with MAC auth. Funny, clearpass didn't burp at all and loved the new code on the controllers.
We gave it 2 weeks...
We're higher-ed and need to be on solid code for the beginning of our semester in a week...so I opted to backout to 6.3.8.
Problems disappeared. Guess we have to wait to deploy our new AP103s till 6.4 is more solid for our "mixed" environment.
Just some real-world issues we've seen on our community college campus 400+ APs, 24 buildings, 4 campuses and about 1800+ users.
I have several tickets open with TAC with 6.4...We'll do this in the fall when the kids are on break.
Anyone else see this quirky behavior?