08-23-2012 11:12 AM
Any one having trouble with the upgrade from 188.8.131.52 to 184.108.40.206.
We are havening trouble with our remote Campus AP loading the new system. Most of the remote AP105 hung up and will not load the firmware until we pull them down and clear the OS and then point them to a local TFTP Server. The force them to reboot from the controller then they seem to come up and work fine and we can point them back to the master controller.
When we upgraded the local AP were havening trouble loading the new code and took more reboots and time than normal to come online.
The 2 remote offices appeared to upgrade and showed in the controller they were updated and up and running when they were down and still on the old code.
08-23-2012 08:31 PM
Check your "ip access-list session ap-acl" and make sure ftp and tftp are being allowed. Here is what mine looks like.
ip access-list session ap-acl
any any svc-gre permit
any any svc-syslog permit
any user svc-snmp permit
user any svc-http permit
user any svc-http-accl permit
user any svc-smb-tcp permit
user any svc-msrpc-tcp permit
user any svc-snmp-trap permit
user any svc-ntp permit
user alias controller svc-ftp permit
08-24-2012 06:01 PM
We supposedly have it to level 2 engineering involved at this time. 3 Aruba engineers have been through the entire system and they don't know what is happening.
I was trying to solicit if anyone else is having the same issues. I noticed one other person is having a similar issue. I am trying to get it into the software group so they can get out a fix for the problem.
We are not able to upgrade our APs across our wan link with version 220.127.116.11. It has worked on every other version in the past. This one will only work if we install a local TFTP server on the same subnet and force the AP to load from it instead of the 3600 controller.
It is a real mess we had to pull down over 20 of the APs from the ceiling and hook a serial cable to them Clear the OS and then force them to load from the local TFTP then force the controller to do a remote reset on the AP before they world come alive. The other spooky thing is that after the upgrade all of our campus APs at the remote office showed they were up and working when they were all down and stuck at the .1 code level. It wasn't until Monday morning that a few of them showed down and the CLI interface shows the devices were inactive.
It has been a brutal upgrade from 18.104.22.168 to 22.214.171.124. The only good thing is the Ipads seem to run faster, and they seem to roam better.
08-29-2012 11:24 AM
Aruba engineering found the problem was bug in the code 126.96.36.199 code that affect the loading of APs across a wan link, and can also cause problem loading the new code on AP on the local network.
We were getting excessive timeouts while trying to upgrade/update the campus APs at the remote office. This has always worked in the past, and we were beginning to question our Wan and local network (which checked out fine), when we verified it happens on the local network as well.
If you are loading a new AP with no code (purge, clear os) or with a version that is prior to .2 code you can have trouble with the AP failing to load the new code.
If they fail to load you will probably need to pull them down, clear the OS and point then to a "local" TFTP server with the new code to get them to come up. We also need to send a reset to the AP from the controller to get them to come up and be recognized.
This was a tough process pulling down all of the AP in our NY education office and manually reloading them.
This is the quote from Aruba TAC.
"Engineering has identified the reason of APs fail to upgrade over WAN link where it took more than 9 minutes ( approximately ) to upgrade. This issue is addressed in Aruba OS 188.8.131.52 onwards. The reason we hit this issue, as the APs at NY location still had 184.108.40.206 in their flash. Bug ID for your reference is 65344. As we have all the APs up and running 220.127.116.11 in their flash, we would not see this issue in further upgrade."