Hi Praveen,
What release of Spectrum are you working with?
You could create a watch in Spectrum to monitor the "udpNoPorts" (1.3.6.1.2.1.7.2) and "udpInErrors" (1.3.6.1.2.1.7.3) MIB objects, for the Linux Server in question, but this would only work is the SNMP agent is up and responding.
To test the SNMP agent of the Linux server, you could try connecting to the host by using MIB Tools. If you are able to connect, then we should look at why the alarms is getting triggered. If you're not able to connect, then there could be a legitimate problem with the SNMP agent on the Linux server.
If you find the SNMP agent is truly up and responding, you may want to use Wireshark to see how long it takes for the Linux server to reply back to Spectrum's SNMP getRequests. By default we wait 3000 miliseconds (3 seconds) between polls, and will try to communicate 3 times . If Spectrum does not receive a reply in within the 3000 ms, we issue a second poll and wait another 3000 ms. After the third failed instance, we issue an ICMP request to see if the device's IP is up. If the device replies to the ICMP, but not the SNMP, we issue the "Management Agent Lost" alarm.
If the device is responding slowly, say 3010 ms, we will mark those as a failed reply, since we didn't receive them in the expected time (3000 ms). So using Wireshark will help you determine if the device is just responding slow, or not at all. If the Linux server, on average is taking longer to reply, you may want to increase the device models "DCM Timeout" and/or DCM Retry Count" values. This will give the Linux Server more time to reply, before Spectrum generates the alarm.
Thank you,
Brad