Staging Many Lightweight Cisco AP's for Deployment

Question

My organization is soon going to be deploying approximately 600 new Cisco 2602i access points in a CAPWAP deployment with several 5508 controllers.

This is an infrastructure refresh; currently we have a mix of older Cisco AP's using CAPWAP with several sets of WiSM controllers. Our current procedure for deploying new/replacement AP's is, to my understanding, the standard priming procedure as listed in this Cisco Support Forum document.

• Connect new access point to the network at our desks
• AP gets a DHCP address
• DHCP Option 43 points AP to a controller
• Log into NCS Prime and find the new AP
• Change AP name and Primary/Secondary controller
• Box AP back up and take to site for deployment

I know there are other options for initially getting the AP to talk to a controller, such as Over-the-Air-Provisioning or placing the AP into a Layer 2 VLAN with a controller. But these seem focused on just getting the AP connected to ANY controller, not priming it for a specific Primary/Secondary controller.

I would like to setup some sort of staging/prep area for pre-configuring the new access points, conducting inventory, tagging with asset tags, sorting AP by final deployment area, and so on.

In setting up this staging area, is there a better way to prime these AP's quickly and easily? Or are we already doing this in the most efficient manner?

Answer 1

I would like to setup some sort of staging/prep area for pre-configuring the new access points, conducting inventory, tagging with asset tags, sorting AP by final deployment area, and so on.

In setting up this staging area, is there a better way to prime these AP's quickly and easily? Or are we already doing this in the most efficient manner?

NOTE: I am assuming you're already familiar with loading MIBs on a Windows / Linux machine, and using snmpwalk / snmpset... if not, please let me know

I recently discovered how well you can manage Cisco's LWAPs through the AIRESPACE-WIRELESS-MIB, in fact I have mostly forsaken our WCS in favor of managing our LWAPs with the MIB (we have a couple hundred LWAPs spread across multiple WLCs at our facility).

Since you know Perl, you could write a loop to poll your WLCs for the new LWAPs; then the script reacts accordingly when it sees a new LWAP mac-address on a WLC.

• Loop through a list of all controllers, then poll the LWAPs on each controller with bsnAPEthernetMacAddress (ro). Use the mac-address as the unique identifying key for all activity on this LWAP.
• When you see a new LWAP, print the discovery time / mac-address of the LWAP; then ask the user what hostname / location to assign to this LWAP

• Optionally perform bsnAPClearConfig (rw) using snmpset (note 255.254.253.252.251.250 is the hexidecimal index to bsnAPTable translated into decimal octets); setting bsnAPClearConfig will immediately reboot the LWAP:

  snmpset -v 2c -OXsq -c private -m AIRESPACE-WIRELESS-MIB <WLC_IP> \
    bsnAPClearConfig.255.254.253.252.251.250 integer 1
  

• Assign bsnAPName (rw), bsnAPPrimaryMwarName (rw), bsnAPSecondaryMwarName (rw) using snmpset

• Get the bsnAPSerialNumber (ro); save it to a CSV file along with bsnAPEthernetMacAddress (ro), bsnAPName (rw), bsnAPPrimaryMwarName (rw), and bsnAPSecondaryMwarName (rw)
• Reset the LWAP if required with bsnAPReset (rw)

Using SNMP to manage LWAPs has been helpful, since I can automatically react to changes in LWAP to WLC mappings, as well as when an AP drops offline or gets large error / user counts. I usually poll them all every 15 minutes and record who is on them, as well as recording what LWAPs are on each controller. The WLC is powerful, but I like building custom-reaction scripts and reports.