Controllerless Networks

I have a small cluster (3) AP-109s running Instant 6.5.4.3_61959. It is working as configured.

I do not have cluster security enabled. 

I do not have any VPNs enabled.

My WLAN is 192.168.23.0/24

My syslog server is receiving the following two errors from all of my APs every several seconds:

cli[xxxx]: [primary tunnel] Error!!!: Received RC_OPCODE_ERROR lms192.168.10.2 tunnel 0.0.0.0 RC_EROR_IKEP2_PKT1 debug-error:-8949 (ERR_IKE_TIMEOUT)

cli[xxxx]: [primary tunnel] tunnel_err_msg_recv(1762): Error !!! Received RC_OPCODE_ERROR peer public ip 192.168.10.2 tunnel ip 0.0.0.0, controller ip 0.0.0.0, RC_EROR_IKEP2_PKT1 debug-error:-8949 (ERR_IKE_TIMEOUT)

These errors looked like crypto failures that are VPN related, but I do not have a VPN configured.  Also I have no idea where the IP address 192.168.10.2 was coming from (where it had been configured).  It is not in my current configuration

I decided to do a show vpn status from the cli and I found the 192.168.10.2 IP address; it is defined as the primary tunnel peer address!  See below:

AP109-East# show vpn status
profile name:default
--------------------------------------------------
current using tunnel                            :unselected tunnel
current tunnel using time                       :0
ipsec is preempt status                         :disable
ipsec is fast failover status                   :disable
ipsec hold on period                            :600s
ipsec tunnel monitor frequency (seconds/packet) :5
ipsec tunnel monitor timeout by lost packet cnt :6

ipsec     primary tunnel crypto type            :Cert
ipsec     primary tunnel peer address           :192.168.10.2
ipsec     primary tunnel peer tunnel ip         :0.0.0.0
ipsec     primary tunnel ap tunnel ip           :0.0.0.0
ipsec     primary tunnel using interface        :
ipsec     primary tunnel using MTU              :0
ipsec     primary tunnel current sm status      :Retrying
ipsec     primary tunnel tunnel status          :Down
ipsec     primary tunnel tunnel retry times     :404
ipsec     primary tunnel tunnel uptime          :0

ipsec      backup tunnel crypto type            :Cert
ipsec      backup tunnel peer address           :N/A
ipsec      backup tunnel peer tunnel ip         :N/A
ipsec      backup tunnel ap tunnel ip           :N/A
ipsec      backup tunnel using interface        :N/A
ipsec      backup tunnel using MTU              :N/A
ipsec      backup tunnel current sm status      :Init
ipsec      backup tunnel tunnel status          :Down
ipsec      backup tunnel tunnel retry times     :0
ipsec      backup tunnel tunnel uptime          :0
AP109-East#

So my questions are why are my APs trying to establish a VPN tunnel with a controller when it is not configured?  All my APs are associated with my virtual controller

And how to I reconfigure my APs in order to stop the constant barrage of log messages.

Are you sure you don't have anything under the More> VPN listing?

Positive nothing under More->VPN.  

Just Aruba IPSec in the drop down and primary & backup host fields are blank.

More info:

I did a fill reset of my AP by booting into the APBOOT mode and doing a factory_reset, clearOS and then a save.  I booted up the AP and upgraded the os to Instant 6.5.4.3 and rebooted. Then I manually reconfigured it by assing the SSID, the virtual controller info and set the IP address of the syslog server.   I tested the configuration to validate it and backed up the config.  I shut down the AP and did a paperclip reset of the AP.  When it booted, I restored the saved config and rebooted again.

Within several seconds of the AP booting up, I see the following in my syslog file:

<WARN> <192.168.23.81 24:DE:C6:CB:60:22> provision try

<WARN> <192.168.23.81 24:DE:C6:CB:60:22> provision recv_convert_ap: Convert AP Url- mode-1, master-192.168.10.2

<WARN> <192.168.23.81 24:DE:C6:CB:60:22> Setup VPN for RAP conversion - 192.168.10.2

<WARN> <192.168.23.81 24:DE:C6:CB:60:22> Set amp discover allowed: code: success

The the previous error message pair started showing up every few seconds.

Why is my AP trying to do a a conversion when it is the virtual controller?

It almost looks like you have a convert rule in activate.  I would contact TAC, if you could.  Activate is a cloud service that the IAP contacts on first boot, and you could have a convert to CAP or Convert to RAP rule in activate that you are hitting...

Colin,

Thanks for the reply. Were would that rule originate from?  Is that a setting in the APBOOT environment variables?

No.    Register for an account here:  https://activate.arubanetworks.com/registration/

When you get a login to activate, add your device using the cloud activation key. You can find the key like this: http://community.arubanetworks.com/t5/Controller-less-WLANs/How-to-find-the-cloud-activation-key-via-CLI/ta-p/234889

That might solve your issue.

Colin,

I think this may be related

http://community.arubanetworks.com/t5/Controllerless-Networks/IAP205H-and-firmware-version-6-5-2-0/td-p/304640

Do you have a controller on your network that the AP might be reaching out to?

Also, is this a new IAP or used?

There isn't a controller or another AP on the L2 network.

The AP was used in a lab setting with a 7000 series controller.

After it was repurposed for this Instant application, it was reset to factory defaults by running the factory_reset from APBOOT.

Ok.  The link you sent would only apply if there was a controller on your network that it could search for to convert.  If the behavior survives a reboot, it is probably activate.

OK.  So where do we go from here?  I have a requirement from my customer where they want the virtual controller on their L2 network so using the cloud controller (setting up an account) as you suggested isn't really an option. There must be a way to force a RAP into Instant mode where it is not trying to configure itself as a RAP or CAP.

If your customer purchased it, find out if they signed up for an aruba activate account.  They could have configured the rule in there.

They do not have an Aruba activate account.  Nor have they associated the APs I am working with because I have been in sole possession of them.  This is starting to feel like a software defect.

Then you should open a TAC case so they can get to the bottom of it.

The challenge is that this is a proof of concept to meet the customer's requirements in an RFC and they will not buy until this is resolved.  So since these APs are for our lab, there isn't maintenance on them and that prevents us from opening a case with TAC.  It is a shame that there isn't a way to report a software defect unless you have a maintenance contract.