|
|
MIB syntax validation involves validating the private MIBs with respect to SMI standards / ASN.1 rules. The reference standards include RFC 2578, 2579, and 2580. SNMP Agent Tester has defined parsing levels for checking the MIB syntax, viz. Lenient, Normal, Serious, and Critical.
SNMP Agent Tester, based on the parsing level, performs various checks with reference to the standards, validates the syntax, and provides a report of failed test cases.
Steps Involved in MIB Syntax Validation
Load the MIBs that have to be tested for syntax.
Select the MIBSyntax from the project tree to open the MIB Syntax Validation in the right panel.
Viewing the Validation Reports
The result of the validation can be viewed by selecting the Report Viewer tab. The details of the failed test cases are shown at the bottom of the panel. You have the following options to view the report:
You can view the reports based on the result status by selecting the required option from the Select a view combo box.
You can select the MIB from the top to view its corresponding failures at the bottom
You van view the details of a specific test case by selecting a row from the report. Clicking Modify will open the MIB in an editor for necessary corrections. You also have an option to choose your own editor.
You have an option to view the graphical representation of the reports by clicking the bar graph or pie chart icon.
The report summary is displayed at the bottom of the report viewer.
You can also generate HTML reports of the performed validation.
The following table describes the different levels of parsing that can be set and their corresponding checks. It may be noted that the checks specified for various parsing levels are incremental, i.e., the checks for critical level will include checks of all the other levels.
| Level |
Description |
Checks |
Reference |
|---|---|---|---|
|
Lenient |
This level accepts all types of MIB files. For example, it allows both SMIv1 and v2.
|
The OID construct should contain at least two sub-OIDs. |
RFC 2578 (page 15) |
|
The second and its subsequent sub-OIDs should be number or nameNumber to identify their ancestors and their position in the MIB tree. |
RFC 2578 (page 14) | ||
|
In the OBJECT IDENTIFIER construct, if the first sub-oid is a number, it should be 0. 1, or 2. If the sub-oid is a name Number, it should be ccit(0), iso(1), or joint-iso-ccit(2). |
RFC 2578 (page 15) | ||
|
The label of the last sub-OID should be the same as that of the descriptor. |
RFC 2578 (page 14) | ||
|
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. |
RFC 2578 (page 11) | ||
|
The TC name should not start with lowercase letter. |
RFC 2579 (page 19) | ||
|
Normal |
This level is the default level conforming to the obsolete standards, such as RFC 1902, RFC 1903, etc. Most MIBs follow the obsolete standard.
|
The value of the first sub-identifier is one of the following well-known names (0 - ccitt, 1 - iso, and 2 - joint-iso-ccitt). Each sub-identifier has a maximum value of 4294967295. |
RFC 2578 (page 14) |
|
Checks if no reserved keyword is used as descriptor. There should not be a comma at the end of the descriptor and also the descriptor should be unique and mnemonic. |
RFC 2578 (page 15) | ||
|
Serious |
This level strictly follows the current standard. It accepts the constructs with inter-operability implementation problems.
|
If any of the following data types and macros are defined in this document, they must be imported using the IMPORTS statement: Counter32, Counter64, Gauge32, Integer32, IpAddress, MODULE-IDENTITY, NOTIFICATION-TYPE, Opaque, OBJECT-TYPE, OBJECT-IDENTITY, TimeTicks, Unsigned32. Named types defined by ASN.1 must not be included in an IMPORTS statement. |
RFC 2578 (page 13) |
|
Checks if the revisions made are in chronological order, number of module identity macro defined is one, and the UTC time format contains 11 or 13 characters. |
RFC 2578 (page 18) | ||
|
Checks the defval, table constructs, syntax, access, and the status. |
RFC 2578 (page 37) | ||
|
Checks the trap number range, the value range for generic traps. |
RFC 1215 (page 4) | ||
|
For the NOTIFICATION-TYPE macro, the objects should not have MAX-ACCESS value as 'not-accessible'. |
RFC 2578 (page 33) | ||
|
Checks the occurrence of display hint, display hint format, and syntax clause of textual convention. |
RFC 2579 (page 19) | ||
|
Critical |
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.
|
Checks for the access level for objects which are named in the Creation Requires clause. |
RFC 2580 (page 18) |
|
Checks if the objects defined in the object group for access level is read-only, read-write, or read-create and the objects start with uppercase. |
RFC 2578 (page 25) | ||
|
Checks if the value of an invocation of the NOTIFICATION-GROUP macro is the name of the group, which is an OBJECT IDENTIFIER. |
RFC 2580 (page 12) | ||
|
Checks if object Identity macro is used to define information about an OBJECT IDENTIFIER assignment. |
RFC 2578 (page 18) | ||
|
Checks if the MODULE-COMPLIANCE macro is used to convey a minimum set of requirements with respect to implementation of one or more MIB modules. |
RFC 2580 (page 13) | ||
|
Checks if the descriptor of textual convention is not of all uppercase letters and descriptor for the sequence starts with a uppercase letter. Checks if a hyphen included for ASN.1 identifier and check the enumerated label list. |
RFC 2578 (page 12) |
Clearing the Validation Reports
|
|