Do i need to configure any snmp trap in order to allow snmp trap in solarwind

Hi currently i had one isilon storage server and my customer wish to monitor the snmp trap from isilon to solarwind. I had enable port 162 and start the snmp traps at the solarwind server. However i does not received any traps at solarwind from isilon. Is that any ways to simulate the snmp traps to send? Plus what does it means in the screenshot i attach. Thanks for the help in advance

  • The message you attached is basically just saying you don't have any traps yet, so make sure the trap service is running.   It sounds like you've checked that.  The next thing I'd check is that the isilon storage server is actually configured to send traps to your SolarWinds Orion server, and that there's nothing blocking the trap from getting to the server.

    If those don't work for you, I'd suggest opening a support ticket and our reps should be able to help validate that everything is okay on the Orion server side.



  • Hi Casey, actually i had set isilon storage server to send the snmp trap to the Solarwind Server, however at solarwind there does not received any things. Normally is there always will have SNMP traps sent or the trap will send only when something is trigger? Beside is that anyway that can i verify the traps is working?    

  • Can you use something like wireshark to make sure the traps are getting to the server. Also, make sure the Orion server is listening on the same port as the Isilson is sending the traps to (netstat -b -n should help you here).

  • Not sure if the SYSLOG on this device is conforming to RFC 5424 which is the SYSLOG levels below.

    0Emergencyemerg (panic)System is unusable.A "panic" condition usually affecting multiple apps/servers/sites. At this level it would usually notify all tech staff on call.
    1AlertalertAction must be taken immediately.Should be corrected immediately, therefore notify staff who can fix the problem. An example would be the loss of a primary ISP connection.
    2CriticalcritCritical conditions.Should be corrected immediately, but indicates failure in a primary system, an example is a loss of a backup ISP connection.
    3Errorerr (error)Error conditions.Non-urgent failures, these should be relayed to developers or admins; each item must be resolved within a given time.
    4Warningwarning (warn)Warning conditions.Warning messages, not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full - each item must be resolved within a given time.
    5NoticenoticeNormal but significant condition.Events that are unusual but not error conditions - might be summarized in an email to developers or admins to spot potential problems - no immediate action required.
    6InformationalinfoInformational messages.Normal operational messages - may be harvested for reporting, measuring throughput, etc. - no action required.
    7DebugdebugDebug-level messages.Info useful to developers for debugging the application, not useful during operations.

    The way this works is if you are sending logs from say Level 4 "Warning" you will get all logs/events that happen from Level 0-4.  Depending on what level you are set at currently you may be missing events/logs because they aren't classified between levels 0-4.  These first 5 levels are the most severe in SYSLOG.  If you are just monitoring these and you don't see anything then I would say that is AWESOME!! emoticons_laugh.png  It means you have no issues going on in this environment.  If you have the ability and resources I would at least set my level to 6 "Informational" this should start giving you a ton of messages for smaller transactions and events happening on the system.  If you are set to Level 6 and aren't seeing anything now then you have an issue somewhere starting at Point A "SAN" and Point B "Syslog Server".

    Hope this helps you out, and can find out where your break is at.