SNMP4J and net-snmp integration to send Traps to NMS

SNMP4J
#1

hi, I am new to SNMP, I am trying to do integration of SNMP with our product. Apologies in advance if some of the questions are too basic. I did try to build my knowledge and some example java code. But the integration with the device is not working. Our Product is java based services deployed on a photon appliance. I installed net-snmp (V3 support required) and I am able to query system-related configs from SNMPwalk. However, there are some blockers -

  • How to send traps from our java code?

  1. Should the trap be sent to NMS directly?

  2. Should we create a sub-agent? if yes, anyone done sub-agent programmatically with net-snmp?

  3. Should we send the trap to snmpd running on photon appliance (via net-snmp) and then that can be in some way configured to fwd/send the trap to NMS?

#2

I am afraid, that based on the requirements and background you provided, I cannot given any clear guidance:

  • You can send a notification/trap using SNMP4J easily with Snmp.send from your Java code.
  • Yes, you should send notifications directly. Any proxying is error prone and could lead to unnecessary delay.
  • No, because NET-SNMP’s AgentX subagent interface has issues, that could cause problems when doing that. But, you can run AgentX++ master agent and run NET-SNMP as a subagent to that master agent. But even in that case, for me it is unclear what you are trying to accomplish with that?
  • You can do that, but why you would like to do that?

Best regards,
Frank

#3

AgentX++ as master agent and net-snmp as sub agent may not serve the purpose.

Thank you for the quick revert.

Why I was exploring sub agent and master agent approach is because I don’t want to take care of system-related OIDs values to be available by default.

If I use only SNMPJ based agent in program, how will system-level information be available? This program runs on a dedicated device along with other services. Device level resources (CPU, Mem, etc) reporting is also important and is required intention.

My intention is to provide an SNMP agent for my application and the device it runs on. Such that it reports traps based on application events and also responds to get/getnxt from NMS for system related properties.

What is the best way to achieve this?

#4

The best way would be to run SNMP4J-AgentX master agent with NET-SNMP as subagent.

You can then use the system specific objects from the NET-SNMP subagent and add your managed objects in the master agent.

The benefits over the opposite solution with the NET-SNMP agent as master, are better stability, performance, and probably more security.

#5

To summarize master-subagent is the way to achieve this.

net-snmp agent as master and snmpj agent as sub agent is recommended from performance, security, and stability.

Hope I have got it correctly.

#6

No, SNMP4J-AgentX master agent and NET-SNMP subagent. That is the recommended combination.

#7

Thank you for all your help here.
As this is complex to make master and sub-agent between net-snmp and SNMP4j. I have decided for now to proceed with only sending traps.

If I am sending a trap from SNMP4J as an API call without starting an Agent, I am not able to verify it being received on snmptrapd. A local SNMP4J based receiver receives it, but the same doesn’t work with snmptrapd.

  • Am I following the right approach by not having an agent at all?
  • How else can I verify that trap generated will be received by any NMS?
  • Is EngineId a mandatory field? If so can I generate a random UUID and send or it has to be a mac address?
#8

If you want to be sure that a SNMP message has been received by the remote entity, you need to send a confirmed PDU. For trap like use cases, this is the INFORM PDU. If you receive a response on a sent INFORM PDU, you know the remote entity received it, but you still do not know if it was able to understand/process it.

The Engine ID is mandatory and has to be unique. It has a special format, see RFC 3411. Violations of these basic SNMPv3 rules are causing the majority of interoperability issues.