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.