Centralized Configuration

Mobility Master uses a centralized configuration application to maintain all configurations under the management domain, eliminating the use of multiple points of contact to apply global and local configurations to each managed device. You can organize all common configurations at a higher level of the hierarchy.

Mobility Master Configuration

The Mobility Master that provides this configuration service to other devices in the network also contains its own configuration. The Mobility Master configuration is obtained through nodes in the hierarchy labeled /mm or /mm/mynode. Configurations under the /mm node, which are shared by the redundant Mobility Master pair (primary and standby Mobility Masters), are synced to the standby Mobility Master. Configurations under /mm/mynode are synced to individual Mobility Master devices.

Allowed Node Operations

The following node operations are allowed on Mobility Master:

Create Node: Creates a new node as the child of an existing node in the configuration hierarchy (system-generated or user-created)

Add Device: Associates a device to an existing node in the hierarchy. This device inherits configurations from all nodes between the root node and the device (node-path).

Delete Node: Deletes an existing user-created node or node without any child nodes. System-generated nodes cannot be deleted. Only leaf nodes without any child nodes can be deleted.

Delete Device: Deletes a currently associated device from the configuration hierarchy. This will cause the device to reload and erase all configurations received from Mobility Master.

Clone Node: Copies the configuration of an existing node into a new node. The new node is created as a child of an existing node in the hierarchy.

Move Node: Moves an existing user-created node in the hierarchy to the specified destination node. System-generated nodes cannot be moved. Ensure the following points while moving a node or device, otherwise the move operation will fail:

The node to be moved is a leaf node and does not have any group node or a device node as a child node under it.

No configuration is pending on the parent nodes of the child node to be moved.

The configuration on the node to be moved is complaint with the configuration in the new ancestor nodes chain.

Rename Node: Renames the existing node name to the specified name. The node paths of the child nodes under the renamed node are automatically updated.

Drag and Drop Node: Allows you to move any controller from one group to another group within the hierarchy, without deleting the controller from the Mobility Master.


Moving multiple controller or group within the network hierarchy is not supported.

Edit Action: Allows you to rename a controller or a group in the managed network hierarchy.

Refer to the ArubaOS Command Line Interface Reference Guide for more details on the configuration commands for node and device management.

Access Permissions

The Mobility Master management domain can be large and widespread across various geographic regions. In a Mobility Master, the editing scope of the admin user can be restricted to individual node-paths within the configuration hierarchy, unlike the legacy ArubaOS management domain where an administrator can modify any configuration in the system.

Each management user is granted editing permissions for a given node, allowing the user to modify the configuration for that node and any child node within its node-path. The user, however, cannot modify any parent nodes or nodes on a different path in the hierarchy. Users can view configurations for any node in the hierarchy to refer to a parent node configuration or verify that the derived configuration for a device matches the parent node configuration.

Management users that are configured with the root (/) or Mobility Master (/mm) nodes are granted editing permissions for Mobility Master.

Management users that are configured with permissions to the mynode (/mm/mynode) can modify configurations under /mm/mynode for the respective Mobility Master and stand-alone controller.

Management users that are configured with permissions to a managed device can modify configurations for that managed device.

Only the management users that are configured with root node level permissions can modify configurations on both Mobility Master and managed devices.

Bulk Edit

The Bulk Edit Support feature enables you to perform a bulk configuration in the Mobility Master. This option helps reduce the time taken to perform configuration tasks individually.

The following procedure describes how to do a bulk edit:

1. In the Managed Network node hierarchy, navigate to Configuration > Tasks > Bulk configuration upload.

2. Click Download sample template.

3. Enter values in the fields provided in the template.

4. Save the file.

5. Select Browse and navigate to the path where the template is stored.

6. Click Submit. The Bulk Configuration Status pop up is displayed with the status of the configurations that are being applied. Once the configurations are applied successfully, a message confirming that the file upload was successful is displayed. The next pop up displays the following details:



Number of devices updated

Total new devices added


If the configurations are not applied successfully, the Bulk Configuration Status pop up displays the reason for the failure and the managed device will rollback to the previous configuration.

When devices are added using the bulk edit feature, each template file can include up to 400 devices.

Bulk Stand-alone Controller Deployment

This feature supports bulk configuration of stand-alone controllers by replacing the configuration files in the stand-alone controllers and rebooting them.

The following procedure describes how to replace the configuration files in the stand-alone controller:

1. Login to the node, /mm or /mm/mynode from which you want to copy the configuration files and execute the command, encrypt disable.

2. Execute the command, show configuration committed and save the configuration to a .cfg file (for example, mmfile.cfg) on the tftp server.

3. Edit the file and copy that file to the controller’s flash from the server using the command,

(host) [mynode] # copy tftp: <IP address> vmccfg1.cfg flash: vmccfg1.cfg

4. Execute the command, replace-config-reboot,

configuration node replace-config-reboot <filename1> <config-path1> <filename2> <config-path2>

For example, configuration node replace-config- reboot mmfile.cfg /mm mynodefile.cfg /mm/mynode


The controller prompts you to upload both the /mm and /mm/mynode files together.

5. Once the command is executed, the stand-alone controller will prompt you to reboot the controller.

6. Reboot the controller and the stand-alone controller will now boot up with the copied configuration.

Override Support in the WebUI

Starting from ArubaOS, the Mobility Master WebUI provides an option to retain or remove overrides for the fields configured under a node. If any field has an overridden value, the UI User Interface. displays a blue dot to the left of the field name. Clicking on the dot, gives you an option to remove the overrides.


Order-dependent configurations, such as roles and ACLs Access Control List. ACL is a common way of restricting certain types of traffic on a physical port., cannot be overridden. These configurations can only be set up once in the network hierarchy.

Support for Viewing Inheritance History in the WebUI

Starting from ArubaOS, the WebUI allows you to view the inheritance details of any configuration at any group or node level. This feature is supported only for configurations that can be overridden. A blue color information icon is displayed in the respective rows of the configuration table under which some configurations are overridden. Clicking on the icon displays the details of the inheritance with a link to the parent node. You can click on the parent node link to navigate to the parent node level. You can choose to remove all the overrides under the selected node level from this pop-up window by clicking the Remove Overrides button. Else, you can choose to remove the individual configuration overrides at the field level.

Validation and Application Processes

When a user enters a configuration into a managed device, the configuration is validated. The validated configuration is accepted by the system but does not take effect until the configuration is committed. When the configuration is being committed, it is stored in the persistent memory, allowing users to verify the configuration before making it operational.

This separation of validation and application processes is applied to both the Mobility Master and managed devices. Since each node can be managed by a different admin user, the commit operation is executed on a per-node basis and follows the configuration hierarchy. For example, if a configuration has a dependency, the dependent configuration must be present on that node or one of the parent nodes .

Configurations are classified as pending configuration or committed configuration. A pending configuration refers to a configuration that has been validated but not yet committed. A committed configuration refers to all configurations that have been committed by the user. Users can view pending configurations at any time to commit, purge, or leave the configuration uncommitted. Pending configurations are only allowed on one node at any given time in a given configuration sub-tree.

This section includes the following topics:

Viewing the Node Hierarchy

The following CLI Command-Line Interface. A console interface with a command line shell that allows users to execute text input as commands and convert these commands to appropriate functions. command displays how the devices and groups are organized at a global level:

(host) [mynode] #show configuration node-hierarchy

The following sample output displays the list of devices and nodes configured under the root node.

Default-node is "/md". Autopark is enabled.

Configuration node hierarchy


Config Node Type Name

----------- ---- ----

/ System

/md System

/md/00:0b:86:99:e2:17 Device

/md/VPNC Group

/md/VPNC/00:1a:1e:01:46:38 Device

/md/VPNC/00:1a:1e:02:03:d0 Device

/mm System

/mm/mynode System


The show running-config command from the Mobility Master displays the configuration on the Mobility Master and not on the other nodes or managed devices.

Viewing Configuration on Nodes

Use the following variants of the show commands to view the configuration information on a node or device level:

show configuration effective—Displays the running configuration of the current node. You can also view the configuration on a specific node from a different node by specifying the absolute path of the node in the command.

show configuration effective detail—Displays the full configuration details on your current node. It also indicates if a configuration is inherited from a group level or local to the managed device.

show configuration committed—Displays the configuration that is only local to a specific node and not inherited from a parent node in the hierarchy. Configurations such as IP addresses and hostnames are some examples.

show configuration pending—Displays the configuration details which are yet to be committed to the managed device or group, that is any configuration changes that are made before executing the write memory command or submitting the pending changes in the WebUI. This is used to review any configuration before it is applied from the Mobility Master to the managed devices. The output of the command is relevant only to the current node.

show configuration partial—Displays the incremental change in the configuration between the last two synchronizations from the Mobility Master to the node.

show configuration similar—Displays the like configuration between two specific nodes or devices. This is useful to verify equal settings between groups or devices. The output displays only the configurations that are same between both nodes. If you are comparing devices, you must use the path as displayed in the output of the show configuration node-hierarchy command.

show configuration diff—Displays the configurations that are different between two specific nodes or devices. A minus sign against a configuration indicates that it is present in the node specified first but absent in the second node. A plus sign indicates that the configuration is absent in the first node but present in the second node.

For more information on various configuration show commands, see ArubaOS 8.x CLI Reference Guide.