Sun Microsystems
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Index     Next Next

2.7.3 SNMP MIB Compiler - mibgen

The mibgen tool takes as input a set of SNMP MIBs and generates standard MBeans that you can customize. MIBs can be expressed using either structure of management information (SMI) v1 or SMI v2 syntax.

A MIB is like a management interface. It defines what is exposed, but it does not define how to compute the exposed value. Therefore, MBeans generated by mibgen need to be customized to provide the definitive implementation. The MIB is implemented through Java objects, meaning that it has access to all Java runtime libraries and all features of the dynamic agent where it will be instantiated.

The mibgen compiler parses an SNMP MIB and generates the following:

  • An MBean representing the whole MIB

  • MBeans representing SNMP groups and table entries

  • Classes representing SNMP tables

  • Classes representing SNMP enumerated types

  • A class mapping symbolic names with object identifiers

The resulting classes should be made accessible in the agent application. When the single MBean representing the whole MIB is registered in the MBean server, all the associated groups are automatically instantiated and registered as well.

The mibgen compiler supports all data structure of SMI v1 and v2 protocols, including:

  • Tables with cross-references indexed across several MIBs

  • MIBs that contain either SMI v1 or v2 definitions

  • Nested groups

  • Default value variables

  • Row status variables

The Java DMK also provides an example program, showing how an agent can act as an SNMP master agent to access MIBs implemented remotely in subagents. This allows SNMP managers to access hierarchies of agents through a single master agent. In this way, some MIBs can be implemented by native devices and others can be implemented in JMX agents, yet this heterogeneous architecture is completely transparent to the manager issuing a request.

2.7.4 SNMP Manager API

The SNMP manager API simplifies the development of Java applications for managing SNMP agents. Its classes represent SNMP manager concepts such as sessions, parameters, and peers through Java objects. Using this API, you can develop an application that can issue requests to SNMP agents.

For example, you could create an SNMP resource using the SNMP manager API. You would define a management interface that corresponds to your resource's MIB, in which variables are easily mapped as MBean attributes. In response to calls on the attribute getters and setters, your MBean would construct and issue an SNMP request to the SNMP agent that represents the resource.

The SNMP manager API supports requests in the SNMP v1, v2 or v3 protocol, including inform requests for communicating between SNMP managers. The manager API is used to access any compliant SNMP agent, including those developed with the use of the Java DMK.

2.7.5 SNMPv1 and SNMPv2 Security

Because of backward compatibility, Java DMK 5.1 implements the security aspects of the SNMP protocol v1 and v2. However, you should implement the superior security mechanisms of SNMPv3, which are added in the Java DMK 5.1.

2.7.5.1 SNMPv1 and SNMPv2 Access Control

SNMPv1 and v2 define an access control mechanism similar to password authentication. Lists of authorized manager host names are defined in an access control list (ACL) stored in a file on the agent side, called the IP ACL file. There are no passwords, but logical community names (IP addresses) can be associated with authorized managers to define sets of allowed operations.

The SNMP adaptor performs access control if an ACL file is defined. Because SNMP is a connection--free protocol, the manager host and community are verified with every incoming request. By default, the file is not loaded and any SNMP manager can send requests.

The ACL file is the default access control mechanism in the SNMP protocol adaptor. However, you can replace this default implementation with your own mechanism. For example, if your agent runs on a device with no file system, you could implement access control lists through a simple Java class.

2.7.5.2 SNMPv1 and SNMPv2 Encoding

SNMP requests follow the standardized Basic Encoding Rules (BER) for translating management operations into data packets. At the communication level, an SNMP request is represented by an array of bytes in a UDP protocol packet. The SNMP components in the Java DMK provide access to the byte encoding of these packets.

Your applications can customize the encoding and decoding of SNMP requests, as follows:

  • On the manager side, after the request is translated into bytes, your encoding can add signature strings and then perform encryption.

  • On the agent side, the bytes can be decoded and the signature can be verified before the bytes are translated into the SNMP request.

    A decoded SNMP request contains the manager's hostname and community string, the operation, the target object, and any values to be written. Like the context checking mechanism, you can insert code to filter requests based on any of these criteria. However, inserting your own code would make the protocol proprietary.

2.7.6 SNMPv3 Security

The main addition to Java DMK 5.1 provided by SNMPv3 is the possibility of secure SNMP operation. The SNMPv3 security in Java Dynamic Management Kit 5.1 implements the following SNMP RFCs:

RFC 2571

Architecture

RFC 2572

Message Processing and Dispatching

RFC 2574

USM

The SNMPv3 protocol implementation provides:

  • A dispatcher, the SNMP adaptor, for sending and receiving messages

  • The SNMPv3 Message Processing Model (MPM), to prepare messages for sending and to extract data from messages received

  • A User-based Security Model (USM), to provide authentication and privacy for SNMP operations

  • A user-based Access Control Model (ACM), to control access to Java management agents

  • A USM local configuration data file (LCD) that allows configured users persistency

Despite the differences between the previous versions of SNMP and SNMPv3, agents in Java DMK 5.1 can respond to requests from any version if the SNMPv3 protocol adaptor is used. SNMP v1 and v2 requests have greater security constraints than v3 requests in an agent compatible with SNMPv3.

The USM MIB is accessible remotely and is not registered to the SNMPv3 adaptor by default.

The USM MIB can be registered in an MBean server, thus making it accessible through the HTML adaptor. This is particularly useful when debugging, although it does create a security risk. Exposing the USM MIB through SNMP without the MBean server, however, is not insecure.

Users can also be configured into an agent by means of an ASCII text file that acts as an initial configuration template for all agents created.

Previous Previous     Contents     Index     Next Next