Controllerless Networks

I am hoping that some one can help me with this issue.  I have 3-4 instant AP-105's that I have attempted to convert from VC to campus mode AP (thin).  During the process 3 out of 4 AP's have been stuck in this reboot/upgrading loop and seem to have trouble loading the image they got from the controller.  The AP's are sitting in my lab setup (thankfully) and are not directly attached to the controller as they are normally connecting over the network (L3) to my controllers in the DC.

After some time I was able to fix 1 AP by directly attaching it to the controller and running 'tftpboot' from the AP console.  The problem is that in production I don't have the luxury of having a local controller at every location. So, this will not work for me.  Is there a way to recover from this issue if the AP is not local to the Aruba controller?

Here are the troubleshooting steps I used:

1. I have done a purgeenv > saveenv > boot several times and but that did not seems to no avail. 

2. I tried to run 'tfptboot' command from the 'apboot>' prompt but it fails:

apboot> tftpboot

eth0 up: 1 Gb/s full duplex
ADP multicast 1
ADP broadcast 1
ADP multicast 2
ADP broadcast 2
ADP multicast 3

Retry count exceeded

3. Then I directly connected the AP to the test controller (Aruba650) and run 'tftpboot' and that worked fine.  The AP was able to boot load the image from the controller and came up after that.

apboot> tftpboot

eth0 up: 1 Gb/s full duplex
DHCP broadcast 1
DHCP IP address: 10.2.10.13
DHCP subnet mask: 255.255.255.240
DHCP def gateway: 10.2.10.1
DHCP DNS server: 10.2.10.1
DHCP DNS domain: lab
Controller address: 10.2.10.1
Using eth0 device
TFTP from server 10.2.10.1; our IP address is 10.2.10.13
Filename 'mips32.ari'.
Load address: 0x2000000
Loading: *###########################################################
done
Bytes transferred = 3850268 (3ac01c hex)

Here are the details on 1 of the affected AP's and OS version when the issue was happening:

#show version:
ArubaOS Version 6.1.3.1 (build 32786 / label #32786)
Built by p4build@cartman on 2012-03-12 at 23:43:35 PDT (gcc version 4.3.3)

#show ap database

AP Database
-----------
Name               Group            AP Type  IP Address  Status     Flags  Switch IP
----               -----            -------  ----------  ------     -----  ---------
d8:c7:c8:c4:6a:40  default          105      10.2.10.13  Upgrading  I      10.2.10.1

Here's the message from the AP console:
AP rebooted Fri Dec 31 16:01:37 PST 1999; SAPD: Reboot after successful image upgrade
shutting down watchdog process (nanny will restart it)...

What discovering method are you using for the AP to find the controller ? DNS, ADP , DHCP ?

It is finding the controller via DHCP options.

Do you have other APs in the same IP segment using option 43 to find the controller ?

Please upgrade your controller to AOS 6.2 and try again. The version you are running does not fully support the IAP to CAP conversion.

You can get an idea of why the conversion failed within the IAP UI.  Upon conversion failure you can look at the logs of the IAP using "Show AP Log All".   You should also get a messge in the IAP WebUI what failed.

NOTE: Be sure to read the 6.2 Release Notes.  On the 600 series controllers the number of APs has changed.  You go from 8 CAP / 32 RAP on the 620 to 8 CAP / 8 RAP.  Same with the 650.

Ok sure. I am sure it is an issue with the number of AP's either since I only have 3 in this setup. 

In any case,  I know that 'apboot> tftpboot' solved my issues when I attached the AP directly to the controller.  The question is whether this command is going to work over the network (which didn't while I was running 6.1.3.1).  I upgraded my controller to 6.1.3.7 and tried this command over the network and it worked this time.  Not sure what was the issue before on 6.1.3.1.

Now I know this will get me out of a bind as long as the AP's are able to contact the controller.

I attached the output of the second try in case some one else runs into the same issue...

Attachment(s)

AP tftpboot over the network.txt   4 KB 1 version

The conversion should only be done within the IAP WebUI under Maintenance > Convert.  The IAPs only need IP connectivity whether that is locally attached or not does not matter nor does it matter the number of IAPs in a cluster.  The issue you are running into is the version of code running on your controller.  Let us know how it goes with AOS 6.2.  If you do still have issues be sure to capture the output from the WebUI with the failure.

Ok will do. Thanks for the clarifications.

Yes 3 AP's. All are able to find the controller fine with option 43.  I don't feel that locating the controller is the issue since the AP console clearly shows that the AP has located it's master via DHCP.

:::output truncated:::: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready

10.2.10.13 255.255.255.240 10.2.10.1
Running ADP...Done. Master is 10.2.10.1