09-11-2014 12:36 PM
Looking at updating our Master/Local pair of 7210 Controllers from 184.108.40.206 to 220.127.116.11 and looking to see if others have seen any issues that I should be looking out for or has it gone pretty smooth.
Have the following Access Points:
49 x AP-105
35 x AP-115
2 x RAP-3WN
1 x RAP-155
09-11-2014 12:45 PM
09-11-2014 01:26 PM
All smooth here. There are a few posts on this:
09-11-2014 07:53 PM
You might want to wait a day or three for 18.104.22.168.
The issues we have with 22.214.171.124 are probably either unique to
our AP models, which you do not have, or are slated to
be fixed in 126.96.36.199.
09-19-2014 12:59 PM
I would also wait for 188.8.131.52, i have several issues with 184.108.40.206 which i have cases open with TAC for.
1. I have lost the abilibty to Ping all my AP's. They are online and working but i am unable to
monitor them with nagios anymore.
2. I am seeing much weaker signal strengths from my AP's. I have been working with TAC most of the day today on this one but am not really sure whats going on.
3. this issue is only happening on AP 205's but i have lost the ability to open random websites. I did some troubleshooting on this earlier today with TAC as well, and tested it on all the models i have and it only happens on the 205 model. The webpages just time out and there does not appear to be a rhyme or reason why.
09-19-2014 01:29 PM
1) HA intercontroller heartbeats trigger failovers too readily and will be fixed in 220.127.116.11
2) Hospitality (wired-AP) ports after an HA fast failover die for 5 minutes, also will be fixed in 18.104.22.168.
3) 80MHz in especially in dense environments on the 225 causes false radar events (to be expected) but the APs occasionally go rf-dead (nearly no beacons sent) after getting one of these. Probably not fixed by 22.214.171.124 unless a fix occurs by accident, which does happen sometimes. We went deep with TAC on this one including debug AP builds. This
one is especially painful to OSX which hear the occasional beacon and associate but
then get stuck somehow and never roam off the AP until they move out of the area,
all while the AP continues to serve other clients. So it's a client-specific deadzone.
4) ARP spoof protection triggers on corrupt packets and blacklists clients. This happens almost only to iPhones. Unsure where the corruption is happenning. Not sure when the mis-triggering issue will be fixed. Worked around it with local-proxy-arp feature which pretty much eliminates the problem unless Apple decides to start sending too many unsolicited gratuitous arps.
5) A few mystery performance issues we know are there but haven't got anything to go on
but hearsay at the moment.
09-23-2014 09:07 AM
as an update, i did get one of my issues fixed this morning working with TAC. It seems the AP205's auto set the MTU values. The other AP's dont. the 205's were setting this in a way that was causing incomplete information to be sent which causes random webpages to not load anymore. Setting the SAP MTU to 1400 in the AP System profile solved the problem.