Management Information Base
The Management Information Base (short: MIB ) describes the information that can be over a network management protocol (eg, SNMP) queried or modified. This information is called managed objects.
Definition
As a framework for the description of these MOs ( managed objects ) is used SMI ( Structure of Management Information ), a rating based on ASN.1 (Abstract Syntax Notation One) set of rules for describing features of network management. SMI describes how the information is arranged, which data formats and operations are allowed and how the MIB is ever specified. A managed object is no real data, but it provides the descriptions of this data value dar. other words, the MIB does not contain any data, it only describes where to find them and how they look.
MIB modules
In RFC 1155, a global MIB has been defined, which has since been expanded several times. These extensions are branches of this global MIB tree. The branches are called MIB modules, but often MIB is used as a synonym for MIB module.
The managed objects are identified by a unique object identifier (abbreviated OID) identifies. This OID can be represented in two forms: as a string of numbers ( .1.3.6.1.4.1 ) or by an ASCII representation ( iso.org.dod.internet.private.enterprise. ). These two forms can be mixed ( private.1 ). The OID describes the path through the hierarchical MIB to the Managed Object.
Various RFCs define MIB modules, such as RFC 1157 defines a MIB module for SNMP or RFC 1213 MIB -II for TCP / IP. The latter is included in all network components. All components that support this MIB module represent the same data ready in the same place.
Under the branch ". Iso.org.dod.internet.private.enterprises " can own ( private ) MIB modules Creating Company. You will need a Enterprise ID, which can be requested free of charge from IANA.
Application
A MIB is written as an ASCII file in the SMI syntax. Here branches are defined, and for each managed object to be here information about the data type ( SYNTAX ), the access rights (ACCESS ), the status ( STATUS) and made the position in the MIB. In addition, a description (DESCRIPTION ) state the object.
This ASCII definition can be processed by a MIB compiler and are brought into a form which allows further use. For example, such a compiler produce finished code that can be in the programming of the agent that will contain the MIB used. The agent will then request specifying an OID value described in the MIB are available.
Syntax Example
Syntax example from the MIB -II, defined in RFC 1213:
System OBJECT IDENTIFIER :: = { mib -2 1 } sysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE ( 0 to 255 ) ) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the entity. This value shoulderstand include the full name and version identification of the system 's hardware type, software operating-system, and networking Software. It is mandatory thatthis only containment printable ASCII characters. " :: = {System 1} Here a branch (OBJECT IDENTIFIER ) of the MIB is first defined: system is a branch of mib -2 with the number 1, the complete OID for this branch would be 1.3.6.1.2.1.1. After an object (OBJECT -TYPE ) is defined. This is a string that will contain a description of the component. It can only be read and is a mandatory field in the implementation of the MIB. Their position is the # 1 System. The complete OID for this property would be 1.3.6.1.2.1.1.1.
Example of use
If a network manager wants to know what are available for components in the network, he can read the string described above. He or she may send an SNMP get to all parts of the network in which the OID is included 1.3.6.1.2.1.1.1.0. The components then type in their reply, the string with their description back.
Here it is again clear why the MIB is not a database, but rather with an address directory is similar: The description itself keeps each component on the network before, but it is for all components in the same place ( the OID) and in the to find the same ( as defined in the MIB ) form.