This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Rebuild SNMP trap format

I have NPM to receive traps from network nodes, there are some log processing rules to filter out unwanted traps. I have created a rule for required trap OiDs, so that once NPM received the traps, it will generate an alert. Based on this alert, I would like to send the trap to another management system with customization.

For example, there are 5 variable bindings in the trap. I want to send only 3 of them to another management system. How can I put the required variable bindings to a new traps?

Thanks.

Parents
  • Is there a specific reason you want to send a trap to another management system?
    Is it capable of handling other event types as input?

    The reason I ask those questions is that yes you can potentially forward a trap but you likely won't be able to modify it.  Then the receiving system may show the intermediate server as the source of the trap and not the true source.  Secondly, traps are not a sure/guaranteed method to send an alert.  

    To generate a new trap you can use some simple tools to set up new text and such...again then you have a nonstandard trap being sent via a shell environment.  If something breaks in the chain, determining the broken link in the chain could be a challenge.  Case in point, if a device/server gets too busy it stops sending the lowest priority communications...traps.  Not to mention it is fire and forget.  There is no checking or retries to ensure it gets to where it is sent to.  Think of a trap as a message in a bottle.  It may never get where it was intended to go.

Reply
  • Is there a specific reason you want to send a trap to another management system?
    Is it capable of handling other event types as input?

    The reason I ask those questions is that yes you can potentially forward a trap but you likely won't be able to modify it.  Then the receiving system may show the intermediate server as the source of the trap and not the true source.  Secondly, traps are not a sure/guaranteed method to send an alert.  

    To generate a new trap you can use some simple tools to set up new text and such...again then you have a nonstandard trap being sent via a shell environment.  If something breaks in the chain, determining the broken link in the chain could be a challenge.  Case in point, if a device/server gets too busy it stops sending the lowest priority communications...traps.  Not to mention it is fire and forget.  There is no checking or retries to ensure it gets to where it is sent to.  Think of a trap as a message in a bottle.  It may never get where it was intended to go.

Children
No Data