MIB limits (columns in tables and compliance objects)

Question

I am writing some enterprise MIB modules, including tables (columnar objects) and compliance statements.

I note that when using the iReasoning MIB Browser (version 9.0 build 3532) under Linux, it only seems to display the first 15 compliance objects in a group (See MODULE-COMPLIANCE and GROUP).

Does anyone know of any limits of compliance objects in a single group? For example, in Net-SNMP, NMS, (other) MIB browers etc. How many is "safe" to use in a MIB definition? I know that I can define multiple groups to keep the number of objects within this limit.

Further, the objects in the group are columns of a table. I know that extension tables can be used to reduce this number, i.e. extension table(s) using the AUGMENTS clause, or a "repeated" INDEX clause from a base table. However, is there any general limit for the number of columns in a table?

Thanks in advance.

Answer 1

I can't speak to any implementations except ours as to what's "safe", but there are no such limits to the number of objects in a group imposed by the standards, only that the OBJECT-TYPE or NOTIFICATION-TYPEs listed in the OBJECTS and NOTIFICATIONS clauses of OBJECT-GROUPs and NOTFICATION-GROUPs (respectively) must be defined in the same module as the group itself. If your tool only displays 15, then it sounds like a limitation of that specific tool.

Similarly, there are no limits imposed by the standard specifically on the number of columns in a table. You are, however, indirectly limited in how many columns are used as INDEXes depending on type: SNMP specifically limits OIDs to at most 128 subidentifiers [RFC-2578 §3.5]. There are different encoding rules for different SYNTAXes for objects used as INDEXes that result in subidentifiers appended to the column's OID to indicate a particular instance of that columnar object [RFC-2578 §7.7]. The total count of subidentifiers in the column's OID plus each of the instance subidentifiers will be limited to 128.

Other than that, your concern would just be with implementation-specific limits for SNMP message size (or fundamental UDP packet size limit) for tools that might want to fetch tables full-row at a time rather than full-column at a time.

But if you have so many columns that you're concerned with that, there is probably a lot of room for factoring/normalizing the tables anyway, without concern for message size--just with organization.