Chapter 24


The underlying mechanism for the Aruba redundancy solution is the Virtual Router Redundancy Protocol (VRRP). VRRP is used to create various redundancy solutions, including:

VRRP eliminates a single point of failure by providing an election mechanism, among the controllers, to elect a VRRP “master controller. The master controller election is:


The master controller owns the configured virtual IP address for the VRRP instance. When the master controller becomes unavailable, a backup controller steps in as the master and takes ownership of the virtual IP address. All network elements (APs and other controllers) can be configured to access the virtual IP address, thereby providing a transparent redundant solution to your network.

Redundancy Parameters

Depending on your redundancy solution, you configure the VRRP parameters listed in Table 96 on your master and local controllers.

Table 96  VRRP Parameters (Continued) 



Virtual Router ID

This uniquely identifies this VRRP instance. For ease in administration, you should configure this with the same value as the VLAN ID.

Advertisement Interval

This is the interval, in seconds, between successive VRRP advertisements sent by the current master. The default interval time is recommended.

Default: 1 second

Authentication Password

This is an optional password, of up to eight characters, that can be used to authenticate VRRP peers in their advertisements. If this is not configured, there is no authentication password set.


This is an optional text description to describe the VRRP instance.

IP Address

This is the virtual IP address that will be owned by the elected VRRP master.

Enable Router Pre-emption

Selecting this option means that a controller can take over the role of master if it detects a lower priority controller currently acting as master.


Specifying a value enables the delay timer. The timer is triggered when the VRRP state moves out of backup or init state to become a master. This is applicable only if router pre-emption is enabled.

When the timer is triggered, it forces VRRP to wait for a specified period of time, so that all the applications are ready before coming up. This prevents the APs from connecting to the controller before it can receive them. In the mean time, if there is an advertisement from another VRRP, the VRRP stops the timer and does not transition to master.


Priority level of the VRRP instance for the controller. This value is used in the election mechanism for the master.


Configures a tracking mechanism that modifies a specified value to the priority after a controller has been the master for the VRRP instance. This mechanism is used to avoid failing over to a backup Master for transient failures.

Tracking can be based on one of the following:

  • Master Up Time: how long the controller has been the master. The value of duration is the length of time that the administrator expects will be long enough that the database gathered in the time is too important to be lost. This will obviously vary from instance to instance.

  • VRRP Master State Priority: the master state of another VRRP.

Tracking can also be based on the interface states of the controller:

  • VLAN and Interface: prevents asymmetric routing by tracking multiple VRRP instances. The priority of the VRRP interface determined by the sub value can increase or decrease based on the operational and transitional states of the specified VLAN or Fast Ethernet/Gigabit Ethernet port. When the VLAN or interface comes up again, the value is restored to the previous priority level. You can track a combined maximum of 16 interfaces and VLANs.

For example, you can track an interface that connects to a default gateway. In this situation, configure the VRRP priority to decrease and trigger a VRRP master re-election if the interface goes down. This not only prevents network traffic from being forwarded, but reduces VRRP processing.

Admin State

Administrative state of the VRRP instance. To start the VRRP instance, change the admin state to UP in the WebUI.


VLAN on which the VRRP protocol will run.

Configuring the Local Controller for Redundancy

In an Aruba network, the APs are controlled by a controller. The APs tunnel all data to the controller which processes the data, including encryption/decryption, bridging/forwarding, etc.

Local controller redundancy refers to providing redundancy for a controller such that the APs fail overto a backup controller if a controller becomes unavailable. Local controller redundancy is provided by running VRRP between a pair of controllers.

The two controllers need to be connected on the same broadcast domain (or Layer-2 connected) for VRRP operation. The two controllers should be of the same class (for example, and both controllers should be running the same version of ArubaOS.

The APs are then configured to connect to the virtual-IP configured for the VRRP instance.

Collect the following information needed to configure local controller redundancy:

You can use either the WebUI or CLI to configure VRRP on the local controllers. For this topology, it is recommended to use the default priority value.

In the WebUI

1.    Navigate to the Configuration > Advanced Services > Redundancy page on the WebUI for each of the local controllers.

2.    Under Virtual Router Table, click Add to create a VRRP instance.

3.    Enter the IP Address for the virtual router. Select the VLAN on which VRRP will run. Set the Admin State to Up.

4.    Click Done to apply the configuration and add the VRRP instance.

In the CLI

vrrp <id>

   ip address <ipaddr>

   vlan <vlan>

   no shutdown

Configuring the LMS IP

Configure the APs to terminate their tunnels on the virtual-IP address. To specify the controller to which an AP or AP group tunnels client traffic, you configure the LMS IP in the AP system profile on the master controller. For information on how to configure the LMS IP in the AP system profile, see “Configuring APs” .

This configuration needs to be executed on the master controller; the APs obtain their configuration from the master controller.

In the WebUI

1.    Navigate to the Configuration > Wireless > AP Configuration page on the master controller.

2.    Under the Profiles section, select AP to display the AP profiles.

3.    Select the AP system profile you want to modify.

4.    Enter the controller IP address in the LMS IP field.

5.    Click Apply.

In the CLI

On the master controller:

ap system-profile <profile>

   lms-ip <ipaddr>


ap-group <group>

   ap-system-profile <profile>


ap-name <name>

   ap-system-profile <profile>


Configuring the Master Controller for Redundancy

The master controller in the Aruba user-centric network acts as a single point of configuration for global policies such as firewall policies, authentication parameters, RF configuration to ease the configuration and maintenance of a wireless network. It also maintains a database related to the wireless network that is used to make any adjustments (automated as well as manual) in reaction to events that cause a change in the environment (such as an AP becoming unavailable).

The master controller is also responsible for providing the configuration for any AP to complete its boot process. If the master controller becomes unavailable, the network continues to run without any interruption. However, any change in the network topology or configuration will require the availability of the master controller.

To maintain a highly redundant network, the administrator can use a controller to act as a hot standby for the master controller. The underlying protocol used is the same as in local redundancy, that is, VRRP.

The following is a configuration example for the “initially-preferred master”. 

vrrp 22

   vlan 22

   ip address

   priority 110


   authentication password

   description Preferred-Master

   tracking master-up-time 30 add 20

   no shutdown

The following configuration is the corresponding VRRP configuration for the peer controller.

vrrp 22

   vlan 22

   ip address

   priority 100


   authentication password

   description Backup-Master

   tracking master-up-time 30 add 20

   no shutdown

Use the following commands to associate the VRRP instance with master controller redundancy.

Table 97  VRRP Commands (Continued)




Enter the master-redundancy context.

   master-vrrp <id>

Associates a VRRP instance with master redundancy. Enter the virtual router ID of the VRRP instance.

   peer-ip-address <ipaddr> ipsec <key>

Loopback IP address of the peer controller for master redundancy.

The pre-shared key secures communication between the master controllers. Specify a key of up to 64 characters.

masterip <ipaddr> ipsec <key>

Configures the master IP address and pre-shared key on a local controller for communication with the master controller.

Configure this to be the virtual IP address of the VRRP instance used for master redundancy.

All the APs and local controllers in the network should be configured with the virtual IP address as the master IP address. The master IP address can be configured for local controllers during the Initial Setup. The controller will require a reboot after changing the master IP on the controller.

If DNS resolution is the chosen mechanism for the APs to discover their master controller, ensure that the name “aruba-master” resolves to the same virtual IP address configured as a part of the master redundancy.

Configuring Database Synchronization

In a redundant master controller scenario, you can configure a redundant pair to synchronize their WMS and local user databases. In addition, you can also synchronize RF Plan data between the pair of controllers. You can either manually or automatically synchronize the databases.

When synchronizing the databases, Aruba recommends that you also synchronize RF plan data.

When manually synchronizing the database, the active VRRP master synchronizes its database with the standby. The command takes effect immediately.

When configuring automatic synchronization, you set how often the two controllers synchronize their databases. To ensure successful synchronization of database events, you should set periodic synchronization to a minimum period of 20 minutes.

In the WebUI

1.    On each controller, navigate to the Configuration > Advanced Services > Redundancy page.

2.    Under Database Synchronization Parameters, do the following:

a.    Select the Enable periodic database synchronization check box. This enables database synchronization.

b.    Enter the frequency of synchronizing the databases. Aruba recommends a minimum value of 20 minutes.

c.    By default, RF Plan data is also synchronized. Aruba recommends that you always enable this option.

3.    Click Apply.

In the CLI

Use the following commands to configure database synchronization.

Table 98  Database synchronization commands (Continued)



database synchronize

This enable mode command manually synchronizes the databases and takes effect immediately.

database synchronize rf-plan-data

This config mode command includes RF plan data when synchronizing databases. This data is included by default.

database synchronize period <minutes>

This config mode command defines the scheduled interval for synchronizing the databases.

To view the database synchronization settings on the controller, use the following command:

show database synchronize

Incremental Configuration Synchronization

Typically when the master and the local is synchronized, the complete configuration is sent to the local. You can, now send only the incremental updates to the local by using the following CLI commands

In the CLI

Use the following commands for incremental configuration synchronization:

Table 99  Incremental Configuration Synchronization Commands (Continued)



cfgm set sync-type <complete>

The master sends full configuration file to the local.

cfgm set sync-type <snapshot>

The master sends only the incremental configuration to the local.

Note: By default, this configuration is enabled.

cfgm set sync-command-block <number>

To configure the number of command-list blocks. Each block contains a list of global configuration commands for each write-mem operation. By default, the number is 3.

show master-configpending

To show a list of global commands, which are not saved but are sent to the local.

clear master-local-session <A.B.C.D>

To manually push the full configuration to the local.

Configuring Master-Local Controller Redundancy

This section outlines the concepts behind a redundancy solution where a master can act as a backup for one or more local controllers and shows how to configure the Aruba controllers for such a redundant solution. In this solution, the local controllers act as the controller for the APs. When any one of the local controllers becomes unavailable, the master takes over the APs controlled by that local controller for the time that the local controller remains unavailable. It is configured such that when the local controller comes back again, it can take control over the APs once more.

This type of redundant solution is illustrated by the following topology diagram.

This solution requires that the master controller have Layer-2 connectivity to all the local controllers.

Figure 80  


Redundant Topology: Master-Local Redundancy

The network in Figure 80, the master controller is connected to the local controllers on VLANs 1 through n through a Layer-2 network. To configure redundancy as described in the conceptual overview for master-local redundancy, configure VRRP instances on each of the VLANs between the master and the respective local controller. The VRRP instance on the local controller is configured with a higher priority to ensure that when available, the APs always choose the local controller to terminate their tunnels.

The following example configuration of the master controller in such a topology for one of the VLANs (in this case VLAN 22).

vrrp 22

   vlan 22

   ip address

   priority 100


   authentication password

   description Master-acting-as-backup-to-local

   tracking master-up-time 30 add 20

   no shutdown

The following example configuration on the corresponding local controller.

vrrp 22

   vlan 22

   ip address

   priority 110


   authentication password

   description local-backed-by-master

   no shutdown

To configure APs, configure the appropriate virtual IP address (depending on which controller is expected to control the APs) for the LMS IP address parameter in the AP system profile for an AP group or specified AP.

As an example, the administrator can configure APs in the AP group “floor1” to be controlled by local controller 1, APs in the AP group “floor2” to be controlled by local controller 2 and so on. All the local controllers are backed up by the master controller. In the AP system profile for the AP group “floor1”, enter the virtual IP address ( in the example configuration) for the LMS IP address on the master controller.

You configure APs on the master controller.

Configuration changes take effect only after you reboot the affected APs; this allows them to reassociate with the local controller. After rebooting, these APs appear to the new local controller as local APs.

Note:this release has not been updated since the release of the pdf