|
|
Use the Response Time Reporter Enhancement feature to troubleshoot problems by checking the time delays between devices and the time delays on the path from the source device to the destination device at the protocol level.
You can also use this feature to send any combination of SNMP traps and SNA Alerts/Resolutions when one of the following has occurred: a user-configured threshold is exceeded, a connection is lost and reestablished, or when a timeout occurs. Thresholds can also be used to trigger additional collection of time delay statistics.
You can use this feature to perform preliminary problem analysis by scheduling the response time reporter and collecting the results as history and accumulated statistics. You can then use the statistics to model and predict future network topologies.
The Response Time Reporter Enhancement feature extends IP support and allows you to measure various types of IP traffic, such as UDP and TCP. Specifically, the enhancements enable you to perform the following tasks:
This feature is supported on the following platforms:
For descriptions of supported MIBs and how to use MIBs, see Cisco's MIB website on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
No RFCs are supported by this feature.
To configure the response time reporter feature, complete the tasks in the following sections. Refer to the "Command Reference" section for detailed syntax description of the commands used in these tasks. Configuring the probe and scheduling the probe are required tasks; the remaining tasks are optional.
See the "Configuration Examples" section for example configurations.
The responder is an enhancement that extends response time reporter support to new types of probes, such as the UDP echo responder and TCP connection probes. The RTR responder code must exist on target routers to support probes to non-native services such as the UDP echo and TCP connection probes. If UDP and TCP services (ports) are chosen for a probe to which a router does not normally respond, the RTR responder must be enabled to respond to RTR probe packets. If services that are already provided by the target router (such as Telnet or HTTP) are chosen, the RTR responder does not need to be enabled. For non-Cisco devices, the RTR responder can not be configured and RTR can probe only services native to those devices.
To enable the responder, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
Enables the RTR responder. |
RTR uses a control message protocol to communicate with the Cisco routers that are the target of RTR probe operations. For security reasons, users have the option to enable authentication on the RTR Control Protocol. The authentication is provided using MD5 authentication. This authentication requires key definition on the source and target RTR routers. The existing Cisco IOS software commands are used to define the keys. Refer to the Configuration Fundamentals Configuration Guide for more information on these commands. The rtr key-chain command notifies RTR that it should use a specific key for authentication.
To configure the RTR authentication, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
rtr key-chain name | Configures RTR authentication. |
Response time and availability information is collected by probes (devices specifically placed in a network to collect data about the network) that you configure on the router. You must configure the probe type before you can configure any of the other characteristics.
The tasks in this section describe how to:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| rtr number | Enter RTR configuration mode. | ||
| type echo protocol type type-target | Defines an echo probe. |
| Step | Command | Purpose | ||
|---|---|---|---|---|
| rtr number | Enter RTR configuration mode. | ||
| type pathEcho protocol type type-target | Defines a pathEcho probe. |
| Step | Command | Purpose | ||
|---|---|---|---|---|
| rtr number | Enter RTR configuration mode. | ||
| type tcpConnect dest-ipaddr {name | ip addr} dest-port port number [source-ipaddr {name | ip addr} source-port port number] [control {enable | disable}] | Defines a tcpConnect probe. |
| Step | Command | Purpose | ||
|---|---|---|---|---|
| rtr number | Enter RTR configuration mode. | ||
| type udpEcho dest-ipaddr {name | ip addr} dest-port port number [source-ipaddr {name | ip addr} source-port port number] [control {enable | disable}] | Defines a udpEcho probe. |
To configure optional characteristics, use one or more of the following commands in response time reporter configuration mode:
| Command | Purpose |
|---|---|
frequency seconds | Sets the frequency for RTR probe operation. |
lsr-path {name | ip addr} [name | ip addr] ... | Specifies the path on which to measure the ICMP echo response time. |
owner text | Configures the SNMP owner of the probe. |
request-data-size bytes | Sets the protocol data size in the payload of the probe's request packet. |
response-data-size bytes | Sets the protocol data size in the payload of the probe's response packet. |
tag text | Logically links probes together in a group. |
timeout milliseconds | Sets the amount of time the probe waits for a response from its request packet. |
threshold milliseconds | Sets the rising threshold (hysteresis) that generates a reaction event and stores history information for the probe. |
tos number | Defines the IP ToS byte for request packets. (Only valid on the echo probe in this release.) |
Checks each probe response for corruption. |
A statistical distribution of response times can be thought of as a set of buckets that holds the results of a probe. Each bucket holds the completion count that falls into that specific time interval. To modify the time intervals use the statistics-distribution-interval command. To modify the number of buckets use the distributions-of-statistics-kept command. For example, if the statistics-distribution-interval is 20 ms and the distributions-of-statistics-kept is 3 (buckets a, b and c) and 3 round-trip time (RTT) operations are performed with response times of 10 ms, 15 ms, and 30 ms, then the completion count for the buckets is 2 for a, 1 for b, and 0 for c.
In most situations, you do not need to modify the time intervals or number of buckets (also referred to as size). You should change the size only when distribution adjustments are needed (for example, when performing statistical modeling of your network).
To control how many and what type of statistics are collected on the router, use the following optional commands in response time reporter configuration mode:
| Command | Purpose |
|---|---|
statistics-distribution-interval milliseconds | Sets the time interval for each statistical distribution. |
Sets the number of buckets or statistical distributions kept during the probe's lifetime. Size is the number of buckets that contain data counts for their intervals. | |
Collects pathEcho statistical distributions per hop per path. Size specifies the number of hops for which statistics are collected per path for each probe. | |
Collects statistical distributions for multiple paths. Size specifies the number of paths for which statistical distribution buckets are maintained per hour for each probe. | |
hours-of-statistics-kept hours | Sets the number of hours for which statistics are maintained for the probe. |
The RTR can collect data samples for a given probe; these samples are called history data. By default, history data is not collected. When history collection is enabled, RTR collects the last n data points. The number of data points are configured using the buckets-of-history-kept command.
Additionally, when collecting history, RTR introduces the concept of lives. A life is defined as the operational lifetime of a probe. When a probe is stopped and restarted, data is kept in new life entries (if the number of entries is 2 or less). If the number of entries is more than 2, the oldest entry is overwritten by the new entry.
To control how much and what type of history is collected on the router, use the following commands in response time reporter configuration mode. The first command is required; the remaining commands are optional.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| samples-of-history-kept samples | For a pathEcho probe, sets the number of hops in a path. For all other probes, RTR sets the number of samples to 1. | ||
| For a pathEcho probe, sets the number of paths to store. For all other probes, sets the number (size) of data points to be kept. | |||
| lives-of-history-kept lives | Enables history collection and sets the number of lives maintained in the history table for the probe. | ||
| filter-for-history {none | all | overthreshold | failures} | Defines the type of information kept in the history table for the probe. This is a required command to enable history. All, overthreshold, or failures must be specified for history to work. |
To disable history collection, use the default value (0) for the lives-of-history-kept command rather than the filter-for-history none command. The lives-of-history-kept command disables history collection before the probe's operation is attempted, and the filter-for-history command with the none keyword checks for history inclusion after the probe's operation attempt is made.
You can configure the probe to send threshold notifications and use those notifications to trigger additional collection of time delay statistics. You can also configure the probe to send notifications when the probe loses connection, reestablishes connections, times out, and first succeeds after a timeout.
To configure the probe's reaction conditions, use the following optional commands in global configuration mode:
| Step | Command | Purpose | ||
|---|---|---|---|---|
| rtr reaction-configuration number [connection-loss-enable] [timeout-enable] [threshold-falling milliseconds] [threshold-type option] [action-type option] | Configures certain actions (for example, checking for connection losses or timeouts) to occur based on events controlled by the RTR. | ||
| rtr reaction-trigger number target-number | Defines the target probe to make the transition from a pending state to an active state when one of the trigger action-type options is defined for the probe. |
To schedule an RTR probe, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
rtr schedule number [life seconds] [start-time {pending | now | hh:mm [month day | day month]}] [ageout seconds] | Schedules the probe by configuring the time parameters. |
If the probe is in a pending state (the default), you can define the conditions under which the probe makes the transition from pending to active with the rtr reaction-trigger command. When the probe is in an active state it immediately begins collecting information.
| Command | Purpose |
|---|---|
Stops all probes and clears the RTR configuration information. |
 | Caution Use the rtr reset command only in extreme situations such as the incorrect configuration of a number of probes. The rtr reset command reconfigures the router to its startup configuration |
In addition to stopping all probes and clearing the RTR configuration information, the rtr reset command returns the RTR feature to the startup condition. This command does not reread the configuration stored in NVRAM. You must retype the RTR's configuration or perform a config memory command.
| Command | Purpose |
|---|---|
show rtr application [tabular | full] | Displays global information about the RTR feature. |
show rtr collection-statistics [number] [tabular | full] | Displays error totals collected for all probes or a specified probe. |
show rtr configuration [number] [tabular | full] | Displays configuration values including all defaults for all probes or a specified probe. |
show rtr distributions-statistics [number] [tabular | full] | Displays statistical distribution information (captured response times) for all probes or a specified probe. |
show rtr history [number] [tabular | full] | Displays history collected for all probes or a specified probe. |
show rtr operational-state [number] [tabular | full] | Displays the operational state of all probes or a specified probe. |
show rtr reaction-trigger [number] [tabular | full] | Displays the reaction trigger information for all probes or a specified probe. |
show rtr totals-statistics [number] [tabular | full] | Displays the total statistic values (accumulation of error counts and completions) for all probes or a specified probe. |
The example in Figure 1 shows a tcpConnect probe configured from Router B to the Telnet port (TCP port 23) of IP Host 1 (IP address 10.0.0.1).
RouterB(config)# rtr 5 RouterB(config-rtr)# type tcpConn dest-ipaddr 10.0.0.1 dest-port 23 control disable RouterB(config-rtr)# exit RouterB(config)# rtr schedule 5 start now
In the example the control protocol for the probe is disabled. RTR collector uses the RTR control protocol to notify the RTR responder on the responder router to enable the target port temporarily. This action allows the responder to respond to the probe packet. In this case, because the target is not a router and a well known TCP port is used, there is no need to send the control message.
The example in Figure 2 shows a udpEcho probe configured from Router B to UDP port 888 on Router A (IP address 20.0.0.1).
RouterA(config)# key chain rtr-key RouterA(config-keychain)# key 1 RouterA(config-keychain-key)# key-string secrete RouterA(config-keychain-key)# exit RouterA(config-keychain)# exit RouterA(config)# rtr key-chain rtr-key RouterA(config)# rtr responder
In the configuration for Router B we create a keychain called "rtr-key." The rtr key-chain command enables RTR MD5 authentication on the control messages.
RouterB(config)# key chain rtr-key RouterB(config-keychain)# key 1 RouterB(config-keychain-key)# key-string secrete RouterB(config-keychain-key)# exit RouterB(config-keychain)# exit RouterB(config)# rtr key-chain rtr-key RouterB(config)# rtr 6 RouterB(config-rtr)# type udpEcho dest-ipaddr 20.0.0.1 dest-port 888 control enable RouterB(config-rtr)# exit RouterB(config)# rtr schedule 6 start now
The example in Figure 3 shows probe 1 configured from Router A to Host 2, and Probe 2 is configured from Router B to Host 2. This configuration allows normative analysis of the network to determine a baseline from which triggers (and general reactions) are configured. Also, two SNA PUs must be configured: CWBC0A and CWBC0B. For information on configuring PUs, see the dspu host or the sna host commands in the Bridging and IBM Networking Command Reference.
RouterA(config)# rtr 1 RouterA(config-rtr)# type echo protocol snaLU2EchoAppl CWBC0A RouterA(config-rtr)# exit RouterA(config)# rtr schedule 1 start-time now RouterA(config)# exit
RouterB(config)# rtr 2 RouterB(config-rtr)# type echo protocol snaLU2EchoAppl CWBC0B RouterB(config-rtr)# exit RouterB(config)# rtr schedule 1 start-time now RouterB(config)# exit
After you save the configurations for Router A and Router B (using the copy running-config startup-config command), information is stored in the configuration files. kept commands are added automatically to the configuration file because they differ depending on the type you specify for the probe. The following information is stored:
!Router A Configuration File ! Router A's PU Configuration sna host CWBC0A xid-snd 05dcc00a rmac 4001.3745.1088 rsap 4 lsap 12 focalpoint rtr 1 type echo protocol snaLU2EchoAppl CWBC0A paths-of-statistics-kept 1 hops-of-statistics-kept 1 samples-of-history-kept 1 rtr schedule 1 start-time now !Router B Configuration File !Router B's PU Configuration from the Configuration File: sna host CWBC0B xid-snd 05dcc00b rmac 4001.3745.1088 rsap 4 lsap 12 focalpoint rtr 2 type echo protocol snaLU2EchoAppl CWBC0B paths-of-statistics-kept 1 hops-of-statistics-kept 1 samples-of-history-kept 1 rtr schedule 2 start-time now
The example in Figure 4 shows that Probe 3 is configured from Router B to Router A to perform network troubleshooting and identify network problems that configure triggers and general reactions.
This example sets up a pathEcho (with history) pending entry from Router B to Router A via IP/ICMP. It attempts to execute 3 times in 25 seconds (first attempt starts at 0 seconds) and keeps those 3 times with 3 buckets. The entry can be started 5 times before wrapping over stored history (lives-of-history-kept = 5). Because this configuration keeps history, it uses more RAM on the router.
RouterB(config)# rtr 3 RouterB(config-rtr)# type pathEcho protocol ipIcmpEcho RouterA RouterB(config-rtr)# frequency 10 RouterB(config-rtr)# lives-of-history-kept 5 RouterB(config-rtr)# buckets-of-history-kept 3 RouterB(config-rtr)# filter-for-history all RouterB(config-rtr)# exit RouterB(config)# rtr schedule 3 life 25 RouterB(config)# exit
After you save the configuration (using the copy running-config startup-config command) the information is stored in the configuration file. Note the addition of commands in the configuration file. They are automatically included because they differ depending on the type you specify for the probe. The following information is stored:
rtr 3 type pathEcho protocol ipIcmpEcho 172.28.161.21 frequency 10 response-data-size 1 lives-of-history-kept 5 buckets-of-history-kept 3 filter-for-history all rtr schedule 3 life 25 start-time pending
Figure 5 shows Probes 1, 2, and 3 in the network. This example shows how to configure a trigger if Probe 2 encounters a connection loss from Router B to Host 2. If a connection loss occurs between Router B and Host 2, a trap is issued, an SNA NMVT Alert is issued, and the Probe 3 state is changed to active.
RouterB(config)# rtr reaction-configuration 2 connection-loss-enable action-type trapNmvtAndTrigger RouterB(config)# rtr reaction-trigger 2 3
The following commands are new or modified in Cisco IOS Release 12.0(3)T.
The following commands have not been modified, but are necessary to configure RTR:
To set the number of history buckets that are kept during the RTR probe's lifetime, use the buckets-of-history-kept response time reporter configuration command. Use the no form of this command to return to the default value.
buckets-of-history-kept size
size | Number of history buckets kept during the RTR probe's lifetime. The default is 50 buckets. |
50 buckets
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
An RTR probe collects history and captures statistics. By default, history is not collected. When a problem arises where history is useful (for example, a large number of timeouts are occurring), you can configure the lives-of-history-kept command to collect history. You can optionally adjust the buckets-of-history-kept, filter-for-history, and samples-of-history-kept commands.
RTR keeps the last n buckets of data.
If history is collected, each bucket contains one or more history entries from the probe. When the probe type is pathEcho, an entry is created for each hop along the path that the probe takes to reach its destination. The type of entry stored in the history table is controlled by the filter-for-history command. The total number of entries stored in the history table is controlled by the combination of samples-of-history-kept, buckets-of-history-kept, and lives-of-history-kept commands.
Each time the probe starts an RTR operation, a new bucket is created until the number of history buckets matches the specified size or the probe's lifetime expires. History buckets do not wrap. The probe's lifetime is defined by the rtr schedule command. The probe starts an RTR operation based on the seconds specified by the frequency command.
In the following example, probe 1 is configured to keep 25 history buckets during the probe's lifetime:
rtr 1 type echo protocol ipIcmpEcho 172.16.161.21 buckets-of-history-kept 25 lives-of-history-kept 1
filter-for-history
lives-of-history-kept
rtr
rtr schedule
samples-of-history-kept
To set the number of statistic distributions kept per hop during the RTR probe's lifetime, use the distributions-of-statistics-kept response time reporter configuration command. Use the no form of this command to return to the default value.
distributions-of-statistics-kept size
size | Number of statistic distributions kept per hop. The default is 1 distribution. |
1 distribution
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
When the number of distributions reaches the specified size, no further distribution information is stored.
In the following example, the distribution is set to 5 and the distribution interval is set to 10 ms. In this configuration the first distribution contains statistics from 0 to 9 ms, the second distribution contains statistics from 10 to 19 ms, the third distribution contains statistics from 20 to 29 ms, the fourth distribution contains statistics from 30 to 39 ms, and the fifth distribution contains statistics from 40 ms to infinity.
rtr 1 type echo protocol ipIcmpEcho 172.16.161.21 distributions-of-statistics-kept 5 statistics-distribution-interval 10
hops-of-statistics-kept
hours-of-statistics-kept
paths-of-statistics-kept
rtr
statistics-distribution-interval
To define the type of information kept in the history table for the RTR probe, use the filter-for-history response time reporter configuration command. Use the no form of this command to return to the default value.
filter-for-history {none | all | overThreshold | failures}
none | No history is kept. This is the command default. |
all | Keeps a history of all probe operations attempted. |
overThreshold | Keeps a history of packets that are over the threshold. |
failures | Keeps a history of packets that fail for any reason. |
No history is kept.
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
A probe collects history and captures statistics. By default, history is not collected. When a problem arises where history is useful (for example, a large number of timeouts are occurring), you can configure the lives-of-history-kept command to collect history.
In the following example, only probe packets that fail are kept in the history table:
rtr 1 type echo protocol ipIcmpEcho 172.16.161.21 lives-of-history-kept 1 filter-for-history failures
buckets-of-history-kept
lives-of-history-kept
rtr
samples-of-history-kept
To set the rate at which the RTR probe starts a response time operation, use the frequency response time reporter configuration command. Use the no form of this command to return to the default value.
frequency second
second | Number of seconds between the probe's RTR operations. The default value is 60 seconds. |
60 seconds
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
| Caution For normal operation, do not set the frequency value to less than 60 seconds for the following reasons: it is not needed when keeping statistics (the default), and it can slow down the WAN because of the potential overhead that numerous probes can cause. |
The value specified for the frequency command cannot be less than the value specified for the timeout command.
In the following example, the probe is configured to execute an RTR operation every 90 seconds:
rtr 1 type echo protocol ipIcmpEcho 172.16.1.176 frequency 90
To set the number of hops for which statistics are maintained per path for the RTR probe, use the hops-of-statistics-kept response time reporter configuration command. Use the no form of this command to return to the default value.
hops-of-statistics-kept size
size | Number of hops for which statistics are maintained per path. The default is 16 hops for type pathEcho and 1 hop for all other types. |
16 hops for type pathEcho
1 hop for all other types
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
When the number of hops reaches the specified size, no further hop information is stored.
In the following example, the statistics for probe 2 are maintained for only 10 hops:
rtr 2 type pathecho protocol ipIcmpEcho 172.16.1.177 hops-of-statistics-kept 10
distributions-of-statistics-kept
hours-of-statistics-kept
paths-of-statistics-kept
rtr
statistics-distribution-interval
To set the number of hours for which statistics are maintained for the RTR probe, use the hours-of-statistics-kept response time reporter configuration command. Use the no form of this command to return to the default value.
hours-of-statistics-kept hours
hours | Number of hours that the router maintains statistics. The default is 2 hours. |
2 hours
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
In the following example, the statistics for probe 2 are maintained for 3 hours:
rtr 2 type pathecho protocol ipIcmpEcho 172.16.1.177 hours-of-statistics-kept 3
distributions-of-statistics-kept
hops-of-statistics-kept
paths-of-statistics-kept
rtr
statistics-distribution-interval
To set the number of lives maintained in the history table for the RTR probe, use the lives-of-history-kept response time reporter configuration command. Use the no form of this command to return to the default value.
lives-of-history-kept lives
lives | Number of lives maintained in the history table for the probe. The default is 0 lives. |
0 lives
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
When the number of lives exceeds the specified value, the history table wraps (the oldest information is replaced by newer information).
When a probe makes a transition from pending to active, a life starts. When a probe's life ends, the probe makes a transition from active to pending.
In the following example, the history for probe 1 is maintained for 5 lives:
rtr 1 type echo protocol ipIcmpEcho 172.16.1.176 lives-of-history-kept 5
buckets-of-history-kept
filter-for-history
rtr
samples-of-history-kept
To define a loose source routing (LSR) path for IP echo probe, use the lsr-path response time reporter configuration command. Use the no form of this command to remove the definition.
lsr-path {name | ip addr} [{name | ip addr}] ...
name | IP host name. |
ip addr | IP address. |
LSR path is disabled.
Response time reporter configuration
This command first appeared in Cisco IOS Release 12.0(3)T.
The maximum number of hops available is 8 when an LSR path is configured.
In the following example, LSR is defined for the echo probe with IP address 172.16.1.176:
rtr 1 type echo protocol ipIcmpEcho 172.16.1.176 lsr-path 172.18.4.149 172.18.26.155
To configure the SNMP owner of the RTR probe, use the owner response time reporter configuration command. Use the no form of this command to return to the default value.
owner text
text | Name of the SNMP owner from 0 to 255 ASCII characters. The default is no owner. |
No owner is specified.
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
In the following example, the owner is set for probe 1:
rtr 1 type echo protocol ipIcmpEcho 172.16.1.176 owner 172.16.1.189 cwb.cisco.com John Doe RTP 555-1212
To set the number of paths for which statistics are maintained per hour for the RTR probe, use the paths-of-statistics-kept response time reporter configuration command. Use the no form of this command to return to the default value.
paths-of-statistics-kept size
size | Number of paths for which statistics are maintained per hour. The default is 5 paths for type pathEcho and 1 path for all other types. |
5 paths for type pathEcho
1 path for all other types
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
When the number of paths reaches the specified size, no further path information is stored.
In the following example, the statistics for probe 2 are maintained for only 3 paths:
rtr 2 type pathEcho protocol ipIcmpEcho 172.16.1.177 paths-of-statistics-kept 3
distributions-of-statistics-kept
hops-of-statistics-kept
hours-of-statistics-kept
rtr
statistics-distribution-interval
To set the protocol data size in the payload of the RTR probe's request packet, use the request-data-size response time reporter configuration command. Use the no form of this command to return to the default value.
request-data-size byte
byte | Size of the protocol data in the payload of the probe's request packet. Range is 0 to the protocol's maximum payload capacity. The default is 1 byte for the ICMP echo probe and 4 bytes for udpEcho probe. |
1 byte for ICMP echo probe
4 bytes for udpEcho probe
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
In the following example, the request packet size for probe 3 is set to 40 bytes:
rtr 3 type echo protocol snalu0echoappl cwbc0a request-data-size 40
To set the protocol data size in the payload of the RTR probe's response packet, use the response-data-size response time reporter configuration command. Use the no form of this command to return to the default value.
response-data-size byte
byte | Size of the protocol data in the payload in the probe's response packet. For "appl" protocols, the default is 0 bytes. For all others, the default is the same value as specified in the request-data-size command. |
For "appl" protocols, 0 bytes
For all others, the same value as specified in the request-data-size command
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
In the following example, the response packet size for probe 3 is set to 1440 bytes:
rtr 3 type echo protocol snalu0echoappl cwbc0a response-data-size 1440
To configure an RTR probe, use the rtr global configuration command. Use the no form of this command to remove all configuration information for a probe including the probe's schedule, reaction configuration, and reaction triggers.
rtr number
number | Number of the RTR probe to configure. |
None
Global configuration
This command first appeared in Cisco IOS Release 11.2.
A probe is used for the purpose of collecting response time information.
RTR allows a maximum of 500 probes.
The RTR feature allows customers to monitor the performance of their network, network resources, and applications by measuring response times and availability. With this feature, you can perform troubleshooting, problem notification, and preliminary problem analysis. For more information, refer to the "Monitoring the Router and Network" chapter in the Configuration Fundamentals Configuration Guide and the Cisco Round-Trip Time Monitor (RTTMON) MIB.
The rtr command places you in response time reporter configuration mode.
Use the following response time reporter configuration commands to configure the probe's characteristics:
After you configure a probe, you must schedule it. For information on scheduling a probe, refer to the rtr schedule command. You can also optionally set reaction triggers for the probe. For information on reaction triggers, refer to the rtr reaction-configuration and rtr reaction-trigger commands.
To display the probe's current configuration settings, use the show rtr configuration EXEC command.
In the following example, probe 1 is configured to perform end-to-end response time operations using an SNA LU Type 0 connection with the host name cwbc0a. Only the type command is required; all others are optional.
rtr 1 type echo protocol snalu0echoappl cwbc0a request-data-size 40 response-data-size 1440
rtr reaction-configuration
rtr reaction-trigger
rtr reset
rtr schedule
To enable RTR control message authentication and specify an MD5 key chain, use the rtr key-chain global configuration command. Use the no form of this command to remove control message authentication.
rtr key-chain name
name | Name of MD5 key chain. |
None
Global configuration
This command first appeared in Cisco IOS Release 12.0(3)T.
The authentication configuration on the RTR collector and responder must be the same. Both sides must configure the same key chain or both sides must not use authentication.
In the following example, the RTR control message uses MD5 authentication, and the key chain name is rtr:
rtr key-chain rtr
To configure certain actions to occur based on events under the control of the RTR, use the rtr reaction-configuration global configuration command. Use the no form of this command to return to the probe's default values.
rtr reaction-configuration number [connection-loss-enable] [timeout-enable]
number | Number of the existing RTR probe to configure. |
connection-loss-enable | (Optional) Enables checking for connection loss in connection-oriented protocols. The default is disabled. |
timeout-enable | (Optional) Enables checking for RTR operation timeouts based on the timeout value configured for the probe with the timeout command. The default is disabled. |
threshold-falling milliseconds | (Optional) Sets the falling threshold (standard RMON-type hysteresis mechanism) in milliseconds. When the falling threshold is met, generate a resolution reaction event. The probe's rising over threshold is set with the threshold command. The default value is 3000 ms. |
threshold-type option | (Optional) Specifies the algorithm used by the RTR to calculate over threshold and falling threshold violations. Option can be one of the following keywords: · never---Do not calculate threshold violations (the default). · immediate---When the response time exceeds the rising over threshold or drops below the falling threshold, immediately perform the action defined by action-type. · consecutive [occurrences]---When the response time exceeds the rising threshold consecutively five times or drops below the falling threshold consecutively five times, perform the action defined by action-type. Optionally specify the number of consecutive occurrences. The default is 5. · xofy [x-value y-value]---When the response time exceeds the rising threshold five out of the last five times or drops below the falling threshold five out of the last five times, perform the action defined by action-type. Optionally, specify the number of violations that must occur and the number that must occur within a specified time. The default is 5 for both x-value and y-value. |
| · average [attempts]---When the average of the last five response times exceeds the rising threshold or when the average of the last five response times drops below the falling threshold, perform the action defined by action-type. Optionally, specify the number of operations to average. The default is the average of the last five response time operations. For example: if the probe's threshold is 5000 ms and the probe's last 3 attempts results are 6000, 6000, and 5000 ms, the average would be 6000 + 6000 + 5000 = 17000/3 > 5000, thus violating the 5000-ms threshold. |
action-type option | (Optional) Specify what action or combination of actions the probe performs when you configure the connection-loss-enable or timeout-enable commands or threshold events occur. For the action-type to occur for threshold events, the threshold-type must be defined to anything other than never. The option argument can be one of the following keywords: · none---No action is taken. · trapOnly---Send an SNMP trap on both over threshold and falling threshold violations. · nmvtOnly---Send an SNA NMVT Alert on over threshold violations and an SNA NMVT Resolution on falling threshold violations. · triggerOnly---Operational state of one or more target probe makes the transition from "pending" to "active" on over threshold and falling threshold violations. The target probes are defined with the rtr reaction-trigger command. A target probe continues until its life expires as specified by the target probe's life value configured with the rtr schedule command. A triggered target probe must finish its life before it can be triggered again. · trapAndNmvt---Sends a combination of trapOnly and nmvtOnly alerts. · trapAndTrigger---Sends a combination of trapOnly and triggerOnly alerts. · nmvtAndTrigger---Sends a combination of nmvtOnly and triggerOnly alerts. · trapNmvtAndTrigger---Sends a combination of trapOnly, nmvtOnly, and triggerOnly alerts. |
No reactions are generated.
Global configuration
This command first appeared in Cisco IOS Release 11.2.
Triggers are used for diagnostics purposes and are not used in normal operation.
Use triggers to determine where delays are happening in the network when excessive delays are seen on an end-to-end basis.
The reaction applies only to attempts to the target (that is, attempts to any hops along the path in pathEcho do not generate reactions).
To specify trap as an action-type option, you must configure the snmp-server community, snmp-server enable, and snmp-server host commands. Refer to the Configuration Fundamentals Configuration Guide for more information on these commands.
In the following example, probe 19 sends an SNMP trap when there is an over threshold or falling threshold violation:
rtr reaction-configuration 19 threshold-type immediate action-type trapOnly
Figure 6 shows that an alert (rising trap) is issued immediately when the response time exceeds the rising threshold and a resolution (falling trap) is issued immediately when the response time drops below the falling threshold.
In the following example, traps are sent when probe 1 times out.
snmp-server enable traps rtr snmp-server host 172.69.1.129 traps public rtr rtr 1 type echo protocol ipIcmpEcho 172.69.1.129 exit rtr reaction-configuration 1 timeout-enable action-type trapOnly
rtr
rtr reaction-trigger
threshold
timeout
To define a second RTR probe to make the transition from a pending state to an active state when one of the trigger action-type options are defined with the rtr reaction-configuration command, use the rtr reaction-trigger command. Use the no form of this command to remove the trigger combination.
rtr reaction-trigger number target-number
number | Number of the probe in the active state that has the action-type set with the rtr reaction-configuration command. |
target-number | Number of the probe in the pending state that is waiting to be triggered with the rtr command. |
None
Global configuration
This command first appeared in Cisco IOS Release 11.2.
Triggers are used for diagnostics purposes and are not used in normal router operation.
The target probe must be scheduled to start using the rtr schedule command with the start-time pending option configured.
In the following example, the state of probe 1 is changed from pending to active when probe 2's action-type occurs:
rtr reaction-trigger 2 1
rtr
rtr reaction-configuration
rtr schedule
To shut down the RTR (stop all probes and clear the RTR configuration), use the rtr reset global configuration command.
rtr resetThis command has no arguments or keywords.
None
Global configuration
This command first appeared in Cisco IOS Release 11.2.
| Caution Use the rtr reset command only in extreme situations (for example, if the incorrect number of probes is configured. |
The following example resets the RTR feature:
rtr reset
To enable the RTR responder, use the rtr responder global configuration command. Use the no form of this command to disable the responder.
rtr responderThis command has no arguments or keywords.
None
Global configuration
This command first appeared in Cisco IOS Release 12.0(3)T.
The following example enables the RTR responder:
rtr responder
To configure the time parameters for an RTR probe, use the rtr schedule global configuration command. Use the no form of this command to stop the probe and restart it with the default parameters (pending).
rtr schedule number [life seconds] [start-time {pending | now | hh:mm [month day |
number | Number of the RTR probe to schedule. |
life seconds | (Optional) Number of seconds the probe actively collects information. The default is 3600 seconds (1 hour). |
start-time | (Optional) Time when the probe starts collecting information. If the start-time argument is not specified, no information is collected until the start-time is configured or a trigger occurs that performs a start-time now. |
pending | No information is collected. This is the default value. |
now | Information is immediately collected. |
hh:mm | Information is collected at the specified time (use a 24-hour clock). The time is the current day if you do not specify the month and day. |
month | (Optional) Name of the month. If month is not specified, the current month is used. This requires a day. |
day | (Optional) Number of the day in the range 1 to 31. If day is not specified, the current day is used. This requires a month. |
ageout seconds | (Optional) Number of seconds the probe stays active when it is not collecting information. The default is 0 seconds (never ages out). |
Pending state (the probe is started but not actively collecting information).
Global configuration
This command first appeared in Cisco IOS Release 11.2.
If the probe is in a pending state, you can define the conditions under which the probe makes the transition from pending to active with the rtr reaction-trigger and rtr reaction-configuration commands. When the probe is in an active state, it immediately begins collecting information.
The following time line shows the probe's age-out process:
W----------------------X----------------------Y----------------------Z
Where:
The ageout starts counting down at W and Y, is suspended between X and Y, and is reset to its configured size at Y.
It is possible for the probe to age out before it executes (Z can occur before X). To ensure that the probe does not age out, the difference between the probe's configuration time and start time (X and W) must be less than the ageout seconds.
In the following example, probe 25 begins collecting data at 3:00 p.m. on April 5. This probe ages out after 12 hours of inactivity, which can be before it starts or after it has finished with its life. When this probe ages out, all configuration information for the probe is removed (the configuration information is no longer in the running configuration file in RAM.
rtr schedule 25 life 43200 start-time 15:00 apr 5 ageout 43200
rtr
rtr reaction-configuration
rtr reaction-trigger
To set the number of entries kept in the history table for each bucket in the RTR probe, use the samples-of-history-kept response time reporter configuration command. Use the no form of this command to return to the default value.
samples-of-history-kept samples
samples | Number of entries for each bucket kept in the history table. The default is 16 entries for type pathEcho and 1 entry for all other probes. |
16 entries for type pathEcho
1 entry for all other probes
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
A probe collects history and captures statistics. By default, history is not collected. When a problem arises where history is useful (for example, a large number of timeouts are occurring), you can configure the lives-of-history-kept command to collect history.
In the following example, 10 entries are kept in the history table for each of the of probe's 3 lives:
rtr 1 type pathecho protocol ipIcmpEcho 172.16.1.176 lives-of-history-kept 3 samples-of-history-kept 10
buckets-of-history-kept
filter-for-history
lives-of-history-kept
rtr
show rtr history
Use the show rtr application EXEC command to display global information about the RTR feature.
show rtr application [tabular | full]
tabular | (Optional) Displays information in a column format reducing the number of screens required to display the information. |
full | (Optional) Displays all information using identifiers next to each displayed value. This is the default. |
All information is displayed.
EXEC
This command first appeared in Cisco IOS Release 11.2.
The following is sample output from the show rtr application command in full format:
Router# show rtr application full
Response Time Reporter
Version: 1.0.0 Initial Round Trip Time MIB
Max Packet Data Size (ARR and Data): 16384
Time of Last Change in Whole RTR: *16:49:53.000 UTC Thu May 16 1996
System Max Number of Entries: 20
Supported Operation Types
Type of Operation to Perform: echo
Type of Operation to Perform: pathEcho
Supported Protocols
Protocol Type: ipIcmpEcho
Protocol Type: snaRUEcho
Protocol Type: snaLU0EchoAppl
Protocol Type: snaLU2EchoAppl
Use the show rtr authentication EXEC command to display RTR authentication information.
show rtr authenticationThis command has no arguments or keywords.
EXEC
This command first appeared in Cisco IOS Release 12.0(3)T.
The following is sample output from the show rtr application command:
Router# show rtr authentication RTR control message uses MD5 authentication, key chain name is: rtr
number | (Optional) Number of the RTR probe to display. |
tabular | (Optional) Displays information in a column format to reduce the number of screens required to display the information. |
full | (Optional) Displays all information using identifiers next to each displayed value. This is the default. |
All information is displayed.
EXEC
This command first appeared in Cisco IOS Release 11.2.
The following is sample output from the show rtr collection-statistics command in full format:
Router# show rtr collection-statistics 1 full
Collected Statistics
Entry Number: 1
Start Time Index: *17:15:41.000 UTC Thu May 16 1996
Path Index: 1
Hop in Path Index: 1
Number of Failed Operations due to a Disconnect: 0
Number of Failed Operations due to a Timeout: 0
Number of Failed Operations due to a Busy: 0
Number of Failed Operations due to a No Connection: 0
Number of Failed Operations due to an Internal Error: 0
Number of Failed Operations due to a Sequence Error: 0
Number of Failed Operations due to a Verify Error: 0
Target Address: 172.16.1.176
show rtr configuration
show rtr distributions-statistics
show rtr totals-statistics
number | (Optional) Number of the RTR probe to display. |
tabular | (Optional) Displays information in a column format to reduce the number of screens required to display the information. |
full | (Optional) Displays all information using identifiers next to each displayed value. This is the default. |
All information is displayed.
EXEC
This command first appeared in Cisco IOS Release 11.2.
The following is sample output from the show rtr configuration command in full format:
Router# show rtr configuration 1 full
Complete Configuration Table (includes defaults)
Entry Number: 1
Owner:"Sample Owner"
Tag:"Sample Group"
Type of Operation to Perform:echo
Reaction and History Threshold (milliseconds):5000
Operation Frequency (seconds):60
Operation Timeout (milliseconds):5000
Verify Data:FALSE
Status of Entry (SNMP RowStatus):active
Protocol Type:ipIcmpEcho
Target Address:1.0.0.1
Source Address:0.0.0.0
Target Port:0
Source Port:0
Request Size (ARR data portion):28
Response Size (ARR data portion):1
Control Packets:enabled
Loose Source Routing:disabled
LSR Path:
Type of Service Parameters:0x0
Life (seconds):3600
Next Scheduled Start Time:Pending Trigger
Entry Ageout:never
Connection Loss Reaction Enabled:FALSE
Timeout Reaction Enabled:FALSE
Threshold Reaction Type:never
Threshold Falling (milliseconds):3000
Threshold Count:5
Threshold Count2:5
Reaction Type:none
Number of Statistic Hours kept:2
Number of Statistic Paths kept:1
Number of Statistic Hops kept:1
Number of Statistic Distribution Buckets kept:1
Statistic Distribution Interval (milliseconds):20
Number of History Lives kept:0
Number of History Buckets kept:15
Number of History Samples kept:1
History Filter Type:none
show rtr application
show rtr collection-statistics
show rtr distributions-statistics
show rtr history
show rtr operational-state
show rtr reaction-trigger
show rtr totals-statistics
number | (Optional) Number of the RTR probe to display. |
tabular | (Optional) Displays information in a column format to reduce the number of screens required to display the information. This is the default. |
full | (Optional) Displays all information using identifiers next to each displayed value. |
Information is displayed in tabular format.
EXEC
This command first appeared in Cisco IOS Release 11.2.
The distributions statistics include the following information:
You can also use the show rtr collection-statistics and show rtr totals-statistics commands to display additional statistical information.
The following is sample output from the show rtr distributions-statistics command in tabular format:
Router# show rtr distributions-statistics tabular Captured Statistics Multiple Lines per Entry Line 1 Entry = Entry Number StartT = Start Time of Entry (hundredths of seconds) Pth = Path Index Hop = Hop in Path Index Dst = Time Distribution Index Comps = Operations Completed OvrTh = Operations Completed Over Thresholds SumCmp = Sum of Completion Times (milliseconds) Line 2 SumCmp2L = Sum of Completion Times Squared Low 32 Bits (milliseconds) SumCmp2H = Sum of Completion Times Squared High 32 Bits (milliseconds) TMax = Completion Time Maximum (milliseconds) TMin = Completion Time Minimum (milliseconds) EntryStartTPthHopDstCompsOvrThSumCmp SumCmp2LSumCmp2HTMaxTMin 11741706811120128 819206464
show rtr collection-statistics
show rtr configuration
show rtr totals-statistics
Use the show rtr history EXEC command to display history collected for all RTR probes or a specified probe.
show rtr history [number] [tabular | full]
number | (Optional) Number of the RTR probe to display. |
tabular | (Optional) Displays information in a column format to reduce the number of screens required to display the information. This is the default. |
full | (Optional) Displays all information using identifiers next to each displayed value. |
Information displayed in tabular format.
EXEC
This command first appeared in Cisco IOS Release 11.2.
The response return codes are listed in Table 1.
| Code | Meaning |
|---|---|
1 | Okay |
2 | Disconnected |
3 | Over threshold |
4 | Timeout |
5 | Busy |
6 | Not connected |
7 | Dropped |
8 | Sequence error |
9 | Verify error |
10 | Application specific |
The following is sample output from the show rtr history command in tabular format:
Router# show rtr history tabular
Point by point History
Multiple Lines per Entry
Line 1
Entry = Entry Number
LifeI = Life Index
BucketI= Bucket Index
SampleI= Sample Index
SampleT= Sample Start Time
CompT = Completion Time (milliseconds)
Sense = Response Return Code
Line 2 has the Target Address
EntryLifeIBucketISampleISampleTCompTSense
211117436548161
AB 45 A0 16
21211743655141
AC 12 729
21221743655111
AC 12 522
21231743655241
AB 45 A722
21241743655241
AB 45 A0 16
number | (Optional) Number of the RTR probe to display. |
tabular | (Optional) Displays information in a column format to reduce the number of screens required to display the information. |
full | (Optional) Displays all information using identifiers next to each displayed value. This is the default. |
Full information is displayed.
EXEC
This command first appeared in Cisco IOS Release 11.2.
The following is sample output from the show rtr operational-state command in full format:
Router# show rtr operational-state 1 full
Current Operational State
Entry Number: 1
Modification Time: *17:15:41.000 UTC Thu May 16 1996
Diagnostics Text:
Last Time this Entry was Reset: Never
Number of Octets in use by this Entry: 2438
Connection Loss Occurred: FALSE
Timeout Occurred: FALSE
Over Thresholds Occurred: FALSE
Number of Operations Attempted: 6
Current Seconds Left in Life: 3336
Operational State of Entry: active
Latest Completion Time (milliseconds): 60
Latest Operation Return Code: ok
Latest Operation Start Time: *17:19:41.000 UTC Thu May 16 1996
Latest Target Address: 172.16.1.176
number | (Optional) Number of the RTR probe to display. |
tabular | (Optional) Displays information in a column format to reduce the number of screens required to display the information. |
full | (Optional) Displays all information using identifiers next to each displayed value. This is the default. |
Full information is displayed.
EXEC
This command first appeared in Cisco IOS Release 11.2.
The following is sample output from the show rtr reaction-trigger command in full format:
Router# show rtr reaction-trigger 1 full
Reaction Table
Entry Number: 1
Target Entry Number: 2
Status of Entry (SNMP RowStatus): active
Operational State: pending
Use the show rtr responder EXEC command to display RTR responder information.
show rtr responderThis command has no arguments or keywords.
EXEC
This command first appeared in Cisco IOS Release 12.0(3)T.
The following is sample output from the show rtr responder command:
Router# show rtr responder RTR Responder is: Enabled Number of control message received: 19 Number of errors: 1 Recent sources:4.0.0.1 [19:11:49.035 UTC Sat Dec 2 1995] 4.0.0.1 [19:10:49.023 UTC Sat Dec 2 1995] 4.0.0.1 [19:09:48.707 UTC Sat Dec 2 1995] 4.0.0.1 [19:08:48.687 UTC Sat Dec 2 1995] 4.0.0.1 [19:07:48.671 UTC Sat Dec 2 1995]
Recent error sources:4.0.0.1 [19:10:49.023 UTC Sat Dec 2 1995] RTT_AUTH_FAIL
number | (Optional) Number of the RTR probe to display. |
tabular | (Optional) Displays information in a column format to reduce the number of screens required to display the information. |
full | (Optional) Displays all information using identifiers next to each displayed value. This is the default. |
Full information is displayed.
EXEC
This command first appeared in Cisco IOS Release 11.2.
The total statistics consist of the following items:
You can also use the show rtr distributions-statistics and show rtr collection-statistics commands to display additional statistical information.
The following is sample output from the show rtr totals-statistics command in full format:
Router# show rtr totals-statistics full
Statistic Totals
Entry Number: 1
Start Time Index: *17:15:41.000 UTC Thu May 16 1996
Age of Statistics Entry (hundredths of seconds): 48252
Number of Initiations: 10
show rtr collection-statistics
show rtr configuration
show rtr distributions-statistics
To set the time interval for each statistics distribution kept for the RTR, use the statistics-distribution-interval response time reporter configuration command. Use the no form of this command to return to the default value.
statistics-distribution-interval milliseconds
milliseconds | Number of milliseconds used for each statistics distribution kept. The default is 20 ms. |
20 ms
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
In the following example, the distribution is set to 5 and the distribution interval is set to 10 ms. The first distribution will contain statistics from 0 to 9 ms, the second distribution will contain statistics from 10 to 19 ms, the third distribution will contain statistics from 20 to 29 ms, the fourth distribution will contain statistics from 30 to 39 ms, and the fifth distribution will contain statistics from 40 ms to infinity.
rtr 1 type echo protocol ipIcmpEcho 172.28.161.21 distribution-of-statistics-kept 5 statistics-distribution-interval 10
distributions-of-statistics-kept
hops-of-statistics-kept
hours-of-statistics-kept
paths-of-statistics-kept
rtr
To create a user-specified identifier for an RTR probe, use the tag RTR configuration command. It is normally used to logically link probes in a group. Use the no form of this command to remove a tag from a probe.
tag text
text | Name of a group that this probe belongs to. From 0 to 16 ASCII characters. |
None
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
In the following example, probe 1 is tagged with the label bluebell:
rtr 1 type echo protocol ipIcmpEcho 172.16.1.176 tag bluebell
To set the rising threshold (hysteresis) that generates a reaction event and stores history information for the RTR probe, use the threshold response time reporter configuration command. Use the no form of this command to return to the default value.
threshold millisecond
millisecond | Number of milliseconds required for a rising threshold to be declared. The default value is 5000 ms. |
5000 ms
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
The threshold value is used by the rtr reaction-configuration and filter-for-history commands.
In the following example, the threshold for probe 1 is set to 2500 ms:
rtr 1 type echo protocol ipIcmpEcho 172.16.1.176 threshold 2500
filter-for-history
rtr
rtr reaction-configuration
To set the amount of time the RTR probe waits for a response from its request packet, use the timeout response time reporter configuration command. Use the no form of this command to return to the default value.
timeout millisecond
millisecond | Number of milliseconds the probe waits to receive a response from its request packet. The default is 5000 ms. |
5000 ms
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
The value specified for the timeout command cannot be greater than the value specified for the frequency command.
In the following example, the timeout is set for 2500 ms:
rtr 1 type echo protocol ipIcmpEcho 172.16.1.176 timeout 2500
To define a type of service byte in the IP header of an RTR probe, use the tos response time reporter configuration command. Use the no form of this command to return to the default value.
tos number
number | Service type byte in the IP header. The range is 0 to 255. The default is 0. |
The default type of service value is 0.
Response time reporter configuration
This command first appeared in Cisco IOS Release 12.0(3)T.
In the following example, probe 1 is configured as an echo probe using the IP/ICMP Echo protocol and the destination IP address 172.16.1.175. The ToS value is set to 0x80:
rtr 1 type echo protocol ipIcmpEcho 172.16.1.176 tos 0x80
To configure an echo probe, use the type echo response time reporter configuration command. You must configure the probe's type before you can configure any of the other characteristics of the probe. Use the no form of this command to remove the type configuration for the probe.
type echo protocol type type-target
echo | Perform end-to-end RTR operations only. |
protocol type type-target | Protocol used by the probe. Type can be one of the following keywords (whether the keyword is available depends on the Cisco IOS software features installed on your router) followed by the required type parameter: · ipIcmpEcho {ip-address | ip-host-name}---IP/ICMP Echo that requires a destination IP address or IP host name. · snaRUEcho sna-host-name---SNA's SSCP Native Echo that requires the host name defined for the SNA's PU connection to VTAM. · snaLU0EchoAppl sna-host-name [sna-application] [sna-mode]--- SNA LU type 0 connection to Cisco's NSPECHO host application that requires the host name defined for the SNA's PU connection to VTAM. Optionally, specify the host application name (the default is NSPECHO) and SNA mode to access the application. · snaLU2EchoAppl sna-host-name [sna-application] [sna-mode]--- SNA LU type 2 connection to Cisco's NSPECHO host application that requires the host name defined for the SNA's PU connection to VTAM. Optionally, specify the host application name (the default is NSPECHO) and SNA mode to access the application. |
None
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
In the following example, probe 10 is created and configured as echo using the IP/ICMP Echo protocol and the destination IP address 172.16.1.175:
rtr 10 type echo protocol ipIcmpEcho 172.16.1.175
To configure a pathEcho probe, use the type pathEcho response time reporter configuration command. You must configure the probe's type before you can configure any of the other characteristics of the probe. Use the no form of this command to remove the type configuration for the probe.
type pathEcho protocol type type-target
pathEcho | Perform RTR operations using a route discovery algorithm to find a path to the destination and echo each device on the path. |
protocol type type-target | Protocol used by the probe. Type can be one of the following keywords (whether the keyword is available depends on the Cisco IOS software features installed on your router) followed by the required type parameter: · ipIcmpEcho {ip-address | ip-host-name}---IP/ICMP Echo that requires a destination IP address or IP host name. · snaRUEcho sna-host-name---SNA's SSCP Native Echo that requires the host name defined for the SNA's PU connection to VTAM. · snaLU0EchoAppl sna-host-name [sna-application] [sna-mode]--- SNA LU type 0 connection to Cisco's NSPECHO host application that requires the host name defined for the SNA's PU connection to VTAM. Optionally, specify the host application name (the default is NSPECHO) and SNA mode to access the application. · snaLU2EchoAppl sna-host-name [sna-application] [sna-mode]--- SNA LU type 2 connection to Cisco's NSPECHO host application that requires the host name defined for the SNA's PU connection to VTAM. Optionally, specify the host application name (the default is NSPECHO) and SNA mode to access the application. |
None
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
In the following example, probe 10 is created and configured as pathEcho using the IP/ICMP Echo protocol and the destination IP address 172.16.1.175:
rtr 10 type pathEcho protocol ipIcmpEcho 172.16.1.175
To define a tcpConnect probe use the type tcpConnect response time reporter configuration command. Use the no form of this command to remove the type configuration for the probe.
type tcpConnect dest-ipaddr {name | ip addr} dest-port port number [source-ipaddr {name |
dest-ipaddr name | ip addr | Destination of tcpConnect probe. IP host name or IP address. |
dest-port port number | Destination port number. |
source-ipaddr name | ip addr | Source IP host name or IP address. |
source-port port number | (Optional) Port number of the source. When a port number is not specified, RTR picks the best IP address (nearest to the target) and available UDP port. |
control | (Optional) Specifies that the RTR control protocol should be used when running this probe. The control protocol is required when the probe's target is a Cisco router that does not natively provide the service (TCP service in this case). Combined with the enable or disable keyword, enables or disables sending a control message to the destination port. The default is that the control protocol is enabled. |
enable | Enable the RTR collector to send a control message to the destination port prior to sending a probe packet. |
disable | Disable the RTR from sending a control message to the responder prior to sending a probe packet. |
The control protocol is enabled. Prior to sending a probe packet to the responder, the RTR collector sends a control message to the responder to enable the destination port.
Response time reporter configuration
This command first appeared in Cisco IOS Release 12.0(3)T.
You must configure the probe's type before you can configure any of the other characteristics of the probe.
In the following example, probe 11 is created and configured as a tcpConnect probe using the destination IP address 172.16.1.175 and the destination port 2400:
rtr 11 type tcpConnect dest-ipaddr 172.16.1.175 dest-port 2400
To define a udpEcho probe use the type udpEcho response time reporter configuration command. Use the no form of this command to remove the type configuration for the probe.
type udpEcho dest-ipaddr {name | ip addr} dest-port port number [source-ipaddr {name |
dest-ipaddr name | ip addr | Destination of the udpEcho probe. IP host name or IP address. |
dest-port port number | Destination port number. |
source-ipaddr name | ip addr | Source IP host name or IP address. |
source-port port number | (Optional) Port number of the source. When a port number is not specified, RTR picks the best IP address (nearest to the target) and available UDP port |
control | (Optional) Specifies that the RTR control protocol should be used when running this probe. The control protocol is required when the probe's target is a Cisco router that does not natively provide the service (UDP service in this case). Combined with the enable or disable keyword, enables or disables sending of a control message to the destination port. The default is that the control protocol is enabled. |
enable | Enable the RTR collector to send a control message to the destination port prior to sending a probe packet. |
disable | Disable the RTR from sending a control message to the responder prior to sending a probe packet. |
The control protocol is enabled. Prior to sending a probe packet to the responder, the RTR collector sends a control message to the responder to enable the destination port.
Response time reporter configuration
This command first appeared in Cisco IOS Release 12.0(3)T.
You must configure the probe's type before you can configure any of the other characteristics of the probe.
The source IP address and port number are optional. If they are not specified, RTR selects the IP address nearest to the target and an available UDP port.
In the following example, probe 12 is created and configured as udpEcho probe using the destination IP address 172.16.1.175 and destination port 2400:
rtr 12 type udpEcho dest-ipaddr 172.16.1.175 dest-port 2400
To cause the RTR probe to check each response for corruption, use the verify-data response time reporter configuration command. Use the no form of this command to return to the default value.
verify-dataThis command has no arguments or keywords.
Disabled
Response time reporter configuration
This command first appeared in Cisco IOS Release 11.2.
Only use the verify-data command when corruption may be a problem in your network.
| Caution Do not enable this feature during normal operation because it causes unnecessary overhead. Use the verify-data command only if you suspect there is a problem in your network. |
In the following example, probe 5 is configured to verify the data for each response:
rtr 5 type echo protocol ipIcmpEcho 172.16.1.174 request-data-size 2 verify-data
Posted: Mon May 24 08:39:56 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.