I have a strange issue with snmwpalk.
If I do snmpget on yyy.977.4.3.1.3.1006 I get the following successfull output :
yyy.977.4.3.1.3.1006 = INTEGER: 206
This is what I was excepting for, now I want to look for other snmp addresses Under yyy.977.4.3.1.3.xxxx.
If I do snmpwalk on yyy.977.4.3.1.3 I get the following output :
yyy.977.4.3.1.3 = INTEGER: 0
But I am clearly excepting to walk through all snmp adresses possible for 3.xxxx ...
What is even stranger is this
If I do snmpwalk yyy.977.4.3.1 I get the following output :
yyy.977.4.3.1 = No Such Object available on this agent at this OID
But I am crearly excepting to walk through all snmp adresses possible for 3.1.1.xxxx, 3.1.2.xxxx, 3.1.3.xxxx, 3.1.4.xxxx [...], 3.1.9.xxxx
And If I do snmpwalk on yyy.977 it successfully go through all snmp addresses except yyy.977.4 !
How can snmpwalk go through all adresses except yyy.977.4 despite yyy.977.4 is clearly working (see first command) and this is excacly where I need to look ...
Either I do not anderstand how snmp works or I am doing something wrong.
Thank you in advance if you could help me with this.
FFedo
returns me "SNMPv2-SMI::enterprises.31977.4.3.1 = No Such Object available on this agent at this OID"
This morning I browsed the MiB with a tool I have from ManageEngine (monitoring solution), if I browse to 1.3.6.1.4.1.31977.4.3.1.3 the tool returns me "No data available in this sub-tree"
Thanks for providing the information requested. There are a number of things which could be causing your problem.
There are two basic reasons why a request may go unanswered. Either the management application does not like the request so never sends it, or the agent does not like the request so never responds. The simplest way to distinguish between the two is to run snmpwalk with debugging enabled and look at the output. Hopefully your version of snmpwalk allows you to enable debugging output.
Other possibilities to consider:
The agent may return a response to the original query but the management application may not like this response, and refuse to display it. The typical symptoms of this would be that the debugging option would display a sequence of sending and received packet dumps, with the same contents each time.
The agent may simply not support the MIB objects being requested. This is most commonly seen when using snmpwalk. Debugging output would show two pairs of raw packet dumps - one a GETNEXT request, followed by a GET request.
The agent is taking too long to respond and timing out (unusual)
Poorly implemented enterprise MIB
I believe that RHEL, on which CentOS is based, uses the NET-SNMP toolset (Net-SNMP). There is an excellent FAQ there which will assist you in further debugging your problem.