AOS-8.x supports centralized licensing for the following topologies, where:

a Mobility Conductor acts as a licensing server to all its associated managed devices, stand-alone controllers, or another Mobility Conductor acting as a licensing client.

a stand-alone controller acts as a licensing server to other stand-alone controllers.

Mobility Conductor uses licensing pools to distribute licenses to a large number of managed devices across geographic locations. By default, all managed devices associated to Mobility Conductor share a single global pool of all the sharable licenses added to that Mobility Conductor. However, AOS-8 also allows you to create additional licensing pools at a configuration node, allowing a group of managed devices at or below that configuration level to share licenses among themselves, but not with other groups.

The following example shows how licenses can be allocated within one or more license pools. The following examples use only AP licenses for simplicity, but the same methodology applies to all sharable licenses. For more information and additional examples for licensing pool types, see Licensing Pools.

If you create a license pool for the configuration node /USA, as shown in Figure 1, the four managed devices below this node use licenses from the /USA pool, while the other managed devices continue to use the global pool. If the /USA license pool is allocated 40 of the 100 AP licenses installed on Mobility Conductor, the four managed devices using the /USA pool can share 40 AP licenses from Mobility Conductor. The global license pool now contains only 60 of the AP licenses from Mobility Conductor.

Figure 1  Managed Nodes Use Global or Custom License Pools

 

A primary and backup Mobility Conductor connected on the same broadcast domain using the Virtual Router Redundancy Protocol (VRRP Virtual Router Redundancy Protocol. VRRP is an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN.) can share a single set of licenses. Managed devices on the network connect to Mobility Conductor using the VRRP Virtual Router Redundancy Protocol. VRRP is an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. virtual IP address configured for that set of redundant servers. The primary Mobility Conductor uses the configured virtual IP address by default. However, if the primary Mobility Conductor becomes unavailable, the secondary Mobility Conductor will take ownership of the virtual IP address, allowing managed devices to retain seamless connectivity to a Mobility Conductor device.

Only one backup Mobility Conductor can be defined for each primary Mobility Conductor.

To configure the automatic database synchronization period between the primary and backup Mobility Conductor, access the mobility conductor node hierarchy via the command-line interface and run the command database synchronized period <time-interval>.

For example,

(host) [mynode] (config) #change-config-node mm

(host) [mm] (config) #database synchronize period 25

The example below shows a primary and backup license server connected using VRRP Virtual Router Redundancy Protocol. VRRP is an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN.. Licenses must be installed on the primary Mobility Conductor, but are shared between that redundant pair. If the primary Mobility Conductor had 32 AP licenses, 32 PEFNG Policy Enforcement Firewall. PEF also known as PEFNG provides context-based controls to enforce application-layer security and prioritization. The customers using Aruba mobility controllers can avail PEF features and services by obtaining a PEF license. PEF for VPN users—Customers with PEF for VPN license can apply firewall policies to the user traffic routed to a controller through a VPN tunnel. licenses, and 32 xSec licenses installed, both Mobility Conductors would share a combined global pool of 32 AP, 32 PEFNG Policy Enforcement Firewall. PEF also known as PEFNG provides context-based controls to enforce application-layer security and prioritization. The customers using Aruba mobility controllers can avail PEF features and services by obtaining a PEF license. PEF for VPN users—Customers with PEF for VPN license can apply firewall policies to the user traffic routed to a controller through a VPN tunnel., and 32 xSec licenses. By default, any managed devices connected to this pair of redundant servers use licenses from this shared license pool.

 

The sharable licenses for all managed devices associated with a Mobility Conductor are managed through the Mobility Conductor license table. The information in this table is then shared with all managed devices as a pool of available licenses. When a managed device uses a license in the available pool, it communicates this change to the Mobility Conductor, which updates the license pool information, and sends the updated information to the managed devices.

If a controller had previously installed sharable licenses before it was added to a Mobility Conductor as a managed device, those licenses are no longer usable on a managed device. These license keys must be added to the Mobility Conductor and then Mobility Conductor WebUI and then assign them to the Managed node.

Those license keys must be regenerated and associated with to a managed device or licensing pool using the Mobility Conductor WebUI.

When a new AP associates with managed devices, the managed devices sends updated licensing information to Mobility Conductor. Mobility Conductor then recalculates the available total for that pool, and sends the revised license count back to the managed devices. If a managed device uses an AP license from the license pool, it also consumes a PEFNG Policy Enforcement Firewall. PEF also known as PEFNG provides context-based controls to enforce application-layer security and prioritization. The customers using Aruba mobility controllers can avail PEF features and services by obtaining a PEF license. PEF for VPN users—Customers with PEF for VPN license can apply firewall policies to the user traffic routed to a controller through a VPN tunnel. and an RFProtect license from the pool, even if that AP has not enabled any features that would require that license. A managed device cannot use more licenses than what is supported by its controller platform, regardless of how many licenses are available in the license pool.

 

Starting from AOS-8.2.0.0, Mobility Conductor supports multi-version licensing, which allows a managed device to run a different version of AOS-8.x software than the primary (and backup) Mobility Conductor. If a license is introduced in a newer version of AOS-8, Mobility Conductor can still distribute licenses to licensing clients running an older version of AOS-8, even if the managed device does not recognize the newer license type.

In Mobility Conductor Redundancy, the standby Mobility Conductor becomes the standby license server. You must enable database synchronization on both active and standby Mobility Conductors for the license database to synchronize.

Managed devices can continue to operate as usual in the event that a managed device fails to contact the Mobility Conductor. The following sections describe failover behaviors.

Mobility Conductor Fails Over to a Backup Mobility Conductor

If the primary Mobility Conductor fails, the backup Mobility Conductor will retain the shared license limits until the backup Mobility Conductor reboots. If both the primary and the backup Mobility Conductor fail, or if the backup Mobility Conductor reboots before the primary Mobility Conductor comes back up, managed devices will retain the license limits sent to them by Mobility Conductor for 30 days.

Although a managed device retains its licensing information for 30 days after it loses contact with the Mobility Conductor, if the managed device reboots at any time during this 30-day window, the window will restart, and the managed device will retain its information for another 30 days.

Mobility Conductor Must be Replaced

If you need to replace a stand-alone Mobility Conductor, the keys installed on the previous Mobility Conductor must be regenerated and added to the new Mobility Conductor. You do not need to reinstall keys on Mobility Conductor if it is using a redundancy solution with a backup Mobility Conductor, as the replacement Mobility Conductor will synchronize its licensing database with the backup Mobility Conductor once the replacement Mobility Conductor comes back online.

Mobility Conductor is Unreachable

If a managed device does not receive three consecutive heartbeats from the Mobility Conductor, it assumes that Mobility Conductor is down, but continues to use the licenses it received from its Mobility Conductor license pool. When a managed device is unable to reach a license server for 30 consecutive days, it removes any shared licenses pushed to it from Mobility Conductor. If the 30-day window has passed and the managed device does not have enough installed licenses for all of its associated APs, the managed device will nonetheless continue to support each AP. However, when an AP reboots and its managed device does not have enough licenses that AP will not come up.

For more information on replacing a managed device, see Replacing a Controller.

Managed Device is Unreachable

Mobility Conductor sends keepalive Signal sent at periodic intervals from one device to another to verify that the link between the two devices is working. If no reply is received, data will be sent by a different path until the link is restored. A keepalive can also be used to indicate that the connection should be preserved so that the receiving device does not consider it timed out and drop it. heartbeats between the license server and the licensing client controllers every 30 seconds. If Mobility Conductor fails to receive three consecutive heartbeats from a client, it assumes that the licensing client is down, and that any APs associated with that client are also down or have failed over to another controller. Therefore, Mobility Conductor adds any licenses used by that client back into the available pool of licenses.

The WebUI of the licensing client and Mobility Conductor display a warning message when a licensing client and Mobility Conductor are unable to communicate.

AP Fails Over to another Licensing Client

If an AP fails over from one client controller to another, the AP will be allowed to come up even if there aren’t sufficient licenses present on the backup controller. APs continue to stay active until they reboot; however, if there are not sufficient available licenses to bring up an AP after it reboots, that AP will not become active.