Hi Dojo,
When using the redundant polling feature Redundant polling | DataMiner Docs,
Would there then be interference if we still have two single snmp parameters that are being force polled each on their fixed IP?
Our goal is to have the same base OID being polled fixed on Interface A and on Interface B.
This way we can detect and show the connection status ("in timeout" or "OK") onto two custom parameters we can monitor.
We are not sure if force polling via using the ipid feature (ipid attribute | DataMiner Docs)
would work, or if the redundant polling would over-rule the destination for us?
Also, what will happen if there is a timeout for one of these single parameters? I hope this does not confuse the redundant polling feature, and avoid switching around all the time.
Alternatively, I was wondering how the QAction Notify SNMP GET could be a potential alternative option here?
NT_SNMP_GET (295) | DataMiner Docs
or even the RAW GET NT_SNMP_RAW_GET (424) | DataMiner Docs to avoid interference.
Please advise on the best way forward.
Thank you.
Hi Thijs,
I tested this and found that forcing polling to a specific connection via Connection ID or IPID interferes with redundant polling. If a connection fails, I noticed that it toggled unpredictably or would continue using the failed connection
NT_SNMP_RAW_GET does not interfere with redundant polling, so it seems to be the best way forward. Note: I observed that it returns an empty string ("") on timeout instead of null as the documentation suggests.
Hi Thomas, I've tested with NT_SNMP_GET and it too does not trigger redundant polling. A general observation is that SNMP Gets done through QActions are performed independently from the communication options set in protocol.xml. Referring to the documentation, a lot of communication settings like timeout, retries and community strings are defined in C# when these functions are made, which supports my previous observation.