arubaos 8: best practices with hierarchical configuration · arubaos 8: best practices with...

ArubaOS 8: Best Practices withHierarchical ConfigurationUnderstanding and Organizing your system

Ben LoweWLAN Software [email protected]

JUNE 2019

2@ArubaEMEA | #ATM19EMEA

Before We Get StartedMoving from AOS 6 to AOS 8 is a migration, NOT an upgrade!

Configuration will be erased with firmware upgrade

AOS6 → AOS8

Careful planning required

Architectural redesignAudit and Clean residual

configuration

Consult your Aruba SE


Agenda

• AOS 8 Components and Vocabulary

• Mobility Master Layout and Hierarchy

• Why and When to create sub-folders

• What Goes Where

• Practical Examples – using the hierarchy

• Viewing the Hierarchy and Configuration

• Limitations and Gotchas

• High Level Migration Steps


AOS 8 Components and Vocabulary


Mobility Master (MM)

AirMatch

WMS

Traffic Analysis

UCC Visibility

AirGroupWeb Content

Classification

Virtual or Hardware appliance

• If a VM, must be sized appropriately or it will revert to appropriate MM device count.This is a common issue → use the show inventory command to confirm capacity.

Up to 100k clients, up to 10k access points, up to 1000 controllers, multiple clusters

MM the management and control plane for the entire system, and all config is done here


Mobility Master (MM)

If the MM goes down the controllers managed by it will stay up and continue to function but you will lose –

• Centralized services

• Ability to apply configuration changes

• Ability to provision new controllers and APs

AirMatch

WMS

Traffic Analysis

UCC Visibility

AirGroupWeb Content

Classification


Managed Controller (MC)…aka Mobility Controller or Managed Device (MD)

Any of the currently shipping 7000 or 7200 series controllers or VM based Virtual Mobility Controllers (VMC).

MCs are the forwarding plane for the users, APs, and switches that they manage.

Other than the initial startup wizard (in CLI), no configuration is required to be pushed to MCs. This

establishes the connectivity for the first time by IPSec.

• If you fat finger anything in the start up script on the MC that affects connectivity to the MM (IP, subnet mask, DFGW,

MM IP or IPSec passphrase) you will need to fix it before moving on.

If connectivity to the MM is lost the, MC continues to function but some centralized functionality is lost.


Clustering Managed Controllers

72XX series – up to 12 controllers in a single cluster

70XX series – up to 4 controllers in a single cluster

Mix of 70XX and 72XX – up to 4 controllers in a single cluster (not recommended!)

Virtual MC – up to 4 in a single cluster

• You can go up to 12 but it doesn’t make sense to build 12 VM’s when you can build a VMC that supports up to 3000

devices

• Hardware MCs are preferred over VMCs to avoid any potential issues with your virtual machine environment,

especially if your VM environment is managed by another team

Hitless failover requires all MCs in a cluster to be L2-connected.


Understanding the Mobility Master Layout and Hierarchy


Mobility Master (MM) Layout and HierarchyTwo Main Branches

Common Configuration to ALL systems MM’s and MD’s

DO NOT USEApplies to all devices on the system

/md

/

Common Configuration to all MM’s SNMP, NTP, Airwave, DNS Servers, Licensing

Common Configuration to all MD’s

DO NOT USEApplies to all MD’s on the system

/mm

/mm/mynode

Configuration specific to the MM that you are logged into currentlyIP Address(es), DFGW, Hostname


Configuration is inherited down the hierarchy

Configuration in the tree will apply to all devices and/or profiles below it in the hierarchy

A configuration component that is lower in the hierarchy will supercede the same component that is found higher in the tree


Split Cluster

Mobility Master (MM) Layout and HierarchyMD Tree, Where the Magic Happens!

/md

/md/company_x/Chicago/research_building

/md/company_x/Chicago/md/company_x/new_york

/md/company_x/dfw

/md/company_x

/md/company_x/Split

/md/company_x/Split/<MAC Address>

/md/company_x/Split/<MAC Address>

Example of Location Based Structure


Why and When to Create Sub-Folders


Why Create New SubFolders

• Any time you have one or more controllers (in a cluster) and need to logically separate configuration parameters (Otherwise, use AP-Groups)

• It is possible to create multiple clusters in the same folder but usually a bad idea for future proofing as you may want to add different configuration to a site at some point in the future

• Easier to do it the right way versus the wrong way and adding lots of bandages as you go


How to Create a New Sub-Folder

Click the + button next to the folder that you want to

create a new folder under

Select group, name it and click Submit


Creating Subfolders and Planning

So you got your MM setup and you’re ready to get going…”Let’s do this!!!”

STOP!!!

Take a few days and carefully think how this should look in two years. Then, plan accordingly

• There are usually several different ways to organize any system and the MM is no exception

• Many customers with limited locations within a region, like university campuses, will organize by function (Residence Halls, classrooms and lecture halls, athletics)

• Many enterprise customers, which have many medium-large sites, will organize by location

• Retailers may organize by function or location (or both) depending on whether or not their locations have controllers


What Goes Where


Mobility Master (MM) Layout and HierarchyTwo Main Branches

Common Configuration to ALL systems MM’s and MD’s

DO NOT USEApplies to all devices on the system

/md

/

Common Configuration to all MM’s SNMP, NTP, Airwave, DNS Servers, Licensing

Common Configuration to all MD’s

DO NOT USEApplies to all MD’s on the system

/mm

/mm/mynode

Configuration specific to the MM that you are logged into currentlyIP Address(es), DFGW, Hostname


/md/company_x

/

/md

/md/company_x

Common configuration to entire company or division

• SNMP and Airwave (if centralized)• Org wide VAP Profiles (ESSIDS)• Org wide SSID Profiles• Org wide AAA Profiles• Org standard ARM and Radio Profiles• Org Standard netdestinations• Org Standard NTP servers• Org custom netservices• Org standard ACL’s• Org standard user roles• Org standard regulatory domain profiles• Any other high level standard profiles that

may be used


/md/company_x/Chicago

/md

/md/company_x/chicago

Inherits all above configuration in the tree

Site Specific Configuration

• SNMP and Airwave (if site specific)• AAA Profile using Chicago Auth Servers

applied to Chicago AP-Group using inherited VAP and radio profiles

• Site specific ESSID’s and related profiles• Site specific RF profiles• Any other site specific configuration• Cluster Configuration

/md/company_x

Chicago Cluster Configuration

Note that this is the logical container for the cluster configuration so it will apply to both MDs….the physical MD resides in it’s own container one level down….see next slide


/md/company_x/Chicago/Device<MAC>

/md/company_x/chicago/ <controller MAC Address>

/md/company_x

/md/company_x/chicago


Controller Specific Configuration (node)

• IP Address(es)• DFGW• LACP configuration• Cluster membership• Hostname

/md/company_x/chicago/ <controller MAC Address>

MD-CHI-1

MD-CHI-2


/md/company_x/Chicago/Research_Building

/md/company_x/Chicago/research_building


Building Specific Configuration

• Building specific ESSID’s and related profiles

• Building specific RF profiles• Any other building specific configuration• Cluster configuration

/md/company_x/Chicago

/md/company_x


…/Chicago/Research_Building/Device<MAC>

…./research_building/ <controller MAC Address>

/company_x

/company_x/chicago/research_building


Controller Specific Configuration (node)

• IP Address(es)• DFGW• LACP configuration• Cluster membership• Hostname

/research_building/ <controller MAC Address>

MD-CHI-1

MD-CHI-2


Using the Hierarchy – Practical Examples


National Corporation With Regionalized Auth Servers

md/company_x

wlan virtual-ap Corp

aaa-profile aaa_corp_east

Vlan 100

ssid-profile corp_ssid_standard

broadcast-filter all

md/company_x/chicago


aaa-profile aaa_corp_central

<inherited>

<inherited>

<inherited>


Different VLAN Per Site

md/company_x


aaa-profile aaa_corp_east

Vlan 100

ssid-profile corp_ssid_standard

broadcast-filter all

md/company_x/chicago


aaa-profile aaa_corp_central

VLAN 189 (or use VLAN names)

<inherited>

<inherited>


Different Airwave, Time and name Servers Per Region

md/west mgmt-server primary-server 10.10.1.203 profile default-amp transport udp

ntp server 10.10.10.44 iburst

ip name-server 10.10.10.44


/md/centralmgmt-server primary-server 192.168.1.13 profile default-amp transport udp




/md/eastmgmt-server primary-server 172.26.1.86 profile default-amp transport udp





Large University with Several Different Constituencies

Main Campus

Residence Halls

Medical School and Hospital

• Research Facility

Athletics

• Stadium


Large University Layout and Hierarchy

/md/edu-u

/md/edu-u/main_campus

Main Campus Cluster

/md/edu-u/res_halls

Res Halls Cluster

Use AP Groups for Research Facility

/md/edu-u/medical

Medical Cluster

/md/edu-u/athletics

Athletics Cluster

/md/edu-u /athletics/stadium

Stadium Cluster


University Config Structure /md/edu-u

/md/edu-u• University wide ESSIDS and corresponding profiles

• edu-u• Eduroam

• SNMP and Airwave (if centralized)• University wide VAP Profiles (ESSIDS)• University wide SSID Profiles• University wide AAA Profiles• University standard ARM and Radio Profiles• University Standard netdestinations• University Standard NTP servers• University custom netservices• University standard ACL’s• University standard user roles• University standard regulatory domain profiles• Any other high level standard profiles that may be used


Large University /md/edu-u/main_campus

/md/edu-u

/md/edu-u/main_campus

Main Campus Cluster

• Campus-wide ESSIDS and corresponding profiles• edu-u• eduroam

• Airwave server for Main Campus• Main Campus ESSIDS and corresponding profiles

• edu-u• Eduroam• Projectors (uses a PSK)


Large University /md/edu-u/res_halls

/md/edu-u• Campus-wide ESSIDS and

corresponding profiles• edu-u• eduroam

/md/edu-u/res_halls

Res Halls Cluster

• Airwave Server for Residence Halls• Main Campus ESSIDS and corresponding profiles

• edu-u• eduroam• edu-u-peripherals (game systems, AppleTVs, Rokus, etc.)


Large University /md/edu-u/medical

/md/edu-u • Campus-wide ESSIDS and corresponding profiles• edu-u• eduroam

Use AP Groups for Research Facility

/md/edu-u/medical

Medical Cluster

• Airwave Server for Medical School• Main Campus ESSIDS and corresponding profiles

• edu-u• eduroam• med_devices• med_voice

ap-group research_facilityVAPs (ESSIDs) for • edu-u• eduroam• med_devices• med_voice

research_medical


Large University /md/edu-u/athletics

/md/edu-u • Campus-wide ESSIDS and corresponding profiles• edu-u• eduroam

/md/edu-u/athletics

Athletics Cluster

• Athletics ESSIDS and corresponding profiles• edu-u• eduroam• Athletics_Staff• Guest

/md/edu-u/athletics/stadium

Stadium Cluster

• Stadium ESSIDS and corresponding profiles• edu-u• eduroam• Athletics_Staff• Guest• Ticketing


Viewing the Hierarchy and Configuration


Who Moved My Cheese?

Avoid putting configuration at the Managed Network (/md) level


Viewing Configuration in the GUI


Viewing Configuration in the CLI

If you use the CLI, you will have to get out of the habit of using ‘show run’ to view the controller configuration

Show configuration node-hierarchy

• Shows the structure of the system that you’ve created

Show configuration committed

• Shows the configuration that has been configured only in the tree location that you are currently in (does not show inherited configuration)

Show configuration effective (path)

• shows configuration in the tree location you are in as well as all inherited configuration from above in the tree

Show configuration effective (path) detail

• shows configuration in the tree location you are in as well as all inherited configuration from above in the tree with location the configuration is located in

Show configuration pending

• shows configuration that will be pushed after ‘write mem’


Viewing Configuration in the CLIShow configuration node-hierarchyShows default folders and entire structure that you have created all the way down to each MD


Viewing Configuration in the CLIShow configuration committedShows the configuration that has been configured only in the tree location that you are currently in (does not show inherited configuration)


Viewing Configuration in the CLIShow configuration effective shows configuration in the tree location you are in as well as all inherited configuration from above in the tree

Doing this at the MD level (deepest part of the hierarchy will show you all configuration

that applies to this managed device


Viewing Configuration in the CLIShow configuration effective detailshows configuration in the tree location you are in as well as all inherited configuration from above in the tree and the location that it is inherited from


Viewing Configuration in the CLIShow configuration pendingshows configuration pending but not committed

Notice the Carrot Symbol, it tells you that

you have pending configuration


To dump pending configuration that you don’t want to apply

Use the configuration purge-pending-config command (Must be in configure mode!)


Limitations and Gotchas


Configuration Parameters that Cannot be Modified at a Lower Level in the Hierarchy

netdestinations

access control lists

user-roles

aaa-server-groups

aaa-server ip addresses

aaa user derivation

control-plane security


Common Mistakes and Gotchas

Proper resources not allocated to MM resulting in a lower total device count (show inventory)

Making a mistake in the MD startup script resulting in MD failing to connect to MM (factory default and repeat)

Not carefully planning your desired MM layout

• Remember to think about how it will look a year out

• Think about all the “what if’s”

• Easy to create sub-folders but at some point you enter the “event horizon” where it becomes a challenge to cleanup

• …..but the good news is you can stand up another set MM’s and start over if needed later on

If this is a lower number than what you are

licensed for then your VM is not spec’ed

appropriately


High Level Migration TipsAOS 6 → AOS 8


Migration is relatively simple and safe if done correctly

1. Leave your existing AOS 6 environment in place for fallback during migration if needed

2. Build a new AOS 8 environment using spare controllers

3. License conversion is “relatively” easy on the website and will not affect the current AOS 6 deployment

4. Take your time to clean up your configuration. Build your hierarchy and shiny new configuration on the new AOS 8 MM.

5. When ready to migrate controllers, go to existing AOS 6 APs and set the aruba-master and lms-ip to the VRRP-VIP of your AOS 8 controller cluster (NOT the MM).

6. The APs will find the AOS 8 controllers, upgrade, reboot, and come back up on AOS 8 themselves.

7. This is very simplified but this is the high level….CONSULT your Aruba SE or partner!

AB218 yesterday

Please give us your feedback

1. Click on "Agenda" icon

2. Search for the session by session ID or by selecting the session date

3. Click on the session

4. Tap the "Survey" icon


Thank You

Still not a part of the Airheads

Community? Sign up today!

community.arubanetworks.com


arubaos 8: best practices with hierarchical configuration · arubaos 8: best practices with...

Documents