How To Create Custom Snmp Mib

MIB Editor

Creating a New MIB
Adding Imports
Adding a Scalar
Adding a Table
Adding a Trap/Notification
Adding Constructs Specific to SMIv2
Creating User Defined Data Type using Textual Convention
Saving a MIB
Dragging and Dropping a Node
Parsing a MIB

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,

Start the MIB Editor Application.
Select File -> Create MIB from the menu bar or by clicking on icon.
Fill in the following details in the wizard that opens up :
- Name of the MIB Module (Module Name should start with an uppercase letter).
- Directory in which the MibModule should be placed.
- Version of the MIB (Choose SMI V1) and
- The Root OID of the MIB.
- And click OK .

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,

Start the MIB Editor Application.
Select File -> Create MIB from the menu bar or by clicking on icon.
Fill in the following details in the wizard that opens up :
- Name of the MIB Module
- Directory in which the MibModule should be placed.
- Version of the MIB (Choose SMI V2) and
- The Root OID of the MIB.
- And click OK .

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,

Select Add Imports from the Operations menu in the menu bar.
From the frame that comes, use the Import MIB button that lists all the MIBs in mibs directory.
Select the MIB which you like to import and click "Load". This loads the respective MIB.
Click "OK" button which loads the MIB in the Editor frame.
The Indexes and the TCs of this MIB can also be used.
- To use the Indexes : While defining a Table for the New MIB, chose augments or index from Add External Indices/Augments . If index is chosen, it helps you to utilize any selected index of the imported MIB. If Augments option is chosen, all the indexes under the selected entry will be added from the imported MIB.
- To use the TCs : While defining a TC for the New MIB, the Syntax option combo box includes all the TCs of the imported MIB from which you can choose for the new MIB.

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 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,

Select Scalar Objects from Operations -> Add Node in the menu bar.
The corresponding template appears on the right frame. Fill in the template with the following details :
- Name for the Object Type.
- Sub ID of the node (need not be modifided).
- Parent ID for the Scalar Node. (you will not be able to edit this field)
- Syntax to be used for the Scalar Node. The "..." button opens up with a wizard to specify the Value/Range or Enumeration for the syntax chosen.
- Maximum Access for the Node.
- Status of the Node.
- Description of the Scalar Node (If Required).
- Reference for the Scalar Node (If Required).
- Format in which the Default Values have to be generated : either Decimal or Binary or Hexa. Just choosing the required format in the combo box will generate default values in that format.
Finally Add to Module . This will add the Scalar Node under the specified Parent ID and display it in the MIB Tree.

Syntax Definition

Simple option defines the default integer range. It takes the format specified in DefVal.
Enumeration defines a variable for a particular value. Sample Definition : Value - 1, Label - true. This enumeration can be added to the Syntax type.
Value/Range enhances you to specify your own range of Integer. The MIB will respond only with the values that lie within the Range.

Maximum Access Definition

Read_Only - Access for retrieving values of the node.
Read_Write - Access for retrieving and modifying the values.
Write_Only (only for v1) - Access for modifying the existing values of the node.
Read_Create (only for v2) - Access for retrieving, modifying, and creating the values.
Not_Accessible - Access for not being able to perform any operation on this node.
Accessible for Notify (only for v2) - Access for notifying a significant change in the node.

Status Definition

Mandatory (only for v1) - indicates that the definition is valid and should be implemented.
Current (only for v2) - indicates that the definition is valid currently.
Deprecated - indicates that the definition will soon be made obsolete and need not be implemented.
Obsolete - indicates that the definition is not valid and should not be implemented.
Optional (only for v1) - indicates that the definition is valid and may or may not be implemented.

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:

Select Table Object from the Operations -> Add Node menu bar.
The corresponding template appears on the right side frame.
Fill in the template with the following details :
- Name for the Object Type.
- SubID of the Node (Need not be modified).
- Parent OID of the Node.
- Syntax Sequence gets loaded automatically as xxxEntry, xxx being the prefix of of the Table created. This is a special value of the SYNTAX which indicates that a table object is being defined.
- Maximum Access for the node. By default,it will not be accessible and cannot be configured.
- Status of the Table node. It can be deprecated, mandatory, optional or obsolete.
- Description of the Node, if required.
- Reference of the Node, if required.
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

Object Type.
Sub ID value (Need not be modified).
Max-Access of the row.
Status of the row.
Description and Reference (If Required) and
Add the Entry.
# External index/indices can also be added using Add External Indices/ Augments option. External Index is an index column from another Table added to the Table being created. Click the Choose Index button to add external index to the Table. A Select Node Dialog pops up with a list of indexes of various tables (if imported). Select the index columns and click the Add button. The selected index columns are added as the External index to the Table and is visible on the tree view. The Augments option is disabled if it is a V1 MIB. It is similar to having an external index. For more details on External Index please refer to Adding External Index section given below.
Add the entry using Add Entry option which adds the row to the table.

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,

Name for the Object Type.
Sub ID of the Tabular Node (Need not be modified).
Entry of the Table.
Index of the Table - whether it should be an Implied Index or an Ordinary Index column to the Table. For more details on Implied Indexes refer section Adding Implied Index given below.
Syntax to be used for the Table Node. The "..." button opens up with a wizard to specify the Value/Range or Enumeration for the syntax chosen.
Maximum Access for the Node.
Status of the Node. It can be Mandatory, Deprecated, Obsolete, or Optional.
Description of the Table Node (If Required).
Reference for the Table Node (If Required).
Format in which the Default Values have to be generated : either Decimal or Binary or Hexa.

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.

Note :

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.

By checking the Index option for two or more columns in the Table, Multiple Index support is achieved.

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

Hereby, it is clear that the Base Table and the Derived Table are interrelated.
Any row can be added to the Derived Table only after specifying the instances of the Base Table.
Adding a row in the Base Table need not necessarily add a row in the Derived Table.
Please note that, a Derived Table can also have additional index columns (local indexes) apart from the Base Table's index column, as every normal table would have.
Also note that an Implied Index column cannot be made as an External Index column.

For having an External Index in the Table,

Check the Index option that comes while Adding a Row.
'Choose Index' is used to choose the External index from the indexes listed.
Only when the MIB is imported, will it be shown in External Index UI.
The Augments option is disabled as it is available only with V2 MIBs. It is similar to external index.
Please refer to the topic Adding a Row given above for the options.

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,

Check the Implied Index option that comes across Index while Adding a Column to the Table. Please refer to the topic Adding a Column given above for the options.

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.
1. - Enterprise : A Trap message is identified by the value in this Enterprise field. If the value specified is SNMP(.1.3.6.1.2.1.11), 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,

- Select Object Identity from the Operations -> Add Node menu bar.
- The corresponding template opens up with the following details to be filled in,
- - Name of the Object Identity.
  - Sub ID for the Node (Need not be modified).
  - Parent ID of the node.
  - Status of the Node. It can be deprecated, current, or obsolete.
  - Description and Reference can be given for the node, if required.
- Finally, Add to Module. This will include the Object Identity in the tree.

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,

- Select Module Compliance icon from the Operations -> Add Node menu bar.
- The respective template opens up with the following details to be filled in.
- - Name of the node to be created to define this construct.
  - Sub ID of the construct (Need not be modified).
  - Parent ID of the construct.
  - Status of the definition. It can be Current, Deprecated, or Obsolete.
  - Textual description of the node or item being defined.
  - Reference to specify the source of the definition.
  - Clicking the View Module Compliance Definition button and clicking New Button in it, will open up a wizard in which the values for Module and Mandatory groups are entered.
- The MODULE sub-clause specifies the module identifier and by convention the name should start with an uppercase letter. Specify a Mandatory Group also. When you "Add" these details you can find the Module Compliance with two groups namely Groups and Objects. Selecting Group and clicking the New button enables the group details.
- GROUP : The GROUP clause is used to specify a conditionally required object or notification group.
- The DESCRIPTION clause, which is paired with the GROUP clause specifes the conditions when the group is required. A group may not be specified in the MANDATORY-GROUPS clause and in a GROUP clause. Also, a group may not be specified in two different GROUP clauses. The description clause describes the group description.
- Here again "Add" , which will add the details under the Group.
- On selecting Object and clicking New button, the details required for the Object get enabled.
- OBJECT: The OBJECT clause and its associated clauses specify reductions in required behaviors of an object to meet a requirements specifications. This is typically used to specify that an implementation of a table need not support row creation to meet a requirements specification, even though the definition of the table defines row creation. This is accomplished by specifying that the minimum required value for access is either read-write or read-only instead of read-create in the MIN-ACCESS clause.
- MIN-ACCESS: The MIN-ACCESS clause can also be used to specify that an object in an object group need not be implemented. This is done by specifying the value of not-accessible for the MIN-ACCESS clause. The value of accessible-for-notify is used to indicate thatonly an object needs to be present to return an instance in an event.
- SYNTAX & WRITE-SYNTAX: The purpose of SYNTAX and WRITE-SYNTAX clauses is to specify a reduction in the implemented behavior of an object.
- DESCRIPTION: The DESCRIPTION clause associated with SYNTAX clause specifies the reduction in required behaviors of SYNTAX clause. The DESCRIPTION clause associated with GROUP clause, specifies the conditions when the group is required.
- Finally, press Finish button to return to the initial screen and
- Click Add to Module button.

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,

Select Agent Capabilities from the Node Operations -> Add Node menu bar.
Enter the following details in the template that appears on the right frame :
- Name of the node to be created to define this construct.
- Sub ID of the construct (Need not be modified).
- Parent ID of the construct.
- PRODUCT RELEASE to describe the product release which includes the implemented capabilities.
- Status of the definition. It can be Current, Deprecated, or Obsolete.
- Description and Reference for the construct, if required.
- On clicking View Agent Capabilities icon you get a template to be filled in with details :
- 1. - SUPPORTS: Supports sub-class specifies the module identifier. By default, it should start with uppercase letters.
    - INCLUDES: The INCLUDES clause specifies object and event groups that an agent implements. Unless specified in a VARIATION clause, an agent fully implements all the behaviors specified in the definitions of the objects and/or events that are members of the groups in the INCLUDES clause.
- Press "Add" button and the screen reflects the additions.
- Select the newly created item in the left frame and press New button.
- The text boxes Variation, Syntax, Write Syntax, Access, Creation Requires, Deferral, and Description gets enabled.
- 1. - VARIATION: The VARIATION clause may be used to specify a change of behavior of an event or object, or to specify that an event/object is not implemented. The ACCESS clause with a value of not implemented is used for the latter case. This is the only clause other than DESCRIPTION that may be specified for an event variation.
    - SYNTAX & WRITE SYNTAX: The purpose of SYNTAX and WRITE SYNTAX clauses is to specify a reduction in the implemented behavior of an object.
    - CREATION REQUIRES: The CREATION REQUIRES clause is used to document the objects that are required in a single SET operation to create an instance of a row in a table.
    - DEFVAL: The DEFVAL clause specifies a default value that an agent uses when an instance of a columnar object is created, instead of that specified in the definition of the object.
Finally, press Finish button to return to the initial screen and
Click Add to Module button.
The Module Compliance construct is successfully added in the Mib tree.

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,

Select Textual Convention from the Operations -> Add Node menu bar and enter the following details in the template :
- Name of the TEXTUAL- CONVENTION. Please note that the name has to start with uppercase letters.
- SYNTAX Type for the TC. Add any one of the SNMP Base Data Type.
- Also fill in details for the Display Hint, Status, Description and Reference fields.
And ADD to Module .
The Textual Convention is added and displayed in the MIB tree of the left frame.

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,

Select File -> Save MIB Module option from the menu bar.
Save as can be used for Saving the V1 MIB Module as V2 MIB Module or vice versa.
It can also be used for saving the MIB in the required location in the preferred name.

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.

Parsing and validating the syntax of the MIB module
Constructing the MIB module into the tree structure

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.

Lenient

Normal

Serious

Critical

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
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 strictly follows the current standard. It accepts the constructs with inter-operability and implementation problems.
3.	Serious	Serious Checks
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.

OBJECT_IDENTIFIER_CONSTRUCT

CHECK_DEFAULT

Serious Parsing Level

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

IMPORTS_CONSTRUCT

MODULE_IDENTITY_CONSTRUCT

OBJECT_TYPE_CONSTRUCT

TRAP_TYPE_CONSTRUCT

NOTIFICATION_TYPE_CONSTRUCT

TEXTUAL_CONVENTION_CONSTRUCT

Critical Parsing Level

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

AGENT_CAPABILITIES_CONSTRUCT

OBJECT_GROUP_CONSTRUCT

NOTIFICATION_GROUP_CONSTRUCT

OBJECT_IDENTITY_CONSTRUCT

MODULE_COMPLIANCE_CONSTRUCT

CHECK_IDENTIFIERS

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.

The OID construct should contain at least two suboids.
The second and its subsequent suboids should be number or nameNumber to identify their ancestors and their position in the MIB tree.
In the OBJECT_IDENTIFIER construct, if the first suboid is a number, it should be 0. 1, or 2. If the suboid is a name
Number, it should be ccit(0), iso(1), or joint-iso-ccit(2).
The label of the last suboid should be same as the descriptor.
The table entry should be the first child of the table node.
The table entry should be defined as a child of the corresponding table object.
The module name of the MIB file should start with uppercase letter.
The TC name should not start with lowercase letter.

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.

CHECK_ATLEAST_TWO_SUBOID

CHECK_SECOND_SUBOID

CHECK_FIRST_SUBOID

CHECK_LAST_SUBOID

CHECK_ROW_OBJID

CHECK_WRONG_TABLE_OBJECT

VALIDATE_MODULE_NAME

VALIDATE_TC_NAME