cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Level 12

Weird Trap Behavior

So I was looking at some traps today and noticed an AP was trapping from a controller it is not associated with. Is this a bug or something? In this trap the ap:206_Whe1 is an HREAP attached to a controller different from which this trap was seen from. This is not the only issue I am seeing with my traps as a lot of the trap details are not jiving up with the correct sources. Im sure its something simple.

sysUpTime=119 days 1 hour 59 minutes 3.00 seconds
snmpTrapOID=AIRESPACE-WIRELESS-MIB:bsnRogueAPDetected
bsnRogueAPDot11MacAddress=000D.6711.32B9
bsnRogueAPAirespaceAPMacAddress=0024.9776.1570
bsnRogueAPAirespaceAPSlotId=0
bsnRogueAPSsid=timewarnercablewifi
bsnRogueAPChannelNumber=1
bsnRogueAPAirespaceAPRSSI=-94
bsnRogueAPAirespaceAPSNR=1
bsnRogueAPOnWiredNetwork=no(0)
bsnRogueAdhocMode=no(0)
bsnRogueAPRadioType=dot11b(1)
bsnRogueAPAirespaceAPName=ap:206_Whe1
bsnRogueAPClassType=unclassified(3)

0 Kudos
2 Replies
Highlighted
Level 19

Re: Weird Trap Behavior

Some wireless manufacturers allow for shared thin access management. It is a fairly new technology. Virtual controllers.

0 Kudos
Highlighted
Level 15

Re: Weird Trap Behavior

It's not just wireless....there are numerous devices that act as a manager reporting status on any of their managed nodes up through a trap.  Our APC ISX system reports traps on any number of the APC devices it manages.  Same can be said for our Avaya manager and our Cisco Wireless controller.

If you truly suspect it to be a Solarwinds issue however then I would suggest testing with a third party trap receiver to see if you get the same results...however in the example you provided I would say that this is simply the controller reporting status of an AP under its realm of control.

0 Kudos