4.0 Defining a MIB

 

4.1 MIB Overview
4.2 Creating a New MIB
4.3 Adding Imports
4.4 Adding a Scalar
4.5 Adding a Table
4.6 Adding a Trap/Notification
4.7 Adding Constructs Specific to SMIv2
4.8 Creating User Defined Data Type using Textual Convention
4.9 Converting the MIB Module
4.10 Dragging and Dropping a node
4.11 Parsing MIBs

 

4.1 MIB Overview

 

MIB is a file that contains definitions of management information so that networked systems can be remotely monitored, configured, and controlled. The rules for writing a MIB is defined in a collection of documents called the Structure of Management Information (SMI).

 

Defining a MIB is the first step towards development of an SNMP Agent. The steps involved in developing a MIB file are:

4.2 Creating a New MIB

 

The topics covers creating an SMIv1 and SMIv2 MIB module using MIB Editor tool. You can add Scalars, Tables, Imports, and various constructs conforming to SMI standards to make it a complete MIB. Please go through all the topics for complete knowledge on defining a MIB.

 

4.2.1 Creating an SMIv1 MIB Module

 

To create the MIB,

4.2.2 Creating an SMIv2 MIB Module

 

To create the MIB,

    Note:

    • An already existing MIB can be loaded into the MIB Editor using File -> Load MIB Module menu bar or using tool bar icon.

    • A MIB created can be modified using the Operations -> Modify Node option in the menu bar or using tool bar icon.

4.3 Adding Imports

 

Imports specify the items which need to be included from another MIB Module into the Current MIB Module. They are mainly used when an index of another MIB or a Textual Convention of another MIB need to be used. To add imports,

  1. Select Add Imports from the Operations menu in the menu bar or select the icon Add imports to the MIB present in the toolbar.

  2. From the frame that pops up, use the Import MIB button to add MIB(s) from the mibs directory.

  3. Select the MIB which you like to import and click "Load". This loads the respective MIB to the frame.

  4. Click "OK" button which loads it in the MIB tree.

  5. The Indexes and the TCs of this MIB can also be used.

Note:

  • The same procedure has to be followed for both V1 and V2 Module.

  • The MIB file to be imported and the MIB file to be created must be in the same directory.

  • By default, if no imports are specified, the MIB Editor will import mib-2, and enterprises objects from the RFC1213-MIB.

  • It is not necessary that only MIBs created by MIB Editor can be imported. MIB Editor conforms to SMIV1 and V2 specifications and ASN.1 rules for MIB definitions. Therefore, any MIB following this standard can be imported.

 

 

4.4 Adding a Scalar
 

Scalar is a leaf node that can hold only a single value. To store single values in the MIB, scalar variables can be used. To add a scalar variable to the MIB,

  1. Select Scalar Object from Operations -> Add Node in the menu bar. The corresponding template appears on the right frame.

  2. Fill in the template with the following details :

  3. Finally Add to Module and this will add a scalar variable to the MIB module.

Syntax Definition

Maximum Access Definition

Status Definition

4.5 Adding a Table

 

When a group of information is to be given in the MIB, a table can be used. A table can maintain a row with various columns. Each table has an index column and every row of the table is identified by the index column value. To define a table and add it to the MIB, you will have to define a row entry for the table object first and define one or more columnar objects with at least one index column.

 

4.5.1 Defining the Table

 

To add a Table to the MIB, the first step is to define the Table construct. Follow the steps given below for defining the Table.  

4.5.2 Adding Entry to the Table

 

Once the table is added, the template for adding an entry opens up. To add an entry,

 

Specify the

4.5.3 Adding a Column

 

Once the entry is added, the columns have to be defined and the template for the same is made available. To add a column to the table,

      Note:

      • Table Name, by convention should end with "Table" and it should start with lower case letters.

      • To add a row to a table having Row Status column please refer to Testing the Agent  section.

      • At least one column of the table should be defined as the Index column.

      • The Max Access of SMIv1 Table's Index Column are Read -Only and the Maximum Access of SMIv2 Table's Index columns are Not-Accessible.

      • There are provisions for the following conversions from the existing table:

             Column         -> Index
           Column         -> Implied Index
           Index            -> Column
           Index            -> Implied Index
           Implied Index -> Column
           Implied Index -> Index
       

4.5.4 Adding Multiple Indexes

 

This requirement of adding multiple index will arise, when a particular row needs to be identified by two index columns. A table can have any number of index columns and to add multiple indexes to a table, follow the steps given in Adding a Table topic. By checking the Index option for two or more columns in the table, multiple index support is achieved. Apart from multiple indexing, external indexing is also supported that is explained below.

 

4.5.5 Adding External Index

 

External Indices are indices which are inherited from another table of the same MIB or from a different MIB. The table from which the index has been taken is called as the "Base Table" and the table which has been formed using the index of the Base table is called as the "Derived table".

For having an External Index in the Table,

    1. Check the Index option that comes while adding entry.

    2. Choose Index is used to choose the External index from the indices listed.

    3. Only when the MIB is imported, will it be shown in External Index UI.

    4. The Augments option is disabled incase of SMI v1 MIBs. It is similar to external index.

    5. Please refer to the topic Adding Entry to the Table given above for the option.

4.5.6 Adding Implied Index

 

While querying a table, the OID of the column to be queried along with its instance values is given. The length of the Instance value is also specified in cases where the Syntax is of STRING types like OCTET-STRING, OID, Display String. In case, Implied Index support is availed, the length need not be specified. For a Table to have an Implied Index,

    Note:

    • Implied Index cannot be assigned for Index columns with Syntax such as Integer, Counter, etc. (which has no varying length).

    • If the table contains more than one index column, the last object specified in an index clause can be specified as the Implied Index, i.e., Implied Index column will be available only as the last Index.

    • A table cannot have more than one Implied Index defined in it.  

4.5.7 Row Status Support

 

Row Status is a Textual Convention (TC) defined by the SNMPv2-TC MIB. This support enables to add and delete rows in SNMPv2 tables from the management stations, at ease. This is one among the syntax provided by v2c agents. Hence, while defining a column this syntax option can be chosen. The status of whether the row is active or not-in-service etc., can be known here. The status can be any one among the following : -

To add a row to a table having Row Status column, please refer to Using Row Status under Testing the Agent section.

 

4.6 Adding a Trap/Notification

 

To notify the significant change in the state of a scalar or tabular variable, a trap or notification has to be defined for that particular variable. To define a Trap Type construct (for SMI V1) or Notification Type Construct (for SMI V2), please follow the steps given below.

 

4.6.1 Adding a Trap

4.6.2 Adding a Notification

      Note: The Notification-Group construct is used in SMI v2 MIB modules to define a collection of related event definitions. The grouping is done to show the logical grouping of events as a hint for the Agent and Management Application designers/developers. At least a single Notification Type should be present in a Notification Group.

4.7 Adding Constructs Specific to SMIv2

 

4.7.1 Object Group

 

The OBJECT-GROUP construct is used to define a collection of related object type definitions. These object type may be a member of more than one object group. At least a single Object Type should be present in the Object group. This grouping is done by the MIB Module authors to show the logical grouping of object types and to help agent and management application developers. Only the object types defined in the same MIB Module may be members of the OBJECT GROUP.

 

To add this construct,

4.7.2 Object Identity

 

The OBJECT-IDENTITY construct is used to assign an OID value to an identifier in the MIB module. The OID value assigned should be unique. To add an Object Identity to the V2 MIB,

4.7.3 Module Compliance

 

The MODULE-COMPLIANCE construct is used in SMI v2 MIB Modules to define implementation requirement specifications for agents. A requirement specification names groups of object types / events to be implemented. One or more requirement specifications may be defined within a MIB module. It may refer to the items defined in the containing MIB module and/or in other MIB Modules.

 

Currently, the primary use of the MODULE-COMPLIANCE construct is to allow the MIB module author to specify the minimal list of object types and events defined in the containing MIB module that an agent developer must implement. The construct consists of a header, followed by a list of MIB module requirement specifications. Within a MIB module requirements specification, we have a list of groups which are unconditionally required, followed by a list of conditionally required groups and exception specifications.

 

To define the construct,

4.7.4 Agent Capabilities

 

The AGENT-CAPABILITIES construct is used in SMI v2 MIB Modules to specify the implementation characteristics of an SNMP Agent sub-system with respect to object types and events. The term "implement" means that the agent provides all defined behaviors of these items, unless documented by exception clauses in the AGENT CAPABILITIES construct.

 

To define the construct,

4.8 Creating User Defined Data Type using Textual Convention

 

TEXTUAL CONVENTION constructs are used to create new Data Types. This is done by allowing restrictions on an existing base type or previously created TEXTUAL CONVENTIONS. Textual conventions are nothing but redefined data type. To define the construct,

  1. Select Textual Convention from the Operations -> Add Node menu bar and enter the following details in the template :

  2. And Add to Module.

  3. The Textual Convention is added and displayed in the MIB tree of the left frame. Note that the defined TC cannot be modified or deleted.

4.9 Converting the MIB Module

 

To convert a MIB module,

  1. Select File -> Convert MIB option from the menu bar which converts the MIB module from SMI v1 to SMI v2 or vice versa.

  2. Also Save as  option from the File in menu bar can be used for saving MIB Module. It can also be used for saving the MIB in the required location in the preferred name.

4.10 Dragging and Dropping a Node

 

The MIB Editor application facilitates dragging and dropping of nodes. You can drag a node from one group, drop it into another group and save the MIB to store the changes. Dragging and Dropping of a scalar group or a tabular group or a combination of both onto an Object Identifier (in case of v1 and v2) and Module Identity (in case of v2) is possible. You can also move the child node of a parent to another parent node.

 

Note: It is not possible to drag and drop a Trap/Notification and a Textual Convention. You cannot move a Module Identity either under its child node or its parent node.

 

4.11 Parsing MIBs

 

While loading MIB files in MIB Editor, it performs the following operations.

While performing the parsing and validation of the MIB files, if the MIB modules fail to conform to the SMI standards the loading will not be done. However, the Editor application requirements might mandate the loading of the non-standard files. On the other hand, some applications might require a stricter check on the compliance to the standards.

 

The parsing and validating syntax of the MIB file can be configurable. Agent Toolkit provides the following set of parsing levels which facilitates to select the level of parsing required by the Mib Editor application.

In the Mib Editor application, parsing level has to be set first before loading a MIB. This level, once set, is used for subsequent MIBs that are loaded. If the level needs to be modified for the next set of MIBs loaded, it has to be set again.

 

Constructing the MIB Module into the Tree Structure

 

If parsing is completed successfully, the API resolves the parent and child nodes in the current module. If there are any unresolved nodes, it tries to load from the imported module that is defined in the IMPORTS section. If the unresolved object is not present even in the imported module, unresolved TC construct {objectName1, objectName2, ...} exception is thrown.

If the parsing level is NORMAL, SERIOUS, or CRITICAL, and if the MIB file contains errors, then the compiled files (cmi and cds files) or the serialized files (ser files) will not be created.

 

Checks for Various Parsing Levels

 

The following tables describes the different levels of parsing that can be set and their corresponding checks.

 

S.No.

Level of Parsing

 Checks

Description

1

Lenient

No Checks

This level accepts all types of MIB files. For example, it allows both SMIv1 and v2.

2

Normal

Default checks

This level is the default level conforming to the obsolete standards, such as RFC 1902, RFC 1903, etc. Most MIBs follow the obsolete standard.

3

Serious

Serious Checks

This level strictly follows the current standard. It accepts the constructs with inter-operability and implementation problems.

4

Critical

Critical Checks

This level completely follows the SMIv1 and v2 standards. However, it does not accept the backward compatibility constructs, constructs with inter-operability and implementation problems, etc.

 

Normal Parsing Level

 

When the parsing level is normal (default parsing level), the following checks are included.

Serious Parsing Level

 

When the parsing level is serious, the following checks are done in addition to Normal checks.

Critical Parsing Level

 

When the parsing level is critical, the following checks are done in addition to Serious checks.  

When the parsing level is Lenient, none of the above checks are done.

 

There are some rules that a MIB file should follow, without which the MIB tree is not formed properly. When the parser encounters such violations, MibException is thrown.

Therefore, the following checks are done even when the parsing level is set to lenient. These checks are termed as "Very Critical Checks" and are done irrespective of the parsing level.


Copyright © 2013, ZOHO Corp. All Rights Reserved.