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.
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.
In the "show snmp" traps are being generated, 13 of them, and you have snmp-server enable traps syslog set.
Few things you can do is add a logging ip address if one doesn't already exist or an additional address and throw up a simple syslog server and do a few things to generate traps like conf t or add a vlan and delete a vlan as you have these set to trap. If you don't to use vlans then add a loopback and shut/no shut it a few times.
Appears you are dealing with these remotely. I always open two sessions to the box. Session one, I execute "no debug all" then arrow up then switch to the other session and do term mon and then debug snmp packet. The first session is a failsafe so I can turn off debugging with hitting return if for some reason debug is taxing the box. School of remote access hard knocks.
While debug is running do conf t and exit a few times and/or add delete vlans and you will see the traps being generated and if they are pointing to the desired ip.
Should see something similar to these below.
6506E#term mon
6506E#debug snmp packet
SNMP packet debugging is on
6506E#sh run
Building configuration...
...
6506E#
19:24:18: SNMP: Queuing packet to 10.198.28.80
19:24:18: SNMP: V3 Trap, reqid 2, errstat 0, erridx 0
sysUpTime.0 = 6981747
snmpTrapOID.0 = ciscoConfigManMIB.2.0.1
ccmHistoryEventEntry.3.100 = 1
!--- 1 -> commandLine. Executed via CLI.
ccmHistoryEventEntry.4.100 = 3
!--- 3 -> running
ccmHistoryEventEntry.5.100 = 2
!--- 2 -> commandSource. Show command was executed.
6506E#conf t
Enter configuration commands, one per line. End with CNTL/Z.
6506E(config)#exit
22:57:37: SNMP: Queuing packet to 10.198.28.80
22:57:37: SNMP: V3 Trap, reqid 2, errstat 0, erridx 0
sysUpTime.0 = 8261709
snmpTrapOID.0 = ciscoConfigManMIB.2.0.1
ccmHistoryEventEntry.3.108 = 1
In our shop we only use PI for wireless management controllers and users, not switches. Third party and open source for switches. We have logging for all available traps to dual syslog servers for compliance and redundancy so I understand your frustration when traps aren't working as expected.
Also if you aren't are the latest patches in the 2.0 train I would highly recommend it. 2.0 is not the most stable from our experience until the patches are added. fwiw
Best Answer
Configure your devices to send SNMP Traps and Syslog messages when your ports become err-disabled and have your monitoring system collect these.