Thanks for the explanation ..... although I have some more questions.
Table1 is the "main table" while Table2 is a "sparse" table. Table2 can be
thought of as providing additional column information to extend Table1 and
Table2 is indexed by the same table index defined by Table1.
What would be the best way to store this information within NetSNMP?
Currently, I am using the "mib2c.mfd.conf" configuration file to generate code
using mib2c. For each row defined in "Table1", I allocate a new row_context in
NetSNMP and store the data (ie: column data) in that row index. Since "Table2"
is an extension of Table1, then it does not seem like I should be allocating
new row_contexts for all the rows Table2 fields. It seems like I should be
store Table2 field data into the "existing" row contexts defined by Table1
..... is this correct?
If this is correct, then how is this possible within NetSNMP? How can I obtain
an existing row_context allocated when processing Table1 and expand it to store
the additional data defined in Table2? Perhaps I need to use a different
configuration file to generate code via mib2c?
Also, knowing that Table1 and Table2 are defined separately, but are related,
then should the "snmpwalk" command display all data defined in Table1 and
Table2 at the same time by issuing only one "snmpwalk" command ...... or should
an "snmpwalk" command be issued for Table1 and then again for Table2 separately?
Dave Shield <[EMAIL PROTECTED]> wrote: On 25/05/07, Need Help wrote:
> 1) I noticed Table2 does "not" have an "ocStbHost1394Index" field defined.
> I was wondering why Table2 did not have an "Index" field like Table1 had
> defined? I assumed all Tables would have an "Index" field which would
> represent the row index used for storage by NetSNMP. What am I not
> understanding here?
>
> 2) To make me more confused, I looked into the "OC-STB-HOST-MIB" MIB file at
> the definition of Table2 and saw that the definition of Table2 includes the
> "ocStbHostAVInterfaceIndex" field (which is a field defined by Table1). How
> can Table2 reference a Table1 field?
These are basically both the same question.
Table1 is a "normal" table - consisting of assorted column objects, and
indexed by a single integer value, which is one of these column objects.
This is the normal approach to defining a self-contained table.
It exists on its own, with no dependency on any other part of the MIB.
Table is not a "normal", self-contained table.
In fact, it's perhaps best thought of as not being a separate table at all.
Instead, think of these two as forming a single (combined) table, that
just happens to be defined in two chunks:
| Row 1 | .... | Row 1 (ctd) |
| Row 2 | .... | Row 2 (ctd) |
| Row 3 | .... | Row 3 (ctd) |
(Table 1) (Table 2)
The same index value is used for both tables, becase this identifies
a single (combined) row.
There are two main reasons for adopting this style of indexing.
The first is when one table monitors the "core" behaviour, and the
second monitors some (optional) extension. For example, the
Host Resources MIB includes a pair of tables to monitor the processes
running on a given system.
One table (hrSWRunTable) contains the basic information about the
process (name, arguments, PID, etc). This is typically fixed for a given
process, and tends not to change during the lifetime of that process.
The other (hrSWRunPerfTable) contains performance information
(memory and CPU usage). This refers to exactly the same processes,
so uses the same index values. But this is harder to implement
(because it is much more likely to change), and may not be needed.
So it's defined as a separate (optional) table, extending the first.
The second reason for such an approach is where the first table is
fairly general, and the second more specific, monitoring a subset of
the first.
Again, there's an example of this in the Host Resources MIB.
This includes one table (hrDeviceTable), containing information
about all the hardware contained in that system (CPUs, network
cards, disks, printers, etc). This is indexed by a single integer
index (hrDeviceIndex).
But the MIB also includes a series of hardware-specific tables,
concerned with particular types of device. Now the table for
monitoring CPUs doesn't make sense when applied to a network
interface device (or vice versa). So the hrProcTable will only
contain rows for CPU devices, and the hrNetworkTable will only
contain rows for network interfaces. But the same index is used
for all of them. This is known as a "sparse" table:
| Device 1 (cpu) | .... | CPU 1 | .....
| Device 2 (cpu) | .... | CPU 2 | .....
| Device 3 (n/w) | .... ..... | N/W 3 |
(Device Table) (CPU Table) (Network Table)
That diagram may not line up cleanly, but hopefully you get the idea.
I haven't looked closely at the MIB you are working with, but I
suspect that the idea is similar here.
Dave
---------------------------------
Pinpoint customers who are looking for what you sell. -------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
