openNMS ignores some traps
Description
Environment
Acceptance / Success Criteria
Attachments
Lucidchart Diagrams
Activity
Cyrille Bollu July 10, 2017 at 3:27 PM
Not an opennms issue
Cyrille Bollu July 10, 2017 at 3:25 PM
problem doesn't lie within opennmsn, but within my network's design:
As explained in the issue's description, my opennms box has 2 interfaces, eth0 and eth1. Additionaly, its default gateway is defined on eth0.
Now, the box whose traps are ignored is sending its traps on opennms' eth1 interface while its source address is not in the subnet defined for opennms' eth1 interface.
Linux' kernel doesn't expect that to happen and consider the corresponding packets as "martian" and simply ignores them. Turning martian packets' logging (sysctl -w net.ipv4.conf.all.log_martians=1) shows the following in dmesg:
Resolution:
Changing the sending box' configuration so that it sends its trap to opennms' eth0 interface solved the issue
thanks Jesse for helping
Cyrille Bollu July 10, 2017 at 3:16 PM
will close this issue as the problem is not within opennms
Cyrille Bollu July 4, 2017 at 4:01 PM
Here are the log lines related to file trap_OK.pcap:
2017-07-04 17:31:09,569 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] o.s.Snmp: Fire process PDU event: CommandResponderEvent[securityModel=2, securityLevel=1, maxSizeResponsePDU=65535, pduHandle=PduHandle[802325208], stateReference=StateReference[msgID=0,pduHandle=PduHandle[802325208],securityEngineID=null,securityModel=null,securityName=public,securityLevel=1,contextEngineID=null,contextName=null,retryMsgIDs=null], pdu=TRAP[requestID=802325208, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.2.1.1.3.0 = 2:31:29.10; 1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.4.1.12532.251.20; 1.3.6.1.4.1.12532.27 = SYS20704; 1.3.6.1.4.1.12532.28 = critical; 1.3.6.1.4.1.12532.29 = critical - [10.4.1.141] - cyrille(admin ldap)[.Administrators] - Sending iveReboot SNMP trap to 10.8.0.35:162]], messageProcessingModel=1, securityName=public, processed=false, peerAddress=10.15.0.3/16438, transportMapping=org.snmp4j.transport.DefaultUdpTransportMapping@1f254315, tmStateReference=null]
2017-07-04 17:31:09,569 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] o.o.n.s.s.Snmp4JTrapNotifier: V2 TRAP numVars or pdu length: 5
2017-07-04 17:31:09,570 DEBUG [OpenNMS.Sink.AsyncDispatcher.Trap-Thread-5] o.o.n.s.s.Snmp4JTrapNotifier: V2 TRAP first varbind value: 2:31:29.10
2017-07-04 17:31:09,570 DEBUG [OpenNMS.Sink.AsyncDispatcher.Trap-Thread-5] o.o.n.s.s.Snmp4JTrapNotifier: V2 TRAP first varbind value is of type TIMETICKS (correct)
2017-07-04 17:31:09,570 DEBUG [OpenNMS.Sink.AsyncDispatcher.Trap-Thread-5] o.o.n.s.TrapIdentity: snmpTrapOID: .1.3.6.1.4.1.12532.251.20
2017-07-04 17:31:09,570 DEBUG [OpenNMS.Sink.AsyncDispatcher.Trap-Thread-5] o.o.n.s.s.Snmp4JTrapNotifier: Skipping processing of varbind 0: it is sysuptime and the first varbind, and is not processed as a parm per RFC2089
2017-07-04 17:31:09,570 DEBUG [OpenNMS.Sink.AsyncDispatcher.Trap-Thread-5] o.o.n.s.s.Snmp4JTrapNotifier: Skipping processing of varbind 1: it is the trap OID and the second varbind, and is not processed as a parm per RFC2089
2017-07-04 17:31:10,323 DEBUG [AggregatorFlush-Trap] o.o.n.t.EventCreator: v2 trap - trapInterface: /10.15.0.3
2017-07-04 17:31:10,323 DEBUG [AggregatorFlush-Trap] o.o.n.t.EventCreator: Trap Identity org.opennms.netmgt.trapd.TrapIdentityDTO@68d3b1b
2017-07-04 17:31:10,323 DEBUG [AggregatorFlush-Trap] o.o.n.t.EventCreator: v2 trap - trapInterface: /10.15.0.3
2017-07-04 17:31:10,323 DEBUG [AggregatorFlush-Trap] o.o.n.t.EventCreator: Trap Identity org.opennms.netmgt.trapd.TrapIdentityDTO@68d3c32
I have 2 Juniper SA boxes, both configured to send snmp v2 traps to OpenNMS.
Traps sent by one box are received on opennms' eth0 interface and are processed correctly.
Traps sent by the other box are received on opennms' eth1 interface and aren't processed (not even a single line in trapd.log).
Traps from other hosts received on opennms' eth1 interface are processed correctly.
I've a capture of both traps received, which I'm attaching here for assistance, if possible.
Both captures show very similar traps: I can't see any obvious differences that could explain this different behaviours of opennms.
All I can see for now is that:
both traps are sent to different opennms interfaces;
other traps received on opennms' eth1 interface seem to be all version 1 traps.
Can someone help me understand what's going wrong here?
Cheers,
Cyrille