SNMPV3 resync traps found in tcpdump but not processed application

SNMP4J
1

We have adapter which uses snmp4j library with apache camel component

We are able to get real time alarms as expected and our application is getting processed (Snmpv3, TCP)

During Resync scenario we can see StartResyc and EndResync trap in tcpdump but its not processed by our application .We can see ERROR message as EndResync trap not recived time out

Even we enabled trace those trace details are also not seen in logs

some what strange behavior we are observing

Please let us know how to troubleshoot further in this issue

2

Hi,

The ERROR message is generated on trap sender side, right?
When you see the packets on TCP dump like you saw the packets that where successfully received, then the following could happen:

  1. One of the packets was wrongly encoded, the receiver will then log a BER encoding error and will not be able to receive further packets until connection is being reopened.
  2. The TCP connection had been (half) closed.

“trace” cannot be enabled in SNMP4J, maybe you meant that you enabled DEBUG log output. There you must see the incoming packet being received from the DefaultTcpTransportMapping. If not, only option 2 or an OS error could have occurred.

Hope this helps.

Best regards,
Frank

3

Application is implemented using SNMP4J (TCP) : Receiver side
EMS (SNMP) TCP : Sender Side

Application is configured to listen on IP 0.0.0.0 and port 1018
EMS Side have load balancer and sending some traps from one IP say as IP1 and some traps from different IP says as IP2

Application able to receive and process some traps from IP1 and traps are captured in tcpdump at Receiver server side

Application not able to receive traps from IP2 and traps are captured in tcpdump at Receiver server side

4

Hi Frank,

It will be helpful if you can give some hints here . We are stuck to troubleshoot further

5

Most likely it is an error on the trap sender regarding boots counter not increased or engine id is not unique. But that is the absolutely topmost FAQ.

6

msgAuthoritativeEngineID : Is unique for all traps
msgAuthoritativeEngineBoots is 0

7

Isn‘t that the sources of the problem?

8

In Real-time alarms which are procsed by snmp4j application have msgAuthoritativeEngineBoots as 0

We have probelm with Resync alarms where there also msgAuthoritativeEngineBoots as 0

So I dont think think msgAuthoritativeEngineBoots is 0 is the probelm

9

So you mean that sender of the resync alarms is never restarted (the name “resync” seems to suggest something different though)? If it has been restarted, then you have found the problem.

If not, then I assume that the resync trap has wrong BER encoding or wrong encryption, etc. In all those cases you will see a message in the DEBUG log of SNMP4J, even for the reboot counter thing.
If you do not see the message in the DEBUG log at all, then it is an issue of the operating system.
To get better help you should provide unrecognised packets and DEBUG log. Without that it is nearly impossible to help.