06-25-2013 08:49 PM
I'm trying to field some queries from a client on IAPs in mixed clusters. I'm well aware of the constraints in relation to maintaining multiple firmware images fro each class (orion / pegasus etc) and how this works with Airwave / Cloud server.
What i'm not 100% clear on is, can you do a manual firmware upgrade using the image URL for an alternative firmware version.
Eg. Can i manually prep an IAP-105 with a TFTP image of the Cassiopiea image for the 135 or will this reject the image check?
Was planning on actually testing this out when time allows but thought i'd put it to the group first in case someone has already doen this.
The example i'm referring to, my client has no cloud access (firewall / proxy which can't be negotiated with) and no airwave so i'm looking for a Plan C here if possible.
Solved! Go to Solution.
01-03-2014 07:32 AM
I know this is a bit late for a response but I recently had to review a mixxed class upgrade procedure as well, just wanted to add some input to this one, it may not be the exact answer to the question you asked but it may help someone else out down the road..
Any devices in a different class need to be on the same build before they will join the IAP VC. When they were in different firmware versions, I would see PAPI traffic communicating via the "datapath sessions" command (cli), and I would see the mac address populate for the allowed-ap(cil).
Once you have differnet classes in a single IAP VC, you will have a different URL upgrade paths for each class (ex orion or cassiopeia). If for some reason one of the upgrade fails and you didn't reboot any of the IAP's you will lose the devices in that class that failed. You can confirm the upgrade process in the cli by running this command "show upgrade info". This command will only show you the devices that are active in the IAP VC, so if there is a failed attempt somewhere you may not see those devices when running the command.
The issue I came into was when the IAP was on different firmware, it thought it was part of the cluster but wasn't fully synced. If you grabged the IP of the IAP in the other class that you are trying to join the VC with, I noticed it would redirect you to the IAP Master. I attempted to SSH but received a reject message.
Only way I was able to get around this was by putting that IAP on a different vlan / segment so it couldn't communicate with the VC via broadcast and then was able to get into mgmt. If you have more the one IAP in that other class they should create their own VC, and it should be fairly straight forward for the upgrade process.
Once the IAP's in that other class are upgraded you can put them back on the vlan / segment with the other IAP VC, and they will join back in wihtout any issues.
As to using the URL upgrade procedures its pretty straight forward, TFTP was pretty slow for me, and I have yet tried HTTP. Just put any images on your tftp / http server, and enter the following firmware codes in this format.
To confirm the upgrade process you would go into the CLI, and run the following command.
- show upgrade info
I have provided an example below with 2 different classes "Cassiopeia & Orion"
AP-1# show upgrade info
Image Upgrade Progress
Mac IP Address AP Class Status Image Info Error Detail
--- ---------- -------- ------ ---------- ------------
6c:f3:7f:xx:xx:xx 172.16.1.20 Cassiopeia upgrading tftp://172.16.1.10/ArubaInstant_Cassiopeia_184.108.40.206-220.127.116.11_41337 none
6c:f3:7f:xx:xx:xx 172.16.1.21 Cassiopeia upgrade-done tftp://172.16.1.10/ArubaInstant_Cassiopeia_18.104.22.168-22.214.171.124_41337 none
00:0b:86:xx:xx:xx 172.16.1.22 Orion downloading tftp://172.16.1.10/ArubaInstant_Orion_126.96.36.199-188.8.131.52_41337 none
Auto reboot :disable
Use external URL :enable