Wireless Access

last person joined: an hour ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Back to discussions
Expand all | Collapse all

Aruba Profile Management-Organization

This thread has been viewed 1 times

  • 1.  Aruba Profile Management-Organization

    Posted Oct 06, 2015 10:57 AM

    I was curious if anyone would be willing to share/discuss their "methods" of organizing/documenting their various profiles (VAPs, ARM, SSID, AP System, ACLs, etc) for easy reference - for example: a spreadsheet that easily differentiates the differences between each profile and why it exists. We currently have a separate "AP Group" for each building on campus, with duplicate groups for special purposes - followed by special ARM profiles.

    - Building A

    - Building B

    - Library

    - Library ARM Profile

    - Library - HD

    - Library - HD - No-2.4

     

    As you can imagine, this can get complicated - specially if we ever consider using "AP Specific" profiles. We'd like to get our profile management under control as we're in the process of migrating from Meru to Aruba over the next year. There's probably better ways of using the minimal amount of profiles, that we haven't considered yet.

     



  • 2.  RE: Aruba Profile Management-Organization

    Posted Oct 06, 2015 11:26 AM

    HI,

     

    Yes we can document the profiles by following some best practices. here we should consider controllers as well. are you planning to deploy Local controllers for each building ?

     

    Let me know the details, I can help you on documentation.



  • 3.  RE: Aruba Profile Management-Organization

    Posted Oct 06, 2015 12:05 PM
    dhanraj_puduchery@yahoo.com wrote:

    HI,

     

    Yes we can document the profiles by following some best practices. here we should consider controllers as well. are you planning to deploy Local controllers for each building ?

     

    Let me know the details, I can help you on documentation.

    Hi Venu,

     

    1. We currently have a Master-Local (Administrative/Classroom Buildings) pair with all Aruba APs (650 Currently) terminated to the Local Controller (33 Buildings - 647 APs Deployed) - we'll be adding about 550 APs to another 20 buildings this Fall/Spring.

     

    2. We'll be obtaining another Master-Local Pair specifically for our Residence Halls - 20 Buildings this Fall/Spring/Summer - at about 1600 APs.

     



  • 4.  RE: Aruba Profile Management-Organization

    EMPLOYEE
    Posted Oct 06, 2015 11:39 AM
    @cbjohns wrote:

    I was curious if anyone would be willing to share/discuss their "methods" of organizing/documenting their various profiles (VAPs, ARM, SSID, AP System, ACLs, etc) for easy reference - for example: a spreadsheet that easily differentiates the differences between each profile and why it exists. We currently have a separate "AP Group" for each building on campus, with duplicate groups for special purposes - followed by special ARM profiles.

    - Building A

    - Building B

    - Library

    - Library ARM Profile

    - Library - HD

    - Library - HD - No-2.4

     

    As you can imagine, this can get complicated - specially if we ever consider using "AP Specific" profiles. We'd like to get our profile management under control as we're in the process of migrating from Meru to Aruba over the next year. There's probably better ways of using the minimal amount of profiles, that we haven't considered yet.

     

    Honestly, you could deploy an entire campus with access points in the same ap-group if you had a single controller.  If you need access points to be on more than one controller, that is defined in the ap-system profile, so you would need (1) ap-group for devices on one controller and (1) ap-group for devices on the second controller.  If you need access points to have different mininum and maximum power, you would need a separate ap-group for that.  You can be efficient by having access points that share the same minimum and maximum power be in the same ap-group, so that you do not have to create an ap-group for each building.  If 9 buildings have the same "office building" characteristic, they can all be in the same ap-group; the name of the access point (building-floor-ap) will easily tell everyone which access point is located where.  The ap-group that you put that AP in, will decide its RF characteristics.  If many aps share the same characterisitics, put them all in the same ap-group.  Most users have separate groups for different ap-density like Office, Classroom, Auditorium, and maybe outdoor.  That would mean you would only need 4 ap-groups.

     

    I hope any of that makes sense.

     



  • 5.  RE: Aruba Profile Management-Organization

    Posted Oct 06, 2015 12:21 PM
    @cjoseph wrote:
    @cbjohns wrote:

    I was curious if anyone would be willing to share/discuss their "methods" of organizing/documenting their various profiles (VAPs, ARM, SSID, AP System, ACLs, etc) for easy reference - for example: a spreadsheet that easily differentiates the differences between each profile and why it exists. We currently have a separate "AP Group" for each building on campus, with duplicate groups for special purposes - followed by special ARM profiles.

    - Building A

    - Building B

    - Library

    - Library ARM Profile

    - Library - HD

    - Library - HD - No-2.4

     

    As you can imagine, this can get complicated - specially if we ever consider using "AP Specific" profiles. We'd like to get our profile management under control as we're in the process of migrating from Meru to Aruba over the next year. There's probably better ways of using the minimal amount of profiles, that we haven't considered yet.

     

    Honestly, you could deploy an entire campus with access points in the same ap-group if you had a single controller.  If you need access points to be on more than one controller, that is defined in the ap-system profile, so you would need (1) ap-group for devices on one controller and (1) ap-group for devices on the second controller.  If you need access points to have different mininum and maximum power, you would need a separate ap-group for that.  You can be efficient by having access points that share the same minimum and maximum power be in the same ap-group, so that you do not have to create an ap-group for each building.  If 9 buildings have the same "office building" characteristic, they can all be in the same ap-group; the name of the access point (building-floor-ap) will easily tell everyone which access point is located where.  The ap-group that you put that AP in, will decide its RF characteristics.  If many aps share the same characterisitics, put them all in the same ap-group.  Most users have separate groups for different ap-density like Office, Classroom, Auditorium, and maybe outdoor.  That would mean you would only need 4 ap-groups.

     

    I hope any of that makes sense.

     

    Hi Colin,

     

    Thank you, all of that did make sense. I joined the wireless team (3 engineers total) a little over a year ago when we first started our migration to Aruba. The concept of "AP Groups" was relatively new to us from the Meru point of specific configs (power/channel/etc) for each individual access point. Since we've been deploying slowly from building to building, we went the route of using building specific groups for organiziation/provisioning purposes since each building had different physical characteristics. I do think the minimal groups you described would certainly work for us. We always wondered how other Aruba customers made effective use of ap groups (I remember trying to find a best practices guide at one time). We currently have our APs named to the format you described.

     

    After reading the VRD for High Density and our interest in RAPs (considerations for each having special ARM/SSID/System Profiles (Trimmed Data Rates for Lecture Halls/Bridged Mode for APs that already sit behind a Cisco ASA), reviewing our profile management is something I'm taking a stronger look at moving forward.