[Contents]
[Prev]
[Next]
[Index]
[Report an Error]
Response Time Reporter
The Response Time Reporter
(RTR) feature enables you to monitor network performance and resources
by measuring response times and the availability of your network devices.
RTR configuration is associated with a specific
virtual router, distinct from any other virtual router.
Configuration Tasks
To configure RTR:
- Configure the probe type—an echo probe or a path
echo probe.
- (Optional) Configure probe characteristics:
- frequency
- hops-of-statistics-kept (path echo)
- max-response-failure (path echo)
- operations-per-hop (path echo)
- owner
- receive-interface
- request-data-size
- samples-of-history-kept
- tag
- timeout (echo)
- tos
 |
Note:
You cannot set any of these characteristics until you have set
the probe type. The default values of these characteristics depend
on the type of the entry.
|
- (Optional) Set reaction conditions.
- Schedule the probe.
- (Optional) Capture statistics and collect error information.
- (Optional) Collect history.
Configuring the Probe Type
To begin configuring RTR, enter RTR Configuration
mode and configure the probe type—either an echo probe or a path echo probe.
rtr
- Use to configure an RTR probe and to enter RTR Configuration
mode.
- Example
- host1(config)#rtr 1
- Use the no version to delete
all configuration information for an RTR probe.
- See rtr
type
- Use to set an echo or path echo probe:
-
echo—Limited to end-to-end
RTR operations; corresponds to SNMP ping
-
pathEcho—Finds a path
to the destination and echoes each device in the path; corresponds
to SNMP traceroute
- You must specify this value before any other.
- If you change the type for an existing RTR entry, all
values are reset, including the administrative status. There is no
default value.
- More than one RTR entry can become active, provided each
entry’s target address is unique.
- If you configure multiple RTR entries to use the same
target address, you must issue the receive-interface command to specify the interface on which the RTR probe expects
to receive responses. (For information, see Setting the Receiving Interface.)
- If you use a target address already configured for another
RTR entry that is active, the test will not run if both entries are
in the same virtual router. If they are in distinct virtual routers,
however, there is no restriction.
- Example
- host1(config-rtr)#type echo protocol ipIcmpEcho
10.10.0.9
- Use the no version to remove
the type configured for the probe.
- See type
Configuring Optional Characteristics
In addition to configuring the probe’s type,
you can configure the probe characteristics presented in Table 8.
Table 8: Probe Characteristics
|
Characteristic
|
Description
|
|
frequency
|
Time between tests (in seconds)
|
|
hops-of-statistics-kept
|
Hops per path for which statistics are gathered
|
|
max-response-failure
|
Maximum number of consecutive failures
|
|
operations-per-hop
|
Number of probes per hop
|
|
owner
|
Owner of the probe
|
|
receive-interface
|
Interface on which the probe expects to receive responses
|
|
request-data-size
|
Request’s payload size
|
|
samples-of-history-kept
|
Maximum number of history samples
|
|
tag
|
User-defined tag
|
|
timeout
|
Probe timeout (in milliseconds)
|
|
tos
|
A value for the TOS byte
|
frequency
- Use to set the rate (in seconds) that the RTR probe
uses to start a response time operation.
- Example
- host1(config-rtr)#frequency 90
- Use the no version to return
to the default value, 60 seconds.
- See frequency
operations-per-hop
- Use to set the number of RTR probe operations sent to
a given hop.
- You can apply this option only to a pathEcho type.
- Example
- host1(config-rtr)#operations-per-hop 5
- Use the no version to return
to the default, 3.
- See operations-per-hop
owner
- Use to identify the owner of the probe.
- If the SNMP agent is the owner of the probe, the owner’s
name can begin with agent.
- Example
- host1(config-rtr)#owner 192.10.27.6 rtc.boston.com
555.1212
- Use the no version to return
to the default, no owner.
- See owner
request-data-size
- Use to set the protocol data size, in bytes, in the
request packet.
- Example
- host1(config-rtr)#request-data-size 20
- Use the no version to return
to the default value, 1 byte.
- See request-data-size
tag
- Use to set an identifier for the probe.
- Example
- host1(config-rtr)#tag westford
- Use the no version to return
to the default, no tag.
- See tag
timeout
- Use to set the time (in milliseconds) that the probe
waits for a response.
- You can apply this option only to an echo type.
- Do not set the value for timeout to more than the value
set for frequency. If you do, the timeout value is ignored.
- If you set the timeout to 0, no timeout is set.
- Example
- host1(config-rtr)#timeout 3000
- Use the no version to return
to the default value, 5000 milliseconds.
- See timeout
tos
- Use to set the type of service (ToS) byte in the probe’s
IP header.
- Example
- host1(config-rtr)#tos 16
- Use the no version to return
to the default value, 0. The default applies to both the echo and
pathEcho types.
- See tos
Capturing Statistics
The primary objective of RTR is to collect statistics
and information about network performance. You can control the number
and type of statistics collected.
hops-of-statistics-kept
- Use to set the number of hops per path for which statistics
are collected.
- When the number of hops reaches the specified number (that
is, size), no additional statistical information
about the path is stored.
- This option applies only to pathEcho entries.
- To turn off this feature, set the value to 0.
- Example
- host1(config-rtr)#hops-of-statistics-kept
5
- Use the no version to set the
default, 16 hops.
- See hops-of-statistics-kept
max-response-failure
- Use to set the maximum number of consecutive failures
to respond to a probe’s request.
- When the maximum number is reached, the test stops.
- This option applies only to pathEcho entries.
- To turn off this feature, set the value to 0.
- Example
- host1(config-rtr)#max-response-failure 2
- Use the no version to set the
default, 5 consecutive failures.
- See max-response-failure
Collecting
History
RTR can collect data samples for a given probe.
These samples are referred to as history data. When RTR collects history,
it refers to tests. A test is the lifetime of a probe operation.
samples-of-history-kept
- Use to set the maximum number of entries in the history
table for each RTR probe.
- This command enables you to control the number of samples
saved in the history table.
- If you set the number of samples to 0, no samples are
kept.
- Because collecting history increases memory usage, do
so only when there is a problem in your network.
- Example
- host1(config-rtr)#samples-of-history-kept
5
- Use the no version to set the
default, 16 hops for pathEcho type, 1 hop for echo type.
- See samples-of-history-kept
Setting the Receiving Interface
When
you configure multiple RTR entries to use the same target address,
you must issue the receive-interface command
to set the interface on which the probe expects to receive responses.
This action enables the router to map incoming responses to the proper
RTR entry, even when multiple RTR entries have the same target address.
receive-interface
- Use to specify
the interface on which the RTR probe expects to receive
responses.
- You must set this attribute when multiple RTR entries
are configured to use the same target address.
- Example
- host1(config-rtr)#receive-interface fastEthernet
3/0
- Use the no version to restore
the default value, which is to receive a response on any interface.
- See receive-interface
Setting Reaction Conditions
You can set the RTR probe to react to events that
take place and to send notifications about these events.
 |
Note:
The only no version for all the rtr reaction-configuration commands is no rtr reaction-configuration rtrIndex. Use the no version to clear all traps. This works for all the options.
|
rtr reaction-configuration action-type
- Use to specify the type of actions to occur depending
on the events controlled by RTR.
- The default is to take the traps of enabled events.
- Example
- host1(config)#rtr reaction-configuration 1
action-type trapOnly
- There is no no version.
- See rtr reaction-configuration action-type
rtr reaction-configuration operation-failure
- Use to enable the operation-failure reaction.
- The operation-failure event is triggered when a number
of consecutive probe operations are not received or when they are
received after a timeout.
- Example
- host1(config)#rtr reaction-configuration 1
operation-failure 3
- There is no no version.
- See rtr reaction-configuration operation-failure
rtr reaction-configuration path-change
- Use to enable the path-change reaction.
- The path-change event is triggered when a change is detected
in the hop table. At most, there can be one such event per test.
- Example
- host1(config)#rtr reaction-configuration 1
path-change
- There is no no version.
- See rtr reaction-configuration path-change
rtr reaction-configuration test-completion
- Use to enable test-completion reaction.
- The test-completion event is triggered when a test is
completed successfully.
- For echo, a successful test means that all probes were
sent.
- For pathEcho, a successful test means that the destination
was reached at least once.
- At most, there can be one such event per test.
- Example
- host1(config)#rtr reaction-configuration 1
test-completion
- There is no no version.
- See rtr reaction-configuration test-completion
rtr reaction-configuration test-failure
- Use to enable test-failure reaction.
- The test-failure event is triggered when a test fails.
Failure is determined in the following ways:
- If Echo, this event is triggered after testFailureValue
probes are either not received or are received after a timeout.
- If PathEcho, this event is triggered when the test ends
and no responses are received from the destination.
- At most, there can be one such event per test.
- Example
- host1(config)#rtr reaction-configuration 1
test-failure
- There is no no version.
- See rtr reaction-configuration test-failure
Scheduling the Probe
When you have configured the RTR probe, you must
schedule the operation to begin collecting statistics and other information
about problems that may arise.
rtr schedule
- Use to create an RTR schedule.
- Example
- host1(config)#rtr schedule 5
- Use the no version to stop
the test. The no version stops the probe
operation by putting it in the pending state. The no version also resets the restart-time
attribute and the life attribute.
- See rtr schedule
rtr schedule life
- Use to schedule the test’s length.
- Life is a value that depends on the
type of the RTR entry; it is not a length of time.
- If the type is echo, life relates to the number of probes
sent until a test finishes.
- If the type is pathEcho, life relates to the maximum number
of hops used by the traceRoute trap.
- Example
- host1(config)#rtr schedule 5 life 1800
- Use the no version to stop
the test. The no version stops the probe
operation by putting it in the pending state. The no version also resets the life attribute.
- See rtr schedule life
rtr schedule restart-time
- Use to specify a restart time, in seconds, after which
a test is restarted.
- Example
- host1(config)#rtr schedule 5 restart-time
15
- Use the no version to stop
the test. The no version stops the probe
operation by putting it in the pending state. The no version also resets the restart-time attribute.
- See rtr schedule restart-time
rtr schedule start-time
- Use to schedule a test’s starting time (now or pending).
- Example
- host1(config)#rtr schedule 5 start-time now
- Use the no version to stop
the test. The no version stops the probe
operation by putting it in the default state, pending.
- See rtr schedule start-time
Shutting Down the Probe
You can shut down the RTR probe operation.
rtr reset
- Use to shut down the RTR, stop all probe operations, and
clear the RTR configuration for the given virtual router.
 |
Note:
We recommend that you use this command only in extremely serious
situations, such as problems with the configurations of a number of
probe operations.
|
- Example
- host1(config)#rtr reset
- Use the no version to negate
the reset operation.
- See rtr reset
Monitoring RTR
You can monitor RTR by displaying status and configuration
information.
show rtr application
show rtr collection-statistics
- Use to display statistical information for a particular
probe operation or for all operations.
- Field descriptions
- rtrIndex—Index number of the RTR probe
- operationsSent—Number of probe operations sent
- operationsRecvd—Number of probe operations received
- lastGoodResponse—Time when last valid probe operation
was received
- operStatus—Operational status of the probe: enabled,
disabled
- minRtt—Minimum round-trip time in milliseconds
- maxRtt—Maximum round-trip time in milliseconds
- avgRtt—Average round-trip time in milliseconds
- rttSumSqr—Sum of the square of all round-trip times
in milliseconds
- testAttempts—Number of times the test ran
- testSuccesses—Number of times the test ran successfully
- currentHop—Current hop (TTL) used in the test
- currentOperation—Current probe operation index sent
to the hop
- Example
host1#show rtr collection-statistics
Echo Entries:
rtrIndex operationsSent operationsRcvd lastGoodResponse
---------- -------------- -------------- ----------------
1 5208 5187 08/30/2000 05:09
rtrIndex operStatus minRtt maxRtt avgRtt rttSumSqr
---------- ---------- ------ ------ ------ ---------
1 enabled 0 1785 3 7109208
PathEcho Entries:
rtrIndex testAttempts testSuccesses lastGoodResponse
---------- ------------ ------------- ----------------
2 156 156 08/30/2000 05:09
rtrIndex operStatus currentHop currentOperation
---------- ---------- ---------- ----------------
2 enabled 2 4
- See show rtr collection-statistics
show rtr configuration
- Use to display the configuration for a particular probe
or for all probes.
- Field descriptions
- rtrIndex—Index number of the RTR probe
- type—Probe type: echo, pathEcho
- targetAddress—Address of the probe’s target
- reqSize—Protocol data size in the request packet
- freq—Rate in seconds that the RTR probe uses to
start a response time operation
- life—Length of the test
- source—Interface from which the probe is sent
- restartTime—Restart time of the test in seconds
- owner—Owner of the probe
- samples—Maximum number of entries saved in the history
table for this RTR probe
- admin—Administrative status of the probe: enabled,
disabled
- tos—Setting of the type of service (ToS) byte in
the probe’s IP header
- reactionConfiguration—RTR reactions that are configured
for the probe
- receiveInterface—Type and specifier of the interface
on which the probe expects to receive responses; this field is blank
if the optional receive-interface characteristic
is not configured
- operFail—Operation failure event is triggered when
this number of consecutive probe operations is not received or when
the operations are received after a timeout
- testFail—Test failure event is triggered when this
number of probe operations is not received or when the operations
are received after a timeout
- timeout—Time in milliseconds that the probe waits
for a response
- tag—Identifier configured for the probe
- operPerHop—Number of RTR probe operations sent to
a given hop
- maxFail—Maximum number of consecutive failures to
respond to a probe’s request. When the maximum number is reached,
the test stops. Applies only to pathEcho entries.
- hopKpt—Number of hops per path for which statistics
are collected. When this number is reached, no additional statistical
information about the path is stored. Applies only to pathEcho entries.
- Example
host1#show rtr configuration
rtrIndex type targetAddress reqSize freq life
------- -------- ------------ ------ ------ -----
1 echo 10.5.0.200 1 1 20
2 pathEcho 10.5.0.11 1 1 30
rtrIndex source restartTime owner
---------- ------------------ ----------- ----------
1 fastEthernet0/0 10
2 60
rtrIndex samples admin tos reactionConfiguration
---------- ------- -------- --- ------------------------
1 5 enabled 0
2 5 enabled 0
rtrIndex receiveInterface
---------- ----------------
1 fastEthernet0/0
rtrIndex operFail testFail timeout tag
---------- -------- -------- ------- ------
1 1 1 10000
rtrIndex operPerHop maxFail hopKpt tag
---------- ---------- ------- ------ ------
2 5 3 16
- See show rtr configuration
show rtr history
- Use to display history (data samples) for a particular
probe or for all probes.
- Field descriptions
- rtrIndex—Index number of the RTR probe
- operation—Index number of the probe operation
- rtt—Round-trip time in milliseconds
- statusDescription
- concurrentLimitFail—Target already being used by
another rtrIndex
- ifInactiveToTarget—Interface used to reach target
is not operational
- invalidHostAddress—Target address is not supported
- noRouteToTarget—Target address is not reachable
- responseReceived—Probe operation replied by target
- requestTimedOut—Probe operation not replied to by
target or reply received after timeout
- unknownDestAddress—Target address is invalid
- unableToResolveName—Target address could not be
looked up
- timeStamp—Date and time when the RTR entry was created
- test—Index number of the pathEcho test
- hop—Index number of the hop count
- operation—Index number of the probe operation
- address—Address of router at the hop
- Example
host1#show rtr history
Echo Entries:
rtrIndex operation rtt statusDescription timeStamp
-------- --------- --- ----------------- ---------
1 5476 0 responseReceived 08/30/2000 05:17
1 5477 0 responseReceived 08/30/2000 05:17
1 5478 0 responseReceived 08/30/2000 05:17
1 5479 0 responseReceived 08/30/2000 05:17
1 5480 0 responseReceived 08/30/2000 05:17
PathEcho Entries:
rtrIndex test hop operation rtt statusDescription
---------- ------ ---- --------- ------ -----------------
2 165 3 5 0 responseReceived
2 165 3 1 0 responseReceived
2 165 3 2 0 responseReceived
2 165 3 3 0 responseReceived
2 165 3 4 0 responseReceived
rtrIndex test hop operation timeStamp address
---------- ------ ---- --------- ---------------- --------
2 165 3 5 08/30/2000 20:39 10.5.0.11
2 165 3 1 08/30/2000 20:40 10.5.0.11
2 165 3 2 08/30/2000 20:40 10.5.0.11
2 165 3 3 08/30/2000 20:40 10.5.0.11
2 165 3 4 08/30/2000 20:40 10.5.0.11
- See show rtr history
show rtr hops
- Use to display RTR hops information.
- Field descriptions
- rtrIndex—Index number of the RTR probe
- hop—Index number of the hop count
- address—Address of the router at the hop
- minRtt—Minimum round-trip time in milliseconds
- maxRtt—Maximum round-trip time in milliseconds
- avgRtt—Average round-trip time in milliseconds
- rttSumSqr—Sum of the square of all round-trip times
in milliseconds
- operationsSent—Number of probe operations sent
- operationsRcvd—Number of probe operations received
- lastGoodResponse—Time when last valid probe operation
was received
- Example
host1#show rtr hops
rtrIndex hop address minRtt maxRtt avgRtt rttSumSqr
---------- ---- ----------- ------ ------ ------ --------
2 1 192.168.1.1 1 276 1 955363
2 2 10.2.0.3 0 1109 2 10094451
rtrIndex hop operationsSent operationsRcvd lastGoodResponse
-------- --- -------------- -------------- ------------
2 1 36985 36838 09/18/2000 20:20
2 2 30717 21494 09/18/2000 20:20
- See show rtr hops
show rtr operational-state
[Contents]
[Prev]
[Next]
[Index]
[Report an Error]