Controller-less WLANs

Product and Software: This article applies to Aruba Instant Access Points (IAP's) running on 6.2.0.0-3.2.0.0 and later

Aruba Instant does not require an external mobility controller to regulate and manage the Wi-Fi network. Instead, one IAP in every network assumes the role of a Virtual Controller (VC).

The Master Election Protocol enables the Aruba Instant network to dynamically elect an IAP to take on a VC role. This protocol ensure stability of the network during initial startup or when the VC goes down by allowing graceful failover to a new Virtual Controller when the existing VC is down.

IAP uses following order as Conflict Resolve Algorithm, to resolve conflicts:

1. look into IP scope. IAP with default-ip cannot win
2. look into 3G/4G capability
3. look into AP class, Arran (IAP-13x) gets higher priority
4. look into uptime, older AP gets higher priority
5. look into AP MAC, bigger address gets higher priority

NOTE: If it is a single IAP in the network running with default-ip, then it would take  the role of VC.

Normally, adding a new IAP into a cluster will not affect the existing Master, but again there are exceptions to this rule as mentioned-below:

• Master is running with default-ip, a new IAP comes up and gets DHCP address and thereby becomes the new Master. At the same time, any IAP with default-ip will reboot automatically for IP recovery. However, mesh and Hierarchy topologies will accept default-ip.
• Master (without 3G dongle) is UP for less than 5 mins, then a new IAP (with 3G dongle) comes up. The new IAP becomes the new Master.
• AP class applies only for AP-10x and AP-12x and AP-13x platform and not applicable for latest models.

Master election follow the basic criteria that we have listed above. However, it is determined by kinds of scenarios and topology:

Let us consider a normal scenario with flat topology without mesh/3G/hierarchy/preferred master case:

1. All AP's bootup, (no election has occurred till now)
   • IF AP hear master beacon, it will be slave immediately
   • If AP cant hear master beacon, within a random time (4-120sec), it will be master
   • If there are multiple master beacons in the swarm, master election will happen with the basic criteria listed above
2. Master failover scenario
   • If current master is down, all other slaves have chance to become master and this is determined by a random time
   • The AP with the min random time will become the master first
   • If the two AP's get the same random time they will follow the basic criteria listed above

So, the conclusion is who can be master is random.

We can also check how the master random time is chosen from the below output:

# show election statistics

State        : Slave

master_beacon   : sent=0 rcvd=399156

hierarchy_beacon: sent=399087 rcvd=0

hierarchy_ack   : sent=0 rcvd=0

beacon_req      : sent=0 rcvd=0

beacon_resp     : sent=0 rcvd=0

election wait   : 47(0)

timer slow      : 0

master high cpu : 0

ap cpu usage    : 0

cpu core usage  : 0 0 1 0

delay by cpu usage: 4

Slave->Pot-Master : 0 time

Pot-master->Master: 0 time

Pot-master->Slave : 0 time

last spoof arp rcvd: 0

last spoof mac: 00:00:00:00:00:00

last beacon received ticks: 0

uplink flap count         : 0

max beacon miss ticks     : 1

hierarchy mode            : 0

last hierarchy beacon received ticks: 0

provisioned master denied : 0

NOTE: IAP Master Election Process, do not take InstantOS in to consideration. After the Master is elected, the virtual controller can take of image synchronization with slave IAP's.