Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2925

Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations

Pages: 77
Obsoleted by:  4560
Part 1 of 4 – Pages 1 to 12
None   None   Next

ToP   noToC   RFC2925 - Page 1
Network Working Group                                           K. White
Request for Comments: 2925                                     IBM Corp.
Category: Standards Track                                 September 2000


    Definitions of Managed Objects for Remote Ping, Traceroute, and
                           Lookup Operations

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to an IP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability.

Table of Contents

1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2.0 The SNMP Network Management Framework . . . . . . . . . . . 4 3.0 Structure of the MIBs . . . . . . . . . . . . . . . . . . . 5 3.1 Ping MIB . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1 pingMaxConcurrentRequests . . . . . . . . . . . . . . . 6 3.1.2 pingCtlTable . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3 pingResultsTable . . . . . . . . . . . . . . . . . . . . 7 3.1.4 pingProbeHistoryTable . . . . . . . . . . . . . . . . . 7 3.2 Traceroute MIB . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1 traceRouteMaxConcurrentRequests . . . . . . . . . . . . 8 3.2.2 traceRouteCtlTable . . . . . . . . . . . . . . . . . . . 8 3.2.3 traceRouteResultsTable . . . . . . . . . . . . . . . . . 9
ToP   noToC   RFC2925 - Page 2
     3.2.4  traceRouteProbeHistoryTable   . . . . . . . . . . . . . .  9
     3.2.5  traceRouteHopsTable   . . . . . . . . . . . . . . . . . . 10
   3.3  Lookup MIB  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.3.1  lookupMaxConcurrentRequests and lookupPurgeTime   . . . . 10
     3.3.2  lookupCtlTable  . . . . . . . . . . . . . . . . . . . . . 10
     3.3.3  lookupResultsTable  . . . . . . . . . . . . . . . . . . . 11
   4.0  Definitions   . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.1  DISMAN-PING-MIB   . . . . . . . . . . . . . . . . . . . . . . 12
   4.2  DISMAN-TRACEROUTE-MIB   . . . . . . . . . . . . . . . . . . . 36
   4.3  DISMAN-NSLOOKUP-MIB   . . . . . . . . . . . . . . . . . . . . 63
   5.0  Security Considerations   . . . . . . . . . . . . . . . . . . 73
   6.0  Intellectual Property   . . . . . . . . . . . . . . . . . . . 74
   7.0  Acknowledgments   . . . . . . . . . . . . . . . . . . . . . . 74
   8.0  References  . . . . . . . . . . . . . . . . . . . . . . . . . 74
   9.0  Author's Address  . . . . . . . . . . . . . . . . . . . . . . 76
   10.0  Full Copyright Statement   . . . . . . . . . . . . . . . . . 77

1.0 Introduction

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [13]. This document is a product of the Distributed Management (DISMAN) Working Group. Its purpose is to define standards-based MIB modules for performing specific remote operations. The remote operations defined by this document consist of the ping, traceroute and lookup functions. Ping and traceroute are two very useful functions for managing networks. Ping is typically used to determine if a path exists between two hosts while traceroute shows an actual path. Ping is usually implemented using the Internet Control Message Protocol (ICMP) "ECHO" facility. It is also possible to implement a ping capability using alternate methods, some of which are: o Using the UDP echo port (7), if supported. This is defined by RFC 862 [2]. o Timing an SNMP query. o Timing a TCP connect attempt. In general, almost any request/response flow can be used to generate a round-trip time. Often many of the non-ICMP ECHO facility methods stand a better chance of yielding a good response (not timing out for
ToP   noToC   RFC2925 - Page 3
   example) since some routers don't honor Echo Requests (timeout
   situation) or they are handled at lower priority, hence possibly
   giving false indications of round trip times.

   It must be noted that almost any of the various methods used for
   generating a round-trip time can be considered a form of system
   attack when used excessively.  Sending a system requests too often
   can negatively effect its performance.  Attempting to connect to what
   is supposed to be an unused port can be very unpredictable.  There
   are tools that attempt to connect to a range of TCP ports to test
   that any receiving server can handle erroneous connection attempts.

   It also is important to the management application using a remote
   ping capability to know which method is being used.  Different
   methods will yield different response times since the protocol and
   resulting processing will be different.  It is RECOMMENDED that the
   ping capability defined within this memo be implemented using the
   ICMP Echo Facility.

   Traceroute is usually implemented by transmitting a series of probe
   packets with increasing time-to-live values.  A probe packet is a UDP
   datagram encapsulated into an IP packet.  Each hop in a path to the
   target (destination) host rejects the probe packet (probe's TTL too
   small) until its time-to-live value becomes large enough for the
   probe to be forwarded.  Each hop in a traceroute path returns an ICMP
   message that is used to discover the hop and to calculate a round
   trip time.  Some systems use ICMP probes (ICMP Echo request packets)
   instead of UDP ones to implement traceroute.  In both cases
   traceroute relies on the probes being rejected via an ICMP message to
   discover the hops taken along a path to the final destination.  Both
   probe types, UDP and ICMP, are encapsulated into an IP packet and
   thus have a TTL field that can be used to cause a path rejection.

   Implementations of the remote traceroute capability as defined within
   this memo SHOULD be done using UDP packets to a (hopefully) unused
   port.  ICMP probes (ICMP Echo Request packets) SHOULD NOT be used.
   Many PC implementations of traceroute use the ICMP probe method,
   which they should not, since this implementation method has been
   known to have a high probability of failure.  Intermediate hops
   become invisible when a router either refuses to send an ICMP TTL
   expired message in response to an incoming ICMP packet or simply
   tosses ICMP echo requests altogether.

   The behavior of some routers not to return a TTL expired message in
   response to an ICMP Echo request is due in part to the following text
   extracted from RFC 792 [20]:
ToP   noToC   RFC2925 - Page 4
   "The ICMP messages typically report errors in the processing of
   datagrams.  To avoid the infinite regress of messages about messages
   etc., no ICMP messages are sent about ICMP messages."

   Both ping and traceroute yield round-trip times measured in
   milliseconds.  These times can be used as a rough approximation for
   network transit time.

   The Lookup operation enables the equivalent of either a
   gethostbyname() or a gethostbyaddr() call being performed at a remote
   host.  The Lookup gethostbyname() capability can be used to determine
   the symbolic name of a hop in a traceroute path.

   Consider the following diagram:

+--------------------------------------------------------------------+
|                                                                    |
|           Remote ping, traceroute,  Actual ping, traceroute,       |
|       +-----+or Lookup op.    +------+or Lookup op.    +------+    |
|       |Local|---------------->|Remote|---------------->|Target|    |
|       | Host|                 | Host |                 | Host |    |
|       +-----+                 +------+                 +------+    |
|                                                                    |
|                                                                    |
+--------------------------------------------------------------------+

   A local host is the host from which the remote ping, traceroute, or
   Lookup operation is initiated using an SNMP request.  The remote host
   is a host where the MIBs defined by this memo are implemented that
   receives the remote operation via SNMP and performs the actual ping,
   traceroute, or lookup function.

2.0 The SNMP Network Management Framework

The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [7]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [14], STD 16, RFC 1212 [15] and RFC 1215 [16]. The second version, called SMIv2, is described in STD 58, RFC 2578 [3], STD 58, RFC 2579 [4] and STD 58, RFC 2580 [5].
ToP   noToC   RFC2925 - Page 5
   o   Message protocols for transferring management information.  The
       first version of the SNMP message protocol is called SNMPv1 and
       described in STD 15, RFC 1157 [1].  A second version of the SNMP
       message protocol, which is not an Internet standards track
       protocol, is called SNMPv2c and described in RFC 1901 [17] and
       RFC 1906 [18].  The third version of the message protocol is
       called SNMPv3 and described in RFC 1906 [18], RFC 2572 [8] and
       RFC 2574 [10].

   o   Protocol operations for accessing management information.  The
       first set of protocol operations and associated PDU formats is
       described in STD 15, RFC 1157 [1].  A second set of protocol
       operations and associated PDU formats is described in RFC 1905
       [6].

   o   A set of fundamental applications described in RFC 2573 [9] and
       the view-based access control mechanism described in RFC 2575
       [11].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies MIB modules that are compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations.  The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64).  Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process.  However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

3.0 Structure of the MIBs

This document defines three MIB modules: o DISMAN-PING-MIB Defines a ping MIB. o DISMAN-TRACEROUTE-MIB Defines a traceroute MIB.
ToP   noToC   RFC2925 - Page 6
   o   DISMAN-NSLOOKUP-MIB

       Provides access to the resolver gethostbyname() and
       gethostbyaddr() functions at a remote host.

   The ping and traceroute MIBs are structured to allow creation of ping
   or traceroute tests that can be set up to periodically issue a series
   of operations and generate NOTIFICATIONs to report on test results.
   Many network administrators have in the past written UNIX shell
   scripts or command batch files to operate in fashion similar to the
   functionality provided by the ping and traceroute MIBs defined within
   this memo.  The intent of this document is to acknowledge the
   importance of these functions and to provide a standards-based
   solution.

3.1 Ping MIB

The DISMAN-PING-MIB consists of the following components: o pingMaxConcurrentRequests o pingCtlTable o pingResultsTable o pingProbeHistoryTable

3.1.1 pingMaxConcurrentRequests

The object pingMaxConcurrentRequests enables control of the maximum number of concurrent active requests that an agent implementation supports. It is permissible for an agent either to limit the maximum upper range allowed for this object or to implement this object as read-only with an implementation limit expressed as its value.

3.1.2 pingCtlTable

A remote ping test is started by setting pingCtlAdminStatus to enabled(1). The corresponding pingCtlEntry MUST have been created and its pingCtlRowStatus set to active(1) prior to starting the test. A single SNMP PDU can be used to create and start a remote ping test. Within the PDU, pingCtlTargetAddress should be set to the target host's address (pingCtlTargetAddressType will default to ipv4(1)), pingCtlAdminStatus to enabled(1), and pingCtlRowStatus to createAndGo(4).
ToP   noToC   RFC2925 - Page 7
   The first index element, pingCtlOwnerIndex, is of type
   SnmpAdminString, a textual convention that allows for use of the
   SNMPv3 View-Based Access Control Model (RFC 2575 [11], VACM) and
   allows a management application to identify its entries.  The send
   index, pingCtlTestName (also an SnmpAdminString), enables the same
   management application to have multiple requests outstanding.

   Using the maximum value for the parameters defined within a pingEntry
   can result in a single remote ping test taking at most 15 minutes
   (pingCtlTimeOut times pingCtlProbeCount) plus whatever time it takes
   to send the ping request and receive its response over the network
   from the target host.  Use of the defaults for pingCtlTimeOut and
   pingCtlProbeCount yields a maximum of 3 seconds to perform a "normal"
   ping test.

   A management application can delete an active remote ping request by
   setting the corresponding pingCtlRowStatus object to destroy(6).

   The contents of the pingCtlTable is preserved across reIPLs (Initial
   Program Loads) of its agent according the values of each of the
   pingCtlStorageType objects.

3.1.3 pingResultsTable

An entry in the pingResultsTable is created for a corresponding pingCtlEntry once the test defined by this entry is started.

3.1.4 pingProbeHistoryTable

The results of past ping probes can be stored in this table on a per pingCtlEntry basis. This table is initially indexed by pingCtlOwnerIndex and pingCtlTestName in order for the results of a probe to relate to the pingCtlEntry that caused it. The maximum number of entries stored in this table per pingCtlEntry is determined by the value of pingCtlMaxRows. An implementation of this MIB will remove the oldest entry in the pingProbeHistoryTable to allow the addition of an new entry once the number of rows in the pingProbeHistoryTable reaches the value specified by pingCtlMaxRows. An implementation MUST start assigning pingProbeHistoryIndex values at 1 and wrap after exceeding the maximum possible value as defined by the limit of this object ('ffffffff'h).
ToP   noToC   RFC2925 - Page 8

3.2 Traceroute MIB

The DISMAN-TRACEROUTE-MIB consists of the following components: o traceRouteMaxConcurrentRequests o traceRouteCtlTable o traceRouteResultsTable o traceRouteProbeHistoryTable o traceRouteHopsTable

3.2.1 traceRouteMaxConcurrentRequests

The object traceRouteMaxConcurrentRequests enables control of the maximum number of concurrent active requests that an agent implementation supports. It is permissible for an agent either to limit the maximum upper range allowed for this object or to implement this object as read-only with an implementation limit expressed as its value.

3.2.2 traceRouteCtlTable

A remote traceroute test is started by setting traceRouteCtlAdminStatus to enabled(1). The corresponding traceRouteCtlEntry MUST have been created and its traceRouteCtlRowStatus set to active(1) prior to starting the test. A single SNMP PDU can be used to create and start a remote traceroute test. Within the PDU, traceRouteCtlTargetAddress should be set to the target host's address (traceRouteCtlTargetAddressType will default to ipv4(1)), traceRouteCtlAdminStatus to enabled(1), and traceRouteCtlRowStatus to createAndGo(4). The first index element, traceRouteCtlOwnerIndex, is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-Based Access Control Model (RFC 2575 [11], VACM) and allows a management application to identify its entries. The second index, traceRouteCtlTestName (also an SnmpAdminString), enables the same management application to have multiple requests outstanding. Traceroute has a much longer theoretical maximum time for completion than ping. Basically 42 hours and 30 minutes (the product of traceRouteCtlTimeOut, traceRouteCtlProbesPerHop, and traceRouteCtlMaxTtl) plus some network transit time! Use of the defaults defined within an traceRouteCtlEntry yields a maximum of 4 minutes and 30 seconds for a default traceroute operation. Clearly
ToP   noToC   RFC2925 - Page 9
   42 plus hours is too long to wait for a traceroute operation to
   complete.

   The maximum TTL value in effect for traceroute determines how long
   the traceroute function will keep increasing the TTL value in the
   probe it transmits hoping to reach the target host.  The function
   ends whenever the maximum TTL is exceeded or the target host is
   reached.  The object traceRouteCtlMaxFailures was created in order to
   impose a throttle for how long traceroute continues to increase the
   TTL field in a probe without receiving any kind of response
   (timeouts).  It is RECOMMENDED that agent implementations impose a
   time limit for how long it allows a traceroute operation to take
   relative to how the function is implemented.  For example, an
   implementation that can't process multiple traceroute operations at
   the same time SHOULD impose a shorter maximum allowed time period.

   A management application can delete an active remote traceroute
   request by setting the corresponding traceRouteCtlRowStatus object to
   destroy(6).

   The contents of the traceRouteCtlTable is preserved across reIPLs
   (Initial Program Loads) of its agent according to the values of each
   of the traceRouteCtlStorageType objects.

3.2.3 traceRouteResultsTable

An entry in the traceRouteResultsTable is created upon determining the results of a specific traceroute operation. Entries in this table relate back to the traceRouteCtlEntry that caused the corresponding traceroute operation to occur. The objects traceRouteResultsCurHopCount and traceRouteResultsCurProbeCount can be examined to determine how far the current remote traceroute operation has reached.

3.2.4 traceRouteProbeHistoryTable

The results of past traceroute probes can be stored in this table on a per traceRouteCtlEntry basis. This table is initially indexed by traceRouteCtlOwnerIndex and traceRouteCtlTestName in order for the results of a probe to relate to the traceRouteCtlEntry that caused it. The number of entries stored in this table per traceRouteCtlEntry is determined by the value of traceRouteCtlMaxRows. An implementation of this MIB will remove the oldest entry in the traceRouteProbeHistoryTable to allow the addition of an new entry once the number of rows in the traceRouteProbeHistoryTable reaches the value of traceRouteCtlMaxRows. An implementation MUST start
ToP   noToC   RFC2925 - Page 10
   assigning traceRouteProbeHistoryIndex values at 1 and wrap after
   exceeding the maximum possible value as defined by the limit of this
   object ('ffffffff'h).

3.2.5 traceRouteHopsTable

The current traceroute path can be stored in this table on a per traceRouteCtlEntry basis. This table is initially indexed by traceRouteCtlOwnerIndex and traceRouteCtlTestName in order for a traceroute path to relate to the traceRouteCtlEntry that caused it. A third index, traceRouteHopsHopIndex, enables keeping one traceRouteHopsEntry per traceroute hop. Creation of traceRouteHopsTable entries is enabled by setting the corresponding traceRouteCtlCreateHopsEntries object to true(1).

3.3 Lookup MIB

The DISMAN-NSLOOKUP-MIB consists of the following components: o lookupMaxConcurrentRequests, and lookupPurgeTime o lookupCtlTable o lookupResultsTable

3.3.1 lookupMaxConcurrentRequests and lookupPurgeTime

The object lookupMaxConcurrentRequests enables control of the maximum number of concurrent active requests that an agent implementation is structured to support. It is permissible for an agent either to limit the maximum upper range allowed for this object or to implement this object as read-only with an implementation limit expressed as its value. The object lookupPurgeTime provides a method for entries in the lookupCtlTable and lookupResultsTable to be automatically deleted after the corresponding operation completes.

3.3.2 lookupCtlTable

A remote lookup operation is initiated by performing an SNMP SET request on lookupCtlRowStatus. A single SNMP PDU can be used to create and start a remote lookup operation. Within the PDU, lookupCtlTargetAddress should be set to the entity to be resolved (lookupCtlTargetAddressType will default to ipv4(1)) and lookupCtlRowStatus to createAndGo(4). The object lookupCtlOperStatus
ToP   noToC   RFC2925 - Page 11
   can be examined to determine the state of an lookup operation.  A
   management application can delete an active remote lookup request by
   setting the corresponding lookupCtlRowStatus object to destroy(6).

   An lookupCtlEntry is initially indexed by lookupCtlOwnerIndex, which
   is of type SnmpAdminString, a textual convention that allows for use
   of the SNMPv3 View-Based Access Control Model (RFC 2575 [11], VACM)
   and also allows for a management application to identify its entries.
   The lookupCtlOwnerIndex portion of the index is then followed by
   lookupCtlOperationName.  The lookupCtlOperationName index enables the
   same lookupCtlOwnerIndex entity to have multiple outstanding
   requests.

   The value of lookupCtlTargetAddressType determines which lookup
   function to perform.  Specification of dns(16) as the value of this
   index implies that the gethostbyname function should be performed to
   determine the numeric addresses associated with a symbolic name via
   lookupResultsTable entries.  Use of a value of either ipv4(1) or
   ipv6(2) implies that the gethostbyaddr function should be performed
   to determine the symbolic name(s) associated with a numeric address
   at a remote host.

3.3.3 lookupResultsTable

The lookupResultsTable is used to store the results of lookup operations. The lookupResultsTable is initially indexed by the same index elements that the lookupCtlTable contains (lookupCtlOwnerIndex and lookupCtlOperationName) but has a third index element, lookupResultsIndex (Unsigned32 textual convention), in order to associate multiple results with the same lookupCtlEntry. Both the gethostbyname and gethostbyaddr functions typically return a pointer to a hostent structure after being called. The hostent structure is defined as: struct hostent { char *h_name; /* official host name */ char *h_aliases[]; /* list of other aliases */ int h_addrtype; /* host address type */ int h_length; /* length of host address */ char **h_addr_list; /* list of address for host */ }; The hostent structure is listed here in order to address the fact that a remote host can be multi-homed and can have multiple symbolic (DNS) names. It is not intended to imply that implementations of the DISMAN-LOOKUP-MIB are limited to systems where the hostent structure is supported.
ToP   noToC   RFC2925 - Page 12
   The gethostbyaddr function is called with a host address as its
   parameter and is used primarily to determine a symbolic name to
   associate with the host address.  Entries in the lookupResultsTable
   MUST be made for each host name returned.  The official host name
   MUST be assigned a lookupResultsIndex of 1.

   The gethostbyname function is called with a symbolic host name and is
   used primarily to retrieve a host address.  Normally, the first
   h_addr_list host address is considered to be the primary address and
   as such is associated with the symbolic name passed on the call.

   Entries MUST be stored in the lookupResultsTable in the order that
   they are retrieved.  Values assigned to lookupResultsIndex MUST start
   at 1 and increase in order.

   An implementation SHOULD NOT retain SNMP-created entries in the
   lookupTable across reIPLs (Initial Program Loads) of its agent, since
   management applications need to see consistent behavior with respect
   to the persistence of the table entries that they create.



(page 12 continued on part 2)

Next Section