Table of Contents DOS
TCP/IP Tutorial and Technical Overview

4.14 Network Management




Figure: Network Management

With the growth in size and complexity of the TCP/IP-based internets the need for network management became very important. The current network management framework for TCP/IP-based internets consists of:

  1. SMI (RFC 1155) - describes how managed objects contained in the MIB are defined. (It will be discussed in Structure and Identification of Management Information (SMI).)
  2. MIB-II (RFC 1213) - describes the managed objects contained in the MIB. (It will be discussed in Management Information Base (MIB).)
  3. SNMP (RFC 1098) - defines the protocol used to manage these objects. (It will be discussed in Simple Network Management Protocol (SNMP).)
The Internet Architecture Board issued an RFC detailing its recommendation, which adopted two different approaches:

Both the SNMP and CMOT use the same basic concepts in describing and defining management information called Structure and Identification of Management Information (SMI) described in RFC 1155 and Management Information Base (MIB) described in RFC 1156.

4.14.1 Standards

SNMP (Simple Network Management Protocol) is an Internet standard protocol. Its status is recommended. Its current specification can be found in RFC 1157 - Simple Network Management Protocol (SNMP).

MIB-II is an Internet standard protocol. Its status is recommended. Its current specification can be found in RFC 1213 - Management Information Base for Network Management of TCP/IP-based Internets: MIB-II.

CMIP (Common Management Information Protocol) and CMIS (Common Management Information Services) are defined by the ISO/IEC 9595 and 9596 standards.

CMOT (CMIS/CMIP Over TCP/IP) is an Internet proposed standard protocol. Its status is elective. Its current specification can be found in RFC 1189 - Common Management Information Services and Protocols for the Internet (CMOT) and (CMIP).

OIM-MIB-II is an Internet proposed standard protocol. Its status is elective. Its current specification can be found in RFC 1214 - OSI Internet Management: Management Information Base.

Other RFCs issued by IAB on this subject are:

4.14.2 Structure and Identification of Management Information (SMI)

The SMI defines the rules for how managed objects are described and how management protocols may access these objects. The description of managed objects is made using a subset of the ASN.1 (Abstract Syntax Notation 1, ISO standard 8824), a data description language. The object type definition consists of five fields:

As an example, we can have:



This example shows the definition of an object contained in the Management Information Base (MIB). Its name is sysDescr and it belongs to the system group (see Management Information Base (MIB)).

A managed object not only has to be described but identified, too. This is done using the ASN.1 Object Identifier in the same way as a telephone number, reserving group of numbers to different locations. In the case of TCP/IP-based network management the number allocated was 1.3.6.1.2 and SMI uses it as the base for defining new objects.

The number 1.3.6.1.2 is obtained by joining groups of numbers with the following meaning:

In the example the {system 1} beside the object name means that the object identifier is 1.3.6.1.2.1.1.1. It is the first object in the first group (system) in the Management Information Base (MIB).

4.14.3 Management Information Base (MIB)

4.14.3.1 Overview

The MIB defines the objects which may be managed for each layer in the TCP/IP protocol. There are two versions, MIB-I and MIB-II. MIB-I was defined in RFC 1156, and is now classified as a historic protocol with a status of not recommended.


Figure: Management Information Base II (MIB-II) - Group definition.

Each managed node supports only those groups that are appropriate. For example, if there is no gateway, the EGP group need not be supported. But if a group is appropriate, all objects in that group must be supported.

The list of managed objects defined has been derived from those elements considered essential. This approach of taking only the essential objects is not restrictive, since the SMI provides extensibility mechanisms like definition of a new version of the MIB and definition of private or non-standard objects.

Below are some examples of objects in each group. The complete list is defined in RFC 1213.

This is not the complete MIB definition but it is presented as an example of the objects defined in each group.

To illustrate this, the Interfaces Group contains two top-level objects: the number of interface attachments on the node (ifNumber) and a table containing information on those interfaces (ifTable). Each entry (ifEntry) in that table contains the objects for a particular interface. Among those, the interface type (ifType) is identified in the MIB tree using the ASN.1 notation by 1.3.6.1.2.1.2.2.1.3. and for a token-ring adapter the value of the corresponding variable would be 9, which means "iso88025-tokenRing" (see Figure - Object Identifier).


Figure: Object Identifier - Allocation for TCP/IP-based Network.

4.14.3.2 IBM-Specific MIB Part

IBM has added the following objects in the MIB-II database: 

* IBM SNMP agent DPI UDP port
DPI_port                1.3.6.1.4.1.2.2.1.1.    number          2

* IBM "ping" round-trip-time table
RTTaddr                 1.3.6.1.4.1.2.2.1.3.1.  internet        60
minRTT                  1.3.6.1.4.1.2.2.1.3.2.  number          60
maxRTT                  1.3.6.1.4.1.2.2.1.3.3.  number          60
aveRTT                  1.3.6.1.4.1.2.2.1.3.4.  number          60
RTTtries                1.3.6.1.4.1.2.2.1.3.5.  number          60
RTTresponses            1.3.6.1.4.1.2.2.1.3.6.  number          60

Where:

4.14.4 Simple Network Management Protocol (SNMP)

The SNMP added the improvement of many years of experience in SGMP and allowed it to work with the objects defined in the MIB with the representation defined in the SIM.

RFC 1157 defines the Network Management Station (NMS) as the one that executes network management applications (NMA) that monitor and control network elements (NE) such as hosts, gateways and terminal servers. These network elements use a management agent (MA) to perform the network management functions requested by the network management stations. The Simple Network Management Protocol (SNMP) is used to communicate management information between the network management stations and the agents in the network elements.


Figure: SNMP - Components of the Simple Network Management Protocol.

All the management agent functions are only alterations (set) or inspections (get) of variables limiting the number of essential management functions to two and avoiding more complex protocols. In the other direction, from NE to NMS, a limited number of unsolicited messages (traps) are used to inform about asynchronous events. In the same way, trying to preserve the simplicity, the interchange of information requires only an unreliable datagram service and every message is entirely and independently represented by a single transport datagram. This means also that the mechanisms of the SNMP are generally suitable for use with a wide variety of transport services. The RFC 1157 specifies the exchange of messages via the UDP protocol, but a wide variety of transport protocols can be used.

The entities residing at management stations and network elements that communicate with one another using the SNMP are termed SNMP application entities. The peer processes that implement it are the protocol entities. An SNMP agent with some arbitrary set of SNMP application entities is called an SNMP community, where each one is named by a string of octets that need to be unique only to the agent participating in the community.

A message in the SNMP protocol consists of a version identifier, an SNMP community name and a protocol data unit (PDU). It is mandatory that all implementations of the SNMP support the five PDUs:

The formats of these messages are as follows:


Figure: SNMP Message Format - Request, Set and Trap PDU format.

4.14.5 Common Management Information Protocol over TCP/IP (CMOT)

CMOT is the network management architecture that has been developed to move towards a closer relationship with the Open System Interconnection (OSI) network management standards named Common Management Information Protocol (CMIP). With these premises CMOT, as in the OSI model, can be divided into an organizational model, functional model and informational model.

In the organizational and informational models the same OSI concept is used in CMOT and in SNMP. The object identification is formed using the subtree related to the DoD with subdivisions in management, directory, experimental and private. All the management objects are defined in the Management Information Base (MIB) being represented by the Structure and Identification of Management Information (SMI), a subset of the ASN.1 (OSI Abstract Syntax Notation 1).

In the functional model CMOT adopted the OSI model that divides the management components into managers and agents. The agent collects information, performs commands and executes tests and the manager receives data, generates commands and sends instructions to the agents. This manager and agent are formed by a set of specific management information per communication layer named the Layer Management Entities (LME).


Figure: CMOT - Components of the CMIP over TCP/IP.

All the LME are coordinated by a System Management Application Process (SMAP) that can communicate between different systems over the Common Management Information Protocol (CMIP).

In the OSI approach the management can occur only over fully established connections between the managers and the agents. CMOT allows management information exchange over connectionless services (datagram). But to maintain the same service interface required by CMIP, called Common Management Information Services (CMIS), the CMOT architecture defined a new communication layer, the Lightweight Presentation Protocol (LPP). This layer has been defined to provide the presentation services required for the CMIP so that the entirely defined network management standards defined by OSI will fit in the TCP/IP CMOT architecture.


Figure: Lightweight Presentation Protocol (LPP)

4.14.6 SNMP Distributed Programming Interface (SNMP DPI)

SNMP defines a protocol that permits operations on a collection of variables. This set of variables (MIB) and a core set of variables have previously been defined. However, the design of the MIB makes provision for extension of this core set. Unfortunately, conventional SNMP agent implementations provide no means for an end user to make new variables available. The SNMP DPI addresses this issue by providing a light-weight mechanism that permits end users to dynamically add, delete, or replace management variables in the local MIB without requiring recompilation of the SNMP agent. This is achieved by writing the so-called subagent that communicates with the agent via the SNMP DPI. It is described by G. Carpenter and B. Wijnen (T.J. Watson Research Center, IBM Corp.) in RFC 1228.

The SNMP DPI allows a process to register the existence of a MIB variable with the SNMP agent. When requests for the variable are received by the SNMP agent, it will pass the query on to the process acting as a subagent. This subagent then returns an appropriate answer to the SNMP agent. The SNMP agent eventually packages an SNMP response packet and sends the answer back to the remote network management station that initiated the request. None of the remote network management stations have any knowledge that the SNMP agent calls on other processes to obtain an answer.

Communication between the SNMP agent and its clients (subagents) takes place over a stream connection. This is typically a TCP connection, but other stream-oriented transport mechanisms can be used (as an example, the VM SNMP agent allows DPI connections over IUCV).

The SNMP Agent DPI can:

The following figure shows the flow between an SNMP agent and a subagent.


Figure: SNMP DPI Overview

4.14.7 Simple Network Management Protocol Version 2 (SNMPv2)

The framework of version 2 of the Simple Network Management Protocol (SNMPv2) was published in April 1993 and consists of 12 RFCs including the first, RFC 1441, which is an introduction. In August 1993 all 12 RFCs became a proposed standard with the status elective.

This framework consists of the following disciplines:

The following sections describe the major differences and improvements from SNMPv1 to SNMPv2.

4.14.7.1 SNMPv2 Entity

An SNMPv2 entity is an actual process which performs network management operations by generating and/or responding to SNMPv2 protocol messages by using the SNMPv2 protocol operations. All possible operations of an Entity can be restricted to a subset of all possible operations that belong to a particular administratively defined Party. Please refer to SNMPv2 Party below. An SNMPv2 Entity could be member of multiple SNMPv2 Parties. The following local databases are maintained by an SNMPv2 Entity:

An SNMPv2 Entity can act as an SNMPv2 agent or manager.

4.14.7.2 SNMPv2 Party

An SNMPv2 party is a conceptual, virtual execution environment whose operation is restricted, for security or other purposes, to an administratively defined subset of all possible operations of a particular SNMPv2 entity. Please refer to SNMPv2 Entity above. Architecturally, each SNMPv2 party comprises:

4.14.7.3 GetBulkRequest

The GetBulkRequest is defined in RFC 1448 and is thus part of the protocol operations. A GetBulkRequest is generated and transmitted as a request of an SNMPv2 application. The purpose of the GetBulkRequest is to request the transfer of a potentially large amount of data, including, but not limited to, the efficient and rapid retrieval of large tables. The GetBulkRequest is more efficient than the GetNextRequest in case of retrieval of large MIB object tables. The syntax of the GetBulkRequest is: 

GetBulkRequest [ non-repeaters = N, max-repetitions = M ]
                ( RequestedObjectName1,
                  RequestedObjectName2,
                  RequestedObjectName3 )
Where:
RequestedObjectName1, 2, 3
MIB object identifier like sysUpTime etc. The objects are in a lexicographically ordered list. Each object identifier has a binding to at least one variable. For example, the object identifier ipNetToMediaPhysAddress has a variable binding for each IP address in the ARP table and the content is the associated MAC address.
N
Specifies the non-repeaters value, which means that you request only the contents, of the variable next to the object specified in your request, of the first N objects named between the parentheses. This is the same function as provided by the GetNextRequest.
M
Specifies the max-repetitions value, which means that you request from the remaining (number of requested objects - N) objects the contents of the M variables next to your object specified in the request. Similar to an iterated GetNextRequest but transmitted in only one request.
With the GetBulkRequest you can efficiently get the contents of only the next variable or the next M variables in only one request.

Assume the following ARP table in a host which runs an SNMPv2 agent: 

Interface-Number  Network-Address  Physical-Address  Type

       1            10.0.0.51     00:00:10:01:23:45  static
       1             9.2.3.4      00:00:10:54:32:10  dynamic
       2            10.0.0.15     00:00:10:98:76:54  dynamic
An SNMPv2 manager sends the following request to retrieve the sysUpTime and the complete ARP table: 
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
                ( sysUpTime,
                  ipNetToMediaPhysAddress,
                  ipNetToMediaType )
The SNMPv2 entity acting in an agent role responds with a Response-PDU: 
Response (( sysUpTime.0 =  "123456" ),
          ( ipNetToMediaPhysAddress.1.9.2.3.4 =
                                     "000010543210" ),
          ( ipNetToMediaType.1.9.2.3.4 =  "dynamic" ),
          ( ipNetToMediaPhysAddress.1.10.0.0.51 =
                                      "000010012345" ),
          ( ipNetToMediaType.1.10.0.0.51 =  "static" ))
The SNMPv2 entity acting in a manager role continues with: 
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
                ( sysUpTime,
                  ipNetToMediaPhysAddress.1.10.0.0.51,
                  ipNetToMediaType.1.10.0.0.51 )
The SNMPv2 entity acting in an agent role responds with: 
Response (( sysUpTime.0 =  "123466" ),
          ( ipNetToMediaPhysAddress.2.10.0.0.15 =
                                     "000010987654" ),
          ( ipNetToMediaType.2.10.0.0.15 =
                                          "dynamic" ),
          ( ipNetToMediaNetAddress.1.9.2.3.4 =
                                          "9.2.3.4" ),
          ( ipRoutingDiscards.0 =  "2" ))
This response signals the end of the table to the SNMPv2 entity acting in a manager role. With the GetNextRequest you would have needed four requests to retrieve the same information. If you had set the max-repetition value of the GetBulkRequest to three, in this example, you would have needed only one request.

4.14.7.4 InformRequest

An InformRequest is generated and transmitted as a request from an application in an SNMPv2 manager entity that wishes to notify another application, acting also in an SNMPv2 manager entity, of information in the MIB view (20)of a party local to the sending application. The packet is used as an indicative assertion to the manager of another party about information accessible to the originating party (manager-to-manager communication across party boundaries). The first two variables in the variable binding list of an InformRequest are sysUpTime.0 and snmpEventID.i (21)respectively. Other variables may follow.

4.14.8 MIB for SNMPv2

This MIB defines managed objects which describe the behavior of the SNMPv2 entity.

Note: This is not a replacement of the MIB-II.

Following are some object definitions to get an idea of the contents: 

snmpORLastChange OBJECT-TYPE
    SYNTAX     TimeStamp
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
            "The value of sysUpTime at the time of the most
            recent change in state or value of any instance of
            snmpORID."

warmStart NOTIFICATION-TYPE
    STATUS  current
    DESCRIPTION
            "A warmStart trap signifies that the SNMPv2
            entity, acting in an agent role, is reinitializing
            itself such that its configuration is unaltered."

4.14.9 Party MIB

The party MIB defines managed objects which correspond to the properties associated with an SNMPv2 party. An example of some MIB objects: 

partyIdentity OBJECT-TYPE
    SYNTAX      Party
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
            "A party identifier uniquely identifying a
            particular SNMPv2 party."

partyAuthProtocol OBJECT-TYPE
    SYNTAX      OBJECT IDENTIFIER
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
            "The authentication protocol by which all messages
            generated by the party are authenticated as to
            origin and integrity.  The value noAuth signifies
            that messages generated by the party are not
            authenticated.

            Once an instance of this object is created, its
            value can not be changed."

4.14.9.1 Manager-to-Manager MIB

The purpose of this MIB is to provide the means for coordination between multiple management stations. That is, the means by which the controlling and monitoring functions of network management can be distributed amongst multiple management stations in a large network. Specifically, this MIB provides the means for one management station to request management services from another management station. Therefore, an SNMPv2 entity can act in a dual role; when providing management information to another manager the entity acts as an agent, and when requesting information, it acts as a manager. The manager-to-manager MIB consists of the following three tables:

Each alarm is a specific condition detected through the periodic, at a configured sampling interval, monitoring of the value of a specific management information variable. An example of an alarm condition is when the monitored variable falls outside a configured range. Each alarm condition triggers an event and each event can cause (one or more) notifications to be reported to other management stations using the InformRequest frame.

4.14.10 Single Authentication and Privacy Protocol

The authentication protocol provides a mechanism by which SNMPv2 management communications, transmitted by a party, may be reliably identified as having originated from that party.

The privacy protocol provides a mechanism by which SNMPv2 management communications, transmitted to a party, are protected from disclosure.

Principal threats against which the SNMPv2 security protocol provides protection are:

The following security services provide protection against the above threats:

4.14.11 The New Administrative Model

It is the purpose of the Administrative Model for SNMPv2, to define how the administrative framework is applied to realize effective network management in a variety of configurations and environments.

The model entails the use of distinct identities for peers that exchange SNMPv2 messages. Thus, it represents a departure from the community-based administrative model of the original SNMPv1. By unambiguously identifying the source and intended recipient of each SNMPv2 message, this new strategy improves upon the historical community scheme both by supporting a more convenient access control model and allowing for effective use of asymmetric (public key) security protocols in the future. Please refer to Figure - SNMP Version 2 Message Format for the new message format.


Figure: SNMP Version 2 Message Format

PDU
Includes one of the following Protocol Data Units: The GetBulkRequest has a different PDU format as shown above. Please also refer to GetBulkRequest.

Note: The SNMP-Trap now has the same format as all the other requests.

SnmpMgmtCom (SNMP Management Communication)
Adds the source party ID (srcParty), the destination party ID (dstParty) and the context to the PDU. The context specifies the SNMPv2 context containing the management information referenced by the communication.
SnmpAuthMsg
This field is used as authentication information from the authentication protocol used by that party. The SnmpAuthMsg is serialized according to ASN.1 BER (22)and can then be encrypted.
SnmpPrivMsg SNMP Private Message
An SNMPv2 Private Message is an SNMPv2 authenticated management communication that is (possibly) protected from disclosure. A private destination (privDst) is added to address the destination party.
The message is then encapsulated in a normal UDP/IP datagram and sent to the destination across the network.

For further information please refer to the above mentioned RFCs.

4.14.12 Implementations

Note: The implementations described below only refer to the SNMP version 1.

4.14.12.1 VM and MVS

The TCP/IP for VM and MVS products provide both an SNMP client and an SNMP agent. They support the following MIB-II groups: system, interfaces, address translation, ip, icmp, tcp, udp and the IBM 3172 Enterprise Specific. Although no Exterior Gateway Protocol (EGP) is currently available under MVS or VM, you can query, from a VM or MVS manager, an agent that supports EGP. Of course a VM or an MVS agent will not be able to create EGP traps. The TCP/IP for VM and MVS products do not support the Set-Request PDU.

The traps generated by the SNMP agent (VM or MVS) are:

The SNMP Agent DPI is also implemented under VM and MVS. This DPI allows external processes to generate SNMP traps.

The SNMP agent is provided within the SNMPD (Simple Network Management Daemon) Virtual Machine (VM) or Address Space (MVS).

The SNMP manager function requires that both NetView and the SNMPQE (Simple Network Management Query Engine) be up and running.


Figure: Overview of NetView SNMP Support

A description of the operation of the interface between TCP/IP and SNMP/NetView follows:

  1. NetView operator or CLIST issues an SNMP command.
  2. SNMP command is validated by SNMP Command Processor.
  3. SNMP Command Processor passes the request to SNMPIUCV task.
  4. SNMPIUCV task passes the request to SNMP Query Engine (SNMPQE).
  5. SNMP Query Engine validates and encodes the request in ASN.1 and SNMP PDU (using the tcpip.MIB@DESC.DATA MVS data set or the MIB_DESC DATA VM file) and sends it to SNMP agent (variables must always be in ASN.1 notation when they are sent to an SNMP agent).
  6. SNMP Query Engine receives a response from the SNMP agent.
  7. SNMP Query Engine decodes the response and sends it to the NetView SNMPIUCV task.
  8. SNMPIUCV task sends the response as a multi-line message to the requesting operator or authorized receiver.

To avoid unnecessary network traffic, each variable described in the customizable file, "MIB_DESC DATA" in VM or "tcpip.MIB@DESC.DATA" in MVS, has a Time To Live (TTL) value assigned. This specifies the number of seconds that the variable lives in the Query Engine's internal cache. The value is obtained from the cache if multiple requests for the same variable are issued within the TTL period.

IBM 3172 support:

IBM TCP/IP supports SNMP GET and SNMP GETNEXT operations to request and retrieve the IBM 3172 enterprise-specific MIB variables. These requests will only be answered by those IBM 3172 devices connected to the MVS host's TCP/IP and whose DEVICE definition in the PROFILE.TCPIP data set includes the keyword NETMAN. Following is an example of such a definition:



Please refer to IBM TCP/IP Version 2 Release 3 for VM: Planning and Customization and IBM TCP/IP Version 3 Release 1 for MVS: Customization and Administration Guide for details.

The SNMP starter set from TCP/IP for MVS provides NetView operators with the tool to manage the TCP/IP network. NetView commands can be entered from the SNMP main panel and standard PF key definitions used in the other NetView components are used within SNMP CLISTs.

Full documentation of the starter set is in member SNMPREXX in tcpip.v3r1.SEZAINST. The full screen panels require NetView Version 1 Release 3 (they are written in REXX).

The following screen output shows a sample MVS NetView session to another MVS host named mvs20 using the community name ITSC: 

snmp get mvs20 itsc sysdescr
SNM040I SNMP Request 1001 from LI Returned the following response:
SNM042I Variable name: 1.3.6.1.2.1.1.1.0
SNM043I Variable value type: 9
SNM044I Variable value: IBM , MVS TCP/IP V2R2
SNM049I SNMP Request 1001 End of response

snmpgrp mvs20 itsc sys
================================================
   SYSTEM Group for MVS20
Descr:    IBM , MVS TCP/IP V2R2
ObjectId: 1.3.6.1.4.1.2.2.1.2.4
UpTime:   0 days/0 hours/34 minutes/6 seconds
Contact:  LADY LESIA OR SIR PHILIPPE
Name:     MVS20.ITSC.RALEIGH.IBM.COM
Location: COMPUTER ROOM BLDG 657
Services: 76
================================================


The remote PING is implemented in TCP/IP for MVS. With this an SNMP monitor can send a remote PING via an SNMP GET request to the MVS TCP/IP SNMP agent. When the SNMP agent receives this SNMP GET request, it issues a PING command to the specified host and returns the round-trip time value as reply to the SNMP GET request.

4.14.12.2 AIX/ESA

AIX/ESA supports the SNMP agent functions and a limited set of client (manager) functions.

Its SNMP client (manager) provides the following functions:

Its SNMP agent provides the following functions:

For details, please refer to AIX/ESA Network Application Programmer's Guide Version 2 Release 1, AIX/ESA System and Network Administrator's Reference Version 2 Release 1 and AIX/ESA Network and Communications Administrator's Guide Version 2 Release 1.

4.14.12.3 OS/400

The SNMP agent support provided in the OS/400 consists of three parts:

4.14.12.4 AIX/6000

AIX/6000 supports both the SNMP client and agent functions.

Its SNMP client (manager) provides the following functions:

The SNMP agent of AIX/6000 provides the following functions:

The following screen output shows a sample session from an AIX/6000 host named rs60002 to another AIX/6000 host and an MVS host, using the community name ITSC: 

<rs60002># snmp_get rs60003 ITSC sysDescr
1.3.6.1.2.1.1.1.0 = IBM RISC System/6000
Machine Type: 0x0010 Processor id: 000105681000
The Base Operating System AIX version: 03.02.0000.0000
TCPIP Applications version: 03.02.0000.0000

<rs60002:/># snmpinfo -m get -h mvs20 -c ITSC -v sysContact
sysContact.0 = "LADY LESIA OR SIR PHILIPPE"


4.14.12.5 OS/2

TCP/IP for OS/2 provides both an SNMP client and an SNMP agent.

Its SNMP client (manager) provides the following functions:

Its SNMP agent provides the following functions:

The following screen output shows a sample session from an OS/2 host to another OS/2 host named ps2fred using the community name ITSC: 

[C:\]snmpgrp ps2fred ITSC sys
SYSTEM group
Descr  OS/2 SNMP AGENT version 1.2
ObjectId  1.3.6.1.4.1.2.2.1.2.2
UpTime  788974
Contact  Sir Fred
Name  ps2fred
Location  room BB117, Green Road, Raleigh
Services  76

[C:\]snmp get ps2fred ITSC sysdescr
Value of sysdescr is OS/2 SNMP AGENT version 1.2
[C:\]snmp next ps2fred ITSC sysdescr
Value of sysObjectID is 1.3.6.1.4.1.2.2.1.2.2


NetView for OS/2 delivers a comprehensive SNMP platform for management of systems and heterogeneous multivendor networks. This support allows NetView for OS/2 to manage any device having an SNMP agent.

NetView for OS/2 includes agents for management of OS/2, OS/2 LAN Server and OS/2 LAN Requester.

NetView for OS/2 V2.1 will include agents for OS/2 Communications Manager V1.1, and IBM DB2/2 V1.1.

4.14.12.6 DOS

TCP/IP for DOS Version 2.1.1 supports the SNMP agent function. It supports MIB-II data collection as well as provides unsolicited notifications of significant events to a SNMP monitor.

NetView for Windows is a new low-end SNMP management platform. This product provides fault, configuration and performance management capabilities for hubs, bridges, routers and switches. It also includes trouble ticketing, Telnet capabilities, TCP/IP communications, an integrated object-oriented database, and can operate in both the Ethernet and token-ring environments.

Table of Contents NetBIOS Services Protocol