1.1 Introduction

1.2 Network Management

1.2.1 Managed Nodes

1.2.2 Management Information Bases

1.2.3 Management Stations

1.2.4 Management Protocol

1.2.5 Object Identifier

1.2.6 Accessing MIB Objects

1.2.7 Using Get-Next

1.3 Supported MIBs

1.1 Introduction

Simple Network Management Protocol (SNMP) is a protocol defined by the Internet Engineering Task Force (IETF). Network devices supporting this protocol allow a management station to monitor network status, modify network settings, and receive network events.

The NMS SNMP Reference Manual explains how to configure and install SNMP for Natural MicroSystems (NMS) products. This manual is intended for customers who want to add SNMP monitoring to Natural MicroSystems boards.

This chapter provides an overview of SNMP. Specifically, it describes the functionality of Management Information Bases (Management Information Bases) and agents that are used to support SNMP on NMS hardware.

1.2 Network Management

Network management allows network administrators to maintain network integrity. SNMP is an industry standard protocol that defines a method for performing network management. SNMP was initially made available for IP based enterprise networks, and is now available for telephony networks.

An SNMP network management system consists of:

• One or more Managed Nodes, running one or more SNMP agents. An agent keeps information about its managed node in a database called a Management Information Base (MIB).

• One or more network Management Stations, which run network management software and display network information. The management station is called the host.

• A network Management Protocol, which determines how the managed node and the management station can communicate with each other over the network.

Figure 1 shows the relationship of SNMP components:

Figure 1. SNMP Network Components

In Figure 1, one management station is shown communicating with two managed nodes. The first managed node has more than one agent, and each agent has its own MIB. The dotted lines in the managed node show that there can be more agent/MIB pairs running on a managed node. The dotted lines to the right of the managed nodes show that there can be additional nodes managed by a single management station.

The following sections describe each of these components in greater detail.

1.2.1 Managed Nodes

Any device which connects to a data network and can execute the SNMP protocol can be an SNMP managed node. A managed node can be:

• A host system, such as a workstation, a printer, a file server, a terminal server, or a mainframe.

• A network router, a bridge, a hub, an analyzer or a repeater.
  
  
  Figure 2. Managed Nodes and Management Stations

Figure 2 shows managed nodes as grey, and management stations as white.

A managed node executes a program called the SNMP service, which communicates with the management station. The SNMP service responds to messages from the host and sends unsolicited messages if a defined event occurs on the managed node.

The SNMP service is a daemon on Unix systems and a system service on Windows NT.

The SNMP service runs one or more agents, which are applications that collect information about the managed node and keep it in a MIB. A managed node can have more than one MIB, and has one agent for each MIB.

See Chapter 2 for information about how to activate the SNMP service and load an agent.

The SNMP architecture is designed to be simple and fast. The processing load is placed on the management station, and minimized on the managed node. The set of information contained in the MIB is designed to be simple, so information about the network will not congest the network.

1.2.2 Management Information Bases

A Management Information Base (MIB) defines the information that will be maintained by the associated agent. A MIB is viewed as a database, but is actually a sequential list of managed objects. The managed objects are logically grouped to represent a row in a table, where each object in that group represents a field. The field may be a variable, or a structure of variables. Each managed object is referred to by a unique Object Identifier (OID).

A MIB is often shown as a tree, where the nodes of the tree define the database and its tables, rows, and fields. The collection of all MIBs is organized in a tree structure, where each node on the tree represents a single MIB. The SNMP MIB hierarchy is defined by RFC 1155 and RFC 1213. MIBs fall into two categories:

MIB	Description
Standard	A standard MIB is defined by the IETF. An example of a standard MIB is RFC 2495, the Trunk MIB.
Private	A non-standard, proprietary MIB is defined by an enterprise. The IETF assigns a unique OID number to a company, under which they can define their own OIDs for their specific products. An example of a private MIB is the Natural MicroSystems chassis MIB.

1.2.3 Management Stations

A management station is a system running:

• The network management protocol.

• One or more network management applications.

The network management station (host) determines which information is required from the managed node. The host sends queries to a managed node to determine what information is available and to retrieve that information. The host then uses those responses to display the information in human readable form.

Host applications are much larger than agent applications, because they are designed to do most of the work in the SNMP architecture, and because one host application communicates with many agents. One example of a host management station is HP Openview.

1.2.4 Management Protocol

SNMP defines a mechanism to transport network management information. Messages containing queries and replies are sent between the host management system and managed nodes over a connectionless transport service. A commonly used transport service is User Datagram Protocol (UDP), which is part of the IP suite.

Two types of messages are supported:

Message	Description
Traversal	Provides a way for the host to read the values in an agent's MIB.
Trap	Sent by an agent to report events to the host.

Figure 3 shows the host and agent message flow:

Figure 3. SNMP Message Flow

Traversal messages are generated by host commands. These commands are:

Command	Description
get	Requests a specific value (for example, the amount of hard disk space available).
get-next	Requests the next value in a MIB after using the get command. Useful when getting a block of related objects.
set	Changes the value of an object in a MIB. Only objects with read-write access can be set.

Trap messages are sent by an agent to notify the host about an unusual occurrence. The host can then request the value of related variables to determine more about the managed node's condition. The agent can be set to send a trap when certain conditions arise, such as an error on a line. Care must be taken to ensure that trap information does not congest the network or overwhelm the host.

Connectionless transport does not guarantee delivery, which means that traps (and other network messages) are not guaranteed to arrive at the host. You should plan your network management policies to consider lost messages.

1.2.5 Object Identifier

An object identifier (OID) is a unique sequence of integers that represents how to traverse the MIB tree to get to a managed object. All MIBs have a common root node and all OID integer sequences start from that root. The OIDs are assigned by the IETF.

The entire tree of MIBs is referred to as a namespace, which means that each MIB and OID is unique. The namespace for the entire tree is maintained by the IETF and related organizations, who delegate that authority only for MIBs below the Enterprises MIB, whose OID is 1.3.6.1.4.1.

1.2.6 Accessing MIB Objects

Objects in a MIB can be accessed in the following ways:

Type	Description
Single	Contains a single value. Getting the value for an instance of this object type requires adding a 0 to the end of the OID. For example, if the OID to a single object type is p, then use p.0 to get its value.
Indexed Table	The column is the type of item, and the row (index) is the instance of that item type. The OID of the start of the table is p, and p.column.index describes a field, where index specifies the row.
Doubly Indexed Table	Uses two indices to specify a row. The column is the type of item and the row is defined by two indices that further define the meaning of that row. The OID of the start of the table is p. p.column.index1.index2 specifies a field, where index1 defines a set of related rows, and index2 specifies the specific row in the set of related rows.

1.2.7 Using Get-Next

The get-next operator finds the next object in the current MIB that has a value. It returns the value of the object and its OID. If the current object is in a table, it returns the next column, which is the last digit in the OID.

The OID to a field in an indexed table is p.column.index.

get-next retrieves the next index in the current column, until that column ends. The next get-next moves to the next column. These actions represent reading the table from top to bottom, then left to right.

For example, the Trunk MIB has an indexed table called the Current table, where each row is the index of the interface and each column is a statistic. If you get ESs for interface 1, then each get-next retrieves ESs for the next interface, as shown in Figure 4:

Figure 4. Indexed Table

When get-next has retrieved ESs for interface 5, the next get-next retrieves SESs for interface 1.

The OID to a field in a doubly indexed table is p.column.index1.index2. The field is grouped by index1, and the particular field in that group is specified by index2.

For example, the Trunk MIB has an Interval table, which is doubly indexed by the bus interface and the time interval. The first index is the interface, and the second index is the time interval. If you get ES for the first time interval of the third interface, get-next retrieves ES for the next time interval, as shown in
Figure 5:

Figure 5. Doubly Indexed Table

When get-next has retrieved ES for all intervals of interface 3, the next get-next will either get ES for the first interval of the next interface (if there is one), or SES for the first interval of interface 3.

For more information about the Current and Interval tables, refer to Chapter 4.

1.3 Supported MIBs

NMS produces agents for the following MIBs:

MIB	Description
RFC 2495	The Trunk (DS1) MIB, which represents DS1 (and higher speed) lines and is defined by the IETF. All the boards in an NMS chassis are represented as one managed node.
Chassis	A private MIB, which represents the slots, ISA and PCI bus, bus segments, and boards in the chassis. The Chassis MIB detects the presence of each board, and monitors its operational status.

NMS has been assigned a namespace under the Enterprises MIB. The OID for the NMS MIB is 1.3.6.1.4.1.2628, under which the chassis MIB resides, and future private MIBs will be created.

Note: ISA boards are not supported by CT Access 4.0 or later.

A portion of the MIB tree showing the Trunk MIB, the Natural MicroSystems (NMS) MIB, and the chassis MIB is illustrated in Figure 6:

Figure 6. Enterprise MIB

In Figure 6, the Trunk MIB (DS1) and the Chassis MIB are shown with their major tables. The MIBs that are currently implemented are shown in grey. The MIBs with dotted lines are defined by the Natural MicroSystems MIB (2628), but are currently not implemented.

The NMS subtree consists of the following MIBs:

MIB	Description
Directory	Describes all MIBs defined by NMS. Currently not implemented.
Common	Contains general-purpose MIBs, applicable across multiple product lines.
Specific	Contains specialized MIBs for individual products. Currently not implemented.
Experimental	Contains MIBs that are under development and test. Currently not implemented.