MIB Editor


Creating a New MIB


Mib Editor tool is used for creating a v1 MIB module and v2 MIB module. MIB creation does not stop with this. You can add Scalars, Tables, Imports, and various constructs conforming to SMI standards to make it a complete MIB.


Creating a V1 MIB Module


To create a V1 MIB,

You can see the Parent Node (MIB file name) added under the MIB tree frame in the left side.


Creating a V2 MIB Module


To create a V2 MIB,

You can see the Parent Node (MIB file name) added under the MIB tree frame in the left side.



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

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

  • To edit the MIB use Undo, Redo, Copy, Paste, and Find options in the Edit menu or in the toolbar.


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.

  2. From the frame that comes, use the Import MIB button that lists all the MIBs in mibs directory.

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

  4. Click "OK" button which loads the MIB in the Editor frame.

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



  • 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 enterprises objects from the RFC1155-MIB for SMIv1 and enterprises module identity from the SNMPv2-SMI for SMIv2.  

  • It is not necessary that only MIBs created by Mib Editor can be used for Adding imports. Mib Editor conforms to SMIv1 and SMIv2 specifications and ASN.1 rules for MIB definitions. Therefore, any MIB following this standard can be imported.


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,

Syntax Definition

Maximum Access Definition

Status Definition

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.


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:

  1. Select Table Object from the Operations -> Add Node menu bar.

  2. The corresponding template appears on the right side frame.

  3. Fill in the template with the following details :

  4. Finally, Add Table.

Adding a Row


Once the Table and Entry are added the template for adding a row opens up. To add a Row, specify the

Adding a Column


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


Specify the,

And Add Column to Table. Finally, "Add to Module". This will add the Table Node under the specified parent ID and display it in the MIB Tree.




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

  • 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.


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.

Adding External Index


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

For having an External Index in the Table,

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,


  • Implied Index can be assigned for Index columns with Syntax of varying length namely OCTET-STRING and OID. i.e., it cannot be assigned for Syntaxes such as Integer, Counter, etc.

  • 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.

  • Any Table which has an implied index cannot be used as an External Index column. i.e if a Table has an Integer Index and the second index as an implied index and say another Table uses the Integer Index in this Table as the external index then it will not work.

  • Any Table which has an implied index column and other additional indexes, it should not be made as the Augments for other Table.


Row Status Support


Row Status is a Textual Convention (TC) defined by the SNMP v2c 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 notIn Service etc., can be known here. The status can be any one among the following : -


active (1)

notInService (2)

notReady (3)

createAndGo (4)

createAndWait (5)

destroy (6)


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


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.


Adding a Trap

    1. Select an OID.

    2. Add Trap Type, using Trap Type Construct from the Operations -> Add Node menu bar.

    3. A Template opens up wherein the following details need to be filled in for Trap Type Construct :

      • Trap Type : The first 6 Trap types mentioned here are of Generic Type and are defined by the snmp group of MIB-II.

      • Cold Start : coldStart traps indicate that a device has just powered up or has performed a complete reinitialization (hard-reset). The configuration of the device may have changed and any data collected prior to the reset may have been lost.

      • WarmStart : The warmStart is an indication that adevice has reinitialized. Neither the device configuration nor the stored data gets changed. The device is expected to continue in the same state as seen before the reinitialization.

      • linkdown : The linkDown trap is an indication that a communications link or a port on a network node has failed. The affected interface is identified in the first variable binding of the Trap PDU data as the name and value of the ifIndex instance of MIB-II interfaces group of the link that went down.

      • linkup : A linkUp trap is an indication that a communications link or a port on a node has come up and is ready for service. The affected interface is identified in the first variable binding of the trap PDU data as the name and value of the ifIndex.

      • Authentication Failure : The authenticationFailure trap indicates that an agent has received an SNMP message that cannot be authenticated. This is typically an indication that the SNMP PDU contained an unrecognized community name, or that the message was sent from a node residing at an network address not authorized to send SNMP requests to the agent.

      • egbNeighborLoss : The agent is reporting that the peer relationship between an External Gateway Protocol (EGP) neighbor and an EGP peer no longer exists.

      • enterprisespecific : This trap is used to define all events other than the six generic traps specified above. An "enterprise specific trap" is indicated by a value other than "snmp" for the ENTERPRISE field. The sending agent has detected an enterprise-specific event. The value of the specific trap type field indicates the nature of the event.

      • Enterprise : A Trap message is identified by the value in this Enterprise field. If the value specified is SNMP(., then the value is for generic-trap. Generic-traps are defined traps and so you need not define them. Otherwise, they are specific-traps. You can define Specific from the listed entries.

      • Variables : Used to specify one or more scalar or columnar objects whose value describes the event. The variables are listed by pressing the Var button.

      • Description and Reference: Trap Type can be specified, if required.

      • Sub ID for Trap Type construct (Need not be modified).

    1. Finally, Add to Module.

    2. The construct gets added to the MIB and is displayed in the MIB Tree in the left hand side.

Adding a Notification

    1. Select an OID/ ModuleIdentity/ ObjectIdentity.

    2. Add Notification Type, using Notification Type Construct from the Operations -> Add Node menu bar.

    3. A Template opens up wherein the following details need to be filled in for Notification Type Construct:

      • The Template for Notification Type includes :

      • Name of the Notification Type.

      • Sub ID of the Notification (Need not be modified).

      • Parent OID of the Notification Type.

      • Status of the Notification - Current / Deprecated / Obsolete.

      • Scalar and Tabular Objects for which Notification has to be generated. These objects need to be browsed and chosen.

      • Description and Reference for the Notification Type can be given, if required.

    4. Finally click Add to Module to add the Notification.


The Notification-Group construct is used in SNMPv2 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 the Notification Group.


Adding Constructs Specific to SMIv2


Object Group


The OBJECT-GROUP construct is used to define a collection of related object type definitions. These object types 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,

    1. Select a Node.

    2. Add Object Group from the Operations -> Add Node menu bar.

    3. The corresponding template opens for the details to be filled in for the following :

      • Name of the Object Group.

      • Sub ID of the Group (Need not be modified).

      • Parent ID of the Group.

      • Objects to be present in the Group.

      • Status of the Group.

      • Description and Reference for the Node, if required.

    4. Finally, Add to Module. The construct gets added in the MIB Tree.

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,

Module Compliance


The MODULE-COMPLIANCE construct is used in SNMPv2 Mib Modules to define implementation requirement specifications for Agents. A requirements specification names groups of object types / events to be implemented. One or more requirements 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 requirements 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,

The Module Compliance construct is successfully added in the Mib tree.


Agent Capabilities


The AGENT-CAPABILITIES construct is used in SNMPv2 Mib Modules to specify the implementation characteristics of a 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,

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 do not create a new SAN type, but these textual conventions look and function as a new Data Type. To define the construct,


Textual Convention cannot be modified or deleted using the MibEditor and it has to be done manually by editing in some text editors.



Saving a MIB


To save a MIB Module,

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 parent node to a child node.



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


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 not 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. It is recommended to use the higher parsing level (SERIOUS, CRITICAL) for validating the MIB file and not for loading the MIB file in the application. It affects the performance of the application while loading the MIB files, because it takes considerable amount of time and resources, such as memory, CPU usage etc.


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



No Checks

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



Default Checks

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



Serious Checks




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 © 2012, ZOHO Corp. All Rights Reserved.