Case 1) The SNMP trap receiver is setup on the controller, but it
doesn't take effect until a reboot. (Typically older versions of AOS,
~2.4-2.5.)
Case 2) The community string in the trap receiver must be the same as
the "read" community string. I know this makes no technical sense, but
it's an AOS bug. (See attached screenshot).
Case 3) The "snmp-server trap source" must be set to match the IP
address which AMP uses to communicate with the controller. (Let's say a
controller has multiple interfaces, and AMP polls it via 10.1.1.1, but
the trap comes from 10.1.1.2, then AMP drops the trap on the floor, as
it comes from a different IP address.)
Case 4) Specific traps must be enabled. For IDS events, AMP is only
reporting on the following: wlsxSignatureMatchAP,
wlsxSignatureMatchSta, wlsxSignAPNetstumbler, wlsxSignStaNetstumbler,
wlsxSignAPAsleap, wlsxSignStaAsleap, wlsxSignAPAirjack,
wlsxSignStaAirjack, wlsxSignAPNullProbeResp, wlsxSignStaNullProbeResp,
wlsxSignAPDeauthBcast, wlsxSignStaDeauthBcast.
So a couple of controller commands like "show snmp trap-list | include
wlsxSign" should point us in the right direction here.
But this brings up an important point. The *only* IDS events which you
are going to see in the AMP interface are the IDS events on the
controller's "Signature Pattern Matches".
Moving on...
How can we troubleshoot this on the AMP side? (I can walk through
this with the customer, of course).
Step #1) Check the AMP's Home->Overview tab. Look in the IDS events
section to see if we've ever gotten an event.
Step #2) See if they are even getting to the AMP. On the AMP:
"tcpdump port 162" goes a long way. :-)
Step #3) Make sure AMP is processing those events. (This is a bit of
an advanced AirWave troubleshooting, but we can do a "qlog enable
snmp_traps". Then, check the logfile named
"/var/log/amp_diag/snmp_traps". When we are done, remember to "qlog
disable snmp_traps".