tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2925


Pages: 77
Top     in Index     Prev     Next
 

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

Part 1 of 4, p. 1 to 12
None       Next RFC Part

Obsoleted by:    4560


Top       ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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 RFC Part