we are facing intermittent issue, for every five minutes the interface is going down and again its coming up .
there is now any fluctuation in link.
Below is the error code .
No response (check: firewalls, routing, snmp settings of device, IPs, SNMP version, community, passwords etc) (SNMP error # -2003)
How to overcome this error ?
Article Comments
Hello,
Thank you for your KB Post. Such short-time errors on only one device point to an issue on the device actually (otherwise you would see many SNMP Sensors on other devices also showing errors in the same time).
There are SNMP Compatibility Options that may help here with such connectivity issues on the SNMP on the target NetApp. It seems the errors are rather sporadic, I would suggest to try using a longer scanning interval here on the SNMP Disk Sensors (usually 5 or 10 minutes is fine for disk sensors). Then you could try working with a longer timeout. It may help, but if the device responds with "No such name..."-error in these cases, there is very little PRTG can do, other than showing you the error.
This looks like there is an issue with keeping the SNMP connection towards the target. It seems the connection is quite unstable. Please make sure that the "Retry" is enabled on "Failed Requests" in the "SNMP Compatibility Options" and you can try to slightly increase the "SNMP Timeout" in the "SNMP Credentials"-Settings (but please do not set the timeout higher than the scanning interval). You can also try a "SNMP Delay" of 50 to 100 milliseconds, that helps as well sometimes.
To verify the issue, you could use our SNMP Tester (https://www.paessler.com/tools/snmptester), run it on the PRTG Host, and perform a "Scan available standard interfaces" against the target device, in the very moment the sensors are in error in PRTG. Do you then see the same errors? Then it really points to an issue on the device.
best regards.
Oct, 2015 - Permalink
Still we are facing the same issue . Can anyone help us on this error .
Oct, 2015 - Permalink
Hello there,
What happens when you do an interface scan using our SNMP-Tester when this error occurs?
Kind regards.
Oct, 2015 - Permalink
I too am having this issue with SonicWALL NSA firewalls. Most of the time they read the SNMP fine but some times one out of 4 Firewalls generates errors with -2003 no data from the firewall.
After a little while it goes back to normal. Not sure what is going on.
jason
Nov, 2021 - Permalink
Hello Jason,
the error -2003 means the device does not respond within the SNMP timeout, or not at all. You can increase the SNMP timeout in the PRTG device object, "Settings" tab, the section were you also enter the SNMP credentials (port and public string).
Nov, 2021 - Permalink
Hello,
Thank you for your KB Post. Such short-time errors on only one device point to an issue on the device actually (otherwise you would see many SNMP Sensors on other devices also showing errors in the same time). There are SNMP Compatibility Options that may help here with such connectivity issues on the SNMP on the target NetApp. It seems the errors are rather sporadic, I would suggest to try using a longer scanning interval here on the SNMP Disk Sensors (usually 5 or 10 minutes is fine for disk sensors). Then you could try working with a longer timeout. It may help, but if the device responds with "No such name..."-error in these cases, there is very little PRTG can do, other than showing you the error. This looks like there is an issue with keeping the SNMP connection towards the target. It seems the connection is quite unstable. Please make sure that the "Retry" is enabled on "Failed Requests" in the "SNMP Compatibility Options" and you can try to slightly increase the "SNMP Timeout" in the "SNMP Credentials"-Settings (but please do not set the timeout higher than the scanning interval). You can also try a "SNMP Delay" of 50 to 100 milliseconds, that helps as well sometimes.
To verify the issue, you could use our SNMP Tester (https://www.paessler.com/tools/snmptester), run it on the PRTG Host, and perform a "Scan available standard interfaces" against the target device, in the very moment the sensors are in error in PRTG. Do you then see the same errors? Then it really points to an issue on the device.
best regards.
Oct, 2015 - Permalink