NAME

Solaris::MIB2 - Perl extension for reading network device status and throughput information.

SYNOPSIS

  use Solaris::MIB2 ':all';

  $mib = new Solaris::MIB2;
  foreach my $entry ( @{$mib->{ipNetToMediaEntry}} ) {
     print "Device: $entry->{ipNetToMediaIfIndex}\n";
     print "IP Address: $entry->{ipNetToMediaNetAddress}\n";
     print "Phys Address: $entry->{ipNetToMediaPhysAddress}\n";
     ...
  }

DESCRIPTION

MIB or Management Information Base is a collection of data describing the operations of a particular device on a network. Normally, MIB data is delivered through SNMP (Simple Network Management Protocol). The detailed description of information elements, maintained within a MIB database could be found in RFC 1213. Reading MIB data through SNMP is fairly involved and requires availability of a heavy duty SNMP infrastructure - SNMP agents, management stations, etc. Solaris::MIB2 allows for a simplified retrieval of the MIB data via a hierarchical hash interface. In order to read tcp statistics, for instance, one would just have to create an instance of Solaris::MIB2 and read the values, using the hash reference, returned from the 'new' function:

   use Solaris::MIB2;

   $mib = new Solaris::MIB2;
   print $mib->{tcpInSegs}, $mib->{tcpOutSegs}, "\n";
   ...

Solaris::MIB2 utilizes the fact that Solaris stream modules maintain extensive statistical data pertinent to the operations and throughput of a particular network device. In addition to normal data, which can be written out to the network through the streams mechanism, control messages can also be sent downstream. One of the control messages is the option management request, which instructs the stream modules to return all available statistical information. Unfortunately, retrieving MIB data is 'all-or-none' proposition - i.e. once a control message is sent downstream, all stream modules will send their information back so that it is impossible to just retrieve the data, pertinent to, say, UDP. Hence, Solaris::MIB2 extension is NOT a tied-hash - i.e. reading a particular value from the MIB handle doesn't trigger a control message to be sent downstream. Instead, when the instance of Solaris::MIB2 is first constructed, the message is sent and all information, returned by the stream modules, is saved into the hierarchial hash structure. In order to refresh the values, 'update' function shall be used as follows:

   use Solaris::MIB2;

   $mib = new Solaris::MIB2;
   print $mib->{tcpInSegs}, "\n";
   ...
   $mib->update();
   print $mib->{tcpInSegs}, "\n";
   ...

Internally, Solaris::MIB2 constructs a stack of streams modules for the sole purpose of retrieving the MIB data. By default (i.e. if no parameter is passed to the 'new' function) it will attempt to open '/dev/arp' as it doesn't require any special privileges. The '/dev/arp' streams stack seems to contain all the necessary stream modules, therefore, all statistics should be accurate. To make sure that the stack is constructed exactly to your specification, you may want to create an instance of Solaris::MIB2 over the '/dev/ip' as follows:

   use Solaris::MIB2;

   $mib = new Solaris::MIB2 '/dev/ip';

On Solaris, however, '/dev/ip' is only accesible by root and members of sys group, therefore the script should be run with sufficient level of privileges. One approach is to make every Solaris::MIB2 script setgroupid 'sys', which is fairly secure as starting from Solaris 2.6 OS supports secure setuid/setgroupid scripts. In fact, this is exactly how netstat command is setup under Solaris - it is setgroupid sys.

EXPORT

None by default.

AUTHOR

Alexander Golomshtok, golomshtok_alexander@jpmorgan.com

SEE ALSO

perl.