Hierarchical Configuration
Overview
ArubaOS running on the Mobility Conductor (MCR), uses a centralized, multi-tiered architecture that consolidates all deployment models (e.g. all-conductor, single-conductor/multiple-managed-devices, and multiple-conductors/managed-devices) through a dedicated management console. Network configurations can be implemented and distributed from the Mobility Conductor through zero-touch provisioning (ZTP) to all Managed Devices. The Mobility Conductor also allows for licensing pools that can allocate licenses to individual Managed Devices based on the site requirements
Concept of configuration hierarchy as each endpoint can be used to configure a particular node
All the configuration for the MDs managed by the MCR goes into the MCR
MCR specific configuration hierarchy
The MCR's configuration itself goes under the /mm and/or /mynode group. These are default hierarchy groups
/md is the highest level of configuration node for Managed Devices managed by Mobility Conductor
/md group is the highest node in the Managed Device configuration hierarchy.
An additional level of hierarchy can be added for better configuration organization based on site location
Recommendation
It is recommended not to add any configuration under the /md level
It is typical to add 3 to 4 hierarchy levels for further granularity and parking the more common configuration items at a higher node based on the deployment
Device level configuration is config that is applicable to the device only - for e.g. hostname. The goal with this model is reduce device level configurations as much as possible
Device specific configurations reside at the device level node
Note
Knowledge of the CLI is required to some extent as all objects are based on the equivalent CLIs
Configuration Best Practices
It is highly recommended to leverage the hierarchical configuration model for better organization and minimizing site level changes. This concept is important to understand to operate the REST API on the Wireless LAN Managed Devices and the Mobility Conductor, since the REST API calls have to be made at the right level in the hierarchy, by specifying the node-path in the http API call request.
As general best practice large enterprises should configure common set of features at a higher level in the node hierarchy and keep device level overrides at the minimum. This ensures minimal deployment-wide impact if a configuration change needs to be made that is applicable site-wide.
Find more about ArubaOS in the datasheet below.
- Complete documentation of various containers and objects that are supported in Mobility Conductor (MCR) can be found in the API Reference section. The MCR itself contains API documentation that can accessed from of the MCR using it's IP address, the URL of the API doc available on the MCR is shown below.
https:// <mcr-ip> :4343/api
Updated about 1 year ago