we have a problem with SNMP responses on the filer (running ONTAP 7.3.2P5).
I am trying to do a snmpwalk over the NetApp MIB:
D:\usr\bin>snmpwalk -v 2c -c public <IPof the filer> 220.127.116.11.4.1 > netappsnmp.txt
after about 30min. (the filer has a lot of vFilers and about 200 volumes and is pretty busy) the snmpwalk fails and I receive the following error from snmpwalk:
Timeout: No Response from <IP of the filer>
Looking at results (the netappsnmp.txt file) I see, that collection is aborted always in different places, sometimes earlier and sometimes later.
The filer logs at that time the following error:
[snmp.agent.resp.failed:warning]: Could not send response to host : <IP of the host> : reason : Failure could be due to either DNS/gateway misconfiguration or takeover/giveback in progress
The filer and the host are on the same subnet, so there are no gateways between them. And the network is functioning properly - all accesses through CIFS, SSH, Telnet etc are succesfull.
Snmpwalk through the SNMPv2 MIB is working correctly without timeouts (D:\usr\bin>snmpwalk -v 2c -c public <IPof the filer> > snmp.txt).
Do you have any ideas regarding this issue?
with best regards,
Did anybody get this resolved? We been getting this error message since we installed this but Netapp support is unable to fix this for us or point us to the right direction. Everything is working fine but these messages are annoying when you are working through commandline and they keep poping up while you are typing.
a customer of mine had the same problem (this snmp message described above every 5 minutes in syslog)
This was the solution:
I just took a look at the server 192.168.1.1 again, and found out that there is another software installed called "ProCurve Manager".
This software does periodic SNMP discovery too.
I had a problem similar to this, with the same error message. I solved it by restarting SNMP:
1) Check SNMP state: "options.snmp"
2) Disable SNMP: "options.snmp.enable off"
3) Enable SNMP: "options.snmp.enable on"
Just like that, SNMP was working as expected without the nasty error message.