How to confirm DFM trap forwarding?

Unanswered Question
Jan 15th, 2008
User Badges:


I have configured snmp trap forwarding from DFM 2.0.7 to another NMS server (HP open view), (DFM > Configuration > Other Configuration > SNMP Trap Forwarding.) And DFM is also listening to traps itself (DFM > Configuration > Other Configuration > SNMP Trap Receiving. Port 162.)

Is there any way I can see that these traps really are getting forwarded to the other NMS server? I have installed Wireshark on my LMS server

and I can only see traps coming into DFM from the network devices. I have tried to find some help/answer about this, but so far no luck.

Can anyone please give some advice?



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Joe Clarke Tue, 01/15/2008 - 11:14
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

IF you have Wireshark, and you filter on the HPOV trap destination port (udp/162?) then you should see the trap leaving the DFM server.

linawillerstrom Tue, 01/15/2008 - 12:33
User Badges:

Thanks for you reply. I have filtered out the trap destination port on the HPOV server (162) in wireshark, but still only see traps destined for the DFM.

I have also filtered out destination snmp traffic for the HPOV server, but see no snmp traffic leave DFM at all.


Joe Clarke Tue, 01/15/2008 - 12:40
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

Check the NMSROOT/objects/smarts/local/logs/DFM.log for errors, and make sure the DfmServer process is running using pdshow.

linawillerstrom Wed, 01/16/2008 - 01:19
User Badges:

I can not see any errors in the DFM.log-file and the pdshow shows DfmServer running.

DFM is running on a Windows server 2003. Will there be a conflict if the server itself sends out snmp traps to the NMS? Will it be able to distinguish between DFM forwarding traps and its own "server traps"?

The snmp community RO name is not the same in DFM as it is on the NMS server. Could that be a problem?

Joe Clarke Wed, 01/16/2008 - 09:44
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

A screenshot of the DFM trap forwarding config page may be helpful. As would the output of netstat -a -n -o -b.

I'm not sure I understand your first question. What do you mean by the server itself? Are you referring to the end device?

The community string could prevent HPOV from processing the forwarded trap, but it would not prevent that trap from showing up in a sniffer trace.

Since this is a Windows server, do you have .NET 2.0 SP1 installed?

linawillerstrom Tue, 01/29/2008 - 08:11
User Badges:

I have added a screenshot of the DFM trap forwarding config page if that could be of any help. As for the output of netstat, would it be possible for you to tell me what i should be looking for in the different outputs?

.NET 2.0 SP1 is not installed on the server. Do I need it for this to work?


miheg Tue, 01/29/2008 - 23:17
User Badges:
  • Gold, 750 points or more

If the hostname you mention is resolvable from the server it should work.

And the snmp community in the trap message is irrelevant, you could put anything there.

.NET is not required.

I'm not confident when DFM will actually forward a trap. (It may drop traps it doesn't like, e.g. from a host it doesn't manage, that you may wish to receive in HPOV ) I think it is safer to have another application (like net-snmp) receive the traps and let it forward it to DFM and HPOV. Also this will give you a proper file with the received traps.



linawillerstrom Wed, 01/30/2008 - 09:03
User Badges:

Yes, you are right. DFM will only process some traps. These processed traps can then be forward to HPOV by using notification services for example. DFM can also receive other traps which it will only forward to a NMS as unidentified (raw) traps.

I will look into other applications such as net-snmp for receiving and forwarding traps to HPOV since DFM is better at generating alerts based on monitoring devices with polling and tresholds.




This Discussion