NetXMS Support Forum

I recently decided to start moving our trap notifications over to NetXMS from what I hope will soon be our old NMS.  We have a number of various model Procurve switches which the system seem to try and detect.  It shows the driver on the general tab as PROCURVE.  However, when we get a trap for link down and then a trap for link up it is NOT clearing the Link down event and it stays up on the device until we manually terminate.  It is detecting the ports correctly from the varbinds, just not clearing.

First traps .1.3.6.1.6.3.1.1.5.3 (link down) followed by .1.3.6.1.6.3.1.1.5.4 (link up).  These appear to be the "standard" down / up noticed and are listed in the SNMP Trap Configuration section.

Not sure how it comes up with the port drawings either, but it is wrong.  For example our 4000M switch shows an odd layout of ports 1-22 in slot 1, 0 - 23 in slot 2, 0 in slot 3 and 1 in slot 4.  In actuality there are 6 8 port cards, 1 1 port card.  It also pops up a components tab with nothing filled in.

Also, would like to make a suggestions that you allow clipboard copy from the SNMP Trap Monitor display so it is easier to grab OID's or messages. 

Thanks as always!

Quote from: lweidig on July 20, 2012, 05:50:21 AM
I recently decided to start moving our trap notifications over to NetXMS from what I hope will soon be our old NMS.  We have a number of various model Procurve switches which the system seem to try and detect.  It shows the driver on the general tab as PROCURVE.  However, when we get a trap for link down and then a trap for link up it is NOT clearing the Link down event and it stays up on the device until we manually terminate.  It is detecting the ports correctly from the varbinds, just not clearing.

First traps .1.3.6.1.6.3.1.1.5.3 (link down) followed by .1.3.6.1.6.3.1.1.5.4 (link up).  These appear to be the "standard" down / up noticed and are listed in the SNMP Trap Configuration section.

How do you define rules in event processing policy for create and terminate alarm?

Quote from: lweidig on July 20, 2012, 05:50:21 AM
Not sure how it comes up with the port drawings either, but it is wrong.  For example our 4000M switch shows an odd layout of ports 1-22 in slot 1, 0 - 23 in slot 2, 0 in slot 3 and 1 in slot 4.  In actuality there are 6 8 port cards, 1 1 port card.  It also pops up a components tab with nothing filled in.

Can you please send me output of nxsnmpwalk for the following OIDs on this 4000m:
.1.3.6.1.2.1.1
.1.3.6.1.2.1.2
.1.3.6.1.2.1.47.1.1.1.1

Components tab may be empty because switch may not support appropriate MIB.

Quote from: lweidig on July 20, 2012, 05:50:21 AM
Also, would like to make a suggestions that you allow clipboard copy from the SNMP Trap Monitor display so it is easier to grab OID's or messages. 

It's already done in upcoming 1.2.2.

Best regards,
Victor

Actually, I created no event processing policy for either of them, just apparently the even was set for down through receipt of the trap all on its own, unless that got picked up by some of the base policy rules.  I was just hoping the up would be processed likewise.  It is not an issue to create these of course, was just asking since one processed "automatically" and the other did not.

The walk requests are attached to the message.

No, there are no default rules for handling SNMP ifdown/ifup traps. You should create them by yourself.

Ok, tried creating them "cloning" the link up / down policies that exist.  For the down event I create an alarm SNMP_IF_DOWN_%i_%2 and then for the up event terminate the alarm SNMP_IF_DOWN_%i_%2.  However, it never clears even though the trap for clearing it is sent and received by the server as it is in the Trap Monitor when I watch it. 

Is it possible that the macro %i is not allowed for traps since the "source" is really not a node object as others would be and that it is grabbing just some sort of random value for that.  If so, is there a macro variable that would contain the source IP of the trap or what would you use to give it a unique alarm key?

Also, and I believe I mentioned this in the past would be nice if you could view the alarm KEYS so that it is easier to see if for some reason you are not matching properly.  In both the Alarm Browser and Alarm Log would be great.

Every event has source object ID. For events created from SNMP traps, source object determined by SNMP trap packet's source IP address. If node with that IP address cannot be found, event will not be created. Can you check that for both down and up traps events are generated?

Macro for IP address exists - %a. Full list of possible macros available here: http://wiki.netxms.org/wiki/UM:Event_Processing#Macros_for_Event_Processing.

I have added "Key" column to alarm log in 1.2.2.

Best regards,
Victor

I expected it would use IP to find node.  Can see up hitting with trap monitor and same IP, just not creating event it appears.

That's strange. Can you show me SNMP trap mapping and part of trap log?

Best regards,
Victor

Ok, now that I can see the keys ins 1.2.2 I was able to find the problem and have worked out a solution.

When we get a SNMP_LINK_DOWN event we create an alarm with key SNMP_IF_DOWN_%i_%2, then on the SNMP_LINK_UP we terminate alarm SNMP_IF_DOWN_%i_2.  This is working and the event is clearing as it should be.  However, further down our processing policy have an event that creates an alarm NOTIFY_%i_%1.  To start a process of notification to pagers if an event does not clear.  Of course when I get the clearing event for this pair %1 is different than the first time as that contains the OID of the trap.  I have fixed this and we now seem to be fine.

Thanks for adding the Alarm key in 1.2.2 display!