Wired

last person joined: 2 hours ago 

Bring performance and reliability to your network with the Aruba Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of the ArubaOS-Switch and ArubaOS-CX devices, and find ways to improve security across your network to bring together a mobile first solution.
Expand all | Collapse all

Pre-provision offline campus APs

  • 1.  Pre-provision offline campus APs

    Posted May 22, 2012 01:14 PM

     

    We are on the verge of swapping out a competitor’s APs with AP134s.  Since we have active users on the existing APs we want to minimize outage windows.  Preferably, we would like to pre-provision APs so that they start serving clients minutes after coming online.

     

    The easiest way to do this would be to provision the AP by serial number or wired MAC before the AP hits the controller, then allow it to download code and settings when it comes online in the production environment.  Unfortunately, we cannot find a way to provision an AP which is offline - is there a way to do this?



  • 2.  RE: Pre-provision offline campus APs

    Posted May 22, 2012 01:39 PM

    If you have the MAC address of the APs then you can add them to the database on the master controller and specify the ap-group in which you want them to be provisioned 

     

    (master) #local-userdb-ap add mac-address <mac-address> ap-group <ap_group> ap-name <ap_name>

     

    When the AP contacts the master, it will download the configuration for that specific ap-group



  • 3.  RE: Pre-provision offline campus APs

    Posted May 22, 2012 02:32 PM

    Thanks, that is a great help.  Is there a similar method which will allow me to set antenna gain?



  • 4.  RE: Pre-provision offline campus APs

    Posted May 22, 2012 02:38 PM

    @amb2035 wrote:

    Thanks, that is a great help.  Is there a similar method which will allow me to set antenna gain?


    I do not believe there is a way to pre-provision the antenna gain. 

     

    --

    HT

     



  • 5.  RE: Pre-provision offline campus APs

    Posted Jul 06, 2014 07:31 PM
    Is there an update to this command since the command was depreciated. Anyone have a good excel sheet for deploying campus-ap's


  • 6.  RE: Pre-provision offline campus APs

    Posted Jul 06, 2014 08:04 PM

    sdr,

     

    What is your specific use case?  What do you want to provision?

     

    To pre-provision Campus APs, they would need to first have at least booted once to the master controller that you want to do the preprovisioning to.  The ap-rename and the ap-regroup command referencing the mac address of the AP only work with devices that have booted at least once to the master controller.  If you just boot the AP once to the master controller, it would be just like "burning in" devices to determine if they are even viable or not...  You don't want to wait until someone is mounting an access point to determine that it is not even viable.

     

    Just to recap, the ap-regroup and the ap-rename command specifying the mac address of the AP is all that is needed to provision devices that have already booted once to the master controller.

     



  • 7.  RE: Pre-provision offline campus APs

    Posted Jul 06, 2014 08:46 PM
    Honestly just trying to figure out the best way to go from the box to the ceiling and then update airwave. Is it better to pre-boot before deployment?


  • 8.  RE: Pre-provision offline campus APs

    Posted Jul 06, 2014 08:52 PM
    Forgot to include we are replacing access points.


  • 9.  RE: Pre-provision offline campus APs

    Posted Jul 06, 2014 09:10 PM

    There are two parts to your problem:

     

    - How do I automatically get access points to be named correctly?

    - How do I get Airwave to recognize them by their new name?

     

    Your most significant challenge is that Aruba will not allow you to name two different access points the same thing.  May I suggest that you name your access points something slightly different from the access points you are replacing (building-floor-ap-1-new) so that you do not run into that issue.  That will also alert you that this AP replaced something similar and there is no confusion over two access points named the same thing.

     

    You should boot the APs to the controller to burn them in, to make sure they work.  In addition, when they are physically deployed, they should not have to upgrade their code, so they will come up quicker.  After you burn them in, you can run your ap-rename and ap-regroup script (or even run it multiple times throughout this process) to make sure that devices have the most current info.  When access points come up in Airwave, they are automatically authorized, they will probably come up with the mac address as the name, and that name will "stick".  To get Airwave to recognize the new name, you will have to click on "Import Settings" in Airwave, or have it periodically run the script refrenced here:  http://community.arubanetworks.com/t5/Monitoring-Management-Location/Script-for-triggering-quot-import-settings-quot-on-AP-in-AMP/ta-p/171568 so that they will import the latest name that the controller has for the APs into Airwave (somehow the script is not attached to the knowledgebase article, but we are going to find it).

     

    Since the summer is the time when everyone does migrations and upgrades, it would be good to hear more ideas about what people are doing to deploy more Wifi in the offseason...

     



  • 10.  RE: Pre-provision offline campus APs

    Posted Apr 19, 2018 03:05 PM

    Almost four years later and this thread is still relevant.

     

    Realistically, we don't have the workflow to pre-provision APs by connecting first to burn them in. If it is determined that an AP in the field needs to be replaced we have a separate team that swaps them out. This AP-swap team is not given root to the controllers and so cannot provision APs. So they connect the new AP and email us the MAC addresss. We then do a clear gap-db on the old AP Name, remove the AP from Airwave, and provision the new AP on the controller. Once the AP comes up in Airwave  we move into monitoring. If the AP was discovered in Airwave prior to being provisioned it eventually inherits the AP Name.

     

    I would like to have a command that preprovisioned the AP similar the command set in this thread. The issue for us is that we use AP-324s and the AP will not come up without antenna values filled in.

     

    Mike



  • 11.  RE: Pre-provision offline campus APs

    Posted Apr 19, 2018 04:12 PM

    As of ArubaOS 6.4.3, these things are possible:

     

    CPSec Whitelist
    – CPSec Whitelist can be pre-configured with AP-Group and
    AP-Name similar to RAP
    • Example: whitelist-db cpsec add mac-address 22:10:10:20:20:34 ap-name [ap132-1] ap-group [B1322]
    • CPSec Whitelist can be offloaded to CPPM



  • 12.  RE: Pre-provision offline campus APs

    Posted Apr 19, 2018 04:25 PM
      |   view attached

    6.4.3.1 Release notes:

     

    Screenshot 2018-04-19 at 15.23.49.png

    Attachment(s)



  • 13.  RE: Pre-provision offline campus APs

    Posted Sep 26, 2019 02:42 PM

    Aruba:  We shouldn't have to select each ap, name, and define ap-group.  Large site installs of 2k plus access points require rooms and staging areas taht customers sometimes cannot provide.

     

     



  • 14.  RE: Pre-provision offline campus APs

    Posted Sep 26, 2019 03:28 PM

    If the intention here is to mass deploy APs without having to provision each one.

     

    This may be a solution.

     

    1.) Enable CPSEC on the controller if it is not already enabled (Note: If it is not enabled and there are APs in the network, enabling it will reboot the existing APs)

     

    2.) Add whitelist entries for cpsec for the APs as follows.

     

    whitelist-db cpsec add mac-address <mac of AP> ap-group <ap-group that you want the APs to fall into on first boot> ap-name <Name of the AP>

     

    If there is an exact deployment plan( list of APs, SSIDs to be broadcast, AP-groups to fall under etc. ) then this should save a ton of time for large scale deployments.(bypassing the provisioning and the reboots thereafter for example)

     

    --Give Kudos: found something helpful, important, or cool? Click Kudos Star in a post.
    --Problem Solved? Click "Accepted Solution" in a post.





  • 15.  RE: Pre-provision offline campus APs

    Posted Sep 27, 2019 12:19 PM

    We chose a different path to do this which mostly worked but had some unintended consequences. I am not advocating that this is a good solution nor is it a best practice. But with a few exceptions it worked for us.


    The challenge was that several subcontractors were sent a ton of new APs in boxes and asked to swap out old APs. We didn't know which MAC addresses were sent to which crew. The sub then subbed out some of the work further. Because the contractors were working in multiple buildings in parallel we couldn't provision a single building all at once as we had done with initial AP deployments. Sometimes it was a room access issue or challenges with new mounts that were slowing things down. So we had a bunch of APs coming up (in default group: eth0 up, radios down) but the whole building was not completed for weeks. The subcontractor did not give us the list of MAC addresses that got installed - and not all switches supported LLDP - until they completed the entire building. We were essentially keeping the whole building down until ALL APs were connected. That was unanticipated. You can imagine the user angst. So we started provisioning APs daily, trying to get them as they came online using temporary names until the full AP-Name/MAC list came in. Unfortunately, sometimes AP provisioner staff was unavailable plus the subcontractors began working weekends.


    In the end we ended up modifying the default ap-group (the original default group was copied off so we can return it to normal state). This was done in both AOS 6.4.x and 6.5x. We added our two campus-wide VAPs, chose an empty-ish "staging" controller (in ap-system-profile) for the APs to land on (not the master!), created a least-objectionable RF profile to support multiple AP models, and let her rip. The ap-name is automatically the AP's MAC address so it was unique which is mandatory.


    The result was that when a freshly unboxed AP connected it came online, checked in with the Master, downloaded a new image, rebooted, came back online and immediately started serving clients on the two VAPs. Without any assistance from a controller admin. We did this for about 2500 APs during a summer of major upgrades.


    Pros:

    • Allows newly unboxed APs to immediately host client devices without waiting for provisioning
    • Eliminated staging area pre-deployment (despite our efforts at labeling sometimes the APs were simply not installed where they were supposed to be, and sometimes the physical room numbers changed in the building!)
    • No longer need to be on the lookout for new APs that come online. No more Whack-a Mole.
    • No need to immediately determine AP Name, AP-Group, etc.
    • No waiting for subcontractors to complete a building
    • Users are online minutes after an AP is connected
    • Weekend work could proceed without provisioning staff involved
    • When a building was complete and we got the AP-Name/MAC hash we could then do a formal provisioning of the entire building at once in a maintenance window

    Cons:

    • AP models with external antennas (that end in "4") will not come up until antenna gains are specified through formal provisioning.
    • Users might suffer through duplex mismatches or CRC/FCS switchport errors that would typically get discovered before provisioning
    • Users often assume the whole building must have coverage when in fact only a few APs have been installed
    • We lost some oversight and QC of APs that either didn't initially come up or never got swapped out (often only discovered when we got the list and formally provisioned)
    • In some buildings we carry additional SSIDs. Because the default ap-group had to be "least common denominator" additional VAPs were absent until the AP was formally provisioned
    • During the height of AP swap outs we almost maxed out the AP count limit of the "staging" controller due to weekend work
    • Users connect right away to an AP that comes online. If the "correct" ap-group is required (e.g. need additional VAPs or correct RF profile) we either had to interrupt client connections during business hours or wait until next maintenance window
    • Sometimes users opened t-tickets because of in-building coverage gaps while the process was going on. End users often don't know that a building is in the process of AP work.
    • Not scalable. Not easy to redact.

    That last point is a tricky one. The major upgrade work is done and I hope to restore the 'default' ap-group back to default. But it's not easy putting that genie back in the bottle. Having the AP's "radios down" until all APs in the project (bldg, floor, auditorium, etc.) are ready eliminated user confusion, held the contractors accountable and looked more polished. And ARM didn't have to work as hard. When the 'default' ap-group is actually default (the way Aruba designed it) then the user only has coverage when the AP is formally provisioned. When we were doing "all APs up or nothing" the users in a building could reasonably expect full coverage and service when they (eventually) had any coverage. It's harder to explain that an AP is in a "hobbled but up" state that will be corrected at some point.


    That's our story, good bad or otherwise. Tweaking the 'default' ap-group worked for us when the big swap outs were happening. Now we're discussing whether to restore things back to "normal". I'm not advocating this as a particularly good solution but it is one that worked for us when we faced similar challenges.


    Hope this helps,

    Mike

     

     



  • 16.  RE: Pre-provision offline campus APs

    Posted Sep 28, 2019 04:26 AM

    @mldickson,

     

    One of our large customers has good results deploying thousands of sites by giving the contractors a large map and putting Xs where they wanted access points mounted.  The contractor could place any access point anywhere, but would take the sticker off the box or the AP with the barcode and put it on the map where he mounted each access point.  The contractor would then return a digital copy of the map with the stickers to the administrator who would then update the ap name and group as desired.  Later a person could return to the site with Aruba utilities on an android tablet to ensure that each access point would be where it is expected.  Aruba Utilities integrates with the controller or airwave and would say the name for each AP and would allow you to also blink access points to ensure that is the correct access point.

     

    What i described above would not necessarily work every everyone, but many users have had success with other user's ideas.



  • 17.  RE: Pre-provision offline campus APs

    Posted Sep 30, 2019 11:53 AM

    Thanks Colin. The second (removable) MAC address sticker on each AP is indeed a crucial part of the data we receive back from the installation contractors. And LED light blinking is used for those environments without LLDP support or when the AP/Room hash is in question. I never used the Android app but will keep that in mind (mostly iPhones here!).

     

    For mass deployments or upgrades we'd print out a spreadsheet with Building, AP-Name, and Room Number. We also left a blank space. We asked the installer to grab the next available AP from the pile and place the MAC sticker in the space provided. Once we got the AP list back we imported the "MAC sticker data" using a cheap USB bar code scanner we found online. Works pretty well. We would then formally provision bulk APs via cli in a two step config process, waiting about 5 minutes between each process. An example of provisioning three APs is below. Using this method we can formally provision dozens of APs within minutes during a maintenance window. The 'clear gap-db' command is crucial when swapping out older APs with the same AP-Name.

     

    ------------
    clear gap-db ap-name BLDG-123-N
    clear gap-db ap-name BLDG-345-N
    clear gap-db ap-name BLDG-678-N
    ap-rename ap-name 12:34:56:78:12:34 BLDG-123-N
    ap-rename ap-name 12:34:56:78:12:35 BLDG-345-N
    ap-rename ap-name 12:34:56:78:12:36 BLDG-678-N
    (**Wait 5 Minutes for AP to come back online**)
    ap-regroup ap-name BLDG-123-N new-ap-group
    ap-regroup ap-name BLDG-345-N new-ap-group
    ap-regroup ap-name BLDG-678-N new-ap-group
    ------------

     

    Quick note about dealing with APs with external antennas (models ending with "4") before we get the whole list back. These APs would be "quickly" provisioned whenever they came online using the appropriate antenna gain parameters. But the AP-Name (which is the MAC by default) and the ap-group did not change (so it remained the modified default group).

     

    Once we got back the list from the installer we would provision these using the same command set as above (antenna gain parameters stayed with the AP throughout the process).

     

    Again, this worked for us when we upgraded thousands of APs as well as for green field deployments with dozens of APs. It may not work in all circumstances.



  • 18.  RE: Pre-provision offline campus APs

    Posted Sep 28, 2019 03:58 AM

    @dtreff_RR wrote:

    Aruba:  We shouldn't have to select each ap, name, and define ap-group.  Large site installs of 2k plus access points require rooms and staging areas taht customers sometimes cannot provide.

     

     


    What should be the solution, then?

    EDIT

    If you configure the default ap group the way you want your WLAN to be setup, you can just put access points on the network and they will upgrade their code and broadcast the SSIDs that you want.  You do not have to configure an ap name or ap group for them to function.  @mldickson above describes how that can be done.