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.
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 or . Configurations under the node, which are shared by the redundant Mobility Master pair (primary and standby Mobility Masters), are synced to the standby Mobility Master. Configurations under are synced to individual Mobility Master devices.
The following node operations are allowed on Mobility Master:
: Creates a new node as the child of an existing node in the configuration hierarchy (system-generated or user-created)
: 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).
: 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.
Mobility Master.: Deletes a currently associated device from the configuration hierarchy. This will cause the device to reload and erase all configurations received from
: 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.
: 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.
: Renames the existing node name to the specified name. The node paths of the child nodes under the renamed node are automatically updated.
controller from one group to another group within the hierarchy, without deleting the controller from the Mobility Master.: Allows you to move any
Moving multiple controller or group within the network hierarchy is not supported.
controller or a group in the managed network hierarchy.: Allows you to rename a
Refer to the ArubaOS Command Line Interface Reference Guide for more details on the configuration commands for node and device management.
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 (Mobility Master ( ) nodes are granted editing permissions for Mobility Master.) or
Management users that are configured with permissions to the mynode (Mobility Master and stand-alone controller.) can modify configurations under for the respective
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.
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 node hierarchy, navigate to
2. Click sample template.
3. Enter values in the fields provided in the template.
4. Save the file.
5. Select and navigate to the path where the template is stored.
6. Click . The 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:
If the configurations are not applied successfully, the managed device will rollback to the previous configuration.pop up displays the reason for the failure and the
When devices are added using the bulk edit feature, each template file can include up to 400 devices.
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, or from which you want to copy the configuration files and execute the command, .
2. Execute the command, 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, ,
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 theand 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 188.8.131.52, 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 UIUser 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 ACLsAccess 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.
Starting from ArubaOS 184.108.40.206, 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 button. Else, you can choose to remove the individual configuration overrides at the field level.
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:
The following CLICommand-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
----------- ---- ----
The Mobility Master displays the configuration on the Mobility Master and not on the other nodes or managed devices.command from the
Use the following variants of the show commands to view the configuration information on a node or device level:
—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.
managed device.—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
—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.
managed device or group, that is any configuration changes that are made before executing the 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.—Displays the configuration details which are yet to be committed to the
Mobility Master to the node.—Displays the incremental change in the configuration between the last two synchronizations from the
—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 command.
—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.