Q: How do I configure a 8.0 MM hierarchy deployment?
ASE Link: Go to the solution
A: OBJECTIVE
This solution creates a configuration hierarchy on the Mobility Master.
ACRONYMS USED IN THIS SOLUTION
- MM - Mobility Master
- MC - Mobility Controller (can be MM managed, standalone, etc.)
- MD - Managed Device (an MC managed by MM)
- AP - Access Point
- AOS - Aruba Operating System
ABOUT CONFIGURATION HIERARCHY
- A configuration (config) node is a hierarchical level on the MM at which you would apply a certain configuration.
- Two pre-defined config nodes exist - /mm and /md. These nodes cannot be deleted.
- All configuration related to the MM goes under /mm or /mm/mynode.
- Configuration common to both primary and standby MMs goes under /mm.
- Configuration specific to the MM device goes under /mm/mynode.
- User defined config nodes can be created under /md.
- You can create multiple config nodes under /md where each config node may have different configuration from other nodes under /md. See examples of Building_1344 and Building1322 below.
- Config nodes under /md can be further classified into group nodes and device nodes.
- Group nodes:
- Any user-defined config node under /md can be called a group node.
- For example, both /md/Aruba_Sunnyvale and /md/Aruba_Sunnyvale/Building_1344 are group nodes.
- A config node inherits configuration from all the higher nodes in the hierarchy.
- You can always override configuration received from higher level config nodes. Configuration defined on the lower level config nodes will always take precedence over that defined on the higher level config nodes.
- Device nodes:
- MDs can be parked at any configuration node (/md and below). The resulting config node is called a device node.
- MDs are typically parked under the lowest group node in the configuration hierarchy.
- For example, the device node for an MD with MAC address 11:22:33:44:55:66 parked under group node Building 1344 would look like /md/Aruba_Sunnyvale/Building_1344/11:22:33:44:55:66.
- Configuration on the device node always takes precedence over that on group nodes.
SOME EXAMPLES OF THE HIERARCHICAL CONFIGURATION MODEL
-
SINGLE ORGANIZATION
The first illustration is an example of a configuration hierarchy for a single organization. If this were the ACME organization,then different campuses for ACME would be defined under /md. Each campus may have multiple buildings. If there were a controller per building, each controller x would be parked under the Buildingx group node.
The possible config nodes for this example are -
- /md/mm
- /mm/mynode
- /md/campus1
- /md/campus1/building1
- /md/campus1/building1/<device01's-MAC>
- /md/campus1/building2
- /md/campus1/building2/<device02's-MAC>
- /md/campus1/building3
- /md/campus1/building3/<device03's-MAC>
- /md/campus2
-
MANAGED SERVICE PROVIDER
The second illustration is an example of how an MSP that is managing multiple different organizations would define the configuration hierarchy on MM.
The possible config nodes for this example are -
- /mm
- /mm/mynode
- /md
- /md/acme
- /md/acme/campus1
- /md/acme/campus1/building1
- /md/acme/campus1/building1/<device01-MAC>
- /md/acme/campus1/building2
- /md/acme/campus1/building2/<device02-MAC>
- /md/acme/campus1/building3
- /md/acme/campus1/building3/<device03-MAC>
- /md/acme/campus2
- /md/globex
- /md/globex/campus1
PLATFORM TESTED
ArubaOS 8.0.1.0, build 57204
NOTE
- This solution is not applicable to AOS 6.x deployments.
- This solution is not applicable to a standalone controller deployment in AOS 8.x.
REFERENCES