Hi Dojo,
In a DataMiner SNMP connector, I have a polling group that uses SNMP multipleGet:
<Group id="742">
<Name>temperatures</Name>
<Type>poll</Type>
<Content multipleGet="true">
<Param>700</Param> <!-- inside temp -->
<Param>705</Param> <!-- outside temp -->
<Param>706</Param> <!-- return temp -->
</Content>
</Group>
On one device variant, one of the OIDs (e.g. temperatureOutside) is not supported because the corresponding sensor is not present, and direct polling with an external MIB browser shows this OID consistently times out. With multipleGet="true", this single OID causes the entire group to fail, so none of the parameters in the group get updated.
If I remove multipleGet="true", the supported OIDs update correctly, but the element can still go into timeout periodically due to the failing OID.
Question:
Is there any supported way in DataMiner (protocol XML options, group configuration, SNMP settings, or best-practice approach) to prevent a single failing/timeout OID from causing the entire polling element to time out so that working OIDs are still written while the failing OID is marked N/A instead of timing out?
Hi,
Is it possible that the element is SnmpV1? If that is the case, is it possible to use SnmpV2 in combination with multipleGet="true"? Or does that also fail the entire group?
As to prevent the timeout, the advice would be to make sure that the last polled item is an OID that always responds. E.g. you could place the temparatureOutside in a separate group and first poll that group, then poll the group that contain the other two parameters (that responding group could then again be multipleGet="true"). As that group has communication after the potential non-communicating group, it prevents the element from going into timeout.
Regards,
Hi,
If the communication is SNMPv2 and multipleGet="true" is used then, according to RFC-1905 (which defines the SNMP spec), the device should reply with "noSuchObject" for the missing OIDs, and it should fill in values for the valid OIDs.
As stated in chapter 4.2.1 The GetRequest-PDU: "If the variable binding's name name exactly matches the name of a variable accessible by this request, then the variable binding's value field is set to the value of the named variable. Otherwise, if the variable binding's name does not have an OID prefix of any variable accessible by this request, then its value field is set to 'noSuchObject'"
With SNMPv1 it would indeed fail the entire request message. Which is strange in this case with SNMPv2 that the device does not adhere to the RFC. When polling the missing OID separately, the device should be replying with "noSuchObject", while the StreamViewer shows a timeout (=no reply at all from the device). As it seems that the device does not communicate according to the SNMPv2 specs, there is no other way to either put the 'problematic' OIDs each in their own separate group, or have multipleGet="false" on the groups where there is such problematic OID included. There is no supported method in DataMiner to handle with such kind of scenario to dynamically exclude OIDs from the groups at runtime.
Hi Laurens,
Thank you for your quick and helpful response.
To clarify further based on your questions:
The element is using SNMPv2, when multipleGet="true" is enabled, the entire group fails.
Regarding your proposed workaround, placing the problematic OID (temperatureOutside) in a separate group. I confirm that this approach works for the example group with temperature parameters. However, my question was aimed at a more scalable solution, as we have multiple groups containing 5-6 or more parameters, some of which may have the same issue (unsupported OIDs on certain device variants).
I am looking for a way to isolate the timeout so that:
The working OIDs in a multipleGet="true" group are still updated, or if without multipleGet="true" element not going into timeout.
The failing OID is simply marked as "N/A" (or a similar exception value) without causing the entire group or the element to time out.
Is there a supported method in DataMiner to handle this scenario? For example:
Is it possible to configure per OID timeout handling within a multipleGet="true" group or just on Param we are polling?
Or is there a way to use conditional polling or exception handling (e.g. via QActions or protocol logic) to detect that an OID is unsupported and skip it in future polling cycles?
I want to avoid manually splitting every potentially problematic parameter into separate groups, as that would make the protocol harder to maintain and less efficient.
Thank you again for your assistance, and I look forward to your insights.
Best regards,
Luka