Management Information Base

from Wikipedia, the free encyclopedia

A Management Information Base ( MIB ; German Management Information Base ) is includes a description, the definitions of management information that can be used to a to a network monitor connected device from afar, configure and control. A network management protocol ( e.g. SNMP ) is used for these functions . The information is managed objects ( managed objects called).

definition

For network management based on SNMP, a generic SMI (Structure of Management Information) was defined as the framework for describing these MOs (Managed Objects) . This is a collection of rules written in the specification language ASN.1 (Abstract Syntax Notation One) for the description of network management objects. The SMI describes how the information is arranged, which data formats and operations are permitted and how the MIB is actually specified. A managed object is not a real data value; it represents the descriptions of this data value. In other words: the MIB does not contain any data, it only describes where it can be found and what it looks like.

MIB modules

The MIB tree

A global MIB was defined in RFC 1155 , the so-called MIB I, which has since been expanded several times. These extensions are branches from this global MIB tree. The branches are called MIB modules , but MIB is often used as a synonym for MIB module .

The managed objects are identified by a unique object identifier ( OID for short ). This OID can be represented in two forms: as a string of numbers (.1.3.6.1.4.1) or as an ASCII representation (.iso.org.dod.internet.private.enterprise). These two forms can also be mixed (private.1). The OID describes the path through the hierarchically structured MIB to the managed object.

Various RFCs define MIB modules, e.g. B. RFC 1157 defines a MIB module for SNMP or RFC 1213 the MIB-II for TCP / IP. The latter is included in all network components. All components that support this MIB module provide the same data in the same place.

Companies can create their own ( private ) MIB modules under the branch ".iso.org.dod.internet.private.enterprises" . To do this, you need an Enterprise ID, which can be requested from IANA free of charge.

application

A MIB is written as an ASCII file in SMI syntax. Branches are specified here, and information about the data type (SYNTAX), the access rights (ACCESS), the status (STATUS) and the position in the MIB are made for each managed object . A description (DESCRIPTION) of the object is also included.

This ASCII definition can be prepared by a MIB compiler and brought into a form that enables further use. For example, such a compiler can generate ready-made code that can be used in programming the agent that is to contain the MIB. The agent then provides the value described in the MIB on request, specifying an OID.

Syntax example

Syntax example from MIB-II, defined in RFC 1213 :

system   OBJECT IDENTIFIER ::= { mib-2 1 }

sysDescr OBJECT-TYPE
   SYNTAX  DisplayString (SIZE (0..255))
   ACCESS  read-only
   STATUS  mandatory
   DESCRIPTION
      "A textual description of the entity.  This value
       should include the full name and version
       identification of the system's hardware type,
       software operating-system, and networking
       software.  It is mandatory that this only contain
       printable ASCII characters."
   ::= { system 1 }

First a branch (OBJECT IDENTIFIER) of the MIB is 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. Then an object (OBJECT-TYPE) is defined. This is a character string that should contain a description of the component. It can only be read and is a mandatory field when implementing the MIB. Your position is number 1 under system . The full OID for this object would be 1.3.6.1.2.1.1.1.

Application example

If a network manager wants to know what kind of components are present in the network, he can read out the character string described above. To do this, it can send an SNMP get to all components in the network, which contains the OID 1.3.6.1.2.1.1.1.0. The components then return the character string with their description in their response.

The MIB when processing an SNMP request

Here it becomes clear again why the MIB is not a database, but rather can be compared with an address directory: The description itself holds each component in the network for itself, but is in the same place (the OID) and in the for all components same form (defined in the MIB).

literature

  • David T. Perkins, Evan McGinnis: Understanding SNMP MIBs , 1997, Prentice Hall, Upper Saddle River, New Jersey, ISBN 0-13-437708-7
  • Stephen Morris: Network Management, Mibs and Mpls: Principles, Design and Implementation . Prentice Hall International, June 2003, ISBN 978-0131011137
  • Larry Walsh: SNMP Mib Handbook . Wyndham Press, March 2008, ISBN 978-0981492209

Web links