cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 15

NPM 10.2 Traps no longer matching established rules

We upgraded to 10.2 on Friday and all seemed well.  However I got a call to see if we had received traps from some of our APC equipment over the weekend.  Turns out I'm receiving the traps but the Trap Types have changed.  I now see thousands of traps listing as SNMPv2-MIB:snmpTraps.7 instead of their native trap type.

This a major issue as several of my rules are no longer being matched.  I turned up one device to send to my laptop as well (engineers toolset) and it is matching properly so I know the issue is with NPM or perhaps the new SW trap reciever.

I'm on hold with support right now trying to open a case. 

Tags (1)
0 Kudos
36 Replies
Level 15

Mine look like they are working now too.

0 Kudos

10.2.1 fixed me too.  It also fixed the Catalyst 6500 memory reporting 0 issue I had, and the Traps list not ordering/displaying alerts correctly.  So all and all I would say I'm much happier.  Still have Aruba Wireless AP problems, but we are hunting that down on another thread.  Thanks to the community and the developers for collaborating and making this solution as good as it is! 

0 Kudos
Level 7

Its fixed for me, I now see for example, trap.0.1 for BGP down and .0.2 for up/established

I also see other trap notifications coming through that are returning correct trap state information, so I am making a wild assumption here by saying its all fixed

nothing scientific about my info but it means I am now obtaining correct up/down notifications and relaying that through to my colleagues correctly

thanks SW, good turnaround time, despite warning previously of a Q1 release.........

thanks

Kieran

0 Kudos
Level 9

I'm going to try and get Change Management in for tomorrow.  I also noticed my Aruba Wireless Controllers are no longer reporting RAP's that are down, which I also send notifications on.  Not mentioned in the release notes for 10.2.1 but I'm hoping 🙂  

0 Kudos

Please let us know if its got fix.

 I don't see pepole moving to the 10.2 without that fix.

 

/SJA

0 Kudos
Level 7

Not sure if anyone has been made aware, but I've been given official notice that the 10.2.1 fix is very soon available, let us hope that this time it merely fixes something and breaks nothing further. I'll update if nothing transpires by Friday.

thanks

Kieran

Sent: 09 December 2011 15:09 To: Kieran Omelia Subject: Case Update: 293889 - SNMP Traps Update for Case #293889 - "SNMP Traps" Hello Kieran, I just got confirmation that this issue will be addressed in NPM 10.2.1 which should be available by the end of next week. Please let me know your decision regarding wait or downgrade.

0 Kudos

All I NEED for the holidays is a fix for this - come on 10.2.1!

I'd be interested in knowing what else is going to be fixed in 10.2.1. Anyone from Solarwinds able to give us a look at the bugfix list?

0 Kudos

Totally agree with the urgency on this one.  I'm stuck in a situation, do I go spend the time to figure out how to make my alerts work and update everything, knowing I will need to revert back once the fix comes out? 

0 Kudos

Especially considering the SNMP traps module unlike alerts doesn't have a copy function which is a completely different level of frustration to begin with.

0 Kudos

Just saw 10.2.1 go up on our license page lets hope it resolves the issue

0 Kudos

We are having the same problem since upgrading to v10.2.  I have logged a support ticket.

Did anyone get a solution for this?

0 Kudos

Ah, just seen this page, so no fix at the moment.

 

Why do Solarwinds upgrades fix one thing and break 2 others?

Very poor.

0 Kudos
Level 15

Trap received in engineers toolset.

snmpTrapOID = netBotzV2TempSensorTraps.0.2

Trap received in NPM

snmpTrapOID=SNMPv2-MIB:snmpTraps.7

 

 

0 Kudos

Upgraded myself this weekend and we're having the same issue. The rules in place discarded messages so we are getting inundated with e-mails now that we weren't getting before the upgrade so I'm very interested in hearing what the fix is!

0 Kudos

I'm speaking with support now...as soon as I have a ticket # and hopefully a fix I will update this thread.

0 Kudos

Ticket #292321

Support asked me to restart services which I cannot do at the moment (nor do I feel necessary).  No immediate answers while on the phone with support.  They have me gathering data.  Here is what I am sending them.

 

Here are the full trap details from a trap that is currently broken (I intentionally set the alert to trigger if the temp exceeded 60 degrees to force the traps)

Trap from NPM 10.2

netBotzV2TrapErrorID=nbErrorCond_5655A5FB

netBotzV2TrapErrorType=nbErrorType_toohigh

netBotzV2TrapErrorTypeLabel=Value Too High

netBotzV2TrapSensorID=nbHawkEnc_0_TEMP

netBotzV2TrapSensorLabel=Temperature

netBotzV2TrapPodID=nbHawkEnc_0

netBotzV2TrapPodLabel=Sensor Pod

netBotzV2TrapPortID=

netBotzV2TrapPortLabel=

netBotzV2TrapStartTime=1323115920

netBotzV2TrapNotifyTime=1323118020

netBotzV2TrapResolveTime=0

netBotzV2TrapSeverity=critical(3)

netBotzV2TrapSensorValue=84.4 __F

netBotzV2TrapSensorValueInt=29

netBotzV2TrapSensorValueFraction=99999

snmpTrapOID=SNMPv2-MIB:snmpTraps.7

sysUpTime=21 days 0 hours 46 minutes 18.59 seconds

experimental.1057.1.0=172.16.30.19

snmpTrapEnterprise=NETBOTZV2-MIB:netBotzV2TempSensorTraps

 

 

Exact same trap from Engineers Toolset

sysUpTime = 181717775

snmpTrapOID = netBotzV2TempSensorTraps.0.2

netBotzV2TrapErrorID = nbErrorCond_5655A5FB

netBotzV2TrapErrorType = nbErrorType_toohigh

netBotzV2TrapErrorTypeLabel = Value Too High

netBotzV2TrapSensorID = nbHawkEnc_0_TEMP

netBotzV2TrapSensorLabel = Temperature

netBotzV2TrapPodID = nbHawkEnc_0

netBotzV2TrapPodLabel = Sensor Pod

netBotzV2TrapPortID =

netBotzV2TrapPortLabel =

netBotzV2TrapStartTime = 1323115920

netBotzV2TrapNotifyTime = 1323118020

netBotzV2TrapResolveTime = 0

netBotzV2TrapSeverity = critical(3)

netBotzV2TrapSensorValue = 84.4 __F

netBotzV2TrapSensorValueInt = 29

netBotzV2TrapSensorValueFraction = 99999

experimental.1057.1 = 172.16.30.19

 

 

Here is the rule I currently have...as you can see the traps no longer match said rule

Here is a trap from last week that matched that rule.

sysUpTime=77 days 22 hours 36 minutes 58.70 seconds 

snmpTrapOID=PowerNet-MIB:apc.0.5 

mtrapargsString=UPS: On battery power in response to an input power problem. 

experimental.1057.1=172.16.39.16

snmpTrapEnterprise=PowerNet-MIB:apc 

 

And here is a trap from this weekend (post upgrade) that no longer matches.

mtrapargsString=UPS: On battery power in response to an input power problem.

snmpTrapOID=SNMPv2-MIB:snmpTraps.7

sysUpTime=128 days 22 hours 45 minutes 44.20 seconds

experimental.1057.1.0=172.22.104.16

snmpTrapEnterprise=PowerNet-MIB:apc

0 Kudos

So I looked to see how bad the problem is.  I upgraded on Friday and I have over 22,000 traps classified as this snmpTraps.7 from a myriad of devices, Avaya, APC, Cisco, Netapp, NetBotz, VMware, etc.

Are there other's out there with this same issue?

0 Kudos

Now that you mention it, I do too, I also found that I have a bunch of event from my BES server that are "INTELCORPORATION-MULTI-FLEX-SERVER-MIB:chassis.30.5", but are for blackberry I am used to getting them, but not as from intel; MIB database messed up?

0 Kudos

My BES traps always came in as that Netlogix...I remember the day they turned on the traps I thought it was odd they appeared as Intel.  

If you go to the trap viewer and search by trap type *snmptraps.7* do you get any hits?

0 Kudos

I could test the MIB database theory...I will install the latest database on my laptop for the toolset and see if the data I get changes.

0 Kudos