Question regarding uniqueness of node names

[danielr1996]

I'm currently experimenting with gosnmp and gosmi to write a terraform module for my dlink dgs 1210-24 switch, so far I'm able to set single values by looking up the oid and then passing the oid to gosnmp using e.g.gosmi.GetNode("sysSwitchName") and I got the right oids for the values I'm setting, however I'm wondering what happens if I had two nodes with the same name but in another subtree, to mitigate that I tried passing the full path of companySystem.sysSwitchNameto GetNode() but then I couldn't find the node.

Is it possible to get an oid by full path instead, if not, how can I make sure that I get the right node. In the mib of my switch there are no duplicate nodes, but eventually I want the terraform module to be as generic as possible, so I want to avoid errors when using other mib that are currently unknown to me.

[sleepinggenius2]

Node names only need to be unique per module, which is why GetNode() takes an optional second parameter for the module. Using your example, if you had a node named sysSwitchName in module COMPANY-MIB, then you can use module, err := gosmi.GetModule("COMPANY-MIB") to get the module, then node, err := gosmi.GetNode("sysSwitchName", module) or node, err := module.GetNode("sysSwitchName") to make sure you get the node you're looking for. If you already know the numeric OID, then you can also use GetNodeByOID() to uniquely target the node you're looking for as well.

[danielr1996]

Ok so I did a quick test and I'm not really sure about the the uniqueness in the module. I duplicated the sysSwitchName under the companyIpifGroup tree, so now my MIB contains two entries with the same name but on a different path

 sysSwitchName OBJECT-TYPE
      ...
       ::= { companyIpifGroup 5 }

 sysSwitchName OBJECT-TYPE 
      ....
       ::= { companySystem 1 }

When running

package main

import (
	"fmt"
	"github.com/sleepinggenius2/gosmi"
	"log"
)

func main() {
	gosmi.Init()
	gosmi.AppendPath("/usr/share/snmp/mibs") # Imported MIBs like SNMPv2-SMI, come with netsnmp
	gosmi.AppendPath("mibs")
	_, err := gosmi.LoadModule("dgs-1210-24-d1")
	if err != nil {
		log.Fatalf("Error opening file: %v\n", err)
	}

	v, err := gosmi.GetNode("sysSwitchName")
	fmt.Println(v.Oid.String())
}

I get 1.3.6.1.4.1.171.10.76.24.2.5 which is the one I added, so when a node is duplicated gosmi seems to take the last node it found.

I know I just made that example up, but how can I be really sure that there is no MIB file with duplicate node names inside a module, is this forbidden by some rfc, or is this just a convention used by vendors which we rely on here.

Looking at my MIB with browser shows that each node contains some sort of reference to it's parent, but it doesn't really seem to follow a specific pattern.

After all, why should snmp even use a tree if every node name would be unique, then it could just be one big table like structure.

[danielr1996]

Well I forgot to just google: https://stackoverflow.com/questions/59619704/must-object-names-descriptors-be-unique-within-an-snmp-mib-module basically confirms my assumption, it's not technically forbidden to use a duplicated entry name, but per the rfc it should be unique.

[sleepinggenius2]

It is not technically forbidden, but you're definitely going to have a bad time if it's not unique. For example, when linking a child node, which parent should it refer to? When importing a node from a module, which should it refer to? I have not tested this, but I believe the way the library would handle that at the moment is when linking inside of a module, it would use the most recently defined parent, so two nodes that refer to the same parent name could be part of different subtrees, and when importing it would use the last defined one, because it's looking up names in exactly the same way you are. In practice, I have not come across duplicates in the wild and a MIB file would certainly fail linting if it had duplicates, but based on all the other issues I've seen, there are a lot of companies that do not consistently lint their MIB files before releasing them, so ymmv.

[danielr1996]

Well then I'm happy that my switch is conformant and everything works fine.

Thank you very much for the explanation.