-
Cisco IOS Configuration Fundamentals and Network Management Command Reference, Release 12.3 T
-
Introduction
-
CFR Commands: absolute through clock timezone
-
CFR Commands: clock update-calendar through escape-character
-
CFR Commands: event application through ip ftp passive
-
CFR Commands: major rising through periodic
-
CFR Commands: ping through service sequence-numbers
-
CFR Commands: service slave-log through show
tee -
CFR Commands: show context through show ip sla monitor total-statistics
-
CFR Commands [12.3T]: 'show kron schedule' through 'show rtr collection-statistics'
-
CFR Commands: show rtr configuration through snmp-server enable informs
-
CFR Commands: snmp-server enable traps through statistics-distribution-interval
-
CFR Commands: stopbits through ttl ip
-
CFR Commands: type dhcp through xsm vdm
-
Appendix: ASCII Character Set and Hex Values (12.3T CF CR)
-
Table Of Contents
type jitter dest-ipaddr (codec)
type pathEcho protocol ipIcmpEcho
type slm frame-relay interface
type slm frame-relay pvc interface
type voip delay gatekeeper registration
upgrade rom-monitor preference
xsm privilege configuration level
type dhcp
To configure a Cisco IOS IP Service Level Agreements (SLAs) Dynamic Host Configuration Protocol (DHCP) operation, use the type dhcp command in IP SLA monitor configuration or RTR configuration mode.
type dhcp [source-ipaddr {ip-address | hostname}] [dest-ipaddr {ip-address | hostname}] [option 82 [circuit-id circuit-id] [remote-id remote-id] [subnet-mask subnet-mask]]
Syntax Description
Defaults
No IP SLAs operation type is configured for the operation being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
12.0(5)T
This command was introduced.
12.1(1)T
The following keywords were added:
•
source-ipaddr
•
•
Usage Guidelines
If the source IP address is configured, then packets will be sent with that source address.
You may configure the ip dhcp-server global configuration command to identify the DHCP server that the DHCP operation will measure. If the target IP address is configured, then only that device will be measured. If the ip dhcp-server command is not configured and the target IP address is not configured, then DHCP discover packets will be sent on every available IP interface.
Option 82 is called the Relay Agent Information option and is inserted by the DHCP relay agent when client-originated DHCP packets are forwarded to a DHCP server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client.
The Relay Agent Information option is organized as a single DHCP option that contains one or more suboptions that convey information known by the relay agent. The initial suboptions are defined for a relay agent that is colocated in a public circuit access unit. These suboptions are as follows: a circuit ID for the incoming circuit, a remote ID that provides a trusted identifier for the remote high-speed modem, and a subnet mask designation for the logical IP subnet from which the relay agent received the client DHCP packet.
Note
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 193). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation number 4 is configured as a DHCP operation enabled for DHCP server 172.16.20.3. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 193).
IP SLA Monitor Configuration
ip sla monitor 4type dhcp option 82 circuit-id 10005A6F1234ip dhcp-server 172.16.20.3!ip sla monitor schedule 4 start-time nowRTR Configuration
rtr 4type dhcp option 82 circuit-id 10005A6F1234ip dhcp-server 172.16.20.3!rtr schedule 4 start-time nowRelated Commands
type dlsw peer-ipaddr
To configure a Cisco IOS IP Service Level Agreements (SLAs) Data Link Switching Plus (DLSw+) operation, use the type dlsw peer-ipaddr command in IP SLA monitor configuration or RTR configuration mode.
type dlsw peer-ipaddr ip-address
Syntax Description
Defaults
No IP SLAs operation type is configured for the operation being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
To configure an IP SLAs DLSw+ operation, the DLSw feature must be configured on the local and target routers.
For DLSw+ operations, the default request packet data size is 0 bytes (use the request-data-size command to modify this value) and the default amount of time the operation waits for a response from the request packet is 30 seconds (use the timeout command to modify this value).
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 194). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation number 10 is configured as a DLSw+ operation enabled for remote peer IP address 172.21.27.11. The data size is 15 bytes. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 194).
IP SLA Monitor Configuration
ip sla monitor 10type dlsw peer-ipaddr 172.21.27.11request-data-size 15!ip sla monitor schedule 10 start-time nowRTR Configuration
rtr 10type dlsw peer-ipaddr 172.21.27.11request-data-size 15!rtr schedule 10 start-time nowRelated Commands
type dns target-addr
To configure a Cisco IOS IP Service Level Agreements (SLAs) Domain Name System (DNS) operation, use the type dns target-addr command in IP SLA monitor configuration or RTR configuration mode.
type dns target-addr {target-hostname | target-ip-address} name-server ip-address [source-ipaddr {ip-address | hostname} source-port port-number]
Syntax Description
Defaults
No IP SLAs operation type is configured for the operation being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 195). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation 7 is configured as a DNS operation using the target IP address 172.20.2.132. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 195).
IP SLA Monitor Configuration
ip sla monitor 7type dns target-addr host1 name-server 172.20.2.132!ip sla monitor schedule 7 start-time nowRTR Configuration
rtr 7type dns target-addr host1 name-server 172.20.2.132!rtr schedule 7 start-time nowRelated Commands
type echo protocol ipIcmpEcho
To configure an IP Service Level Agreements (SLAs) Internet Control Message Protocol (ICMP) echo operation, use the type echo protocol ipIcmpEcho command in IP SLA monitor configuration or RTR configuration mode.
type echo protocol ipIcmpEcho {destination-ip-address | destination-hostname} [source-ipaddr {ip-address | hostname} | source-interface interface-name]
Syntax Description
Defaults
No IP SLAs operation type is configured for the operation being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
The default request packet data size for an ICMP echo operation is 28 bytes. Use the request-data-size command to modify this value. This data size is the payload portion of the ICMP packet, which makes a 64-byte IP packet.
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 196). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation 10 is created and configured as an echo operation using the IP/ICMP protocol and the destination IP address 172.16.1.175. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 196).
IP SLA Monitor Configuration
ip sla monitor 10type echo protocol ipIcmpEcho 172.16.1.175!ip sla monitor schedule 10 start-time nowRTR Configuration
rtr 10type echo protocol ipIcmpEcho 172.16.1.175!rtr schedule 10 start-time nowRelated Commands
type frame-relay interface
To measure response time, frame loss, or data corruption across a Frame Relay permanent virtual circuit (PVC) using Cisco IOS IP Service Level Agreements (SLAs), use the type frame-relay interface command in IP SLA monitor configuration or RTR configuration mode.
type frame-relay interface interface-id dlci dlci-number
Syntax Description
Defaults
No IP SLAs operation type is configured for the operation ID being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
The IP SLAs Responder must be enabled on the target router before this command is used.
If the first measurement does not have the correct values for frames sent and frames lost, the IP SLAs Frame Relay operation cannot work properly. There need to be at least two successful measurements for the frames sent and frames lost values to be correct.
If the encapsulation on the target interface is not Frame Relay (for example, if the encapsulation is changed), the Frame Relay operation will be removed automatically from the configuration.
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 197). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, an IP SLAs Frame Relay operation is configured to be sent from serial interface 2/0 using DLCI subinterface 22. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 197).
IP SLA Monitor Configuration
ip sla monitor 1type frame-relay interface serial 2/0 dlci 22!ip sla monitor schedule 1 start-time nowRTR Configuration
rtr 1type frame-relay interface serial 2/0 dlci 22!rtr schedule 1 start-time nowRelated Commands
type ftp operation get url
To configure a Cisco IOS IP Service Level Agreements (SLAs) File Transfer Protocol (FTP) GET operation, use the type ftp operation get url command in IP SLA monitor configuration or RTR configuration mode.
type ftp operation get url url [source-ipaddr {ip-address | hostname}] [mode {passive | active}
Syntax Description
Defaults
No IP SLAs operation type is configured for the operation being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
The url argument must be in one of the following formats:
•
•
If the username and password are not specified, the defaults are anonymous and test, respectively.
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 198). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, an FTP operation is configured. User1 is the username and password1 is the password; host1 is the host and file1 is the filename. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 198).
IP SLA Monitor Configuration
ip sla monitor 3type ftp operation get url ftp://user1:password1@host1/file1!ip sla monitor schedule 3 start-time nowRTR Configuration
rtr 3type ftp operation get url ftp://user1:password1@host1/file1!rtr schedule 3 start-time nowRelated Commands
type http operation
To configure a Cisco IOS IP Service Level Agreements (SLAs) HTTP operation, use the type http operation command in IP SLA monitor configuration or RTR configuration mode.
type http operation {get | raw} url url [name-server ip-address] [version version-number] [source-ipaddr {ip-address | hostname}] [source-port port-number] [cache {enable | disable}] [proxy proxy-url]
Syntax Description
Defaults
No IP SLAs operation type is configured for the operation being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 199). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs HTTP operation 6 is configured as an HTTP RAW operation. The destination URL is http://www.cisco.com. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 199).
IP SLA Monitor Configuration
ip sla monitor 6type http operation raw url http://www.cisco.comhttp-raw-requestGET /index.html HTTP/1.0\r\n\r\n!ip sla monitor schedule 6 start-time nowRTR Configuration
rtr 6type http operation raw url http://www.cisco.comhttp-raw-requestGET /index.html HTTP/1.0\r\n\r\n!rtr schedule 6 start-time nowRelated Commands
type jitter dest-ipaddr
To configure a Cisco IOS IP Service Level Agreements (SLAs) User Datagram Protocol (UDP) jitter operation, use the type jitter dest-ipaddr command in IP SLA monitor configuration or RTR configuration mode.
type jitter dest-ipaddr {destination-ip-address | destination-hostname} dest-port port-number [source-ipaddr {ip-address | hostname}] [source-port port-number] [control {enable | disable}] [num-packets number-of-packets] [interval interpacket-interval]
Syntax Description
Defaults
No IP SLAs operation type is configured for the operation being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
The type jitter dest-ipaddr command configures an IP SLAs UDP Plus operation. The UDP Plus operation is a superset of the UDP echo operation. In addition to measuring UDP round-trip time, the UDP Plus operation measures per-direction packet loss and jitter. Jitter is interpacket delay variance. Jitter statistics are useful for analyzing traffic in a Voice over IP (VoIP) network.
You must enable the IP SLAs Responder on the target router before you can configure a UDP jitter operation. Prior to sending an operation packet to the target router, IP SLAs sends a control message to the IP SLAs Responder to enable the destination port.
The default request packet data size for an IP SLAs UDP jitter operation is 32 bytes. Use the request-data-size command to modify this value.
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 200). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, operation 6 is configured as a UDP jitter operation with the destination IP address 172.30.125.15, the destination port number 2000, 20 packets, and an interpacket interval of 20 ms. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 200).
IP SLA Monitor Configuration
ip sla monitor 6type jitter dest-ipaddr 172.30.125.15 dest-port 2000 num-packets 20 interval 20!ip sla monitor schedule 6 start-time nowRTR Configuration
rtr 6type jitter dest-ipaddr 172.30.125.15 dest-port 2000 num-packets 20 interval 20!rtr schedule 6 start-time nowRelated Commands
type jitter dest-ipaddr (codec)
To configure a Cisco IOS IP Service Level Agreements (SLAs) User Datagram Protocol (UDP) jitter operation that returns Voice over IP (VoIP) scores, use the type jitter dest-ipaddr command in IP SLA monitor configuration or RTR configuration mode.
type jitter dest-ipaddr {ip-address | hostname} dest-port port-number codec codec-type [codec-numpackets number-of-packets] [codec-size number-of-bytes] [codec-interval milliseconds] [advantage-factor value] [source-ipaddr {ip-address | hostname}] [source-port port-number] [control {enable | disable}]
Syntax Description
destination-ip-address | destination-hostname
Specifies the destination IP address or hostname.
dest-port port-number
Specifies the destination port number. For UDP jitter (codec) operations, the port number should be an even number in the range of 16384 to 32766 or 49152 to 65534.
codec codec-type
Enables the generation of estimated voice-quality scores in the form of Calculated Planning Impairment Factor (ICPIF) and Mean Opinion Score (MOS) values. The codec type should match the encoding algorithm you are using for VoIP transmissions.
The following codec-type keywords are available:
•
•
•
Configuring the codec type sets default values for the variables codec-numpackets, codec-size, and codec-interval in this command. See Table 201 for details.
codec-numpackets number-of-packets
(Optional) Specifies the number of packets to be transmitted per operation. The valid range is from 1 to 60000 packets. The default is 1000 packets.
codec-size number-of-bytes
(Optional) Specifies the number of bytes in each packet transmitted. (Also called the payload size or request size.) The valid range is from 16 to 1500 packets. The default varies by codec (see Table 201).
codec-interval milliseconds
Specifies the interval (delay) between packets that should be used for the operation, in milliseconds (ms). The valid range is from 1 to 60000 ms. By default, packets are sent 20 ms apart.
advantage-factor value
Specifies the expectation factor to be used for ICPIF calculations. This value is subtracted from the measured impairments to yield the final ICPIF value (and corresponding MOS value). See the "Usage Guidelines" section for recommended values. The valid range is from 0 to 20. The default is 0.
source-ipaddr {ip-address | hostname}
(Optional) Specifies the source IP address or hostname. When a source IP address or hostname is not specified, IP SLAs chooses the IP address nearest to the destination.
source-port port-number
(Optional) Specifies the source port number. When a port number is not specified, IP SLAs chooses an available port.
control {enable | disable}
(Optional) Enables or disables the sending of IP SLAs control messages to the IP SLAs Responder.
By default, IP SLAs control messages are sent to the destination device to establish a connection with the IP SLAs Responder.
Note
Defaults
No IP SLAs operation type is associated with the operation number being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
The type jitter dest-ipaddr (codec) command is a special implementation of the type jitter dest-ipaddr command. This command is documented separately from the standard type jitter dest-ipaddr command because when you specify the codec in the command syntax, the standard configuration options are replaced with codec-specific keywords and arguments.
You must enable the IP SLAs Responder on the target router before you can configure a UDP jitter (codec) operation. Prior to sending an operation packet to the target router, IP SLAs sends a control message to the IP SLAs Responder to enable the destination port.
IP SLAs UDP Jitter (codec) Statistics
The IP SLAs UDP jitter operation computes statistics by sending n UDP packets, each of size s, sent t milliseconds apart, from a given source router to a given target router, at a given frequency f.
To generate MOS and ICPIF scores, you specify the codec type used for the connection when configuring the UDP jitter operation. Based on the type of codec you configure for the operation, the number of packets (n), the size of each payload (s), the inter-packet time interval (t), and the operational frequency (f) will be auto-configured with default values. (See Table 201 for specific information.) However, you are given the option, if needed, to manually configure these parameters in the syntax of the type jitter dest-ipaddr (codec) command.
Table 201 shows the default parameters that are configured for the operation by codec.
Table 201 Default UDP Jitter Operation Parameters by Codec
G.711 mu-law (g711ulaw)
1000
160 bytes
20 ms
Once every 60 seconds
G.711 a-law (g711alaw)
1000
160 bytes
20 ms
Once every 60 seconds
G.729A (g729a)
1000
20 bytes
20 ms
Once every 60 seconds
1 The actual data size of each request packet will contain an additional 12 bytes of Real-Time Transport Protocol (RTP) header data in order to simulate the RTP/UDP/IP/Layer 2 protocol stack.
For example, if you configure the UDP jitter operation to use the characteristics for the g711ulaw codec, by default an operation will be sent once a minute (f). Each operation would consist of 1000 packets (n), with each packet containing 160 bytes (plus 12 header bytes) of synthetic data (s), sent 20 ms apart (t).
The advantage-factor value keyword and argument allow you to specify an access Advantage Factor (also called the Expectation Factor). Table 202, adapted from ITU-T Rec. G.113, defines a set of provisional maximum values for Advantage Factors in terms of the service provided.
These values are only suggestions. To be meaningful, the use of the Advantage/Expectation factor (A) and its selected value in a specific application should be used consistently in any planning model you adopt. However, the values in Table 202 should be considered as the absolute upper limits for A. The default Advantage/Expectation factor for IP SLAs UDP jitter operations is always zero.
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 203). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation 10 is configured as a UDP jitter (codec) operation with the destination IP address 209.165.200.225 and the destination port number 3000. The operation is configured to use the characteristics of the G.711 a-law codec, which means the operation will consist of 1000 packets, each of 172 bytes (160 plus 12 header bytes), sent 20 ms apart. The default value for the Advantage Factor and operation frequency is used. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 203).
IP SLA Monitor Configuration
ip sla monitor 10type jitter dest-ipaddr 209.165.200.225 dest-port 3000 codec g711alaw!ip sla monitor schedule 10 start-time nowRTR Configuration
rtr 10type jitter dest-ipaddr 209.165.200.225 dest-port 3000 codec g711alaw!rtr schedule 10 start-time nowRelated Commands
type pathEcho protocol ipIcmpEcho
To configure a Cisco IOS IP Service Level Agreements (SLAs) Internet Control Message Protocol (ICMP) path echo operation, use the type pathEcho protocol ipIcmpEcho command in IP SLA monitor configuration or RTR configuration mode.
type pathEcho protocol ipIcmpEcho {destination-ip-address | destination-hostname} [source-ipaddr {ip-address | hostname}]
Syntax Description
Defaults
No IP SLAs operation type is configured for the operation being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 204). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation 10 is configured as an ICMP path echo operation using the IP/ICMP protocol and the destination IP address 172.16.1.175. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 204).
IP SLA Monitor Configuration
ip sla monitor 10type pathEcho protocol ipIcmpEcho 172.16.1.175!ip sla monitor schedule 10 start-time nowRTR Configuration
rtr 10type pathEcho protocol ipIcmpEcho 172.16.1.175!rtr schedule 10 start-time nowRelated Commands
type pathJitter dest-ipaddr
To configure a Cisco IOS IP Service Level Agreements (SLAs) Internet Control Message Protocol (ICMP) path jitter operation, use the type pathJitter dest-ipaddr command in IP SLA monitor configuration or RTR configuration mode.
type pathJitter dest-ipaddr {destination-ip-address | destination-hostname} [source-ipaddr {ip-address | hostname}] [num-packets packet-number] [interval milliseconds] [targetOnly]
Syntax Description
Defaults
No IP SLAs operation type is configured for the operation number being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
If the targetOnly keyword is used, the ICMP path jitter operation will send echoes to the destination only (the path from the source to the destination is not traced).
If the targetOnly keyword is not used, the IP SLAs ICMP path jitter operation will trace a "hop-by-hop" IP path from the source to the destination and then send a user-specified number of test packets to each hop along the traced path at user-specified time intervals.
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 205). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
The following examples show how to enable the ICMP path jitter operation to trace the IP path to the destination 172.69.5.6 and send 50 test packets to each hop with an interval of 30 ms between each test packet. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 205).
IP SLA Monitor Configuration
ip sla monitor 2type pathJitter dest-ipaddress 172.69.5.6 num-packets 50 interval 30!ip sla monitor schedule 2 start-time nowRTR Configuration
rtr 2type pathJitter dest-ipaddress 172.69.5.6 num-packets 50 interval 30!rtr schedule 2 start-time nowRelated Commands
type slm atm interface
To configure a Cisco IOS IP Service Level Agreements (SLAs) operation as a Service Level Monitoring (SLM) Asynchronous Transfer Mode (ATM) interface operation, and specify the interface that the operation should be run on, use the type slm atm interface command in IP SLA monitor configuration or RTR configuration mode.
type slm atm interface interface-type interface-number
Syntax Description
Defaults
No IP SLAs operation type is configured for the operation number being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
12.2(15)T
This command was introduced. This command replaces the type atm slm interface command.
Usage Guidelines
The IP SLAs SLM ATM interface operation provides monitoring data for an ATM connection at the link layer. The type slm atm interface command specifies the operation type and the interface that the operation should be run on. The specified interface should be configured for ATM.
The ATM interface link statistics are used to monitor the basic health of an ATM interface. This information includes some traffic counters, assorted error counts, and some performance-related counters.
For SLM ATM operations to function properly, the operation should be configured on the interface on both ends of the ATM connection. The atm slm statistics command should also be used to enable data collection.
Statistics gathered with this operation can be retrieved from external network monitoring applications through the Cisco Networking Services (CNS) event gateway.
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 206). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation 2 is configured as an SLM ATM interface operation. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 206).
IP SLA Monitor Configuration
atm slm statisticsip sla monitor 2type slm atm interface ATM 1/1/0enhanced-history interval 900 buckets 100!ip sla monitor schedule 2 start-time now life foreverRTR Configuration
atm slm statisticsrtr 2type slm atm interface ATM 1/1/0enhanced-history interval 900 buckets 100!rtr schedule 2 start-time now life foreverRelated Commands
type slm atm pvc interface
To configure a Cisco IOS IP Service Level Agreements (SLAs) operation as a Service Level Monitoring (SLM) Asynchronous Transfer Mode (ATM) permanent virtual circuit (PVC) operation, and specify the interface that the operation should be run on, use the type slm atm pvc interface command in IP SLA monitor configuration or RTR configuration mode.
type slm atm pvc interface interface-type interface-number dlci
Syntax Description
interface-type
Interface type (ATM).
interface-number
Interface number (slot/port).
dlci
Data-link connection identifier (DLCI) of the PVC to be monitored (also called the PVC number).
Defaults
No IP SLAs operation type is configured for the operation number being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
12.2(15)T
This command was introduced. This command replaces the type slm interface (atm) command introduced in Cisco IOS Release 12.2(11)T.
Usage Guidelines
This command specifies that the operation is an IP SLAs SLM ATM circuit operation, which provides data for the specified circuit. The specified interface should be configured with a PVC connection.
The ATM circuit statistics are used to monitor the basic health of an ATM circuit. This information includes some traffic counters, assorted error counts, and some performance-related counters.
For SLM ATM operations to function properly, the operation should be configured on the interface on both ends of the ATM connection. The atm slm statistics command should also be used to enable data collection.
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 207). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation 3 is configured as an SLM ATM circuit operation. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 207).
IP SLA Monitor Configuration
atm slm statisticsip sla monitor 3type slm atm pvc interface ATM0:1 100/100enhanced-history interval 900 buckets 100!ip sla monitor schedule 3 start-time now life foreverRTR Configuration
atm slm statisticsrtr 3type slm atm pvc interface ATM0:1 100/100enhanced-history interval 900 buckets 100!rtr schedule 3 start-time now life foreverRelated Commands
type slm controller
To configure a Cisco IOS IP Service Level Agreements (SLAs) operation as a Service Level Monitoring (SLM) interface operation, and to specify the interface that the operation should be run on, use the type slm controller command in IP SLA monitor configuration or RTR configuration mode.
type slm controller controller-type controller-number
Syntax Description
controller-type
Controller type. Valid controller types are E1, E3, T1, and T3.
controller-number
Controller number (slot/port).
Defaults
No IP SLAs operation type is configured for the operation number being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
12.2(15)T
This command was introduced. This command replaces the type t1-slm command.
12.3(1)
Support for controllers configured for Frame Relay was added.
Usage Guidelines
This command specifies that the IP SLAs operation is an SLM physical controller operation, which provides information about the data-link layer connection, and specifies the controller that the operation should be run on.
Controllers that can be monitored using this operation are T1, E1, T3, and E3.
The specified controller should be configured for Frame Relay or ATM.
For SLM Frame Relay operations to function properly, use the ip sla monitor slm frame-relay statistics or rtr slm frame-relay statistics global configuration command to enable data collection.
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 208). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation 1 is configured as an SLM controller operation. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 208).
IP SLA Monitor Configuration
ip sla monitor slm frame-relay statisticsip sla monitor 1type slm controller T1 0enhanced-history interval 900 buckets 100!ip sla monitor schedule 1 start-time now life foreverRTR Configuration
rtr slm frame-relay statisticsrtr 1type slm controller T1 0enhanced-history interval 900 buckets 100!rtr schedule 1 start-time now life foreverRelated Commands
type slm frame-relay interface
To configure a Cisco IOS IP Service Level Agreements (SLAs) operation as a Service Level Monitoring (SLM) Frame Relay (FR) interface operation, and to specify the interface that the operation should be run on, use the type slm frame-relay interface command in IP SLA monitor configuration or RTR configuration mode.
type slm frame-relay interface interface-type interface-number
Syntax Description
Defaults
No IP SLAs operation type is associated with the operation number being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
The IP SLAs SLM Frame Relay interface operation provides Frame Relay link (Layer 2) layer data. The type slm frame-relay interface command specifies the operation type and the interface that the operation should be run on. The specified interface should be configured for Frame Relay.
Frame Relay interface link statistics are used to monitor the basic health of a Frame Relay interface. This information includes some traffic counters, assorted error counts, and some performance-related counters.
For SLM Frame Relay operations to function properly, use the ip sla monitor slm frame-relay statistics or rtr slm frame-relay statistics global configuration command to enable data collection.
Statistics gathered with this operation can be retrieved from external network monitoring applications through the Cisco Networking Services (CNS) event gateway.
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 209). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation 2 is configured as an SLM Frame Relay interface operation. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 209).
IP SLA Monitor Configuration
ip sla monitor slm frame-relay statisticsip sla monitor 2type slm frame-relay interface Serial0:0enhanced-history interval 900 buckets 100!ip sla monitor schedule 2 start-time now life foreverRTR Configuration
rtr slm frame-relay statisticsrtr 2type slm frame-relay interface Serial0:0enhanced-history interval 900 buckets 100!rtr schedule 2 start-time now life foreverRelated Commands
type slm frame-relay pvc interface
To configure a Cisco IOS IP Service Level Agreements (SLAs) operation as a Service Level Monitoring (SLM) Frame Relay permanent virtual circuit (PVC) operation, and specify the interface that the operation should be run on, use the type slm frame-relay pvc interface command in IP SLA monitor configuration or RTR configuration mode.
type slm frame-relay pvc interface interface-type interface-number dlci
Syntax Description
interface-type
Interface type (serial).
interface-number
Interface number.
dlci
Data-link connection identifier (DLCI) of the PVC to be monitored.
Defaults
No IP SLAs operation type is associated with the operation number being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
This command specifies that the operation is an IP SLAs SLM Frame Relay PVC operation, which provides data for the specified circuit. The specified interface should be configured with a PVC connection.
The Frame Relay PVC statistics are used to monitor the basic health of a Frame Relay circuit. This information includes some traffic counters, assorted error counts, and some performance-related counters.
For SLM Frame Relay operations to function properly, use the ip sla monitor slm frame-relay statistics or rtr slm frame-relay statistics global configuration command to enable data collection.
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 210). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation 3 is configured as an SLM Frame Relay PVC operation. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 210).
IP SLA Monitor Configuration
ip sla monitor slm frame-relay statisticsip sla monitor 3type slm frame-relay pvc interface Serial0:0 111enhanced-history interval 900 buckets 100!ip sla monitor schedule 3 start-time now life foreverRTR Configuration
rtr slm frame-relay statisticsrtr 3type slm frame-relay pvc interface Serial0:0 111enhanced-history interval 900 buckets 100!rtr schedule 3 start-time now life foreverRelated Commands
type slm interface
To configure a Cisco IOS IP Service Level Agreements (SLAs) operation as a Service Level Monitoring (SLM) interface operation, and to specify the interface that the operation should be run on, use the type slm interface command in IP SLA monitor configuration or RTR configuration mode.
type slm interface interface-type interface-number
Syntax Description
interface-type
Interface type. Valid interface types are serial and FR-ATM. Alternatively, an Inverse Multiplexing over ATM (IMA) group number can be specified.
interface-number
Interface number.
Defaults
No IP SLAs operation type is associated with the operation number being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
This command specifies that the operation is an SLM physical interface operation, which provides information about the data-link layer connection. The specified interface should be configured for Frame Relay or ATM.
Interfaces that can be monitored using this operation are serial or high speed serial interface (HSSI) for Frame Relay interfaces, and IMA for ATM interfaces. To specify an HSSI interface, use the serial keyword for the interface type.
For SLM ATM operations to function properly, use the atm slm statistics global configuration command to enable data collection.
For SLM Frame Relay operations to function properly, use the ip sla monitor slm frame-relay statistics or rtr slm frame-relay statistics global configuration command to enable data collection, respectively.
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 211). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation 1 is configured as an SLM interface operation for a Frame Relay interface. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 211).
IP SLA Monitor Configuration
ip sla monitor slm frame-relay statisticsip sla monitor 1type slm interface Serial 0.1enhanced-history interval 900 buckets 100!ip sla monitor schedule 1 start-time now life foreverRTR Configuration
rtr slm frame-relay statisticsrtr 1type slm interface Serial 0.1enhanced-history interval 900 buckets 100!rtr schedule 1 start-time now life foreverRelated Commands
type tcpConnect dest-ipaddr
To define a Cisco IOS IP Service Level Agreements (SLAs) Transmission Control Protocol (TCP) connection operation, use the type tcpConnect dest-ipaddr command in IP SLA monitor configuration or RTR configuration mode.
type tcpConnect dest-ipaddr {destination-ip-address | destination-hostname} dest-port port-number [source-ipaddr {ip-address | hostname} source-port port-number] [control {enable | disable}]
Syntax Description
Defaults
No IP SLAs operation type is associated with the operation number being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
The TCP connection operation is used to discover the time required to connect to the target device. This operation can be used to test virtual circuit availability or application availability. If the target is a Cisco router, then IP SLAs makes a TCP connection to any port number specified by the user. If the destination is a non-Cisco IP host, then the user must specify a known target port number (for example, 21 for FTP, 23 for Telnet, or 80 for HTTP server). This operation is useful in testing Telnet or HTTP connection times.
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 212). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation 11 is configured as a TCP connection operation using the destination IP address 172.16.1.175 and the destination port 2400. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 212).
IP SLA Monitor Configuration
ip sla monitor 11type tcpConnect dest-ipaddr 172.16.1.175 dest-port 2400!ip sla monitor schedule 11 start-time now life foreverRTR Configuration
rtr 11type tcpConnect dest-ipaddr 172.16.1.175 dest-port 2400!rtr schedule 11 start-time now life foreverRelated Commands
type udpEcho dest-ipaddr
To define a Cisco IOS IP Service Level Agreements (SLAs) User Datagram Protocol (UDP) echo operation, use the type udpEcho dest-ipaddr command in IP SLA monitor configuration or RTR configuration mode.
type udpEcho dest-ipaddr {ip-address | hostname} dest-port port-number [source-ipaddr {ip-address | hostname} source-port port-number] [control {enable | disable}]
Syntax Description
Defaults
No IP SLAs operation type is associated with the operation number being configured.
Command Modes
IP SLA monitor configuration (config-sla-monitor)
RTR configuration (config-rtr)Command History
Usage Guidelines
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 213). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor or no rtr global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following examples, IP SLAs operation 12 is configured as a UDP echo operation using the destination IP address 172.16.1.175 and destination port 2400. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 213).
IP SLA Monitor Configuration
ip sla monitor 12type udpEcho dest-ipaddr 172.16.1.175 dest-port 2400!ip sla monitor schedule 12 start-time now life foreverRTR Configuration
rtr 12type udpEcho dest-ipaddr 172.16.1.175 dest-port 2400!rtr schedule 12 start-time now life foreverRelated Commands
type voip delay gatekeeper registration
To configure a Cisco IOS IP Service Level Agreements (SLAs) Voice over IP (VoIP) gatekeeper delay operation, use the type voip delay gatekeeper registration command in IP SLA monitor configuration mode.
type voip delay gatekeeper registration
Syntax Description
This command has no arguments or keywords.
Command Default
No IP SLAs operation type is associated with the operation number being configured.
Command Modes
IP SLA monitor configuration
Command History
Usage Guidelines
The IP SLAs gatekeeper registration delay operation provides statistical data on the amount of time taken to register a gateway to a gatekeeper. IP SLAs was designed to gather information over time, at intervals you specify, so that statistics can be provided on key metrics often used in Service Level Agreements (SLAs). Aggregated totals, median, or average data can be viewed using the Cisco IOS command-line interface (CLI) on the device running the IP SLAs operation, or retrieved from the device by external applications using Simple Network Management Protocol (SNMP).
You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation. To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor global configuration command) and then reconfigure the operation with the new operation type.
Examples
In the following example, IP SLAs operation 10 is configured as a VoIP gatekeeper registration delay operation:
ip sla monitor 10type voip delay gatekeeper registration!ip sla monitor schedule 10 start-time now life foreverRelated Commands
ip sla monitor
Begins configuration for an IP SLAs operation and enters IP SLA monitor configuration mode.
type voip delay post-dial
To configure a Cisco IOS IP Service Level Agreements (SLAs) Voice over IP (VoIP) call setup (post-dial delay) operation, use the type voip delay post-dial command in IP SLA monitor configuration mode.
type voip delay post-dial [detect-point {alert-ringing | connect-ok}] destination tag
Syntax Description
Command Default
No IP SLAs operation type is configured for the operation being configured.
Command Modes
IP SLA monitor configuration
Command History
Usage Guidelines
In order to use the IP SLAs VoIP call setup functionality, your Cisco IOS software image must support the IP SLAs VoIP test-call application and IP SLAs VoIP Responder application. To determine if your Cisco IOS software image is configured with these applications, use the show call application voice command in user EXEC or privileged EXEC mode.
Note
If the detect-point keyword is not specified, the response time for the called number to ring is measured by default.
You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation. To change the operation type of an existing IP SLAs operation, you must first delete the IP SLAs operation (using the no ip sla monitor global configuration command) and then reconfigure the operation with the new operation type.
Examples
The following example shows how to configure an originating gateway to start the IP SLAs VoIP test-call application, set up the dial peer to route the test call, define the VoIP call setup operation, and schedule the VoIP call setup operation. In this example, test-call messages are generated using the Session Initiation Protocol (SIP).
call application session start ipsla-testcall ipsla-testcall!dial-peer voice 6789 voipdestination-pattern 6789session target ipv4:172.29.129.123session protocol sipv2!ip sla monitor 1type voip delay post-dial detect-point alert-ringing destination 6789!ip sla monitor schedule 1 start-time now life foreverThe following example shows how to configure a terminating gateway to set up the dial peer and enable the IP SLAs VoIP Responder application to respond to the IP SLAs VoIP call setup test call. In this example, test-call messages are generated using the Session Initiation Protocol (SIP).
dial-peer voice 6789 voipincoming called-number 6789application ipsla-respondersession protocol sipv2Related Commands
undelete
To recover a file marked "deleted" on a Class A Flash file system, use the undelete command in EXEC mode.
undelete index [filesystem:]
Syntax Description
index
A number that indexes the file in the dir command output.
filesystem:
(Optional) A file system containing the file to undelete, followed by a colon.
Defaults
The default file system is the one specified by the cd command.
Command Modes
EXEC
Command History
11.0
This command was introduced for Class A Flash File Systems (platforms include the Cisco 7500 series and Cisco 12000 series).
Usage Guidelines
For Class A Flash file systems, when you delete a file, the Cisco IOS software simply marks the file as deleted, but it does not erase the file. This command allows you to recover a "deleted" file on a specified Flash memory device. You must undelete a file by its index because you could have multiple deleted files with the same name. For example, the "deleted" list could contain multiple configuration files with the name router-config. You undelete by index to indicate which of the many router-config files from the list to undelete. Use the dir command to learn the index number of the file you want to undelete.
You cannot undelete a file if a valid (undeleted) file with the same name exists. Instead, you first delete the existing file and then undelete the file you want. For example, if you had an undeleted version of the router-config file and you wanted to use a previous, deleted version instead, you could not simply undelete the previous version by index. You would first delete the existing router-config file and then undelete the previous router-config file by index. You can delete and undelete a file up to 15 times.
On Class A Flash file systems, if you try to recover the configuration file pointed to by the CONFIG_FILE environment variable, the system prompts you to confirm recovery of the file. This prompt reminds you that the CONFIG_FILE environment variable points to an undeleted file. To permanently delete all files marked "deleted" on a Flash memory device, use the squeeze EXEC command.
For further information on Flash File System types (classes), see http://www.cisco.com/warp/public/63/pcmciamatrix.html.
Examples
In the following example, the deleted file at index 1 is recovered:
Router# show flashSystem flash directory:File Length Name/status1 8972116 c7000-js56i-mz.121-5.T [deleted]2 6765916 c7000-ds-mz.CSCds70452[15738160 bytes used, 1039056 available, 16777216 total]16384K bytes of processor board System flash (Read/Write)Router# undelete 1 flash:Related Commands
delete
Deletes a file on a Flash memory device.
dir
Displays a list of files on a file system.
squeeze
Permanently deletes Flash files by squeezing a Class A Flash file system.
upgrade filesystem monlib
To upgrade the ATA ROM monitor library (monlib) file without erasing file system data, use the upgrade filesystem monlib command in privileged EXEC mode.
upgrade filesystem monlib {disk0 | disk1}
Syntax Description
disk0
Selects disk 0 as the file system to be formatted.
disk1
Selects disk 1 as the file system to be formatted.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
12.3(7)T
This command was introduced.
12.2(25)S
This command was integrated into the Cisco IOS Release 12.2(25)S.
Usage Guidelines
If you attempt to upgrade the ATA monlib file on a disk that has not been formatted on a router running Cisco IOS software, the upgrade operation will fail.
If the amount of space available on the disk for the monlib image is smaller than the monlib image you are trying to upgrade to, the upgrade operation will fail. The amount of space available for the monlib file can be determined by issuing the show disk command with the all keyword specified. The "Disk monlib size" field displays the number of bytes available for the ATA monlib file.
Examples
The following example shows how to upgrade the ATA monlib file on disk 0:
Router# upgrade filesystem monlib disk0Writing Monlib sectors........................................................................................... ..........................................Monlib write completeRelated Commands
format
Formats a Class A or Class C flash file system.
show disk
Displays flash or file system information for a disk.
upgrade rom-monitor file
To reload the Upgrade ROMmon image on a Cisco 7200 VXR or Cisco 7301 router, use the upgrade rom-monitor file command in Privileged EXEC mode.
For the Cisco 7200 VXR router using the NPE-G1, the syntax is:
upgrade rom-monitor file {bootflash [file-path] | disk0 [file-path] | disk1 [file-path] | disk2 [file-path] | flash [file-path] | ftp [file-path] | slot0 [file-path] | slot1 [file-path] | tftp [file-path]}
For the Cisco 7301 router, the syntax is:
upgrade rom-monitor file {flash [file-path] | ftp [file-path] | disk0 [file-path] | tftp [file-path]}
Syntax Description
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
A Cisco 7200 VXR that has an I/O controller card installed has the following additional devices on its chassis: disk 0, disk 1, slot 0, and slot 1.
Examples
The following example of a Cisco 7200 VXR using an I/O controller loads the Upgrade ROMmon image from a disk 1 filename:
Router# upgrade rom-monitor file disk1:C7200_NPEG1_RMFUR.srec.123-4r.T1This command will reload the router. Continue? [yes/no]:yesROMMON image upgrade in progress.Erasing boot flash eeeeeeeeeeeeeeeeeeProgramming boot flash ppppppNow Reloading via hard watchdog timeoutThe following example on a Cisco 7301 router loads the Upgrade ROMmon image from a specified TFTP file location:
Router# upgrade rom-monitor file tftp://00.0.00.0/biff/C7301_RMFUR.srecLoading biff/C7301_RMFUR.srec from 00.0.00.0 (via GigabitEthernet0/1):!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![OK - 392348 bytes]This command will reload the router. Continue? [yes/no]:yesROMMON image upgrade in progress.Erasing boot flash eeeeeeeeeeeeeeeeeeProgramming boot flash pppppNow Reloading via hard watchdog timeoutUnexpected exception, CPSystem Bootstrap, Version 12.2(20031011:151758) [biff]Copyright (c) 2004 by cisco Systems, Inc.Running new upgrade for first timeSystem Bootstrap, Version 12.2(20031011:151758) [biff]Copyright (c) 2004 by cisco Systems, Inc.ROM:Rebooted by watchdog hard resetC7301 platform with 1048576 Kbytes of main memoryUpgrade ROMMON initializedrommon 1 >upgrade rom-monitor preference
To select a ReadOnly or Upgrade ROMmon image to be booted on the next reload of a Cisco 7200 VXR or Cisco 7301router, use the upgrade rom-monitor preference command in privileged EXEC mode.
upgrade rom-monitor preference [readonly | upgrade]
Syntax Description
readonly
Selects the ReadOnly ROMmon image to be booted on the next reload.
upgrade
Selects the Upgrade second ROMmon image to be booted on the next reload.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
After running the upgrade rom-monitor preference command, you must reload the router for the selected ROMmon image to take effect.
Use the rommon-pref command when you are in ROMmon mode.
Examples
The following example applicable to both the Cisco 7200 VXR and Cisco 7301 routers selects the ReadOnly ROMmon image to be booted on the next reload of the router:
Router# upgrade rom-monitor preference readonlyYou are about to mark ReadOnly region of ROMMON for the highest boot preference.Proceed? [confirm]Done! Router must be reloaded for this to take effect.Related Commands
rommon-pref
Selects a ReadOnly or Upgrade ROMmon image to be booted on the next reload when you are in ROMmon mode.
url (bulkstat)
To specify the host that bulk statistics files should be transferred to, use the url command in Bulk Statistics Transfer configuration mode. To remove a previously configured destination host, use the no form of this command.
url {primary | secondary} URL
no url {primary | secondary} URL
Syntax Description
Defaults
No host is specified.
Command Modes
Bulk Statistics Transfer configuration (config-bulk-tr)
Command History
Usage Guidelines
For bulk statistics transfer retry attempts, a single retry consists of an attempt to send to first the primary URL, then to the secondary URL.
Examples
In the following example, an FTP server is used as the primary destination for the bulk statistics file. If a transfer to that address failed, an attempt will be made to send the file to the TFTP server at 209.169.201.162. As no retry command is specified, only one attempt to each destination will be made.
Router(config)# snmp mib bulkstat transfer ifMibTestingRouter(config-bulk-tr)# schema carMibTesting1Router(config-bulk-tr)# schema carMibTesting2Router(config-bulk-tr)# format bulkBinaryRouter(config-bulk-tr)# transfer-interval 60Router(config-bulk-tr)# buffer-size 10000Router(config-bulk-tr)# url primary ftp://user2:pswd@209.169.201.162/functionality/Router(config-bulk-tr)# url secondary tftp://user2@209.169.201.163/tftpboot/Router(config-bulk-tr)# buffer-size 2500000Router(config-bulk-tr)# enableRouter(config-bulk-tr)# exitRouter(config)#Related Commands
user (ERM)
To apply a global policy, create a resource group or add RUs to a resource group, use the user command in ERM configuration mode. To disable applying the policy, use the no form of this command.
user {resource-instance-name resource-user-type resource-policy-name | global global-policy-name | group resource-group-name type resource-user-type}
no user {resource-instance-name resource-user-type resource-policy-name | global global-policy-name | group resource-group-name type resource-user-type}
Syntax Description
Command Default
Disabled
Command Modes
ERM configuration
Command History
Usage Guidelines
This command helps you to apply the various policies (system global, per user local, and user global) to the ROs, RUs, or a group of RUs.
Use the user resource-instance-name resource-user-type resource-policy-name command to apply a specified policy to a RU. This policy is also known as per user local policy or per user template.
Use the user global global-policy-name command to apply a global thresholding policy to all the users.
Use the user group resource-group-name type resource-user-type command to create a resource group and to enter the resource group configuration mode. After creating the resource group, you can add RUs to this resource group using the instance instance-name command and apply the same thresholding policy to all the RUs together against the resource group using the policy policy-name command in resource group configuration mode.
For example, say you have created a resource group with the name lowPrioUsers and iosprocess as the type. You have some low-priority RUs or tasks like HTTP and SNMP, and you want to set a threshold for all the low-priority RUs together, not separately. You must add the RUs to the resource group using the instance instance-name command and then apply a resource policy. If the resource policy you applied sets a minor rising threshold value of 10% for the resource group, then when the accumulated usage of both HTTP and SNMP RUs crosses the 10% mark, a notification is sent to the RUs in the resource group lowPrioUsers. That is, if HTTP usage is 4% and SNMP usage is 7%, then a notification is sent to the resource group. This facility helps to set thresholds for a group of RUs, as it is difficult to set a threshold for every single RU.
Examples
The following example shows how to apply a per user thresholding policy for the resource instance EXEC, resource user type iosprocess, and policy name policy-test1:
Router(config-erm)# user EXEC iosprocess policy-test1The following example shows how to apply a global thresholding policy with policy name global-global-test1:
Router(config-erm)# user global global-global-test1The following example shows how to create a resource group with the group name lowPrioUsers and resource type as iosprocess, and how to add the RU HTTP to the resource group and apply a thresholding policy group-policy1:
Router(config-erm)# user group lowPrioUsers type iosprocessRouter(config-res-group)# instance httpRouter(config-res-group)# policy group-policy1Related Commands
vacant-message
To display an idle terminal message, use the vacant-message command in line configuration mode. To remove the default vacant message or any other vacant message that may have been set, use the no form of this command.
vacant-message [d message d]
no vacant-message
Syntax Description
Defaults
The format of the default vacant message is as follows:
<blank lines>hostname tty# is now available<blank lines>Press RETURN to get started.This message is generated by the system.
Command Modes
Line configuration
Command History
Usage Guidelines
This command enables the banner to be displayed on the screen of an idle terminal. The vacant-message command without any arguments restores the default message.
Follow this command with one or more blank spaces and a delimiting character of your choice. Then enter one or more lines of text, terminating the message with the second occurrence of the delimiting character.
Note
Examples
The following example turns on the system banner and displays this message:
Router(config)# line 0Router(config-line)# vacant-message %Welcome to Cisco Systems, Inc.Press Return to get started.%verify
To verify the checksum of a file on a Flash memory file system, use the verify command in EXEC mode.
verify [/md5 [md5-value]] filesystem:[file-url]
Syntax Description
Defaults
The current working device is the default device (file system).
Command Modes
EXEC
Command History
Usage Guidelines
This command replaces the copy verify and copy verify flash commands.
Use the verify command to verify the checksum of a file before using it.
Each software image that is distributed on disk uses a single checksum for the entire image. This checksum is displayed only when the image is copied into Flash memory; it is not displayed when the image file is copied from one disk to another.
Before loading or duplicating a new image, record the checksum and MD5 information for the image so that you can verify the checksum when you copy the image into Flash memory or onto a server. A variety of image information is available on Cisco.com. For example, you can get the Release, Feature Set, Size, BSD Checksum, Router Checksum, MD5, and Publication Date information by clicking on the image file name prior to downloading it from the Software Center on Cisco.com.
To display the contents of Flash memory, use the show flash command. The Flash contents listing does not include the checksum of individual files. To recompute and verify the image checksum after the image has been copied into Flash memory, use the verify command. Note, however, that the verify command only performs a check on the integrity of the file after it has been saved in the file system. It is possible for a corrupt image to be transferred to the router and saved in the file system without detection. If a corrupt image is transferred successfully to the router, the software will be unable to tell that the image is corrupted and the file will verify successfully.
To use the message-digest5 (MD5) hash algorithm to ensure file validation, use the verify command with the /md5 option. MD5 is an algorithm (defined in RFC 1321) that is used to verify data integrity through the creation of a unique 128-bit message digest. The /md5 option of the verify command allows you to check the integrity of a Cisco IOS software image by comparing its MD5 checksum value against a known MD5 checksum value for the image. MD5 values are now made available on Cisco.com for all Cisco IOS software images for comparison against local system image values.
To perform the MD5 integrity check, issue the verify command using the /md5 keyword. For example, issuing the verify flash:c7200-is-mz.122-2.T.bin /md5 command will calculate and display the MD5 value for the software image. Compare this value with the value available on Cisco.com for this image.
Alternatively, you can get the MD5 value from Cisco.com first, then specify this value in the command syntax. For example, issuing the verify flash:c7200-is-mz.122-2.T.bin /md5 8b5f3062c4caeccae72571440e962233 command will display a message verifying that the MD5 values match or that there is a mismatch. A mismatch in MD5 values means that either the image is corrupt or the wrong MD5 value was entered.
Examples
The following example shows how to use the verify command to check the integrity of the file c7200-js-mz on the Flash memory card inserted in slot 0:
Router# dir slot0:Directory of slot0:/1 -rw- 4720148 Aug 29 1997 17:49:36 hampton/nitro/c7200-j-mz2 -rw- 4767328 Oct 01 1997 18:42:53 c7200-js-mz5 -rw- 639 Oct 02 1997 12:09:32 rally7 -rw- 639 Oct 02 1997 12:37:13 the_time20578304 bytes total (3104544 bytes free)Router# verify slot0:c7200-js-mzVerified slot0:c7200-js-mzIn the following example, the /md5 keyword is used to display the MD5 value for the image:
Router# verify /md5 disk1:Verify filename []? c7200-js-mz.........................................................................................................................................................................................................Done!verify /md5 (disk1:c7200-js-mz) = 0f369ed9e98756f179d4f29d6e7755d3In the following example, the known MD5 value for the image (obtained from Cisco.com) is specified in the verify command, and the system checks the value against the stored value:
Router# verify /md5 disk1:c7200-js-mz ?WORD Expected md5 signature<cr>router# verify /md5 disk1:c7200-js-mz 0f369ed9e98756f179d4f29d6e7755d3.........................................................................................................................................................................................................Done!Verified (disk1:c7200-js-mz) = 0f369ed9e98756f179d4f29d6e7755d3The following example shows how the output of the verify command was enhanced to show the hash value in addition to the entire hash image (CCO hash):
Router# verify disk0:c7200-js-mz%Filesystem does not support verify operationsVerifying file integrity of disk0:c7200-js-mz................................................................................................................................Done !Embedded Hash MD5 :CFA258948C4ECE52085DCF428A426DCDComputed Hash MD5 :CFA258948C4ECE52085DCF428A426DCDCCO Hash MD5 :44A7B9BDDD9638128C35528466318183Signature VerifiedRelated Commands
verify-data (IP SLA)
To cause a Cisco IOS IP Service Level Agreements (SLAs) operation to check each reply packet for data corruption, use the verify-data command in the appropriate submode of IP SLA monitor configuration or RTR configuration mode. To return to the default value, use the no form of this command.
verify-data
no verify-data
Syntax Description
This command has no arguments or keywords.
Defaults
Data is not checked for corruption.
Command Modes
IP SLA Monitor Configuration
Frame Relay configuration (config-sla-monitor-frameRelay)
ICMP echo configuration (config-sla-monitor-echo)
ICMP path echo configuration (config-sla-monitor-pathEcho)
ICMP path jitter configuration (config-sla-monitor-pathJitter)
UDP echo configuration (config-sla-monitor-udp)
UDP jitter configuration (config-sla-monitor-jitter)
VoIP configuration (config-sla-monitor-voip)RTR Configuration
Frame Relay configuration (config-rtr-frameRelay)
ICMP echo configuration (config-rtr-echo)
ICMP path echo configuration (config-rtr-pathEcho)
ICMP path jitter configuration (config-rtr-pathJitter)
UDP echo configuration (config-rtr-udp)
UDP jitter configuration (config-rtr-jitter)
Note
Command History
Usage Guidelines
Use the verify-data command only when data corruption may be an issue.
Note
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 214). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
The configuration mode for the verify-data command varies depending on the Cisco IOS release you are running (see Table 214) and the operation type configured. For example, if you are running Cisco IOS Release 12.4 and the ICMP echo operation type is configured, you would enter the verify-data command in ICMP echo configuration mode (config-sla-monitor-echo) within IP SLA monitor configuration mode.
Examples
In the following examples, IP SLAs ICMP echo operation 5 is configured to verify each reply packet for data corruption. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 214).
IP SLA Monitor Configuration
ip sla monitor 5type echo protocol ipIcmpEcho 172.16.1.174verify-data!ip sla monitor schedule 5 start-time now life foreverRTR Configuration
rtr 5type echo protocol ipIcmpEcho 172.16.1.174verify-data!rtr schedule 5 start-time now life foreverRelated Commands
vrf (IP SLA)
To allow monitoring within Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs) using Cisco IOS IP Service Level Agreements (SLAs) operations, use the vrf command in the appropriate submode of IP SLA monitor configuration or RTR configuration mode.
vrf vrf-name
Syntax Description
Defaults
The MPLS VPN parameter is not configured for the IP SLAs operation.
Command Modes
IP SLA Monitor Configuration
ICMP echo configuration (config-sla-monitor-echo)
ICMP path echo configuration (config-sla-monitor-pathEcho)
ICMP path jitter configuration (config-sla-monitor-pathJitter)
UDP echo configuration (config-sla-monitor-udp)
UDP jitter configuration (config-sla-monitor-jitter)RTR Configuration
ICMP echo configuration (config-rtr-echo)
ICMP path echo configuration (config-rtr-pathEcho)
ICMP path jitter configuration (config-rtr-pathJitter)
UDP echo configuration (config-rtr-udp)
UDP jitter configuration (config-rtr-jitter)
Note
Command History
Usage Guidelines
A VPN is commonly identified using the VPN routing and forwarding (VRF) name. If the vrf vrf-name command is configured for an IP SLAs operation, IP SLAs uses the vrf-name value to identify the VPN for this operation. This command should be used only if it is necessary to measure the response time over the VPN tunnel.
This command is supported only for the following operation types:
•
•
•
•
•
IP SLAs Operation Configuration Dependence on Cisco IOS Release
The Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 215). You must configure the type of IP SLAs operation (such as User Datagram Protocol [UDP] jitter or Internet Control Message Protocol [ICMP] echo) before you can configure any of the other parameters of the operation.
The configuration mode for the vrf (IP SLA) command varies depending on the Cisco IOS release you are running (see Table 215) and the operation type configured. For example, if you are running Cisco IOS Release 12.4 and the ICMP echo operation type is configured, you would enter the vrf (IP SLA) command in ICMP echo configuration mode (config-sla-monitor-echo) within IP SLA monitor configuration mode.
Examples
The following examples illustrate how to configure an IP SLAs ICMP echo operation for an MPLS VPN. These examples show how test traffic can be sent in an already existing VPN tunnel between two endpoints. Note that the Cisco IOS command used to begin configuration for an IP SLAs operation varies depending on the Cisco IOS release you are running (see Table 215).
Note
IP SLA Monitor Configuration
ip sla monitor 1type echo protocol ipIcmpEcho 10.1.1.1vrf vpn1!ip sla monitor schedule 1 start nowRTR Configuration
rtr 1type echo protocol ipIcmpEcho 10.1.1.1vrf vpn1!rtr schedule 1 start nowRelated Commands
warm-reboot
To enable a router to do a warm-reboot, use the warm-reboot command in global configuration mode. To disable warm rebooting, use the no form of this command.
warm-reboot [count number] [uptime minutes]
no warm-reboot count number uptime minutes
Syntax Description
Defaults
Warm rebooting is disabled.
If warm rebooting is enabled, the default value for the count number option is 5 times, and the default value for the uptime minutes option is 5 minutes.Command Modes
Global configuration
Command History
Usage Guidelines
Use the warm-reboot command to enable the router to reload a Cisco IOS image without ROM monitor mode (ROMMON) intervention, in which the image restores read-write data from a previously saved copy in the RAM and starts execution from that point. Unlike a cold reboot, this process does not involve a flash to RAM copy or self-decompression of the image.
Note
Note
Examples
The following example shows how to enable a warm reboot on the router:
Router#(config) warm-reboot count 10 uptime 10Related Commands
where
To list the open sessions, use the where command in EXEC mode.
where
Syntax Description
This command has no arguments or keywords.
Command Modes
EXEC
Command History
Usage Guidelines
The where command displays all open sessions associated with the current terminal line.
The break (Ctrl-Shift-6, x), where, and resume commands are available with all supported connection protocols.
Examples
The following is sample output from the where command:
Router# whereConn Host Address Byte Idle Conn Name1 MATHOM 192.31.7.21 0 0 MATHOM* 2 CHAFF 131.108.12.19 0 0 CHAFFThe asterisk (*) indicates the current terminal session.
Table 216 describes the fields shown in the display.
Related Commands
show line
Displays information about all lines on the system or the specified line.
show sessions
Displays information about open LAT, Telnet, or rlogin connections.
width
To set the terminal screen width, use the width command in line configuration mode. To return to the default screen width, use the no form of this command.
width characters
no width
Syntax Description
Defaults
80 character columns
Command Modes
Line configuration
Command History
Usage Guidelines
By default, the route provides a screen display width of 80 characters. You can reset this value for the current session if it does not meet the needs of your terminal.
The rlogin protocol uses the value of the characters argument to set up terminal parameters on a remote host.
Examples
In the following example the location for line 7 is defined as "console terminal" and the display is set to 132 columns wide:
Router(config)# line 7Router(config-line)# location console terminalRouter(config-line)# width 132Related Commands
terminal width
Sets the number of character columns on the terminal screen for the current session.
write core
To test the configuration of a core dump setup, use the write core command in privileged EXEC mode.
write core [hostname [LINE] | destination-address [LINE]]
Syntax Description
Defaults
If the hostname or destination arguments are not specified, the core dump file is written to the IP address or hostname specified by the exception dump command.
If the LINE keyword is not specified, the name of the core dump file is assigned as the host name of the remote server followed by the word "-core."
Command Modes
Privileged EXEC
Command History
Usage Guidelines
When a router reloads, it is sometimes useful to obtain a full copy of the memory image (called a core dump) to identify the cause of the reload. Core dumps are generally useful to your technical support representative. Not all types of router reloads will produce a core dump.
The write core command causes the router to generate a core dump without reloading, which may be useful if the router is malfunctioning but has not reloaded. The core dump files will be the size of the respective memory regions. It is important to remember that the entire memory region is dumped, not just the memory that is in use.
Caution
Depending on your TFTP server, you might need to create an empty target file to which the router can write the core dump.
Examples
The following example shows how to test the configuration of a core dump setup. In this example, the core dump file is written to the remote server with the host name test.
write core testwrite erase
The write erase command is replaced by the erase nvram: command. See the description of the erase command for more information.
write memory
The write memory command has been replaced by the copy system:running-config nvram: startup-config command. See the description of the copy command for more information.
write mib-data
To save MIB Persistence configuration data to NVRAM, use the write mib-data command in EXEC mode.
write mib-data
Syntax Description
This command has no arguments or keywords.
Command Modes
EXEC
Command History
Usage Guidelines
Any modified MIB data must be written to NVRAM memory using the write mib-data command. If the write mib-data command is not used, modified MIB data is not saved automatically.
Examples
The following example enables Event MIB Persistence and writes MIB data to NVRAM:
Router(config)# snmp mib persist event
Router(config)# end
Router# write mib-data
Related Commands
write network
The write network command is replaced by the copy system:running-config destination-url. See the description of the copy command for more information.
write terminal
The more system:running-config command is replaced by the write terminal command. See the description of the more command for additional information.
xmodem
To copy a Cisco IOS image to a router using the ROM monitor and the Xmodem or Ymodem protocol, use the xmodem command in ROM monitor mode.
xmodem [-c] [-y] [-e] [-f] [-r] [-x] [-s data-rate] [filename]
Syntax Description
Defaults
Xmodem protocol with 8-bit CRC, file downloaded into Flash memory and executed on completion.
Command Modes
ROM monitor
Command History
Usage Guidelines
The Cisco 3600 series routers does not support XBOOT functionality. If your Cisco IOS image is erased or damaged, you cannot load a new image over the network.
Use the xmodem ROM monitor command to download a new system image to your router from a local personal computer (such as a PC, Mac, or UNIX workstation), or a remote computer over a modem connection, to the router's console port. The computer must have a terminal emulation application that supports these protocols.
Cisco 3600 Series Routers
Your router must have enough DRAM to hold the file being transferred, even if you are copying to Flash memory. The image is copied to the first file in internal Flash memory. Any existing files in Flash memory are erased. There is no support for partitions or copying as a second file.
Cisco 1600 Series Routers
If you include the -r option, your router must have enough DRAM to hold the file being transferred. To run from Flash, an image must be positioned as the first file in Flash memory. If you are copying a new image to boot from Flash, erase all existing files first.
Caution
Note
Examples
The following example uses the xmodem -c filename ROM monitor command to copy the file named new-ios-image from a remote or local computer:
rommon > xmodem -c new-ios-imageDo not start the sending program yet...File size Checksum File name1738244 bytes (0x1a8604) 0xdd25 george-admin/c3600-i-mzWARNING: All existing data in bootflash will be lost!Invoke this application only for disaster recovery.Do you wish to continue? y/n [n]: yesReady to receive file new-ios-image ...Related Commands
xsm
To enable XML Subscription Manager (XSM) client access to the device, use the xsm command in global configuration mode. To disable XSM client access to the device, use the no form of this command.
xsm
no xsm
Syntax Description
This command has no arguments or keywords.
Defaults
XSM client access to the device is enabled.
Command Modes
Global configuration
Command History
Usage Guidelines
This command requires that the ip http server command is enabled. Enabling the xsm command also enables the xsm vdm and xsm edm commands. This command must be enabled for the XSM client (such as VPN Device Manager [VDM]) to operate.
Examples
In the following example, access by remote XSM clients to XSM data on the device is disabled:
Router# no xsm
Related Commands
xsm dvdm
To enable switch-specific configuration data (for example, configuring switch ports and VLANs) when running VPN Device Manager (VDM) on a switch, use the xsm dvdm command in global configuration mode. To disable switch-specific configuration data for VDM, use the no form of this command.
xsm dvdm
no xsm dvdm
Syntax Description
This command has no arguments or keywords.
Defaults
Access to switch-specific configuration data is enabled when XSM is enabled.
Command Modes
Global configuration
Command History
12.2(9)YO1
This command was introduced.
12.2(13)T
This command was integrated into Cisco IOS Release 12.2(13)T.
Usage Guidelines
Access to switch-specific configuration data (dVDM) is enabled by default when XSM is enabled.
The no xsm dvdm command allows you to disable only switch-specific XSM data. Note however that disabling dVDM will prevent the VDM application from communicating properly with the device (switch). There is minimal performance impact associated with leaving dVDM enabled.
Examples
In the following example, access to switch-specific configuration data is disabled in XSM:
Router(config)# no xsm dvdm
Related Commands
xsm edm
To grant access to Embedded Device Manager (EDM) monitoring and configuration data, use the xsm edm command in global configuration mode. To cancel access to EDM monitoring and configuration data, use the no form of this command.
xsm edm
no xsm edm
Syntax Description
This command has no arguments or keywords.
Defaults
Access to EDM monitoring and configuration data is granted by default if XSM is enabled.
Command Modes
Global configuration
Command History
Usage Guidelines
This command exists to allow you to disable EDM using the no xsm edm form of the command. EDM is enabled by default when XSM is enabled.
EDM provides the following generic information to the VPN Device Manager (VDM):
•
•
•
•
Note that disabling EDM prevents XSM clients (such as VDM) from working properly and also disables the xsm history edm command. There is minimal performance impact associated with leaving EDM enabled.
Examples
In the following example, access to EDM data is disabled:
Router(config)# xsmRouter(config)# no xsm edmRelated Commands
xsm history edm
To enable statistics collection for the Embedded Device Manager (EDM) on the XML Subscription Manager (XSM) server, use the xsm history edm command in global configuration mode. To disable statistics collection for the EDM on the XSM server, use the no form of this command.
xsm history edm
no xsm history edm
Syntax Description
This command has no arguments or keywords.
Defaults
EDM statistics collection is disabled.
Command Modes
Global configuration
Command History
Usage Guidelines
Use this command to save up to five days of data. Historical information on items such as RAM and CPU utilization is gathered and made available, thus enabling XSM clients (such as VPN Device Manager [VDM]) to display charts and data. Use of this command consumes resources on the device. Disabling this command clears all your historical data, as the XSM server does not save this data between reloads.
Examples
In the following example, statistics collection for the EDM is enabled on the XSM server:
Router(config)# xsmRouter(config)# xsm history edmRelated Commands
xsm history vdm
To enable specific VPN statistics collection on the XML Subscription Manager (XSM) server, use the xsm history vdm command in global configuration mode. To disable collection of specific selected VPN statistics on the XSM server, use the no form of this command.
xsm history vdm
no xsm history vdm
Syntax Description
This command has no arguments or keywords.
Defaults
VPN statistics collecting is disabled.
Command Modes
Global configuration
Command History
Usage Guidelines
With this command enabled, you can save up to five days of data. Historical information on items such as the number of active IKE tunnels, IPSec tunnels, total crypto throughput, and total throughput is gathered and made available, thus enabling XSM clients (such as VPN Device Manager [VDM]) to display charts and data. Use of this command consumes resources on the device. Disabling this command clears all your historical data. The XSM server does not save history data across reloads.
Examples
The following example shows how to enable specific VPN statistics collection on the XSM server:
Router(config)# xsmRouter(config)# xsm history vdmRelated Commands
xsm privilege configuration level
To enable the XML Subscription Manager (XSM) configuration privilege level required to subscribe to XML Request Descriptors (XRDs), use the xsm privilege configuration level command in global configuration mode. To remove a previously configured XSM configuration privilege level, use the no form of this command.
xsm privilege configuration level number
no xsm privilege configuration level number
Syntax Description
Defaults
Level 15
Command Modes
Global configuration
Command History
Usage Guidelines
The privilege level for the xsm privilege configuration level command must be greater than or equal to the privilege level for the xsm privilege monitor level command. For example, if the xsm privilege configuration 7 command is enabled, you need a minimum privilege level of 7 to subscribe to configuration XRDs. The higher the number the higher the privilege level. Trying to set a conflicting range of privilege settings will force the Cisco device to display the following message:
Attempt to set monitor privilege greater than configuration. Privilege denied.You can check the XSM privilege level settings by using the show xsm status command. Use the show xsm xrd-list command to check which privilege level is required for each XRD.
Note
Examples
The following example shows how to set a configuration privilege level of 15, and a monitor privilege level of 11 for subscription to XRDs. Users with a privilege level below 11 are denied access.
xsm privilege configuration level 15xsm privilege monitor level 11Related Commands
privilege
Configures IOS privilege parameters.
xsm privilege monitor level
Enables monitor privilege level to subscribe to XRDs.
xsm privilege monitor level
To enable the XML Subscription Manager (XSM) monitoring privilege level required to subscribe to XML Request Descriptors (XRDs), use the xsm privilege monitor level command in global configuration mode. To remove a previously configured XSM monitoring privilege level, use the no form of this command.
xsm privilege monitor level number
no xsm privilege monitor level number
Syntax Description
Defaults
Level 1
Command Modes
Global configuration
Command History
Usage Guidelines
The privilege level for the xsm privilege monitor level command must be less than or equal to the privilege level for the xsm privilege configuration level command. For example, if the xsm privilege monitor 7 command is enabled, you need a minimum privilege level of 7 to subscribe to monitor XRDs. The higher the number the higher the privilege level. Trying to set a conflicting range of privilege settings will force the Cisco device to display the following message:
Attempt to set monitor privilege greater than configuration. Privilege denied.You can check the XSM privilege level settings by using the show xsm status command. Use the show xsm xrd-list command to check which privilege level is required for each XRD.
Note
Examples
The following example shows how to set a configuration privilege level of 15 and a monitor privilege level of 11 for subscription to XRDs. Users with a privilege level below 11 are denied access.
xsm privilege configuration level 15xsm privilege monitor level 11Related Commands
privilege
Configures IOS privilege parameters.
xsm privilege configuration level
Enables configuration privilege level to subscribe to XRDs.
xsm vdm
To grant access to VPN-specific monitoring and configuration data for the VPN Device Manager (VDM), use the xsm vdm command in global configuration mode. To cancel access to VPN-specific monitoring and configuration data for VDM, use the no form of this command.
xsm vdm
no xsm vdm
Syntax Description
This command has no arguments or keywords.
Defaults
Enabled (Access to VPN-specific monitoring and configuration data for the VDM is granted when XSM is enabled.)
Command Modes
Global configuration
Command History
Usage Guidelines
This command enables access to the following VPN-specific information:
•
•
•
•
•
If XSM is enabled, this command is enabled by default. Access to VPN-specific monitoring and configuration data within XSM can be disabled by using the no form of the command. However, disabling this command will prevent VDM from working properly and will also disable the xsm history vdm command. Leaving this command enabled has minimal performance impact.
Examples
In the following example, access to VPN-specific monitoring and configuration data is disabled:
Router(config)# xsmRouter(config)# no xsm dvmRelated Commands
