Higher Education

I think I know the answer to this, but wanted to make sure I hadn't missed something.

With AOS 8 is it possible to have nested AP groups, much like the controller nesting? For our campus it would be neat to have accommodation or academic or library top levels with individual building groups below that. Another useful function would be to have a building or area AP group but then nest a group for a specific model of AP within that.

Nested AP is not something that exists in ArubaOS 8.x  I am moving this to Higher Education so that the community can comment on how they have their own ArubaOS 8.x networks configured to solve this issue.

To be clear, the heirarchy is designed to create WLANs that are common as high up as possible.  AP-Groups are still used to differentiate between the different types of areas that exist within that heirarchy like libraries.

I think this could be a useful organizational feature for large deployments & for grouping buildings that have different environments needing several ap-groups.

Agreed. The controller/md hierachy is a good approached for distributed sites, where controllers are in multiple locations.

In our case, and I suspect many campus environments we don't have and don't want multiple controller/cluster configs. 

I can continue the same approach as with 6.5, but we end up with an awful lot of AP profiles and it's messy.

---

@MatthewSeymour wrote:

Agreed. The controller/md hierachy is a good approached for distributed sites, where controllers are in multiple locations.

 

In our case, and I suspect many campus environments we don't have and don't want multiple controller/cluster configs. 

 

I can continue the same approach as with 6.5, but we end up with an awful lot of AP profiles and it's messy.

---

MatthewSeymor, please state an example.

We use clusters for functionality. We hae one Campus Cluster.

We have several buildings within that cluster & many buildings have multiple ap-groups. The large number of ap-groups makes the configuration unwieldy, IMHO.

Bosborne:

What is the difference between ap-groups?

Sounds very similar to our setup.... though we don't have aos8 deployed yet.

An example would be to be able to group all our accommodation APs into a single "accommodation" group, but then have further settings nested within that for specific buildings, that allow us to enable a VAP in a specific area. We could enable a conferences VAP in the appropriate accommodation only when a conference event is taking place. That's just one example. 

Actually, from what I can see so far (correct me if I'm wrong) AOS 8 makes this even worse because it isn't possible to set override for an individual AP. So the proliferation of AP groups is going to be nasty.

---

@MatthewSeymour wrote:

Actually, from what I can see so far (correct me if I'm wrong) AOS 8 makes this even worse because it isn't possible to set override for an individual AP. So the proliferation of AP groups is going to be nasty.

---

You still can apply specific settings to individual AP's by using the following command:

(config) # ap-name "ap name"

Thanks. I'll have a play and see how that presents in the gui.

---

@MatthewSeymour wrote:

Thanks. I'll have a play and see how that presents in the gui.

---

From my experience, the GUI doesn't expose everything. We manage via CLI. Learning it would be a worthwhile investment fwiw.

Try & forget about the GUI in AOS8

It is not nearly as useful as the one in older versions & many things need the cli anyway.

I'm sure it isn't meant this way... but this thread now reads as a little condescending.

We've recently had a bit of a tidy up at home and pruned down the recipe books... we had too many ;)

---

@MatthewSeymour wrote:

I'm sure it isn't meant this way... but this thread now reads as a little condescending.

 

Oh, definitely my intent! Perhaps my excitement for the topic pushed me somewhere I didn't mean to go. A thousand apologies for anyone that felt this way!

(Runs laps around the office building as punishment.) 

I'm probably just being over sensitive.... It's all good information.

Historically I think we had a tendency to minimize the number of AP groups, which may make things neater, but it restricts flexibility without reprovisioning APs - and users tend to notice that happening.

I'll take my original idea out back and shoot it, then try and lose my fear of excessive AP group numbers.

I typically make roughly equal use of the CLI and GUI, though my building of our config in AOS8 has probably been more in GUI. 

Your point about less obvious config for a specific AP is fair - I don't like things that will trip me or someone else up later on. I'm tripping over quite enough stuff around here without contributing to it.

Different VIPs with :

1, different minimum data rates.

2, Break out the 5GHz only APs from the dual band ones in an area.

3. Force 2.4 GHz channel selection, in a couple of areas.

I had a response in draft and just noticed Ryan chime in. Not much more I can add. nested AP groups though would almost certainly cause far more issues than they solve. And the current heirarchy is really incredibly flexible if structured properly. Placing the globally used elements higher up in the heirarchy and then defining specifics down lower can REALLY streamline ads/moves/changes down the line. And even if we had nested AP groups, you would be trading that away for nearly the same number of AP groups, likely doubling the config complexity, since you now have to account for inheritance and specificity in overlapping elements.

---

@bosborne wrote:

Different VIPs with :

 

1, different minimum data rates.

2, Break out the 5GHz only APs from the dual band ones in an area.

3. Force 2.4 GHz channel selection, in a couple of areas.

---

For each of your items, we handle those as follows:

1. Different ssid-profiles that trim basic and transmits reads and set probe/auth request thresholds. We entitled these "short", "medium", and "long" for each of our ESSIDs (3 SSIDs x 3 flavors = 9 ssid-profiles/virtual-aps) to coincide with the essential association radius they produce.
2. We have a buildingA group and then a buildingA-no-2.4ghz where we have the dot11g-radio-profile set to spectrum-mode
3. We leverage airmatch freezing to set static channelization

Items 1 and 2 above and the associated profiles are all defined at /md/osu and applied to ap-groups also defined at /md/osu.

It seems that, though I can see a use case others cannot...

What I was hoping to avoid was having as many different AP groups as we currently have but it seems I'll actually require more than ever :(

I feel I'm missing something though, @jhoward when you talk about the hierarchy what are you referring to exactly? 

@Ryan that describes what we do in 6.5. It works but becomes messy and means that applying a change to, say, all our accommodation APs involves changing enough AP groups that it's trivial to miss one.

(I think using specific ap-name configurations is asking to trip over it in the future IMO.)

---

@MatthewSeymour wrote:

*snip*

What I was hoping to avoid was having as many different AP groups as we currently have but it seems I'll actually require more than ever :(

*snip*

@Ryan that describes what we do in 6.5. It works but becomes messy and means that applying a change to, say, all our accommodation APs involves changing enough AP groups that it's trivial to miss one.

---

To put this in context:

(*****Domain1) #show ap-group | include Total
Total:318
(*****Domain2) #show ap-group | include Total
Total:428

We have 746 ap-groups at the moment. And while there are currently 4 of us on my team, I used to manage this with only one other person. ArubaOS makes this extremely manageable and flexible as Jerrod stated. AOS8 doesn't have to change that.

Your point about applying a change becoming nasty...I would disagree. If you want to change a particular building's or set of buildings' configuration, you'd want the flexibility of an ap-group(s) per building in order to selectively decide the locations to receive the change. BUT, if you're deciding to make (for example) a change to standardize on 12-18dBm EIRP for 5GHz instead of 12-15dBm EIRP, you still make that change in the applicable radio-profile, and that change is applied within all ap-groups where that radio-profile is used. If you want to change what data rates you trim, you make that at the ssid-profile and it applies to all ap-groups using the virtual-aps that use that ssid-profile. It's still centralized configuration.

Doubling-down on the cooking analogy:

• ap-groups are cookbooks
• profiles are recipes
• knobs|settings are ingredients

(ACK that I used incredients and recipes differently in an earlier post.)

If you had a dessert cookbook that included cake, pie, and brownies and then you decide to use egg white substitute instead of raw egg in the brownies, you just change that recipe -- no need to touch the cookbook, as it already has that brownie recipe applied.

BTW, I love talking about and comparing Wi-Fi configurations, and I'll be at ATM19, so if you want to chat, hit me up. :)

Here are my two cents on the topic. I welcome any conversation or specific questions.

My philosophy is that configuration and monitoring are not interchangeable and are very difficult constructs to coalesce. The AOS8 hierarchy enables OSU to configure all profiles for ap-group configurations at /md/osu. We then configure vlans and vlan pools at /md/osu/cluster# and then perform specific controller configs at the controller itself.

Like all campuses, we have a mixture of buildings structures and types. To accommodate this, we have various RF and SSID/VAP profiles to manipulate EIRP, data rate trimming, and probe/auth request thresholds as appropriate. These profile "ingredients" are used to come up with one or more ap-groups (read: "recipes") for a building to accommodate those various needs stemmed from environment construction.

Separate from that would be monitoring labels like "Academic" or "Residence Hall" or others. For those, we leverage systems like Airwave, NetInsight, and Splunk to review performance and metrics at that level, in addition to building.

I'd love to hear a specific examples of where ap-group nesting would make sense, as I have yet to hear one. :-/

(For reference, our AOS8 deployment consists of 22 controllers across two different MM topologies with a total of 5 clusters across both. All ap-groups are at the /md/osu level and pushed across the controllers.)

EDIT In response to Bosborne:

Is the grouping for configuration or reporting?  Airwave provides grouping for reporting.  Access points should be grouped based on functionality, and that is the purpose of ap-groups.  In AOS8 the folder structure is just to make those set of ap-groups available for whatever building in a folder needs them.  If a building has several different ap-groups, you put those access points into those different ap-groups.  The naming convention of your access points would let the administrator know what building an access point is in.