FAQ - Loading MIBs

Where can I find MIB files?

The latest IANAifType-MIB can be found at http://www.iana.org/assignments/ianaiftype-mib

Standard track RFC MIBs can be found at http://www.ietf.org/rfc.html

For Enterprise MIBs you should contact respective vendors.

All MIBs shipped with SilverCreek can be found in the "mibs" sub-directory in your SilverCreek installation. The files with .tmp extension are actual MIB modules. The files with .defs extension are their correspondent compiled forms used by SilverCreek MIB store.

How do you compile multiple MIBS that have dependencies on each other?

Normally, loading mibs into SilverCreek does not require you do anything particular. SilverCreek will try to resolve dependency after all mibs are loaded. If there is something missing, then SilverCreek would report a message like below:

The following objects can not be linked under any branch in the Object Identifier (OID) tree. The definition for these objects is incomplete due to the fact that their parent objects (or MIB) have not been loaded. For instance: If a MIB module has an OID, for example 'enterprises.311.1' but the MIB module that defines the object at 'enterprises.311' has not been loaded then the OID 'enterprises.311.1' cannot be fully resolved.

The parent MIBs of a MIB are usually listed in the 'IMPORT' clauses at the beginning of that MIB file. See MIB file for more information.

To compile and load multiple mibs, just put all of them in the mibs directory under your SilverCreek root directory and then start SilverCreek. All mibs will be compiled and loaded if no critical errors are detected.

Can I set up multiple MIB directory paths so I can maintain different set of MIBs?

If you have a large number of private MIBs or multiple people testing different MIBs, you may wish to maintain them in different directories. To use a different directory than the default "mibs" directory create an environment variable MIB_PATH and point it to the location of the directory that holds your MIBs.

You case force MIBs shipped by SilverCreek to be always loaded by checking the option "always load MIBs in SilverCreek mibs directory...." found in Tools->Options->Misc tab.

Using MIB_PATH and SilverCreek's initialization file you can maintain different sets of MIBs in different directories and instruct SilverCreek to use the desired set of MIBs when it starts up.

By default, if you place the MIBs for different releases in different directories, you need to redefine the environment variable "MIB_PATH" and restart SilverCreek every time when you want switching to test a different agent release that implements a different set of MIBs. To avoid this, you can customize SilverCreek init file scinit.tcl (or ssinit.tcl, slinit.tcl, sbinit.tcl depending on your SilverCreek Edition) that is used to start SilverCreek. For instance, say you have three sets of MIBs stored in three different directories such as "c:/release_1_mibs", "c:/release_3_mibs", "c:/release_3_mibs" respectively.

You can create three SilverCreekinit files by making copies of the original scinit.tcl under SilverCreek's home (root) directory: scinit_release1.tcl, scinit_release2.tcl, scinit_release3.tcl

Then add "::env(MIB_PATH)" definitions at the beginning of each of these files.

#For scinit_release_1.tcl, at the beginning, insert the line 
set ::env(MIB_PATH) "c:/release_1_mibs"
#Original contents start here

#For scinit_release_2.tcl, at the beginning, insert the line 
set ::env(MIB_PATH) "c:/release_2_mibs"
#Original contents start here

#For scinit_release_3.tcl, at the beginning, insert the line
set ::env(MIB_PATH) "c:/release_3_mibs"
#Original contents start here

Finally on Windows you can create three different "SilverCreek" icons (shortcuts) via "Copy and Paste", then you can right click on each new icon (shortcut), select "Properties", and then edit "Target" field to:

"C:\Program Files\InterWorkingLabs\SilverCreekMx\BIN\wish84.exe" ./tkcon.tcl -root . ./scinit_release1.tcl "C:\Program Files\InterWorkingLabs\SilverCreekMx\BIN\wish84.exe" ./tkcon.tcl -root . ./scinit_release3.tcl "C:\Program Files\InterWorkingLabs\SilverCreekMx\BIN\wish84.exe" ./tkcon.tcl -root . ./scinit_release3.tcl ...

On Unix like platforms, you can copy the existing startup script bin/test-agent into three new files: bin/test-agent1, bin/test-agent2, bin/test-agent3 and then simply modify the last line " wish8.4 ./tkcon.tcl -root . ./scinit.tcl -- $" in bin/test-agent1, bin/test-agent2, bin/test-agent3 to something like: wish8.4 ./tkcon.tcl -root . ./scinit_release_1.tcl -- $ wish8.4 ./tkcon.tcl -root . ./scinit_release_2.tcl -- $ wish8.4 ./tkcon.tcl -root . ./scinit_release_3.tcl -- $

Of course on Unix like systems you can also add the environment variable definition of "MIB_PATH" in bin/test-agent1, bin/test-agent2, bin/test-agent3 directly. For example:

MIB_PATH=/home/bob/rel_1_mibs export MIB_PATH

If you are working with SilverCreekCLI please see HelP->Help Topics ->Maintaining MIBs for Different Releases of the Device

What are the minimal set of MIBs I should load?

The minimal sets of MIBs that should be loaded into SilverCreek are given below.

SNMPv1 Agent: IANAifType-MIB, RFC1213-MIB,

Note: RFC1155, RFC1157 , RFC1215 and RFC1212 are not required. SilverCreek supports them natively. If you want to load them into SilverCreek the MACRO constructs in these files must be removed first. RFC1215 and RFC1212 actually do not contain any MIB modules so do not load these two RFCs.

SNMPv2c Agent: IANAifType-MIB, SNMPv2-MIB (RFC3418), SNMPv2-TC (RFC2579),

Note: RFC2578 ( SNMPv2-SMI ) and SNMPv2-PDU (RFC3416) are not required. SilverCreek supports them natively. If you want to load them into SilverCreek the MACRO constructs in these files must be removed first.

SNMPv3 Agent: IANAifType-MIB, SNMPv2-MIB (RFC3418), SNMPv2-TC (RFC2579), SNMP-FRAMEWORK-MIB (RFC3411), SNMP-MPD-MIB (RFC3412), SNMP-TARGET-MIB, SNMP-NOTIFICATION-MIB (RFC3413) SNMP-USER-BASED-SM-MIB (RFC3414) SNMP-VIEW-BASED-ACM-MIB (RFC3415)

BITS must not be imported?

Remove it from your MIB definition, then the SilverCreek mosy compiler won't complain.

A common area of confusion among SNMP MIB designers is the use of BITS. Putting BITS in the IMPORTs clause of a MIB is illegal. The MIB compiler included with SilverCreek will reject a MIB that has BITS in the IMPORTs, because it is wrong per RFC 2578. Other MIB compilers for other types of products, such as simulators, are very permissive; these MIB compilers will allow this error and many other errors to slide by, in order to manage or simulate very badly written MIBs.

BITS is not a TEXTUAL-CONVENTION. The standard TEXTUAL-CONVENTION types are defined in RFC 1903. Both RFC 1902 and 1903 define BITS, but as part of the OBJECT-TYPE and TEXTUAL-CONVENTION macros:

OBJECT-TYPE MACRO ::=
 BEGIN
 .
 .
 .
 type(ObjectSyntax)
 | "BITS" "{" Kibbles "}"
 .
 .
 .
 END

(From RFC 1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2))

TEXTUAL-CONVENTION MACRO ::=
 BEGIN
 .
 .
 .
 Syntax ::=
 type(ObjectSyntax)
 | "BITS" "{" Kibbles "}"
 .
 .
 .
 END 
 >

(from RFC 1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2))

Hence, BITS is an implicit part of the OBJECT-TYPE and TEXTUAL-CONVENTION macros. For BITS to be considered a TEXTUAL-CONVENTION (and thus need to be imported), BITS would need to have been defined along the lines of:

BITS ::= TEXTUAL-CONVENTION
 STATUS current
 DESCRIPTION
 "This would be BITS as a TEXTUAL-CONVENTION"
 SYNTAX OCTET STRING

Such a definition does not exist.

The BITS clause is intended to add semantic clarity to the notion of assigning meaning to bits in an OCTET STRING. Please see Section 3.2 of RFC 2578 "Structure of Management Information Version 2" that states:

"However, the following must not be included in an IMPORTS statement:

-named types defined by ASN.1 itself, specifically: INTEGER, OCTET STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type,

-the BITS construct."

LEARN MORE