Previous Table of Contents Next


4.2.1 Network Management Relationships

The SNMP standard, RFC 1157, and the “SNMP Administrative Model,” RFC 1351 [4-4], define a number of terms. Many of these definitions describe relationships between management entities:

  Network management stations are devices that execute the management applications that control and monitor the network elements.
  Network elements are devices such as hosts, bridges, routers, and hubs that contain an agent and perform the network management functions that the network management stations request.
  The SNMP allows network management stations and the agents in the network elements to communicate.
  SNMP application entities reside at either a management station or a managed node, and use SNMP as a communication mechanism.
  Protocol entities are peer processes that implement SNMP, thus supporting the SNMP application entities.
  The SNMP community pairs an SNMP agent with an arbitrary set of SNMP application entities. The network administrator assigns the community a name (called the community name) which is essentially a password with associated rights and privileges. A management application with multiple community names may belong to multiple communities.
  Authentic SNMP messages are SNMP messages sent from an application entity to a specific SNMP community. The message contains the community name of interest.
  The authentication scheme is the method by which an SNMP message is identified as belonging to a specific SNMP community.
  The MIB View is the subset of MIB objects, which may be contained within several subtrees, that pertain to a network element.
  The SNMP access mode determines the level of access to objects that a particular application entity is allowed. The choices are read-only and read-write.
  The community profile pairs the SNMP access mode with the SNMP MIB View. The community profile represents specific access privileges for the variables in a MIB view.
  The SNMP access policy pairs an SNMP community with a SNMP community profile. The access policy represents the specific community profile that an agent permits the other members of the community to have.
  The SNMP proxy agent provides management functions on behalf of network elements that would otherwise be inaccessible.

Figure 4-3 illustrates some of the definitions described above.


Figure 4-3.  Network management relationships

4.2.2 Identifying and Communicating Object Instances

SMI managed object types have an object identifier (OID) that uniquely names them and locates their place on the object tree. An instance of an object type is an occurrence of that object type and has an assigned value. For example, the object sysDescr {1.3.6.1.2.1.1.1.0} might have a value of “Retix Remote Bridge Model 2265M.”

Suppose a network management station wishes to retrieve an instance of a specific object. The management station must use SNMP to communicate its question to the agent.

Now, suppose multiple instances (or occurrences) of that object are possible. For example, say a router’s routing table contains a number of entries. How would the network management station retrieve just the value of the third entry in the table?

RFC 1157, pages 12-15 specifies these tasks. For these SNMP operations, a variable name uniquely identifies each instance of an object type. This name consists of two parts of the form x.y. The x portion is the object type defined in the MIB, and the y portion is an OID fragment that identifies the desired instance. The following examples should clarify this.

Consider a scalar object that has one instance. The objects contained in the System group are all scalar objects. For example, the sysServices object has an OID of {1.3.6.1.2.1.1.7} and occurs once. The x portion of the variable name is the OID, and the y portion has been assigned to 0. You can derive this by following the OID tree down to the object sysServices and adding the appropriate instance suffix (with the suffix, or y portion, shown in boldface type):

iso  org  dod internet mgmt mib-2 system sysServices Instance
 1    3    6     1       2   1      1        7         0

Thus, the variable name for sysServices is {1.3.6.1.2.1.1.7.0}.

The variable name for a columnar object is more complicated because it must identify the location of an object within a two-dimensional data structure, such as a table having both rows and columns. (Within the RMON MIB, three-dimensional data structures are added, making the identification even more complex.) Using the familiar speadsheet as an example, the identification of a particular cell requires two coordinates, X and Y, which describe the horizontal and vertical positions, respectively. With columnar objects, an indexing scheme, specified in the INDEX clause in the ASN.1 definition for that object, provides a means for identifying the specific instance. The INDEX clause then further identifies the syntax to be used. And as one might expect, some of the indexing schemes are more complicated than others. RFC 1212, pages 8-10 lists many of the INDEX clauses that are found within the MIB-2. Let’s look at some examples for further clarification.

Consider the IP Address Table object, ipAdEntBcastAddr, which specifies the value of the least significant bit (LSB) of the IP broadcast address (see Figures 4-4a and 4-4b). To begin, follow the OID tree down to ipAdEntBcastAddr:

iso  org  dod  internet  mgmt  mib-2  ip
1     3     6     1        2     1     4

ipAddrTable  ipAddrEntry  ipAdEntBcastAddr
    20            1              4


Figure 4-4a.  The IP address table within the OID tree


Figure 4-4b.  Object instance in the IP address tables

The OID is {1.3.6.1.2.1.4.20.1.4}, consisting of the IP Group {1.3.6.1.2.1.4}, the IP Address Table (20), the ipAddrEntry (1), and the object ipAdEntBcastAddr (4), shown in Figure 4-4a.

Consulting MIB-2, RFC 1157 page 31, the ASN.1 definition for the object ipAddrEntry includes an INDEX clause that specifies the object ipAdEntAddr. Moving a few lines down in RFC 1157, we see that the object ipAdEntAddr has a SYNTAX of IpAddress. Thus, we would expect the index for this object to be defined by an IP address and shown in dotted decimal notation: a.b.c.d. (More on IP addresses and dotted decimal notation can be found in Section 6.3.)


Previous Table of Contents Next