Localized users for Snmp Trap Receiver using Snmp4j.

Hi all,

I’m new to SNMP and currently working with the SNMP4J library (version 2.8.18). I’m implementing two components:

  1. An SNMP GET requester, which sends SNMPv3 GET requests.
  2. An SNMP trap receiver, which receives SNMPv3 traps.

On the GET side, I use SNMPv3 with localized users. I’m able to discover the engine ID of the remote agent dynamically using the discovery API, so I don’t need to provide the engine ID manually.

However, on the trap receiver side, the source address (agent) is not known in advance, so I can’t perform discovery to get the engine ID. This leads me to following questions:

  1. Does the trap receiver need to know the engine ID of the remote SNMP agents/devices in advance, or should the devices sending traps know the engine ID of the trap receiver?
  2. In SNMP4J 2.8.18, is it mandatory to localize users on the trap receiver side? Or is using non-localized users (i.e. relying on username and matching credentials) sufficient?
  3. Currently I have implemented trap receiver using non localized users. In one of my use cases, two different devices send traps using the same SNMPv3 username but with different authentication credentials. In this setup, one trap is consistently dropped due to authentication failure:
    1. Is this kind of configuration valid in SNMPv3 in general?
    2. Or is it unsupported (or unsafe) in SNMP4J?

Thanks in advance for any clarification, best practices, or design suggestions.

Hi davhad,

Here are my answers:

No, the trap-sender is authoritative. That means the trap-receiver can learn the authoritative engine ID from the sender while processing the trap/notification.
The only prerequisite is, that

  1. USM user with the matching security name is either already localised for the trap-sender’s authoritative engine ID
  2. USM user with the matching security name and security level is not localised yet. SNMP4J will then localised it, when the trap is being received, if allowed by its grant settings (SNMP4J >=3.8).

Yes, that is sufficient, see above.

That is expected behaviour. SNMPv3 standard does not allow to have same security name but different passwords in the same management domain.

No.

It is not allowed in SNMPv3 and therefore it is not supported by SNMP4J (for traps&notifications). For confirmed class PDUs (GET, NEXT, GETBULK, SET, INFORM) you can use DirectUserTarget from SNMP4J 3.9 to use different passkeys for different targets but same security name.

Hope this helps anyway.