Hi Everyone,
I am building a Multi-Threaded SNMP Driver that is able to retrieve SNMP tables. I am using the ":tablev2" suffix to define the table columns Parameter in the group. Also, I listed all the columns OIDs in the parameter that I am referencing in the group.
I have other tables that are working but some tables are coming back with: "Unable to retrieve the variable bindings (count=0, last error: 1)" message instead of the required data.
When I tried to remove some of the OIDs that are listed in the parameter, I discovered that some of the OIDs are causing the issue! However, I still get empty object arrays for the other OIDs that don't show the error!
The group:
<Group id="51000" connection="0">
<Name>HP Power Supply</Name>
<Content multipleGet="true">
<Param>50400:tablev2</Param>
</Content>
</Group>
The Parameter:
<Param id="50400" trending="false">
<Name>PowerSupplyTable_SNMP_OIDs</Name>
<Description>PowerSupply Table SNMP</Description>
<Type options="loadOID">read</Type>
<Interprete>
<RawType>other</RawType>
<LengthType>next param</LengthType>
<Type>string</Type>
</Interprete>
<SNMP>
<Enabled>true</Enabled>
<OID type="complete">
1.3.6.1.4.1.232.6.2.9.3.1.1;
1.3.6.1.4.1.232.6.2.9.3.1.3;
1.3.6.1.4.1.232.6.2.9.3.1.4;
1.3.6.1.4.1.232.6.2.9.3.1.5;
1.3.6.1.4.1.232.6.2.9.3.1.6;
1.3.6.1.4.1.232.6.2.9.3.1.7;
1.3.6.1.4.1.232.6.2.9.3.1.8;
1.3.6.1.4.1.232.6.2.9.3.1.9;
1.3.6.1.4.1.232.6.2.9.3.1.13
</OID>
</SNMP>
</Param>
To solve this issue, I am currently polling each column as a table instead of having all columns under one parameter, which I think is not the best effective solution.
Thanks,
As this question has been inactive for a long time, we will now close it. If you still want further assistance, could you post a new question?
Hi,
Can you please confirm again that you actually have the OID's defined in a single line? I understand that you already tried this before without any success but you also mentioned that it didn't make any difference. I just want to emphasize that it actually does make a difference and it's important that they are defined in a single line.
I did a quick test locally and when I define the OID's on multiple lines only the first column retrieves data, all others columns are empty (like you mention)
Result:
However when defining the OID's on a single line all columns are retrieved correctly:
Hi Jelle,
I was testing the full list of the OIDs in the same parameter in the same line which then gave me the error because of some of the OIDs. I then separated them on different lines and checked wich OIDs were causing the error; which then caused the issue of getting empty responses!
So the solution now is to have two groups of OIDs that are listed at the same line in their parameters to get the table contents. I could not get all the required columns under the one parameter as they should be. This is still an issue but I have a better solution with less number of calls to the clients!
Thanks
After few other tests, I found that the list of OIDs of the columns that are listed under the Param (a parameter with “:tablev2” suffix) has to have 5 columns at max. If you exceed that number, you will get the error.
I had to split the columns into different group considering the found limitation. I think this could be a bug of DM.
I’ve adjusted my test protocol to match yours: Every column now has it’s own loadOID-parameter, all column parameters (7 in total) have been added to a group with the tablev2 suffix. Data is still retrieved correctly for all columns.
Could you let me know which DataMiner version you are using?
I am on 9.6.10.
The scenario that gets the error is: list all OIDs in the same single parameter and add the parameter to a group and with the “tablev2” suffix. If the number of OIDs is greater than 5, I get the error mentioned in the question.
I have just done a test on one of the HP ProLiant DL380 G7 servers and I was able to get a response using the method mentioned in the question. However, the returned columns are still empty.
The other servers that failed are HP ProLiant DL360 Gen9 and HP ProLiant DL360 Gen10.
The only solution that worked so far is to work with each column as a separate SNMP table.