Multiple sub-agents for one table in Net-SNMP

437 Views Asked by At

I'm writing a custom MIB to expose a table over SNMP. There will be one table with set columns, but a variable numbers of rows. Is it possible, with Net-SNMP, to add multiple rows to the table from multiple processes (e.g. process A creates row 1, process B creates row 2, etc...)? I would like to avoid having one "master sub-agent" if possible (other then something that is a part of Net-SNMP, like snmpd/snmptrapd/etc).

I would like to use mib2c to help generate code if possible, but I can work around that if it can't accomplish what I need.

I'm using Net-SNMP 5.5 at the moment. Upgrading is possible if support for what I need is added in newer versions.

1

There are 1 best solutions below

0
On

If writing AgentX for snmpd, it looks like you cannot share the table OID over two or more AgentXs, snmpd responds with an error that oid is a duplicate for some of the sub-agents. Thus I am continuing my sources with my own sub-sub-agents (based on Enduro/X) which collect the data into a single AgentX which would fill the SNMP table.

According to the https://www.rfc-editor.org/rfc/rfc2741.html#section-7.1.4.1 :

7.1.4.1. Handling Duplicate and Overlapping Subtrees

As a result of this registration algorithm there are likely to be duplicate and/or overlapping subtrees within the registration data store of the master agent. Whenever the master agent's dispatching algorithm (see section 7.2.1, "Dispatching AgentX PDUs") determines that there are multiple subtrees that could potentially contain the same MIB object instances, the master agent selects one to use, termed the 'authoritative region', as follows:

 1) Choose the one whose original agentx-Register-PDU r.subtree
    contained the most subids, i.e., the most specific r.subtree.
    Note: The presence or absence of a range subid has no bearing
    on how "specific" one object identifier is compared to another.

 2) If still ambiguous, there were duplicate subtrees.  Choose the
    one whose original agentx-Register-PDU specified the smaller
    value of r.priority.

So in best case scenario, you might get that data is randomly collected from one AgentX or another, if the same oid is registered from different AgentX processes