Controllerless Networks

Hi,

 

I'm using a IAP325 with code 4.2.2.0. I currenlty have the VC up and running and have several clients connected to it. When I connect a second AP (factory default) to the same switch in the same VLAN, it receives an IP-address and it is pingable from my client.

When looking at the VC web interface, the seocnd AP sometimes appears in the AP list but most of the time it is not being seen. Also when trying to connect to this AP it won't let clients connect to it.

Once I disconnect the VC from the network, my client gets diconnected but after several seconds connect to the second AP (which than has become VC).

So the second AP receives the VC configuration, however they are not operating together when they are operational at the same time.

 

I'm able to setup a telnet session to the AP, but not able to authenticaite. I don't see any attempts hitting the authentication server. This might indicate that the request stops at the VC, or probably does not reach the VC at all.

 

When checking the log file on the VC when the second AP is operational, I see the following messages:

 

Jan  5 13:39:54  cli[3471]: <341097> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  recv_image_check_v1_0: mac-ac:a3:1e:cd:35:76, version-6.4.4.3-4.2.2.0_53034, ccode_idx-255.
Jan  5 13:39:54  cli[3471]: <341165> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  send image match to 10.32.24.55.
Jan  5 13:44:22  cli[3471]: <341097> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  recv_image_check_v1_1: mac-ac:a3:1e:cd:35:76, version-6.4.4.3-4.2.2.0_53034, ccode_idx-255.
Jan  5 13:44:22  cli[3471]: <341165> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  send image match to 10.32.24.55.
Jan  5 13:44:27  cli[3471]: <341097> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  recv_image_check_v1_1: mac-ac:a3:1e:cd:35:76, version-6.4.4.3-4.2.2.0_53034, ccode_idx-255.
Jan  5 13:44:27  cli[3471]: <341165> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  send image match to 10.32.24.55.
Jan  5 13:44:29  cli[3471]: <341102> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  Incorrect format for message type 0:69521408:223:5:10.32.24.55:8480.
Jan  5 13:44:32  cli[3471]: <341097> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  recv_image_check_v1_1: mac-ac:a3:1e:cd:35:76, version-6.4.4.3-4.2.2.0_53034, ccode_idx-255.
Jan  5 13:44:32  cli[3471]: <341165> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  send image match to 10.32.24.55.
Jan  5 13:44:37  cli[3471]: <341097> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  recv_image_check_v1_1: mac-ac:a3:1e:cd:35:76, version-6.4.4.3-4.2.2.0_53034, ccode_idx-255.
Jan  5 13:44:37  cli[3471]: <341165> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  send image match to 10.32.24.55.
Jan  5 13:44:42  cli[3471]: <341097> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  recv_image_check_v1_1: mac-ac:a3:1e:cd:35:76, version-6.4.4.3-4.2.2.0_53034, ccode_idx-255.
Jan  5 13:44:42  cli[3471]: <341165> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  send image match to 10.32.24.55.
Jan  5 13:44:47  cli[3471]: <341097> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  recv_image_check_v1_1: mac-ac:a3:1e:cd:35:76, version-6.4.4.3-4.2.2.0_53034, ccode_idx-255.
Jan  5 13:44:47  cli[3471]: <341165> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  send image match to 10.32.24.55.
Jan  5 13:44:52  cli[3471]: <341097> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  recv_image_check_v1_1: mac-ac:a3:1e:cd:35:76, version-6.4.4.3-4.2.2.0_53034, ccode_idx-255.
Jan  5 13:44:52  cli[3471]: <341165> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  send image match to 10.32.24.55.
Jan  5 13:49:02  stm[3494]: <304065> <ERRS> |AP ac:a3:1e:cd:46:7e@10.32.24.84 stm|  PAPI_Send failed, send_papi_message_with_args, 880: No such file or directory, dstport 5664
Jan  5 13:49:25  cli[3471]: <341097> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  recv_image_check: mac-ac:a3:1e:cd:35:76, version-6.4.4.3-4.2.2.0_53034, ccode_idx-255.
Jan  5 13:49:25  cli[3471]: <341165> <WARN> |AP ac:a3:1e:cd:46:7e@10.32.24.84 cli|  send image match to 10.32.24.55.

 

When disabling the auto-join feature on the VC, I do see the mac-address in 'red' with status 'This AP is not connected'. Therefore it doesn't seem to be related to the PAPI protocol.

I've checked the forum but cannot find a similar issue. Anyone familiar with this?

Are you connecting a 2nd IAP-325 to the cluster or a different model AP?
If a different model AP, make sure it is on the same firmware as the IAP-325.

Hi pasquale, yes all the AP's that i'm using are IAP325's, and they have the same software code installed.
I do have dhcp option 43 configured for another purpose. Might this ne interferring with the AP not being able to become part of the cluster?
Or is there any requierement for clustering to work that i might have not thought of?

If they are on the same L2 segment and are running the same code, they should cluster together.

Have you tried simply connecting the 2nd AP first, then attempting to join AP1 to the cluster.

If that does not, try factory resetting both APs. Connect AP1, configure it, connect AP2.

Hi, yes i did the same test the other way around (second ap vc, then connect primary) with the same result. I just received them brand new factory default, but i will manually factory reset them and test again.
(Activation) of licenses could'nt be the issue, right? Just to be sure as these units are brand new.

When you say activation of licenses? What do you mean?

There are no licenses unless you are connecting them to Central or Airwave.

I want to make sure there is no license or activation issue that prevents the ap's from clustering.
What other requirements besides being the same model or different model with same software version, and being in the same l2 vlan are needed to get them clustered?
Any indication of the cause of the issue in the log messages that i've added in the first post? Any additional commands or debugging that i can look for?
As i have multiple units i will also try to cluster 2 different iap325's that are still sealed in their boxes and see if i run into the same issue.

the log seems to indicate it is trying to send an image file. which is weird if they indeed have the same version, are you sure about that? are you sure there aren't any other IAPs in that network?

Are those both IAP325's ?

Hi, both are 325's using the same instant software release  6.4.4.3-4.2.2.0 Compiled on 2015-12-18 at 23:24:47 PST (build 53034) by p4build. Aruba has offered me this solution before releasing the official version.

This is not a GA release yet but an early build that I'm using to get the 325's up and running.It might be a bug in this pre-build but I'm trying to get to know if there could be any other issue preventing the AP's to form a cluster. Is there a specific (debug) command which shows me what exactly is happening?Regarding the question if both use the same software version; if these differ and the model is the same wouldn't the master in the VC update the second AP then?

Jer,

 

If you have prerelease software, you should contact whoever gave it to you to understand what the problem is.

Alright, so now I have several IAP225's all with the same software version (6.4.2.6-4.1.1.11_52666).

I did the same test and run into the same issue.

 

I've 2 IAP225's connected to the same switch, in the same VLAN. Port settings are identical, trunkall and both configured with the same native VLAN.

In addition I've connected 3 other IAP225's with the same software version and run into the same issue. Although the first IAP225 is working as expected, a second IAP225 is not able to join the cluster.

 

When I disable to 'auto join mode' feature, I do see the mac address of the IAP in the web interface of the VC, and is being marked red; "this AP is not connected'. It has received an valid IP-address (from a DHCP server) and responds to ICMP requests.

 

Any ideas what might cause the second IAP from beinging prevented being part of the cluster?

SSH into the VC and type "show log system" to see if there is something keeping them from joining.

I've just checked and see the following message in the VC, as can be noticed in the added file.

Seems it keeps trying to send the software, but both already have the same and latest software version; ArubaOS (MODEL: 225), Version 6.4.2.6-4.1.1.11

 

Also, even if it is not the same wouldn't the VC be resonsible to upgrade any AP that is joining the cluster? (apart from the AP updating its software from the cloud)

I've resolved the issue.

After changing the tag settings from untag ap mgmt only to untag all and then back to untag ap mgmt only and a reboot fixed the issue.

Probably some code got 'stuck' and was solved either after the reboot or after changing the tag setting.