Higher Education

Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.

Re: Nested AP groups

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.


Bruce Osborne - Wireless Engineer
ACCP, ACMP

All opinions written here are my own and do not necessarily reflect the views and opinions of my employer or Aruba Networks

Super Contributor I

Re: Nested AP groups

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.)

==========
Ryan Holland, ACDX #1 ACMX #1
The Ohio State University

Re: Nested AP groups

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.

 


Jerrod Howard
Distinguished Technologist, TME
Super Contributor I

Re: Nested AP groups


@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.

==========
Ryan Holland, ACDX #1 ACMX #1
The Ohio State University
Regular Contributor I

Re: Nested AP groups

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.

New Contributor

Re: Nested AP groups


@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"

Regular Contributor I

Re: Nested AP groups

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

Super Contributor I

Re: Nested AP groups

(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. :)

==========
Ryan Holland, ACDX #1 ACMX #1
The Ohio State University
Highlighted
Super Contributor I

Re: Nested AP groups


@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.

==========
Ryan Holland, ACDX #1 ACMX #1
The Ohio State University

Re: Nested AP groups

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.


Bruce Osborne - Wireless Engineer
ACCP, ACMP

All opinions written here are my own and do not necessarily reflect the views and opinions of my employer or Aruba Networks

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: