Network Management Protocols

Article Written by Oren Chapo * August 1999

Index

1. Introduction
2. Basic Terms
3. Understanding MIBs
4. MIB-I vs. MIB-II
5. The SNMP Protocol
6. SNMP Security
7. SNMPv2: What's New?
8. RMON: Remote Network Monitoring
9. SNMP in Windows® Systems
10. SNMP in UNIX Systems
11. Network Management Software
12. The Future - What's Next?
Appendix A: Related RFC's
Appendix B: Bibliography

1. Introduction

Network Management - Why?
Once the scope of a computing environment extends beyond a single LAN and a few PCs, effective network management is possible only with a set of automated network-management tools. To deal with the multi-vendor environment of the typical installation, a network-management system is needed that is based on standardized network-management protocols and applications.

What is SNMP?
The Simple Network Management Protocol (SNMP) is widely used to control network communications devices using TCP/IP. Most network analyzer software can interface to SNMP, and an SNMP monitor is a very useful tool in a network of more than moderate complexity. SNMP is not standardized by an organization such as ISO - the SNMP specifications can be found on internet RFC documents.

2. Basic Terms

Before we begin, let's define some basic terms that will be used in this article:

• SNMP - (Simple Network Management Protocol) - an application-layer protocol for managing TCP/IP based networks. SNMP runs over UDP (which runs over IP).
• MIB - (Management Information Base) - provides a standard representation of the SNMP agent's available information and where it is stored.
• NMS - (Network Management Station) - A device designed to poll SNMP agents for information.
• SNMP Agent - a device running some software that understands the language of SNMP. Almost any network device could potentially run SNMP, but typically you will find SNMP agents running on internetworking devices (eg. routers, hubs, switches, bridges). Some operating systems (UNIX, Windows NT) can also run SNMP agents.

3. Understanding MIBs

Think of the MIB as a "tree" - very similiar to a DOS or UNIX directory structure, with some pre-defined values ("directory" names), and some custom areas for vendors. Since this database includes all the managable objects, MIB is the most basic element of network management.
The following is an example of a standard MIB object, defined in ASN.1 language:

 sysUpTime OBJECT-TYPE
   SYNTAX TimeTicks
   ACCESS read-only
   STATUS mandatory
   DESCRIPTION
	"The time (in hundredths of a second) since
	the network management portion of the system
	was last re-initialized."
   ::= { system 3 }

OBJECT-TYPE is the word used to describe the MIB object. SNMP agents will use an Object Identifier (OID) string instead of the word.

SYNTAX defines what kind of information is stored in the MIB object. These definitions use technical terms like "Integer" or "Counter" for numbers and "DisplayString" for words. A new SYNTAX can also be defined in the MIB itself. For a complete list of SYNTAX's, read the RFC's.

ACCESS tells you whether an outside entity can change the value of this object. read-only means only the agent can change the value - the value cannot be changed by an SNMP SetRequest (which we'll talk about later). If the value is read-write, then the value can be modified if you have the right permissions (which we'll also talk about later) to do so.

STATUS is state of the object with regards to the SNMP community. It has definitions like "obsolete", "current", or "mandatory". Unless you're going to be writing your own MIBs, just ignore this definition.

DESCRIPTION describes the reason why the MIB object exists. Sometimes it refers to other MIB objects, forcing you to read more descriptions which in turn refer to other MIBs.

::= { system 3 } in the last line, is the OBJECT IDENTIFIER (OID) that was mentioned earlier. This means that the sysUpTime object is under the system branch, and that the OID of sysUpTime is 3.

The MIB object defined in the example above, like any MIB object, can be referred in two ways:
1. By its OID number: .1.3.6.1.2.1.1.3
2. By its path in the MIB tree:
  iso.org.dod.internet.mgmt.mib.system.sysUpTime
Look at figure 2 for clarification.

For 99% of the MIB objects you will encounter, the first 4 numbers in their "path" will be ".1.3.6.1" (.iso.org.dod.internet). The OBJECT-TYPE for these four numbers are:
1 - iso: ISO is the International Standards Organization. Visit them at their Web site for more information.
3 - org: Everything under this branch is an organization recognized by ISO.
6 - dod: The Department Of Defence. The DOD came up with ARPANET, which was the precursor to the Internet, so they got their own branch from the National Institute of Standards and Technology (NIST). NIST got their branch nodes from ISO, of course.
1 - internet: This node is allocated by DOD for the "Internet Community", whatever that is.

Important Note: If an OID string is not complete down to the MIB object (that is, if it ends at a node instead of an object), all the objects within that node are displayed when the OID string is queried.

Instances. Imagine a router - a device with multiple network interfaces. There exists a MIB object that contains information about the type of interface(s) used by an entity (in this case - the router). This MIB object is: iso(1) org(3) dod(6) internet(1) mgmt(2) mib(1) interfaces(2) ifTable(1) ifEntry(1) ifType(3). If our router had four interfaces, we'd need four values of the MIB object ifType to describe all four interfaces - one value per interface. Each instance will have its own value for the MIB object. Notice that there are two nodes between the interfaces(2) node and the object, ifType(3). The inclusion of Tables, Entries and a third concept called Indexes in a MIB allows one MIB object definition to represent multiple values, or Instances, of the object. So, in our case, we might see the following if we were to do a MIB query on ifType:
ifType.1: 6 (which means ethernet-csmacd)
ifType.2: 9 (which means iso88025-tokenRing)
ifType.3: 15 (which means fddi)
ifType.4: 28 (which means slip - read the RFCs for more information about those numbers)
Notice: if a MIB is not part of a table, its instance will be 0. This is sometimes reffered to as a scalar value. Example: let's look again at the sysUpTime object. Since this object has only one instance, the instance of this object would be written: sysUpTime.0

4. MIB-I vs. MIB-II

MIB-II (MIB-2) is a newer and updated version of the standard MIB (aka MIB-I). Features of this newer MIB-II (as written in the RFC) include:

(1) incremental additions to reflect new operational requirements;
(2) upwards compatibility with the SMI/MIB and the SNMP;
(3) improved support for multi-protocol entities; and,
(4) textual clean-up of the MIB to improve clarity and readability.

MIB-II defines new SYNTAX types, adds more managable objects to the MIB tree and fixes some problems with the existing ones. The objects defined in MIB-II have the OBJECT IDENTIFIER prefix:

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

which is identical to the prefix used in MIB-I. For more information, read the RFCs, especially RFC 1213 which defines the new MIB-II.

5. The SNMP Protocol

Now, we have a great database of management information - but how do we access it? That's when the SNMP protocol comes into the picture. Since SNMP is a protocol and not a set of O/S commands, you will need some sort of application to use SNMP. The most basic one is something like snmpwalk, a freeware that can send/receive SNMP functions using a command line interface. Another common application, is a MIB Browser, which is usually a GUI based application that allows you to see all the branches and leaf nodes inside a MIB or group of MIBs by selecting "Up Tree" or "Down Tree".

The "S" letter in "SNMP" stands for "Simple". Indeed, SNMP is rather simple - it only has 5 different kind of functions (called Protocol Data Units or PDUs). The following are the 5 PDUs, along with their "slang" names:

GetRequest      Get
GetNextRequest  GetNext
GetResponse     Reply or Response
SetRequest      Set
Trap            Trap

We will now go over in detail the meaning of the 5 PDUs.

Get: This command is the most commonly used PDU. It requests a particular MIB instance from the SNMP agent. Since an instance is a unique OID string, the NMS must send out one SNMP "Get" for each instance that needs to be retrieved. But what if we don't know how many instances of a particular MIB exist? That's why we need the GetNext PDU.

GetNext: This PDU is used primarily to "walk" down a table within the MIB. The GetNext request is designed to ask for the OID and value of the MIB instance that comes one number after the instance supplied in the GetNext Request. If a GetNext request asks for an instance that is "off the scale", the agent will reply with the value and OID of the next OID in the MIB tree instead. So, for example, if the NMS asks for instance #7, and there is no instance #7, the agent will reply with instance #1 for the next MIB object in the tree.

GetResponse: This PDU is simply the response of the agent to a Get, GetNext or Set Request. If the command was Get or GetNext, the response will contain either the information requested by those commands. If the command was Set, a confirmation that the command was successful will be contained in the response.

Set: This PDU is issued by an NMS to change a particular MIB instance to the value contained in the PDU. For example, you use a Get to request the value sysLocation.0 from a hub, and get the reply "basement". Since you (as an administrator) moved this hub to the second floor, you issue a Set Request to sysLocation.0 with a value of "2nd floor". Assuming you have the permission to do this (from an SNMP perspective - we'll talk about this soon), the value of sysLocation.0 will be changed to "2nd floor".

Trap: This PDU is the "black sheep" of the SNMP family. What makes it so different from the other PDUs is that it is sent out by the SNMP Agent without any interaction with the NMS. An SNMP agent can be programmed to send out a trap when a certain set of circumstances arises. Most of these circumstances, and what to do when encountered, are hard coded into the SNMP agent and cannot be modified, even by an SNMP Set request. An SNMP Trap PDU contains an OID that identifies it as a trap, information about which MIB objects set off the trap, and the values of those MIB objects. Example: an SNMP agent of a hub can send a Trap PDU to the NMS, if the temperature of the hub has become harmful to its operation.

How does it work? As defined in RFC 1157: "Communication among protocol entities is accomplished by the exchange of messages, each of which is entirely and independently represented within a single UDP datagram using the basic encoding rules of ASN.1. A message consists of a version identifier, an SNMP community name, and a protocol data unit (PDU). A protocol entity receives messages at UDP port 161 on the host with which it is associated for all messages except for those that report traps (i.e., all messages except those that contain the Trap-PDU). Messages that report traps should be received on UDP port 162 for further processing. An implementation of this protocol need not accept messages whose length exceeds 484 octets. However, it is recommended that implementations support larger datagrams whenever feasible. It is mandatory that all implementations of the SNMP support the five PDUs: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU, SetRequest-PDU, and Trap-PDU."

6. SNMP Security

SNMP is not a very secure protocol. It does, however, have a minimal security system called SNMP Community Strings. SNMP Community strings act kind of like passwords for SNMP information. There are three kinds of SNMP Community strings: Read-Only, Read-Write, and Trap.

Read-Only: The Read-Only string allows you to issue SNMP Get and GetNext requests to the agent and get a Reply. The string is sent out with the SNMP Get or GetNext request and if the SNMP agent is using the same Read-Only string, then it processes the request.

Read-Write: The Read-Write string also allows you to issue SNMP Get and GetNext requests and expect a response. Furthermore, the Read-Write string allows you to perform SNMP Set requests. If a MIB object has an ACCESS value of "read-write", then you can change the value of that MIB object with an SNMP Set and the correct Read-Write SNMP Community string. If the MIB object has an ACCESS value of "read-only", then you can't change the value - even with the correct Read-Write string.

Trap: The Trap community string is not commonly used. It was designed to allow network administrators to clump network entities together into groups, or communities. Then, the NMS could be configured to only process traps received from one or more unique communities - identifying an entity's community by the Trap Community string sent out with the trap. Since most Network Management Applications have other ways to limit what entities are managed, this ability is usually redundant.

If you try to access an SNMP agent with the wrong SNMP Community string, the agent won't give you the information. If the SNMP agent is set up to do so, it may generate an SNMP trap called an "Authentication Failure" trap. In most cases, the SNMP Community strings for a network object cannot be obtained or changed via SNMP. Often, the SNMP agent's Community strings will need to be defined in a configuration file that is downloaded to the agent.

7. SNMPv2: What's New?

By the end of 1988, it became clear that for many of the large, complex network configurations that became common, SNMP was reaching the end of its useful life. There were, and would still be for some time, many configurations for which SNMP provides adequate service. However, many users were faced with the choice between an inadequate facility (SNMP) and one that was not yet available (OSI systems management). Accordingly, there has been much interest in "fixing" SNMP to extend its useful lifetime.

The SMP (Simple Management Protocol) proposal was issued in July 1992 as a set of eight (non-RFC) documents. SMP was accepted as a baseline for defining a new SNMP standard, known as SNMP version 2 (SNMPv2). The original standard is now referred to as SNMPv1. SNMPv2 is quite similar to SMP. It provides a substantial functional enhancement to SNMPv1 and adopts the security enhancements of S-SNMP (Secured SNMP) with some modifications.

The key enhancements to SNMP that are provided in SNMPv2 fall into the following categories:
1. Structure of Management Information - SMI (new MIBs).
2. Protocol operations.
3. Manager-to-manager capability.
4. Security (most important).
We briefly summarize these here.

SMI - New MIBs. The macro used to define object types has been expanded to include several new data types and to enhance the documentation associated with an object. A convention has been provided for creating and deleting conceptual rows in a table. The structure of the new "snmpV2" branch is specified in figure 5.

Protocol operations. The most noticeable change is the inclusion of two new PDUs. The GetBulkRequest PDU enables the manager to efficiently retrieve large blocks of data. In particular, it is well-suited to retrieving multiple rows in a table. The InformRequest PDU enables one manager to send trap type of information to another.

Manager-to-manager. The M2M MIB is specifically provided to support the distributed management architecture. The M2M MIB provides functionality similar to the RMON MIB. In this case, the M2M MIB may be used to allow an intermediate manager to function as a remote monitor of network media traffic.

Security. SNMPv2 has lots of security improvements - too many to specify in this document. One of those enhancements is called Access Control Policy - which defines access privileges of PDUs from the subject to the target. For clarification, please refer to Chapter 10 in William Stallings' Book (see [2] on bibliography), or read RFC 1446: "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)".

8. RMON: Remote Network Monitoring

The most important addition to the basic set of SNMP standards is the remote network monitoring (RMON) standard, RFC 1271. RMON is a major step forward in internetwork management. It defines a remote-monitoring MIB that supplements MIB-II and provides the network manager with vital information about the internetwork.

With MIB-II, the network manager can obtain information that is purely local to individual devices. Consider a LAN with a number of devices on it, each with an SNMP agent. An SNMP manager can learn about the amount of traffic into and out of each device but, with MIB-II, cannot easily learn about the traffic on the LAN as a whole. Devices that traditionally have been employed to study the traffic on a network as a whole are called network monitors (aka network analyzers or probes). The monitor can produce summary information, including error statistics, such as a count of undersize packets and the number of collisions; and performance statistics, such as the number of packets delivered per second and the packet-size distribution.

For the purposes of network management in an internetworked environment, there would typically need to be one monitor per subnet. The monitor may be a stand-alone device whose sole purpose is to capture and analyze traffic. In other cases, the monitoring function is performed by a device with other duties, such as a workstation, a server or a router. For effective network management, these monitors need to communicate with a central network-management station. In this latter context, they are referred to as remote monitors.

The RMON specification is primarily a definition of a MIB. The effect, however, is to define standard network-monitoring functions and interfaces for communicating between SNMP-based management consules and remote monitors. The RMON cabability provides an effective way to monitor (sub)networkwide behavior while reducing the load both on other agents and on management stations. RFC 1271 lists the following goals for RMON:
* Off-line operation
* Pre-emptive monitoring
* Problem detection and reporting
* Value-added data
* Multiple managers

The RMON MIB. The bulk of the RMON specification is devoted to a definition of the RMON MIB. This MIB is now incorporated into MIB-II with a subtree identifier of 16. The RMON MIB is divided into 9 groups (figure 7):
1. statistics: maintains low-level utilization and error statistics for each subnet monitored by the agent.
2. history: records periodic statistical samples from information available in the statistics group.
3. alarm: allows the person at the management consule to set a sampling interval and an alarm threshold for any counter or integer recorded by the RMON agent.
4. host: contains counters for various types of traffic to and from hosts attached to the subnet.
5. hostTopN: contains sorted host statistics that report on the hosts that top a list based on some parameter in the host table.
6. matrix: shows error and utilization information in matrix form, so the operator can retrieve information for any pair of network addresses.
7. filter: allows the monitor to observe packets that match a filter. The monitor may capture all packets that pass the filter or simply record statistics based on such packets.
8. capture (packet capture): governs how data are sent to a management consule.
9. event: a table of all events generated by the RMON agent.

Each group is used to store data and statistics derived from data collected by the monitor. A monitor may have more than one physical interface and hence may be connected to more than one subnet. The data stored in each group represent data gathered from one or more of the attached subnets, depending upon how the monitor is configured for that particular group.

For more detailed information about the RMON MIB, please refer to RFC 1271.

9. SNMP in Windows^® Systems

Windows 95
(The following section is taken from the Windows 95 Resource Kit)

For networks that use SNMP for system management, Windows 95 includes an SNMP agent which conforms to the SNMP version 1 specification. This agent allows you to monitor, from an SNMP console, remote connections to computers running Windows 95. After this agent is installed, you do not need to make any other modifications to client computers to use SNMP. The SNMP agent is implemented as a Win32-based service and works using Windows Sockets over both TCP/IP and IPX/SPX. The extension agents are implemented as Win32 DLLs (For more information about writing SNMP MIBs under Windows 95, see the Microsoft Win32 Software Development Kit).

The configuration information for the RFC 1156 extension agent is placed in the Registry under the following key:
Hkey_Local_Machine\System\CurrentControlSet\Services\SNMP\Parameters

To install the Microsoft SNMP agent:
1. In the Network option in Control Panel, click Add.
2. In the Select Network Component Type dialog box, double-click Service.
3. In the Select Network Service dialog box, click the Have Disk button.
4. In the Install From Disk dialog box, type the path to the ADMIN\NETTOOLS\SNMP directory on the Windows 95 compact disc, and then click OK.
5. In the Select Network Service dialog box, click Microsoft SNMP Agent in the Models list, and then click OK.

If you are prompted to specify the location of additional files, specify the path to the Windows 95 source files on a shared network directory or on the Windows 95 compact disc. When the computer is restarted after the SNMP agent is installed, SNMP automatically starts in an MS-DOS window. You can minimize this window to keep it out of the way while working.

To configure the SNMP agent:
Use System Policy Editor to set the following policies for the computer:

  POLICY "Name Of New Policy" 
    KEYNAME 
    System\CurrentControlSet\Services\SNMP\Parameters 
          \TrapConfiguration\Name Of New Community
    PART !!Traps_PublicListbox LISTBOX 
      VALUEPREFIX "" 
    END PART 
  END POLICY 

Note: The Registry key and value names are case-sensitive. Also, the Registry key name (System\...\ Name Of New Community) must be one continuous line in the ADMIN.ADM file.

For example, the following adds a policy for a community named Prv1:

  POLICY "Traps for Prv1 Community" 
    KEYNAME 
    System\CurrentControlSet\Services\SNMP\Parameters\TrapConfiguration\Prv1
    PART !!Traps_PublicListbox LISTBOX
      VALUEPREFIX ""
    END PART 
  END POLICY 

After editing and saving ADMIN.ADM, you can see this new policy by running System Policy Editor and selecting the Computer policy under Network named SNMP. You can use this policy exactly as you would use the policy named Traps For Public Community.


Windows NT 4.0
Windows NT includes an SNMP agent. To make use of it, you should install The Microsoft SNMP service.

The Microsoft SNMP Service:
* Is written to the Windows Sockets API. This allows calls from management systems written to Windows Sockets.
* Sends and receives messages using UDP port 161, and uses IP to support routing of SNMP messages.
* Provides extension agent DLLs for supporting other MIBs. Third parties can develop their own MIBs for use with the Microsoft SNMP service.
* Includes a Microsoft Win32® SNMP manager API to simplify the development of SNMP applications.

The SNMP service that comes with Windows NT 4.0 supports the following MIBs:
* Internet MIB-II: The standard MIB-II mentioned in chapter 4. Defines 171 objects essential for either fault or configuration analysis.
* LAN Manager MIB II: Defines approximately 90 objects that include such items as statistical, share, session, user and logon information. Most LAN Manager MIB II objects have read-only access because of the nonsecure nature of SNMP. The OID for LAN Manager MIB II is:
  iso.org.dod.internet.private.enterprises.lanmanager (1.3.6.1.4.1.77)
* DHCP MIB: Windows NT 4.0 includes a DHCP MIB that defines objects to monitor DHCP server activity. This MIB (DHCPMIB.DLL) is automatically installed when the DHCP server service is installed. It contains approximately 14 objects for monitoring DHCP, such as the number of DHCP discover requests received, the number of declines, and the number of addresses leased out to clients.
* WINS MIB: Windows NT 4.0 includes a WINS MIB that defines objects to monitor WINS server activity. This MIB (WINSMIB.DLL) is automatically installed when the WINS server service is installed. It contains approximately 70 objects for monitoring WINS, such as the number of resolution requests successfully processed, the number of resolution requests that failed, and the date and time of the last database replication.

To install the SNMP service (where TCP/IP is already installed):
1. From Control Panel, double-click Network.
2. From the Network Settings dialog box, click Add.
3. Click theServices tab and then click Add.
4. TheSelect Network Service dialog box appears.
5. Click SNMP service and then click OK.
6. When prompted, type the path to the Windows NT distribution files.
7. After the appropriate files are copied to the computer, the SNMP Service Configuration dialog box appears.
8. Select the Traps tab.

Configure the following parameters:

Community Names: The community name to which traps are sent. A management system must belong to the designated community to receive traps. The default community name for all hosts is Public.

Trap Destination: The trap destination consists of names or IP addresses of hosts to which you want the SNMP service to send traps. If you use a host name, make sure it can be resolved so the SNMP service can map it to the IP address.

Important note:
You might encounter problems with the SNMP service under Windows NT 4.0 service pack 4. To solve the problem, try one of the following:
1. Install the SNMP service before you install service pack 4.
2. If you already installed the SNMP service on top of service pack 4, try uninstalling service pack 4 and re-insattling it.
3. If uninstall is not available, try updating the existing service pack using the UPDATE.EXE program.


To configure SNMP security:
1. In the Microsoft SNMP Properties dialog box (shown above), click the Security tab.
2. Configure the following parameters:

Send Authentication Trap: When the SNMP service receives a request for information that does not contain the correct community name or doesn't match an accepted host name for the service, the SNMP service can send a trap to the trap destination(s), indicating that the request failed authentication. Select this check box to specify whether this authentication trap is sent.

Accepted Community Names: A host must belong to a community that appears on this list for the SNMP service to accept requests from that host. Typically, all hosts belong to Public which is the standard name for the common community of all hosts.

Accept SNMP Packets from Any Host: If this option button is selected, no SNMP packets are rejected on the basis of the source host ID and the list of hosts in the box bellow it.

Only Accept SNMP Packets from These Hosts: If this option button is selected, SNMP packets are accepted only from the hosts listed in the box bellow it.

Note:
Community names are case sensitive. In Windows SNMP service, the common community name is written as "Public" with a capital "P" by default. You might want to change it to "private" (no capital "P") for compatibility.

To configure SNMP agent services:
1. In the Microsoft SNMP Properties dialog box, click the Agent tab.
2. In the Contact box, type a contact name (this is typically the person who uses the computer).
3. In the Location box, type a description for the location of the computer.
4. Under Service, select the services to be provided by the agent.

Each service provides information on activity at the different layers. The default services are Applications, End-to-End and Internet.

Physical: This Windows NT computer manages any physical devices, such as repeaters.

Datalink/Subnetwork: This Windows NT computer manages a bridge.

Internet: This Windows NT computer acts as an IP gateway (router).

End-to-End: This Windows NT computer acts as an IP host. This option should always be selected.

Applications: This Windows NT computer uses any applications that use TCP/IP. This option should always be selected.

Identifying SNMP Service Errors
Event Viewer records all events of system components, such as failure of the SNMP service starting. All SNMP service errors and activity are recorded in the system log. Event Viewer is the first place you should look to identify a problem with the SNMP service.

10. SNMP in UNIX^® Systems

HP-UX, IRIX and DEC's OSF/1 all come with SNMP agents pre-installed. All of these systems support MIB-II, although there are occasional lapses in coverage, particularly with respect to support for exterior routing protocols. Consult your manuals for specifics.


HP-UX 9.0
HP-UX's snmpd is configured in /etc/snmpd.conf. Comments are introduced with a pound sign ("#"). Five different keywords can be used within snmpd.conf, as illustrated in the following example:

  # SNMP configuration file for host "turbine".
  get-community-name: cuslug
  set-community-name: cuslug
  trap-dest: anchor
  trap-dest: piper
  location: Schreiber building, Room 010
  contact: Gur Aviv, 640-8823

The get-community-name and set-community-name keywords list the SNMP communities that are allowed to read and write data values. There may be more than one instance of each. However, access control cannot be subdivided; any name listed in set-community-name statement is valid for any supported operation.

The trap-dest keyword specifies the name or IP address of an SNMP client that is to receive trap notifications. There may be several of these, and all traps are sent to all destinations.

The location and contact keywords allow free-format information about the machine to be made available via the MIB-II sysLocation and sysContact OIDs. The location and contact information can also be specified on snmpd's command line.

You can control the amount of logging that snmpd generates with

  snmpd -m logmask

The logmask should be a bitwise OR of your choice of option flags listed in figure 8. -m 0 disables logging.

Unfortunately, HP's snmpd does not use syslog. The default log file is /usr/adm/snmpd.log; an alternate can be specified with -l log.


IRIX 5.2
IRIX's snmpd can be configured to start at boot time by running the command chkconfig snmpd on. It can also be started manually.

The file /etc/snmpd.auth is used for security configuration. Lines in this file have the form

  {accept|reject} hostname:community/operation ...

A star ("*") can be used to stand in for all hosts or all communities; unless you want undergraduates in Australia rebooting your router, we don't recommend this configuration. Multiple hosts of communities may be seperated with a comma. The operation field may be left blank to indicate all operations. It's usually specified as get to designate certain hosts or communities as read-only.

IRIX's snmpd reports problems using syslog. Normally, only messages of level "err" or above are reported. The -l loglevel option can be used to vary the amount of information that is logged. The -d option sets various debugging options.


DEC's OSF/1 2.0
DEC's SNMP agent has been segmented into several different processes and configuration files. The system is a bit complicated and unwieldy compared to other implementations, but it is also extensible. New MIBs and code to support them can be integrated into the basic framework.

The components are listed in figure 9. In DEC-speak, a "MOM" is a Managed Object Module, a program that implements a MIB. See the man page for snmpsetup for information about adding additional MOMs to the system.

In the default setup, there are two configuration files of interest: the /etc/eca/snmp_pe.conf file, which configures the basic SNMP protocol engine, and the /etc/eca/internet_mom.conf file, which sets options specific to MIB-II. You can edit these files directly or use the supplied snmpsetup script.

Three kinds of statements can appear in snmp_pe.conf. An SNMP community is defined with the community statement: community name ipaddr type. The name field names the community, and the type field specifies the access afforded to it. type can be readonly, readwrite, writeonly or none. The ipaddr field provides a crude form of authentication: if it is an IP address in normal dot notation, only the specified machine may access the SNMP agent using this community name. If the field contains 0.0.0.0, no address check is performed.

A trap statement specifies a management station to which trap notifications should be sent: trap name ipaddr. The name field specifies the trap community; it does not allow different kinds of traps to be sent to different stations. The ipaddr must be specified in numeric dot notation.

The optional statement no_auth_traps prevents "authentication failure" traps from being generated. If it is not present, the traps are sent to all defined trap communities.

The internet_mom.conf file specifies the text in the sysLocation and sysContact OIDs, along with the interval at which interfaces should be polled to make sure they are still alive, in seconds. These three values should be placed on seperate lines, in the same order. Lines beginning with a pound sign ("#") are comments. For example:

  # internet_mom.conf file for host turbine
  Schreiber building, Room 010
  Mr. Alper Arad, 640-8823
  60

11. Network Management Software

SNMPUTIL - This small utility comes with the Windows NT Resource Kit. The utility verifies whether the SNMP Service has been correctly configured to communicate with SNMP management stations. It can also be used to read MIBs of other managable hosts/devices. SNMPUTIL makes the SNMP calls as an SNMP management station.

The syntax of SNMPUTIL is as follows:

  snmputil command agent community OID

The valid commands are:
* get: Get the value of the requested object identifier.
* genext: Get the value of the next object following the specified object.
* walk: Step through (walk) the MIB branch specified by the object identifier.

For example, to determine the number of DHCP addresses leased by a DHCP server named GAUSS in the Public community, you would issue the following command:

  snmputil getnext gauss Public .1.3.6.1.4.1.311.1.3.2.1.1.1

This command will respond with the OID and counter value for the object ID in question - in this case, the number of IP leases that are issued.

MG-SOFT MIB Browser (30-day trial version)
A simple but powerful tool running on Microsoft's 32-bit operating systems (Windows 95, Windows 98, Windows NT) for browsing MIBs in your network in a graphical view - just like Windows Explorer.

The pack includes MG-SOFT MIB Browser Professional Edition, MIB Compiler and command line winsnmp utilities (SNMP Ping, Send Trap, Simple SNMP Service).

MIB Browser lets you monitor and manage any SNMP device on the network (i.e. file or database servers, routers, hubs, switches, bridges,...) by using the standard SNMPv1 and SNMPv2c protocols. MIB Browser allows you performing the SNMP GET, SNMP GETNEXT, SNMP GETBULK and SNMP SET operations. Besides, the software lets you capture SNMP TRAP packets sent from arbitrary SNMP devices on the network.

MIB Browser can monitor several SNMP devices simultaneously and contains features like SNMP Table viewer, logging capabilities, real-time graphical presentation of queried numerical values etc.

The enclosed MIB Compiler lets you compile any vendor specific MIB file. Compiled MIB file can then be loaded and utilized by the MIB browser. Generally, a MIB file is usually supplied by the vendor of an SNMP manageable device and contains a description of the object hierarchy and object attributes on the managed device and serves as a roadmap for managing that device.

You can find additional MIB files (standard MIBs) HERE You will need to compile them using the MIB Compiler.


Commercial Software

HP OpenView is a series of software products for enterprise management: application & system management, desktop & software management, IT service management, network management, NT-centric management, security management and storage management.

HP OpenView includes the following products: AssetView, Desktop Administrator, IT Service Manager, IT/Administration, IT/Operations, ManageX, NetMetrix, Network Node Manager, OmniBack II, OmniStorage, PerfView, MeasureWare and GlancePlus. For more information about each product, visit the HP OpenView web site.


CA Unicenter TNG addresses today?s most pressing IT management challenges through a tightly integrated set of core solutions. The breadth of these management solutions and their ability to work together delivers true end-to-end management of the environment and sets Unicenter TNG apart from other enterprise management offerings.

Unicenter TNG's ability to manage the entire enterprise from a business process perspective renders it the industry?s only practical solution for today?s unwieldy environments. In fact, Unicenter TNG is widely recognized as the de facto standard for enterprise management. Visit the CA web site for more information.

12. The Future - What's Next?

* Many new RFCs deal with definitions of vendor-specific MIBs. SNMP agents become more and more common - in internetworking devices, printers etc. Also, OS-specific MIBs are defined and developed during time. SNMP became a trivial protocol, a fact which allowed enterprise-management software like CA Unicenter TNG and HP OpenView to be very common.

* On April 1999, RFC2570 introduced the version 3 of the Internet-standard Network Management Framework, also known as The SNMPv3 framework. Other draft RFC's related to SNMPv3 are already available - most of them deal with security improvements.

* Windows 2000: This new OS from Microsoft includes many new microsoft-specific MIBs with standard SNMP service installation. You can click HERE to download the Windows 2000 MIB definitions.

Appendix A: Related Internet RFCs

MIB and MIB-II Related
RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets
RFC 1156: Management Information Base for Network Management of TCP/IP-based internets
RFC 1212: Concise MIB Definitions
RFC 1213: Management Information Base for Network Management of TCP/IP-based internets: MIB-II

SNMP Related
RFC 1157: A Simple Network Management Protocol (SNMP)
RFC 1351: SNMP Administrative Model
RFC 1352: SNMP Security Protocols

SNMPv2 Related
RFC 1441: Introduction to version 2 of the Internet-standard Network Management Framework
RFC 1442: Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1443: Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1445: Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1446: Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1450: Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1452: Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework
RFC 1503: Algorithms for Automating Administration in SNMPv2 Managers
RFC 1592: Simple Network Management Protocol Distributed Protocol Interface Version 2.0

RMON Related
RFC 1271: Remote Network Monitoring Management Information Base
RFC 1513: Token Ring Extensions to the Remote Network Monitoring MIB
RFC 1757: Remote Network Monitoring Management Information Base
RFC 2021: Remote Network Monitoring Management Information Base Version 2 using SMIv2
RFC 2074: Remote Network Monitoring MIB Protocol Identifiers
RFC 2613: Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0

General
RFC 1470: FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices

Note: RFCs are frequently updated - search for new RFCs on http://www.faqs.org/rfcs/

Appendix B: Bibliography

BOOKS
[1] MCSE Networking Essentials Study Guide, Second Edition / ©1998 Sybex Network Press
[2] SNMP, SNMPv2, and CMIP - The Practical Guide to Network Management Standards / William Stallings ©1993 Addison-Wesley Publishing Company, Inc
[3] Internetworking with Microsoft^® TCP/IP in Microsoft Windows NT^® 4.0 - Workbook / Microsoft Official Curriculum, February 1997
[4] UNIX^® System Administration Handbook / Evi Nemeth, Garth Snyder, Scott Seebass, Trent R. Hein ©1995 Prentice-Hall, Inc.

ONLINE RESOURCES
[5] "SNMP for Dummies" / NetCom Systems, Inc (http://www.netcom-sys.com/documents/snmp4dum.doc).

OFFLINE RESOURCES
[6] Microsoft Windows 95 Resource Kit.
[7] Microsoft Windows NT 4.0 Resource Kit.