Response Time Reporter

Configuring RTR

You can configure RTR with the following tasks:

• Configuring the Probe Type for RTR
• Configuring the Probe Characteristics for RTR
• Setting the Reaction Conditions for the RTR Probe
• Scheduling the RTR Probe
• Capturing Statistics and Collecting Error Information for the RTR Probe
• Collecting History for the RTR Probe
• Setting the Receiving Interface for the RTR Entry

Configuring the Probe Type for RTR

You can configure the probe type—either an echo probe or a path echo probe after entering into the RTR Configuration mode.

• 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 the probe type value before any other RTR probe configuration. 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 for the RTR Entry.)

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.

To enter into the RTR configuration mode:

• Issue the rtr command in Global Configuration mode.
  host1(config)#rtr 1

  Use the no version to delete all configuration information for an RTR probe.

To configure the probe type:

• Issue the type command in RTR configuration mode.
  host1(config-rtr)#type echo protocol ipIcmpEcho 10.10.0.9

  Use the no version to remove the type configured for the probe.

Configuring the Probe Characteristics for RTR

You can configure the probe characteristics presented in Table 1.

Note: You cannot set any of these characteristics until you have set the probe type using the type command. The default values of these characteristics depend on the type of the entry.

To configure the probe characteristics:

• Set the rate (in seconds) that the RTR probe uses to start a response time operation.
  host1(config-rtr)#frequency 90

  Use the no version to return to the default value, 60 seconds.

• Set the number of hops per path for which statistics are collected. (For more information, see Capturing Statistics and Collecting Error Information for the RTR Probe.
  host1(config-rtr)#hops-of-statistics-kept 5

  Use the no version to set the default, 16 hops.

• Set the maximum number of consecutive failures to respond to a probe’s request. (For more information, see Capturing Statistics and Collecting Error Information for the RTR Probe.
  host1(config-rtr)#max-response-failure 2

  Use the no version to set the default, 5 consecutive failures.

• Set the number of RTR probe operations sent to a given hop.

  Note: You can apply this option only to a pathEcho type.

  host1(config-rtr)#operations-per-hop 5

  Use the no version to return to the default, 3.

• Set the owner of the probe. If the SNMP agent is the owner of the probe, the owner’s name can begin with agent.
  host1(config-rtr)#owner 192.10.27.6 rtc.boston.com 555.1212

  Use the no version to return to the default, no owner.

• Specify the interface on which the RTR probe expects to receive responses.

  Note: You must set this attribute when multiple RTR entries are configured to use the same target address. (For more information, see Setting the Receiving Interface for the RTR Entry).

  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.

• Set the protocol data size, in bytes, in the request packet.
  host1(config-rtr)#request-data-size 20

  Use the no version to return to the default value, 1 byte.

• Set the maximum number of entries in the history table for each RTR probe. (For more information, see Collecting History for the RTR Probe).
  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.

• Set an identifier for the probe.
  host1(config-rtr)#tag westford

  Use the no version to return to the default, no tag.

• Set the time (in milliseconds) that the probe waits for a response. If you set the timeout to 0, no timeout is set.

  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.

  host1(config-rtr)#timeout 3000

  Use the no version to return to the default value, 5000 milliseconds.

• Set the type of service (ToS) byte in the probe’s IP header.
  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.

Setting the Reaction Conditions for the RTR Probe

You can set the RTR probe to react to events that take place and to send notifications about these events.

You cannot set any of these characteristics until you have set the probe type using the type command. The default values of these characteristics depend on the type of the entry. 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.

To set one or more reaction conditions for the RTR probe:

• Specify the type of actions to occur depending on the events controlled by RTR. The default is to take the traps of enabled events.
  host1(config)#rtr reaction-configuration 1 action-type trapOnly
• 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.
  host1(config)#rtr reaction-configuration 1 operation-failure 3
• 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.
  host1(config)#rtr reaction-configuration 1 path-change
• Enable the test-completion reaction. The test-completion event is triggered when a test is completed successfully. At most, there can be one such event per test. The completion is determined in the following ways:
  • 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.
  host1(config)#rtr reaction-configuration 1 test-completion
• Enable the test-failure reaction. The test-failure event is triggered when a test fails. At most, there can be one such event per test. 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.
  host1(config)#rtr reaction-configuration 1 test-failure

Scheduling the RTR 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.

You cannot set any of these characteristics until you have set the probe type using the type command. The default values of these characteristics depend on the type of the entry. The only no version for all the rtr schedule commands is no rtr schedule rtrIndex. 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.

To schedule the probe:

• Create an RTR schedule.
  host1(config)#rtr schedule 5
• 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.
  host1(config)#rtr schedule 5 life 1800
• Specify a restart time, in seconds, after which a test is restarted.
  host1(config)#rtr schedule 5 restart-time 15
• Schedule a test’s starting time (now or pending).
  host1(config)#rtr schedule 5 start-time now

Capturing Statistics and Collecting Error Information for the RTR Probe

The primary objective of RTR is to collect statistics and information about network performance. You can control the number and type of statistics collected using the hops-of-statistics-kept and max-response-failure commands.

Note: You cannot set any of these characteristics until you have set the probe type using the type command. The default values of these characteristics depend on the type of the entry.

To control the number and type of statistics collected:

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

  To turn off this feature, set the value to 0.

  Note: This option applies only to pathEcho entries.

  host1(config-rtr)#hops-of-statistics-kept 5

  Use the no version to set the default, 16 hops.

• Set the maximum number of consecutive failures to respond to a probe’s request.

  When the maximum number is reached, the test stops.

  To turn off this feature, set the value to 0.

  Note: This option applies only to pathEcho entries.

  host1(config-rtr)#max-response-failure 2

  Use the no version to set the default, 5 consecutive failures.

Collecting History for the RTR Probe

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.

You can set the maximum number of entries in the history table for each RTR probe using the samples-of-history-kept command.

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.

Note: You cannot set this characteristic until you have set the probe type using the type command. The default values of this characteristic depend on the type of the entry.

Best Practice: Collect history only when there is a problem in your network because collecting history increases memory usage.

To set the maximum number of entries in the history table for each RTR probe:

• Issue the samples-of-history-kept command in RTR Configuration mode.
  host1(config-rtr)#samples-of-history-kept 5

  Use the no version to set the default: 16 hops for pathEcho type and 1 hop for echo type.

Setting the Receiving Interface for the RTR Entry

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.

Note: You cannot set this characteristic until you have set the probe type using the type command.

To specify the interface on which the RTR probe expects to receive responses:

• Issue the receive-interface command in RTR Configuration mode.
  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.

Shutting Down the RTR Probe

You can shut down the RTR, stop all probe operations, and clear the RTR configuration for the given virtual router using the rtr reset command.

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.

To shut down the RTR probe operation:

• Issue the rtr reset command in Global Configuration mode.
  host1(config)#rtr reset

  Use the no version to negate the reset operation.