Follow

Troubleshooting: SNMP traps, syslog messages, Windows events

Problem:
SNMP Traps are not being received in Traverse (please follow similar steps for syslog messages, Windows events)

Troubleshooting Steps:

Configuration in Traverse
Is the device configured in Traverse? Note the IP address or FQDN the device is configured as

Configuration on the device
Is the device configured to send SNMP traps to the Traverse DGE where the device is configured? Ensure that the IP address used for the Traverse DGE is accessible from the device

Firewall
Ensure there is no firewall rule in the network path from the device to the Traverse DGE

Generate trap locally
Forcing a SNMP trap generated by the DGE or DGEX itself (to eliminate network as an issue) would be highly beneficial. You may use a third party SNMP generator such as "Trap Sender" described here. This trap should be accepted and processed by the DGEX. For Linux installations, you may use the snmptrap command

Validation
* Simulate a trap from the device to Traverse
* View the <TRAVERSE_HOME>\logs\messages.log directory and note if an entry was generated
  + If no entry is generated - it implies that one or more of the above may not be set correctly. Please review
  + if not entry is still seen - it may be beneficial to set <logunmatched> to true for the duration of troubleshooting. Please see Troubleshooting: Reviewing all incoming syslog data. Simulate a new trap and review the data one more time. Please make sure that <logunmatched> is set to false once troubleshooting is completed.
  + View msgsvr.stderr and msgsrv.stdout and determine if any entries are logged here
  + If an entry is generated indicating the trap was published, the trap will display in the Traverse web Event Management Console
  + If the trap is discarded, note the reason
     - if the reason indicates device not found, ensure that the IP address in the trap message is the same is the device configuration. Occasionally, the trap message may be sent from a different interface and associated with a different IP address. If so, please add the alternate IP address (referred to as alias in Traverse) as directed here: http://help.kaseya.com/webhelp/EN/tv/9000000/index.asp#17692.htm

Network capture
With a tool such as Wireshark or tcpdump, capture all traffic from the device IP address
We have determined that occasionally the device will not send a trap as per RFC specifications (in particular, it may not include the system time) causing Traverse to reject the packet. A network capture will help us validate the same

Data for review:

Typically, for Support's review, please provide the following:

  • date and time when a trap (simulated or real) was sent from the device to the Traverse DGE
  • from the DGE, a zip of the <TRAVERSE_HOME>\plugin\messages and <TRAVERSE_HOME>\etc\messages directory
  • from the DGE, a zip of the <TRAVERSE_HOME>\logs directory
  • identify the IP and device on Traverse that the message is being received from
  • a screenshot of the event on the Event Manager console (including the event details)
  • In addition provide a 'messages' report:
  • as Superuser, navigate to 'Reports->Advanced->Network->Syslogs & Traps'
  • For'Message Types'select 'All''
  • select 'All' devices, 'All' for 'Severity Filter', duration 'Last 24 hours' and output format 'CSV'
  • select 'Run' to generate the report.
  • save the file created and forward a copy

Please do not attach any files here. Please open a ticket with Support and attach files there.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

0 Comments

Article is closed for comments.