Wireless Access

Hi guys,

 

I have an IAP-305 which doesn't transmit in both bands:

It is running firmware 6.5.1.0-4.3.1.0. This happened to me with another IAP-325 long time ago, but it was solved upgrading to 6.5.2.0, this is the thread:

 

https://community.arubanetworks.com/t5/Wireless-Access/Some-IAPs-don-t-broadcast-in-a-cluster/td-p/294618

 

Now I can also see the IAP is skipping initializing the radios:

 

Jun 23 19:35:35  sapd[2187]: Skipping 2.4Ghz initilization as no valid channel.

 

But now I can't upgrade to 6.5.2.0 because I am going to join this IAP to an existing cluster running 6.5.1.0-4.3.1.0.

Is there any solution or workaround for this?

 

Regards,

Julián

Hi Julian,

 

As per the message, it seems the version that you are running does not support any valid channels on the country code which is selected for the IAP.

 

Please share the following output :

 

#show ap allowed-channels

 

Are you using any other IAP apart from 325/305 ?

 

What is the country code selected on your IAP cluster ?

 

You can try upgrading to latest version on 4.3.1.x (4.3.1.3) & verify if the radio comes up.

 

http://support.arubanetworks.com/LifetimeWarrantySoftware/tabid/121/DMXModule/661/EntryId/25164/Default.aspx

 

 

Hi Nitesh,

 

As you said, this IAP with this firmware and this country code supports no channels for both bands:

 

34:fc:b9:cb:05:42# show ap allowed-channels

Allowed Channels for AP Type 305 Country Code PE
------------------------------------------------
PHY Type Allowed Channels
-------- ----------------
802.11g (indoor) None
802.11a (indoor) None
802.11g (outdoor) None
802.11a (outdoor) None
802.11g 40MHz (indoor) None
802.11a 40MHz (indoor) None
802.11g 40MHz (outdoor) None
802.11a 40MHz (outdoor) None
802.11a 80MHz (indoor) None
802.11a 80MHz (outdoor) None
802.11a 160MHz (indoor) None
802.11a 160MHz (outdoor) None
802.11a (DFS) None

 

Upgrading to 4.3.1.3 solved the problem for this IAP, now it can transmit in many channels. But I have an existing cluster of several IAP-325 running 4.3.1.0, if this IAP is joined to the existing cluster, will it work or will I have to upgrade the existing cluster to 4.3.1.3?

 

Regards,

Julián 

Hi Julian,

All the IAP's in a cluster need to run the same firmware.

Please upgrade the 325's to 4.3.1.3 & then add 305 in the network.

It will be better to have one of the 325's as preferred master.

Hi Nitesh,

 

Ok, thanks. About

 

It will be better to have one of the 325's as preferred master.

 

Why this? Is it because to prevent IAP-305 to become master as it has lower capabilities than IAP-325s?

 

Regards,

Julián

 

Hi Julian,

Preferred master will ensure that introduction of new IAP does not cause any issues.

We have seen issues where IAP's with default configuration becomes master & existing ones sync up with it causing configuration to wipe out.

This is generally network related.

So, it's always advisable to have one preferred master in the cluster.

Hi Nitesh,

 

Waw, so very glad to know this and I will select one of the existing as preferred master. I thought this behaviour is a bug, but what do you mean when you say "This is generally network related."?

 

Regards,

Julián

Hi Julian,

 

Lets say you are having issues on the network where master/slaves are unable to communicate properly. Lets say you introduce a new IAP (default config) on the network.

 

Due to network issues, if this new IAP is unable to hear the master beacon from the existing master, it will start sending the master beacon itself by thinking of itself to be the master.

 

This can cause other slaves to align & form cluster with this IAP causing the configuration to wipe out.

 

Preferred Master:

The master election and re-election process is the default behavior for IAP clusters. In addition to the default master election algorithm, Aruba InstantOS 4.0 lets you manually assign the master AP role. Manual
assignment works well in an environment that requires a specific AP with a lower load, an AP with more capable hardware, or an AP with an alternate uplink to always function as the master.

 

The AP that you manually select as the master is known as the preferred master. As long as the preferred master is online, it is the cluster master. If the preferred master goes down because of an uplink failure, the default reelection algorithm elects a new AP as the master. When the preferred master comes back online, it becomes the cluster master again, and the AP that was automatically elected as the master through the reelection algorithm reboots to rejoin the
cluster as a regular member AP.

Cluster mechanics

A preferred master will never lose its configuration or become a slave AP of another master, unless it is on factory default configuration. It will either take over as master or become a single-AP cluster by itself. An
existing AP that is not a ‘preferred master’ can be pre-empted by a preferred master.

An IAP x, if connected to an active cluster (with an already elected master IAP y):
1. IAP x will have its configuration replaced by the master’s configuration, if the IAP x does not have ‘preferred master’ enabled.
2. If IAP x, has preferred master enabled, then it will check if the existing cluster’s master AP y, has ‘preferred master’ enabled or not.
3. If the existing cluster’s master IAP y, does not have ‘preferred master’ set, the new IAP x will take over as the new master of the cluster & its configuration will be propagated.
4. If the existing cluster’s master IAP y, also has ‘preferred master’ set, then the new IAP x will come up as a single-IAP cluster by itself, if IAP x has a non-default configuration.
5. If the existing cluster’s master IAP y, also has ‘preferred master’ set, then the new IAP x will join the cluster as slave, if IAP x has factory default configuration. IAP x will download the configuration of IAP y.

Hi Nitesh,

 

But with that example setting an IAP as preferred master would not prevent a new IAP to become master. If there are network issues that prevent a new IAP to hear master beacons, this new IAP would be unable to hear the master beacons, either they come from a master that has been elected by the election algorithm or from a master that has been set as preferred master. Then it will start sending the master beacon itself by thinking of itself to be the master and the problem keeps being there.

 

Regards,

Julián

Hi Julian,

 

The main point will be :

 

A preferred master will never lose its configuration or become a slave AP of another master, unless it is on factory default configuration. It will either take over as master or become a single-AP cluster by itself.

 

As soon as the IAP with preferred master is reachable from all the slaves, they will start hearing the beacon & this IAP will take over the controls of the cluster & push its configuration to the slaves.

 

Please check the first 4 points under Preferred master behavior in my previous response.

Hi Nitesh,

 

I understand that, and you say "As soon as the IAP with preferred master is reachable from all the slaves", and this is met when there are not network isssues. But this is not the case when there are the network issues, and as you said in a previous message "Lets say you are having issues on the network where master/slaves are unable to communicate properly", so the first sentence will not be accomplished.

But don't worry, I have the idea it is better to have a preferred master in a cluster.

 

Regards,

Julian