Wireless Access

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

So far in my expirence 6.4 has been solid. Im at 6.4.1.0 but it is in a lab environment not production. 

My .02 is its solid. Plus APP-RF 2 is great.

I have been deploying 6.4.1 with great sucess. 6.4.2 was release about a week ago. In the lab, it's been stable.

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.

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.

---

@bjulin wrote:

 

may have to run without inter-controller heartbeats turned on for a few revs.

  

---

bjulin,

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?

Aaron

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.

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?

Couple of other gotchas worth mentioning: on 6.4.2.0 (and probably earlier 6.4.x) when running in production environments. These are already filed with TAC: 1) If you need to remove a Hotspot2.0 profile, do it off hours, remove the profile from all SSIDs, then remove and re-add the SSID that contained it to the virtual AP. Never remove an SSID with a Hotspot profile from a virtual AP, or it may be a very hard and involved process to get the APs to actually stop sending HS2.0 beacons. 2) Do not touch any MFP settings either to enable or disable them. If you are reading this because you just did, reboot all your APs.