We’ve been analyzing an SNMP walk from one Edge-Core switches and noticed it returns non-consecutive interface indexes (like 1, 2, 54, 746, 1001, 1404, etc.).
Our driver polls the ifTable using this configuration:
OID
type="complete"
options=";instance;multipleGetNext"
I understand that this method assumes consecutive indexes and uses incremental GetNext requests instead of performing a full SNMP walk.
It works well with most models but can miss higher or non-sequential indexes — for example, VLAN or loopback interfaces.
I’d like to understand the design reasoning behind this choice, since it is not returning any information in one of our customers.
Any insights from those who’ve worked on similar drivers or protocols would be great.
Hi Esteban,
Allow me to correct your assumption there, none of the snmp table polling methods are meant to expect consecutive indexes. MultipleGetNext does a GetNext request on every column of the table in one go. GetNext = give me the next OID starting from this one, no matter if the next OID is consecutive or not, it should work. It is the SNMP Agent on the data source side that will provide you with the next available OID, it is not DM that will ask a specific OID based on what is the next consecutive one. I would invite you to read our Retrieving tables page on DM Docs for more details.
This means that if it doen't work in your case, there must be a bug somewhere, either in the connector, either on DM side, either in the SNMP Agent of your data source. If you are still out of ideas/options after reading the above mentioned page, I would invite you to further investigate this with an experienced Skyline colleague (System developer) and if the suspicion is on the DataMiner side, create an UOSA ticket for it.