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

来源： 作者： 出处：巧巧读书 2006-06-04 进入讨论组

• 关 键 词：
• internet
• networks
• express
• router
• server

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

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 RFC2119, 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 RFC862 [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

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 RFC792 [20]:

"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 RFC2571 [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, RFC1155 [14], STD 16, RFC1212 [15] and RFC1215 [16]. The
second version, called SMIv2, is described in STD 58, RFC2578
[3], STD 58, RFC2579 [4] and STD 58, RFC2580 [5].

o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC1157 [1]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC1901 [17] and
RFC1906 [18]. The third version of the message protocol is
called SNMPv3 and described in RFC1906 [18], RFC2572 [8] and
RFC2574 [10].

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

o A set of fundamental applications described in RFC2573 [9] and
the view-based access control mechanism described in RFC2575
[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.

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).

The first index element, pingCtlOwnerIndex, is of type
SnmpAdminString, a textual convention that allows for use of the
SNMPv3 View-Based Access Control Model (RFC2575 [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).

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 (RFC2575 [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

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

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

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 (RFC2575 [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.

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.

4.0 Definitions

4.1 DISMAN-PING-MIB

DISMAN-PING-MIB DEFINITIONS ::= BEGIN

IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Integer32,
Unsigned32, mib-2,
NOTIFICATION-TYPE, OBJECT-IDENTITY
FROM SNMPv2-SMI -- RFC2578
TEXTUAL-CONVENTION, RowStatus,
StorageType, DateAndTime, TruthValue
FROM SNMPv2-TC -- RFC2579
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF -- RFC2580
InterfaceIndexOrZero -- RFC2863
FROM IF-MIB
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- RFC2571
InetAddressType, InetAddress
FROM INET-ADDRESS-MIB; -- RFC2851

pingMIB MODULE-IDENTITY
LAST-UPDATED "200009210000Z" -- 21 September 2000
ORGANIZATION "IETF Distributed Management Working Group"
CONTACT-INFO

"Kenneth White

International Business Machines Corporation
Network Computing Software Division
Research Triangle Park, NC, USA

E-mail: wkenneth@us.ibm.com"
DESCRIPTION
"The Ping MIB (DISMAN-PING-MIB) provides the capability of
controlling the use of the ping function at a remote
host."

-- Revision history

REVISION "200009210000Z" -- 21 September 2000
DESCRIPTION
"Initial version, published as RFC2925."

::= { mib-2 80 }

-- Textual Conventions

OperationResponseStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Used to report the result of an operation:

responseReceived(1) - Operation completes successfully.
unknown(2) - Operation failed due to unknown error.
internalError(3) - An implementation detected an error
in its own processing that caused an operation
to fail.
requestTimedOut(4) - Operation failed to receive a
valid reply within the time limit imposed on it.
unknownDestinationAddress(5) - Invalid destination
address.
noRouteToTarget(6) - Could not find a route to target.
interfaceInactiveToTarget(7) - The interface to be
used in sending a probe is inactive without an
alternate route existing.
arpFailure(8) - Unable to resolve a target address to a
media specific address.
maxConcurrentLimitReached(9) - The maximum number of
concurrent active operations would have been exceeded
if the corresponding operation was allowed.
unableToResolveDnsName(10) - The DNS name specified was
unable to be mapped to an IP address.
invalidHostAddress(11) - The IP address for a host

has been determined to be invalid. Examples of this
are broadcast or multicast addresses."
SYNTAX INTEGER {
responseReceived(1),
unknown(2),
internalError(3),
requestTimedOut(4),
unknownDestinationAddress(5),
noRouteToTarget(6),
interfaceInactiveToTarget(7),
arpFailure(8),
maxConcurrentLimitReached(9),
unableToResolveDnsName(10),
invalidHostAddress(11)
}

-- Top level structure of the MIB

pingNotifications OBJECT IDENTIFIER ::= { pingMIB 0 }
pingObjects OBJECT IDENTIFIER ::= { pingMIB 1 }
pingConformance OBJECT IDENTIFIER ::= { pingMIB 2 }

-- The registration node (point) for ping implementation types

pingImplementationTypeDomains OBJECT IDENTIFIER ::= { pingMIB 3 }

pingIcmpEcho OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Indicates that an implementation is using the Internet
Control Message Protocol (ICMP) 'ECHO' facility."
::= { pingImplementationTypeDomains 1 }

pingUdpEcho OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Indicates that an implementation is using the UDP echo
port (7)."
REFERENCE
"RFC862, 'Echo Protocol'."
::= { pingImplementationTypeDomains 2 }

pingSnmpQuery OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Indicates that an implementation is an SNMP query to
calculate a round trip time."

::= { pingImplementationTypeDomains 3 }

pingTcpConnectionAttempt OBJECT-IDENTITY
STATUS current
DESCRIPTION
"Indicates that an implementation is attempting to
connect to a TCP port in order to calculate a round
trip time."
::= { pingImplementationTypeDomains 4 }

-- Simple Object Definitions

pingMaxConcurrentRequests OBJECT-TYPE
SYNTAX Unsigned32
UNITS "requests"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum number of concurrent active ping requests
that are allowed within an agent implementation. A value
of 0 for this object implies that there is no limit for
the number of concurrent active requests in effect."
DEFVAL { 10 }
::= { pingObjects 1 }

-- Ping Control Table

pingCtlTable OBJECT-TYPE
SYNTAX SEQUENCE OF PingCtlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines the ping Control Table for providing, via SNMP,
the capability of performing ping operations at
a remote host. The results of these operations are
stored in the pingResultsTable and the
pingProbeHistoryTable."
::= { pingObjects 2 }

pingCtlEntry OBJECT-TYPE
SYNTAX PingCtlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the pingCtlTable. The first index
element, pingCtlOwnerIndex, is of type SnmpAdminString,
a textual convention that allows for use of the SNMPv3

View-Based Access Control Model (RFC2575 [11], VACM)
and allows an management application to identify its
entries. The second index, pingCtlTestName (also an
SnmpAdminString), enables the same management
application to have multiple outstanding requests."
INDEX {
pingCtlOwnerIndex,
pingCtlTestName
}
::= { pingCtlTable 1 }

PingCtlEntry ::=
SEQUENCE {
pingCtlOwnerIndex SnmpAdminString,
pingCtlTestName SnmpAdminString,
pingCtlTargetAddressType InetAddressType,
pingCtlTargetAddress InetAddress,
pingCtlDataSize Unsigned32,
pingCtlTimeOut Unsigned32,
pingCtlProbeCount Unsigned32,
pingCtlAdminStatus INTEGER,
pingCtlDataFill OCTET STRING,
pingCtlFrequency Unsigned32,
pingCtlMaxRows Unsigned32,
pingCtlStorageType StorageType,
pingCtlTrapGeneration BITS,
pingCtlTrapProbeFailureFilter Unsigned32,
pingCtlTrapTestFailureFilter Unsigned32,
pingCtlType OBJECT IDENTIFIER,
pingCtlDescr SnmpAdminString,
pingCtlSourceAddressType InetAddressType,
pingCtlSourceAddress InetAddress,
pingCtlIfIndex InterfaceIndexOrZero,
pingCtlByPassRouteTable TruthValue,
pingCtlDSField Unsigned32,
pingCtlRowStatus RowStatus
}

pingCtlOwnerIndex OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"To facilitate the provisioning of access control by a
security administrator using the View-Based Access
Control Model (RFC2575, VACM) for tables in which
multiple users may need to independently create or
modify entries, the initial index is used as an 'owner

index'. Such an initial index has a syntax of
SnmpAdminString, and can thus be trivially mapped to a
securityName or groupName as defined in VACM, in
accordance with a security policy.

When used in conjunction with such a security policy all
entries in the table belonging to a particular user (or
group) will have the same value for this initial index.
For a given user's entries in a particular table, the
object identifiers for the information in these entries
will have the same subidentifiers (except for the 'column'
subidentifier) up to the end of the encoded owner index.
To configure VACM to permit access to this portion of the
table, one would create vacmViewTreeFamilyTable entries
with the value of vacmViewTreeFamilySubtree including
the owner index portion, and vacmViewTreeFamilyMask
'wildcarding' the column subidentifier. More elaborate
configurations are possible."
::= { pingCtlEntry 1 }

pingCtlTestName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The name of the ping test. This is locally unique, within
the scope of an pingCtlOwnerIndex."
::= { pingCtlEntry 2 }

pingCtlTargetAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the type of host address to be used at a remote
host for performing a ping operation."
DEFVAL { unknown }
::= { pingCtlEntry 3 }

pingCtlTargetAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the host address to be used at a remote host for
performing a ping operation. The host address type is
determined by the object value of corresponding
pingCtlTargetAddressType.

A value for this object MUST be set prior to transitioning
its corresponding pingCtlEntry to active(1) via
pingCtlRowStatus."
DEFVAL { ''H }
::= { pingCtlEntry 4 }

pingCtlDataSize OBJECT-TYPE
SYNTAX Unsigned32 (0..65507)
UNITS "octets"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the size of the data portion to be
transmitted in a ping operation in octets. A ping
request is usually an ICMP message encoded
into an IP packet. An IP packet has a maximum size
of 65535 octets. Subtracting the size of the ICMP
or UDP header (both 8 octets) and the size of the IP
header (20 octets) yields a maximum size of 65507
octets."
DEFVAL { 0 }
::= { pingCtlEntry 5 }

pingCtlTimeOut OBJECT-TYPE
SYNTAX Unsigned32 (1..60)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the time-out value, in seconds, for a
remote ping operation."
DEFVAL { 3 }
::= { pingCtlEntry 6 }

pingCtlProbeCount OBJECT-TYPE
SYNTAX Unsigned32 (1..15)
UNITS "probes"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the number of times to perform a ping
operation at a remote host."
DEFVAL { 1 }
::= { pingCtlEntry 7 }

pingCtlAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1), -- test should be started

disabled(2) -- test should be stopped
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Reflects the desired state that a pingCtlEntry should be
in:

enabled(1) - Attempt to activate the test as defined by
this pingCtlEntry.
disabled(2) - Deactivate the test as defined by this
pingCtlEntry.

Refer to the corresponding pingResultsOperStatus to
determine the operational state of the test defined by
this entry."
DEFVAL { disabled }
::= { pingCtlEntry 8 }

pingCtlDataFill OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..1024))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The content of this object is used together with the
corresponding pingCtlDataSize value to determine how to
fill the data portion of a probe packet. The option of
selecting a data fill pattern can be useful when links
are compressed or have data pattern sensitivities. The
contents of pingCtlDataFill should be repeated in a ping
packet when the size of the data portion of the ping
packet is greater than the size of pingCtlDataFill."
DEFVAL { '00'H }
::= { pingCtlEntry 9 }

pingCtlFrequency OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of seconds to wait before repeating a ping test
as defined by the value of the various objects in the
corresponding row.

A single ping test consists of a series of ping probes.
The number of probes is determined by the value of the
corresponding pingCtlProbeCount object. After a single

test completes the number of seconds as defined by the
value of pingCtlFrequency MUST elapse before the
next ping test is started.

A value of 0 for this object implies that the test
as defined by the corresponding entry will not be
repeated."
DEFVAL { 0 }
::= { pingCtlEntry 10 }

pingCtlMaxRows OBJECT-TYPE
SYNTAX Unsigned32
UNITS "rows"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum number of entries allowed in the
pingProbeHistoryTable. 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 this value.

Old entries are not removed when a new test is
started. Entries are added to the pingProbeHistoryTable
until pingCtlMaxRows is reached before entries begin to
be removed.

A value of 0 for this object disables creation of
pingProbeHistoryTable entries."
DEFVAL { 50 }
::= { pingCtlEntry 11 }

pingCtlStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row.
Conceptual rows having the value 'permanent' need not
allow write-access to any columnar objects in the row."
DEFVAL { nonVolatile }
::= { pingCtlEntry 12 }

pingCtlTrapGeneration OBJECT-TYPE
SYNTAX BITS {
probeFailure(0),
testFailure(1),

testCompletion(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object determines when and if
to generate a notification for this entry:

probeFailure(0) - Generate a pingProbeFailed
notification subject to the value of
pingCtlTrapProbeFailureFilter. The object
pingCtlTrapProbeFailureFilter can be used
to specify the number of successive probe failures
that are required before a pingProbeFailed
notification can be generated.
testFailure(1) - Generate a pingTestFailed
notification. In this instance the object
pingCtlTrapTestFailureFilter can be used to
determine the number of probe failures that
signal when a test fails.
testCompletion(2) - Generate a pingTestCompleted
notification.

The value of this object defaults to zero, indicating
that none of the above options have been selected."
::= { pingCtlEntry 13 }

pingCtlTrapProbeFailureFilter OBJECT-TYPE
SYNTAX Unsigned32 (0..15)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object is used to determine when
to generate a pingProbeFailed NOTIFICATION.

Setting pingCtlTrapGeneration
to probeFailure(0) implies that a pingProbeFailed
NOTIFICATION is generated only when the number of
successive probe failures as indicated by the
value of pingCtlTrapPrbefailureFilter fail within
a given ping test."
DEFVAL { 1 }
::= { pingCtlEntry 14 }

pingCtlTrapTestFailureFilter OBJECT-TYPE
SYNTAX Unsigned32 (0..15)
MAX-ACCESS read-create
STATUS current

DESCRIPTION
"The value of this object is used to determine when
to generate a pingTestFailed NOTIFICATION.

Setting pingCtlTrapGeneration to testFailure(1)
implies that a pingTestFailed NOTIFICATION is
generated only when the number of ping failures
within a test exceed the value of
pingCtlTrapTestFailureFilter."
DEFVAL { 1 }
::= { pingCtlEntry 15 }

pingCtlType OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object is used to either report or
select the implementation method to be used for
calculating a ping response time. The value of this
object MAY be selected from pingImplementationTypeDomains.

Additional implementation types SHOULD be allocated as
required by implementers of the DISMAN-PING-MIB under
their enterprise specific registration point and not
beneath pingImplementationTypeDomains."
DEFVAL { pingIcmpEcho }
::= { pingCtlEntry 16 }

pingCtlDescr OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The purpose of this object is to provide a
descriptive name of the remote ping test."
DEFVAL { '00'H }
::= { pingCtlEntry 17 }

pingCtlSourceAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the type of the source address,
pingCtlSourceAddress, to be used at a remote host
when performing a ping operation."
DEFVAL { ipv4 }

::= { pingCtlEntry 18 }

pingCtlSourceAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Use the specified IP address (which must be given
in numeric form, not as a hostname) as the source
address in outgoing probe packets. On hosts with
more than one IP address, this option can be used
to force the source address to be something other
than the primary IP address of the interface the
probe packet is sent on. If the IP address is not
one of this machine's interface addresses, an error
is returned and nothing is sent. A zero length
octet string value for this object disables source
address specification.

The address type (InetAddressType) that relates to
this object is specified by the corresponding value
of pingCtlSourceAddressType."
DEFVAL { ''H }
::= { pingCtlEntry 19 }

pingCtlIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Setting this object to an interface's ifIndex prior
to starting a remote ping operation directs
the ping probes to be transmitted over the
specified interface. A value of zero for this object
means that this option is not enabled."
DEFVAL { 0 }
::= { pingCtlEntry 20 }

pingCtlByPassRouteTable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The purpose of this object is to optionally enable
bypassing the route table. If enabled, the remote
host will bypass the normal routing tables and send
directly to a host on an attached network. If the
host is not on a directly-attached network, an

error is returned. This option can be used to perform
the ping operation to a local host through an
interface that has no route defined (e.g., after the
interface was dropped by routed)."
DEFVAL { false }
::= { pingCtlEntry 21 }

pingCtlDSField OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the value to store in the Differentiated
Services (DS) Field in the IP packet used to
encapsulate the ping probe. The DS Field is defined
as the Type of Service (TOS) octet in a IPv4 header
or as the Traffic Class octet in a IPv6 header.

The value of this object must be a decimal integer
in the range from 0 to 255. This option can be used
to determine what effect an explicit DS Field setting
has on a ping response. Not all values are legal or
meaningful. A value of 0 means that the function
represented by this option is not supported. DS Field
usage is often not supported by IP implementations and
not all values are supported. Refer to RFC2474 for
guidance on usage of this field."
REFERENCE
"Refer to RFC2474 for the definition of the
Differentiated Services Field and to RFC1812
Section 5.3.2 for Type of Service (TOS)."
DEFVAL { 0 }
::= { pingCtlEntry 22 }

pingCtlRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object allows entries to be created and deleted
in the pingCtlTable. Deletion of an entry in this
table results in all corresponding (same
pingCtlOwnerIndex and pingCtlTestName index values)
pingResultsTable and pingProbeHistoryTable entries
being deleted.

A value MUST be specified for pingCtlTargetAddress
prior to a transition to active(1) state being

accepted.

Activation of a remote ping operation is controlled
via pingCtlAdminStatus and not by changing
this object's value to active(1).

Transitions in and out of active(1) state are not
allowed while an entry's pingResultsOperStatus is
active(1) with the exception that deletion of
an entry in this table by setting its RowStatus
object to destroy(6) will stop an active
ping operation.

The operational state of a ping operation
can be determined by examination of its
pingResultsOperStatus object."
REFERENCE
"See definition of RowStatus in RFC2579, 'Textual
Conventions for SMIv2.'"
::= { pingCtlEntry 23 }

-- Ping Results Table

pingResultsTable OBJECT-TYPE
SYNTAX SEQUENCE OF PingResultsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines the Ping Results Table for providing
the capability of performing ping operations at
a remote host. The results of these operations are
stored in the pingResultsTable and the pingPastProbeTable.

An entry is added to the pingResultsTable when an
pingCtlEntry is started by successful transition
of its pingCtlAdminStatus object to enabled(1).
An entry is removed from the pingResultsTable when
its corresponding pingCtlEntry is deleted."
::= { pingObjects 3 }

pingResultsEntry OBJECT-TYPE
SYNTAX PingResultsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the pingResultsTable. The
pingResultsTable has the same indexing as the
pingCtlTable in order for a pingResultsEntry to

correspond to the pingCtlEntry that caused it to
be created."
INDEX {
pingCtlOwnerIndex,
pingCtlTestName
}
::= { pingResultsTable 1 }

PingResultsEntry ::=
SEQUENCE {
pingResultsOperStatus INTEGER,
pingResultsIpTargetAddressType InetAddressType,
pingResultsIpTargetAddress InetAddress,
pingResultsMinRtt Unsigned32,
pingResultsMaxRtt Unsigned32,
pingResultsAverageRtt Unsigned32,
pingResultsProbeResponses Unsigned32,
pingResultsSentProbes Unsigned32,
pingResultsRttSumOfSquares Unsigned32,
pingResultsLastGoodProbe DateAndTime
}

pingResultsOperStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1), -- test is in progress
disabled(2) -- test has stopped
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Reflects the operational state of a pingCtlEntry:
enabled(1) - Test is active.
disabled(2) - Test has stopped."
::= { pingResultsEntry 1 }

pingResultsIpTargetAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This objects indicates the type of address stored
in the corresponding pingResultsIpTargetAddress
object."
DEFVAL { unknown }
::= { pingResultsEntry 2 }

pingResultsIpTargetAddress OBJECT-TYPE
SYNTAX InetAddress

MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This objects reports the IP address associated
with a pingCtlTargetAddress value when the destination
address is specified as a DNS name. The value of
this object should be a zero length octet string
when a DNS name is not specified or when a
specified DNS name fails to resolve."
DEFVAL { ''H }
::= { pingResultsEntry 3 }

pingResultsMinRtt OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum ping round-trip-time (RTT) received. A value
of 0 for this object implies that no RTT has been received."
::= { pingResultsEntry 4 }

pingResultsMaxRtt OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum ping round-trip-time (RTT) received. A value
of 0 for this object implies that no RTT has been received."
::= { pingResultsEntry 5 }

pingResultsAverageRtt OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current average ping round-trip-time (RTT)."
::= { pingResultsEntry 6 }

pingResultsProbeResponses OBJECT-TYPE
SYNTAX Unsigned32
UNITS "responses"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of responses received for the corresponding

pingCtlEntry and pingResultsEntry. The value of this object
MUST be reported as 0 when no probe responses have been
received."
::= { pingResultsEntry 7 }

pingResultsSentProbes OBJECT-TYPE
SYNTAX Unsigned32
UNITS "probes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of this object reflects the number of probes sent
for the corresponding pingCtlEntry and pingResultsEntry.
The value of this object MUST be reported as 0 when no probes
have been sent."
::= { pingResultsEntry 8 }

pingResultsRttSumOfSquares OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the sum of the squares for all ping
responses received. Its purpose is to enable standard
deviation calculation. The value of this object MUST
be reported as 0 when no ping responses have been
received."
::= { pingResultsEntry 9 }

pingResultsLastGoodProbe OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Date and time when the last response was received for
a probe."
::= { pingResultsEntry 10 }

-- Ping Probe History Table

pingProbeHistoryTable OBJECT-TYPE
SYNTAX SEQUENCE OF PingProbeHistoryEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines a table for storing the results of a ping
operation. Entries in this table are limited by

the value of the corresponding pingCtlMaxRows
object.

An entry in this table is created when the result of
a ping probe is determined. The initial 2 instance
identifier index values identify the pingCtlEntry
that a probe result (pingProbeHistoryEntry) belongs
to. An entry is removed from this table when
its corresponding pingCtlEntry is deleted.

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."
::= { pingObjects 4 }

pingProbeHistoryEntry OBJECT-TYPE
SYNTAX PingProbeHistoryEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the pingProbeHistoryTable.
The first two index elements identify the
pingCtlEntry that a pingProbeHistoryEntry belongs
to. The third index element selects a single
probe result."
INDEX {
pingCtlOwnerIndex,
pingCtlTestName,
pingProbeHistoryIndex
}
::= { pingProbeHistoryTable 1 }

PingProbeHistoryEntry ::=
SEQUENCE {
pingProbeHistoryIndex Unsigned32,
pingProbeHistoryResponse Unsigned32,
pingProbeHistoryStatus OperationResponseStatus,
pingProbeHistoryLastRC Integer32,
pingProbeHistoryTime DateAndTime
}

pingProbeHistoryIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..'ffffffff'h)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION

"An entry in this table is created when the result of
a ping probe is determined. The initial 2 instance
identifier index values identify the pingCtlEntry
that a probe result (pingProbeHistoryEntry) belongs
to.

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)."
::= { pingProbeHistoryEntry 1 }

pingProbeHistoryResponse OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The amount of time measured in milliseconds from when
a probe was sent to when its response was received or
when it timed out. The value of this object is reported
as 0 when it is not possible to transmit a probe."
::= { pingProbeHistoryEntry 2 }

pingProbeHistoryStatus OBJECT-TYPE
SYNTAX OperationResponseStatus
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The result of a particular probe done by a remote host."
::= { pingProbeHistoryEntry 3 }

pingProbeHistoryLastRC OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The last implementation method specific reply code received.
If the ICMP Echo capability is being used then a successful
probe ends when an ICMP response is received that contains
the code ICMP_ECHOREPLY(0). The ICMP responses are defined
normally in the ip_icmp include file."
::= { pingProbeHistoryEntry 4 }

pingProbeHistoryTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current

DESCRIPTION
"Timestamp for when this probe result was determined."
::= { pingProbeHistoryEntry 5 }

-- Notification Definition section

pingProbeFailed NOTIFICATION-TYPE
OBJECTS {
pingCtlTargetAddressType,
pingCtlTargetAddress,
pingResultsOperStatus,
pingResultsIpTargetAddressType,
pingResultsIpTargetAddress,
pingResultsMinRtt,
pingResultsMaxRtt,
pingResultsAverageRtt,
pingResultsProbeResponses,
pingResultsSentProbes,
pingResultsRttSumOfSquares,
pingResultsLastGoodProbe
}
STATUS current
DESCRIPTION
"Generated when a probe failure is detected when the
corresponding pingCtlTrapGeneration object is set to
probeFailure(0) subject to the value of
pingCtlTrapProbeFailureFilter. The object
pingCtlTrapProbeFailureFilter can be used to specify the
number of successive probe failures that are required
before this notification can be generated."
::= { pingNotifications 1 }

pingTestFailed NOTIFICATION-TYPE
OBJECTS {
pingCtlTargetAddressType,
pingCtlTargetAddress,
pingResultsOperStatus,
pingResultsIpTargetAddressType,
pingResultsIpTargetAddress,
pingResultsMinRtt,
pingResultsMaxRtt,
pingResultsAverageRtt,
pingResultsProbeResponses,
pingResultsSentProbes,
pingResultsRttSumOfSquares,
pingResultsLastGoodProbe
}

STATUS current
DESCRIPTION
"Generated when a ping test is determined to have failed
when the corresponding pingCtlTrapGeneration object is
set to testFailure(1). In this instance
pingCtlTrapTestFailureFilter should specify the number of
probes in a test required to have failed in order to
consider the test as failed."
::= { pingNotifications 2 }

pingTestCompleted NOTIFICATION-TYPE
OBJECTS {
pingCtlTargetAddressType,
pingCtlTargetAddress,
pingResultsOperStatus,
pingResultsIpTargetAddressType,
pingResultsIpTargetAddress,
pingResultsMinRtt,
pingResultsMaxRtt,
pingResultsAverageRtt,
pingResultsProbeResponses,
pingResultsSentProbes,
pingResultsRttSumOfSquares,
pingResultsLastGoodProbe
}
STATUS current
DESCRIPTION
"Generated at the completion of a ping test when the
corresponding pingCtlTrapGeneration object is set to
testCompletion(4)."
::= { pingNotifications 3

文字：http://www.qqread.com/net-protocol/e766116081.html进入讨论组讨论。

【收藏此文】【大 中 小】【打印】【关闭】

较早的文章：RFC2926 - Conversion of LDAP Schemas to and from SLP Templates

较新的文章：RFC2924 - Accounting Attributes and Record Formats