SNMP traps - UI displays IP address varbinds in hex?

Hi all,

We are running OpenNMS 24.1.0 (docker) and receiving SNMP traps from Juniper device.
It seems that IP address based vardinds are not converted from hex to ip string when the OpenNMS event is created. EG: Bgp Backward Transition remote address and BFD remote address.

Is there a way to flag parm[#x] to convert hex to ip string?

Thanks in advance.


Hi all,

just following up as I am unable to find any solid info on the wiki, Am I experiencing a bug with Juniper events where peer address are displayed in Hex?

It seems I am able to work around this for bgp4 events using part[name-#4.4:4] expression but unable to do this with BFD traps because the peer address is only available as a trap value in hex format.

jnxBgpM2PeerLocalAddrType 1; unknown(0) ipv4(1) ipv6(2) dns(16)
jnxBgpM2PeerLocalAddr 0xc0a8fa14;
jnxBgpM2PeerRemoteAddrType 1; unknown(0) ipv4(1) ipv6(2) dns(16)
jnxBgpM2PeerRemoteAddr 0xc0a8fa15;

Please see eventd debug below

2019-06-26 11:38:04,722 INFO [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: Received event:, src=trapd, iface=, svc=null, time=2019-06-26T11:38:03.876+0100, parms=[., ., ., ., ., ., .]
2019-06-26 11:38:04,722 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: Event {
2019-06-26 11:38:04,722 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: uuid =
2019-06-26 11:38:04,722 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: uei =
2019-06-26 11:38:04,723 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: src = trapd
2019-06-26 11:38:04,723 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: iface =
2019-06-26 11:38:04,723 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: svc = null
2019-06-26 11:38:04,723 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: time = 2019-06-26T11:38:03.876+0100
2019-06-26 11:38:04,723 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: parms {
2019-06-26 11:38:04,723 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: (., 1)
2019-06-26 11:38:04,723 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: (., wKj6FA==)
2019-06-26 11:38:04,724 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: (., 1)
2019-06-26 11:38:04,724 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: (., wKj6FQ==)
2019-06-26 11:38:04,724 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: (., Bgc=)
2019-06-26 11:38:04,724 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: (., )
2019-06-26 11:38:04,724 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: (., 1)
2019-06-26 11:38:04,724 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: }
2019-06-26 11:38:04,724 DEBUG [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: }
2019-06-26 11:38:04,724 INFO [AggregatorFlush-Trap] o.o.n.e.DefaultEventHandlerImpl: Rec

Did you find a solution to this problem, I too am wanting to convert the hex to IP address in the events/ for %parm[#2]%

Hi, for BGP I found a work around because the peer addresses are part of the varbind OID but for not BFD and DISMAN. I did try looking at the event-translator to resolve this but OpenNMS seems to encode the varbind value in base64 making useless in an SQL statement see SNMP Trap Varbind Decode issues and event-translator

I have a logged a bug in jira for this particular issue.

interested to know what you are doing with DISMAN-PING

Using rpm probes on Juniper nodes (MX and SRX) to measure Latency/RTT

Juniper use DISMAN-PING MIB for SNMP trap notifications on rpm probe failure.

We then raise alarms for probe failure and threshold exceed based on SNMP traps and use a Vacumd automation in OpenNMS to auto clear when the alarm last event time exceeds a certain amount of time.

similar to what I am attempting to do, though I am wanting to monitor MPLS core; but as standard juniper RTT can jump around; are you monitoring endpoints or other Juniper devices in the rpm probes and if the latter, how are you accounting for the high RTT averages ?

Thanks in advance

Your RTT should be fine if your links are OK and you use hardware timestamps.
If you do not use hardware timestamps I believe the probe will be bound to the control-plane and there for subject to CPU spikes. I do know that some boxes do not support hardware timestamps (generally SRX) in this case perhaps do not make your probe intervals too aggressive.