Cisco IOS IP SLAs Command Reference

react (tplt-icmp-ech)

To configure reaction and proactive threshold monitoring parameters in an auto IP Service Level Agreements (SLAs) operation template for an Internet Control Message Protocol (ICMP) echo operation, use the react command in the ICMP echo submode of IP SLA template configuration mode. To disable all threshold monitoring or to disable individual monitored elements, use the no form of this command.

react [monitored-element [[action-type {type-of-action}] [threshold-type {average [number-of-measurements] | consecutive [occurrences] | immediate | never | xofy [x-value y-value]}] [threshold-value upper-threshold lower-threshold]]]

no react [monitored-element]

Syntax Description

Command Default

IP SLAs proactive threshold monitoring is disabled.

Command Modes

ICMP echo submode of IP SLA template configuration (config-tplt-icmp-ech)

Command History

Usage Guidelines

This command enables proactive threshold monitoring for one or more elements in the auto IP SLAs operation template being configured and defines the conditions under which the operation makes the transition from pending to active.

You can configure this command multiple times so as to allow reactions for multiple monitored elements.

The no form of this command with one or more keywords can be used to disable individual monitored elements or use the no react command without keywords to disable all proactive threshold monitoring in the auto IP SLAs operation template.

Table 18 lists the default upper and lower thresholds for specific monitored elements.

Only SNMP traps are supported for round-trip time (RTT) violations during non-Jitter operations.

Only syslog messages are supported for non-RTT violations other than timeout, connectionLoss, or verifyError.

Both SNMP traps and syslog messages are supported for timeout, connectionLoss, or verifyError violations only.

SNMP traps for IP SLAs are supported by the CISCO-RTTMON-MIB and CISCO-SYSLOG-MIB. Use the ip sla logging traps command to enable the generation of SNMP system logging messages specific to IP SLAs trap notifications. Use the snmp-server enable traps rtr or snmp-server enable traps syslog command to enable the sending of IP SLAs SNMP trap notifications.

To display the current threshold monitoring configuration for an auto IP SLAs operation, use the show ip sla auto template command.

Examples

The following example shows how to configure operation parameters and proactive threshold monitoring using an auto IP SLAs operation template. In this example, the proactive threshold monitoring configuration for the ICMP echo operation specifies that when three consecutive timeout events occur, an SNMP trap notification should be sent.

Router(config)#ip sla auto template type ip icmp-echo react-to 

Router(config-tplt-icmp-ech)#react timeout action-type traponly threshold-type conecutive 
3

Router(config-tplt-icmp-ech)#end

Router# show ip sla auto template type ip icmp-echo

IP SLAs Auto Template: react-to

    Measure Type: icmp-echo

    Description: 

    .

	.

	.

	Reaction Configuration:

        Reaction Index       : 1

          Reaction           : timeout

          Threshold Type     : Consecutive

          Threshold CountX   : 3

          Threshold CountY   : 5

          Action Type        : Trap Only

Related Commands

react (tplt-icmp-jtr)

To configure reaction and proactive threshold monitoring parameters in an auto IP Service Level Agreements (SLAs) operation template for an Internet Control Message Protocol (ICMP) jitter operation, use the react command in the ICMP jitter submode of IP SLA template configuration mode. To disable all threshold monitoring or to disable individual monitored elements, use the no form of this command.

react [monitored-element [[action-type {type-of-action}] [threshold-type {average [number-of-measurements] | consecutive [occurrences] | immediate | never | xofy [x-value y-value]}] [threshold-value upper-threshold lower-threshold]]]

no react [monitored-element]

Syntax Description

Command Default

IP SLAs proactive threshold monitoring is disabled.

Command Modes

ICMP jitter submode of IP SLA template configuration (config-tplt-icmp-jtr)

Command History

Usage Guidelines

This command enables proactive threshold monitoring for one or more elements in the auto IP SLAs operation template being configured and defines the conditions under which the operation makes the transition from pending to active.

You can configure this command multiple times so as to allow reactions for multiple monitored elements.

The no form of this command with one or more keywords can be used to disable individual monitored elements or use the no form of this command without keywords to disable all proactive threshold monitoring in the auto IP SLAs operation template.

Return-trip time (RTT) reactions for jitter operations are triggered only at the end of the operation and use the latest value for the return-trip time (LatestRTT).

SNMP traps for RTT for jitter operations are based on the average value for the return-trip time (RTTAvg) for the whole operation only and do not include return-trip time values for individual packets sent during the operation.

For Mean opinion score (MOS), values are computed as numbers to two decimal places, from a value of 1.00 (worst quality) to 5.00 (best quality). The number for upper-threshold and lower-threshold is expressed in three digits representing ones, tenths, and hundredths. For example, to express a MOS threshold of 3.20, enter 320. The valid range is from 100 (1.00) to 500 (5.00).

Table 20 lists the default upper and lower thresholds for specific monitored elements.

Only syslog messages are supported for RTTAvg threshold violations.

Only syslog messages are supported for RTT violations during Jitter operations.

Only syslog messages are supported for non-RTT violations other than timeout, connectionLoss, or verifyError.

Both SNMP traps and syslog messages are supported for timeout, connectionLoss, or verifyError violations only.

SNMP traps for IP SLAs are supported by the CISCO-RTTMON-MIB and CISCO-SYSLOG-MIB.

Use the snmp-server enable traps rtr or snmp-server enable traps syslog command to enable the sending of IP SLAs SNMP trap notifications.

Use the ip sla logging traps command to enable the generation of SNMP system logging messages specific to IP SLAs trap notifications. Only system logging messages are supported for RTTAvg threshold violations.

To display the current threshold monitoring configuration settings for an auto IP SLAs operation, use the show ip sla auto template command.

Examples

The following example shows how to configure operation parameters and proactive threshold monitoring using an auto IP SLAs operation template. In this example, the proactive threshold monitoring configuration for the ICMP jitter operation specifies that when three consecutive packet loss events occur, an SNMP trap notification should be sent:

Router(config)#ip sla auto template type ip icmp-jitter react-closs 

Router(config-tplt-icmp-jtr)#react packetloss action-type traponly threshold-type 
conecutive 3

Router(config-tplt-icmp-jtr)#end

Router# show ip sla auto template type ip icmp-jitter

IIP SLAs Auto Template: react

    Measure Type: icmp-jitter

    .

	.

	.

	Reaction Configuration:

        Reaction Index       : 1

          Reaction           : packetLoss

          Threshold Type     : Consecutive

          Threshold Rising   : 3

          Threshold Falling  : 10000

          Threshold CountX   : 3

          Threshold CountY   : 5

          Action Type        : Trap Only

Related Commands

react (tplt-tcp-conn)

To configure reaction and proactive threshold monitoring parameters in an auto IP Service Level Agreements (SLAs) operation template for an Transmission Control Protocol (TCP) connect operation, use the react command in the TCP connect submode of IP SLA template configuration mode. To disable all threshold monitoring or to disable individual monitored elements, use the no form of this command.

react [monitored-element [[action-type {type-of-action}] [threshold-type {average [number-of-measurements] | consecutive [occurrences] | immediate | never | xofy [x-value y-value]}] [threshold-value upper-threshold lower-threshold]]]

no react [monitored-element]

Syntax Description

Command Default

IP SLAs proactive threshold monitoring is disabled.

Command Modes

TCP connect submode of IP SLA template configuration (config-tplt-tcp-conn)

Command History

Usage Guidelines

This command enables proactive threshold monitoring for one or more elements in the auto IP SLAs operation template being configured and defines the conditions under which the operation makes the transition from pending to active.

You can configure this command multiple times so as to allow reactions for multiple monitored elements.

The no form of this command with one or more keywords can be used to disable individual monitored elements or use the no form of this command without keywords to disable all proactive threshold monitoring in the auto IP SLAs operation template.

Table 20 lists the default upper and lower thresholds for specific monitored elements.

Only SNMP traps are supported for return-trip time (RTT) violations during non-Jitter operations.

Only syslog messages are supported for non-RTT violations other than timeout, connectionLoss, or verifyError.

Both SNMP traps and syslog messages are supported for timeout, connectionLoss, or verifyError violations only.

SNMP traps for IP SLAs are supported by the CISCO-RTTMON-MIB and CISCO-SYSLOG-MIB. Use the ip sla logging traps command to enable the generation of SNMP system logging messages specific to IP SLAs trap notifications. Use the snmp-server enable traps rtr or snmp-server enable traps syslog command to enable the sending of IP SLAs SNMP trap notifications.

To display the current threshold monitoring configuration settings for an auto IP SLAs operation, use the show ip sla auto template command.

Examples

The following example shows how to configure operation parameters and proactive threshold monitoring using an auto IP SLAs operation template. In this example, the proactive threshold monitoring configuration for the TCP connect operation specifies that when three timeout connection loss events occur, an SNMP trap notification should be sent:

Router(config)#ip sla auto template type ip tcp-connect react-to 

Router(config-tplt-tcp-conn)#react timout action-type traponly threshold-type conecutive 3

Router(config-tplt-tcp-conn)#end

Router# show ip sla auto template type ip tcp-connect

IP SLAs Auto Template: react-to

    Measure Type: tcp-connect

    Description: 

    .

	.

	.

	Reaction Configuration:

        Reaction Index       : 1

          Reaction           : timeout

          Threshold Type     : Consecutive

          Threshold CountX   : 3

          Threshold CountY   : 5

          Action Type        : Trap Only 

Related Commands

react (tplt-udp-ech)

To configure reaction and proactive threshold monitoring parameters in an auto IP Service Level Agreements (SLAs) operation template for a User Datagram Protocol (UDP) echo operation, use the react command in the UDP echo submode of IP SLA template configuration mode. To disable all threshold monitoring or to disable individual monitored elements, use the no form of this command.

react [monitored-element [[action-type {type-of-action}] [threshold-type {average [number-of-measurements] | consecutive [occurrences] | immediate | never | xofy [x-value y-value]}] [threshold-value upper-threshold lower-threshold]]]

no react [monitored-element]

Syntax Description

Command Default

IP SLAs proactive threshold monitoring is disabled.

Command Modes

UDP echo submode of IP SLA template configuration (config-tplt-udp-ech)

Command History

Usage Guidelines

This command enables proactive threshold monitoring for one or more elements in the auto IP SLAs operation template being configured and defines the conditions under which the operation makes the transition from pending to active.

You can configure this command multiple times to allow reactions for multiple monitored elements.

The no form of this command with one or more keywords can be used to disable individual monitored elements or use the no form of this command without keywords to disable all proactive threshold monitoring in the auto IP SLAs operation template.

Table 20 lists the default upper and lower thresholds for specific monitored elements.

Only SNMP traps are supported for round-trip time (RTT) violations during non-Jitter operations.

Only syslog messages are supported for non-RTT violations other than timeout, connectionLoss, or verifyError.

Both SNMP traps and syslog messages are supported for timeout, connectionLoss, or verifyError violations only.

SNMP traps for IP SLAs are supported by the CISCO-RTTMON-MIB and CISCO-SYSLOG-MIB. Use the ip sla logging traps command to enable the generation of SNMP system logging messages specific to IP SLAs trap notifications. Use the snmp-server enable traps rtr or snmp-server enable traps syslog command to enable the sending of IP SLAs SNMP trap notifications.

To display the current threshold monitoring configuration settings for an auto IP SLAs operation, use the show ip sla auto template command.

Examples

The following example shows how to configure operation parameters and proactive threshold monitoring using an auto IP SLAs operation template. In this example, the proactive threshold monitoring configuration for the UDP echo operation specifies that when three consecutive timeout events occur, an SNMP trap notification is sent:

Router(config)#ip sla auto template type ip udp-echo react-to 

Router(config-tplt-udp-ech)#react timeout action-type traponly threshold-type conecutive 3

Router(config-tplt-udp-ech)#end

Router# show ip sla auto template type ip udp-echo

IP SLAs Auto Template: react-to

    Measure Type: udp-echo

    Description: 

    .

	.

	.

	Reaction Configuration:

        Reaction Index       : 1

          Reaction           : timeout

          Threshold Type     : Consecutive

          Threshold CountX   : 3

          Threshold CountY   : 5

          Action Type        : Trap Only

Related Commands

react (tplt-udp-jtr)

To configure reaction and proactive threshold monitoring parameters in an auto IP Service Level Agreements (SLAs) operation template for an User Datagram Protocol (UDP) jitter operation, use the react command in the UDP jitter submode of IP SLA template configuration mode. To disable all threshold monitoring or to disable individual monitored elements, use the no form of this command.

react [monitored-element [[action-type type-of-action] [threshold-type {average [number-of-measurements] | consecutive [occurrences] | immediate | never | xofy [x-value y-value]}] [threshold-value upper-threshold lower-threshold]]]

no react [monitored-element]

Syntax Description

Command Default

IP SLAs proactive threshold monitoring is disabled.

Command Modes

UDP jitter submode of IP SLA template configuration (config-tplt-udp-jtr)

Command History

Usage Guidelines

This command enables proactive threshold monitoring for one or more elements in the auto IP SLAs operation template being configured and defines the conditions under which the operation makes the transition from pending to active.

You can configure this command multiple times so as to allow reactions for multiple monitored elements.

The no form of this command with one or more keywords can be used to disable individual monitored elements or use the no react command without keywords to disable all proactive threshold monitoring in the auto IP SLAs operation template.

Return-trip time (RTT) reactions for jitter operations are triggered only at the end of the operation and use the latest value for the return-trip time (LatestRTT).

SNMP traps for RTT for jitter operations are based on the average value for the return-trip time (RTTAvg) for the whole operation only and do not include return-trip time values for individual packets sent during the operation.

For Mean opinion score (MOS), values are computed as numbers to two decimal places, from a value of 1.00 (worst quality) to 5.00 (best quality). The numbers for upper-threshold and lower-threshold arguments are expressed in three digits representing ones, tenths, and hundredths. For example, to express a MOS threshold of 3.20, enter 320. The valid range is from 100 (1.00) to 500 (5.00).

Table 20 lists the default upper and lower thresholds for specific monitored elements.

Only syslog messages are supported for RTTAvg threshold violations.

Only syslog messages are supported for RTT violations during Jitter operations.

Only syslog messages are supported for non-RTT violations other than timeout, connectionLoss, or verifyError.

Both SNMP traps and syslog messages are supported for timeout, connectionLoss, or verifyError violations only.

SNMP traps for IP SLAs are supported by the CISCO-RTTMON-MIB and CISCO-SYSLOG-MIB.

Use the snmp-server enable traps rtr or snmp-server enable traps syslog command to enable the sending of IP SLAs SNMP trap notifications.

Use the ip sla logging traps command to enable the generation of SNMP system logging messages specific to IP SLAs trap notifications. Only system logging messages are supported for RTTAvg threshold violations.

To display the current threshold monitoring configuration settings for an auto IP SLAs operation, use the show ip sla auto template command.

Examples

The following example shows how to configure operation parameters and proactive threshold monitoring using an auto IP SLAs operation template. In this example, the proactive threshold monitoring configuration for the UDP jitter operation specifies that when three consecutive timeout events occur, an SNMP trap notification should be sent:

Router(config)#ip sla auto template type ip udp-jitter react-to 

Router(config-tplt-udp-jtr)#react timeout action-type traponly threshold-type conecutive 3

Router(config-tplt-udp-jtr)#end

Router# show ip sla auto template type ip udp-jitter

IP SLAs Auto Template: react-to

    Measure Type: udp-jitter

    Description: 

    .

	.

	.

	Reaction Configuration:

        Reaction Index       : 1

          Reaction           : timeout

          Threshold Type     : Consecutive

          Threshold CountX   : 3

          Threshold CountY   : 5

          Action Type        : Trap Only

Related Commands

reply-dscp-bits

To specify the differentiated services codepoint (DSCP) value for an echo reply packet of a Cisco IOS IP Service Level Agreements (SLAs) label switched path (LSP) Health Monitor operation, use the reply-dscp-bits command in auto IP SLA MPLS parameters configuration mode. To return to the default value, use the no form of this command.

reply-dscp-bits dscp-value

no reply-dscp-bits dscp-value

Syntax Description

Command Default

The DSCP value is 0.

Command Modes

Auto IP SLA MPLS parameters configuration (config-auto-ip-sla-mpls-params)

Command History

Usage Guidelines

You must configure the type of LSP Health Monitor operation (such as LSP ping) before you can configure any of the other parameters of the operation.

Examples

The following example shows how to configure operation parameters, proactive threshold monitoring, and scheduling options using the LSP Health Monitor. In this example, LSP Health Monitor operation 1 is configured to automatically create IP SLAs LSP ping operations for all Border Gateway Protocol (BGP) next hop neighbors in use by all VPN routing and forwarding (VRF) instances associated with the source Provider Edge (PE) router. The DSCP value for the echo reply packets of IP SLAs operations created by LSP Health Monitor operation 1 is set to 5.

mpls discovery vpn interval 60

mpls discovery vpn next-hop

!

auto ip sla mpls-lsp-monitor 1

 type echo ipsla-vrf-all

 timeout 1000

 scan-interval 1

 secondary-frequency connection-loss 10

 secondary-frequency timeout 10

 delete-scan-factor 2

 reply-dscp-bits 5

!

auto ip sla mpls-lsp-monitor reaction-configuration 1 react connectionLoss threshold-type 
consecutive 3 action-type trapOnly

auto ip sla mpls-lsp-monitor reaction-configuration 1 react timeout threshold-type 
consecutive 3 action-type trapOnly

ip sla logging traps

!

auto ip sla mpls-lsp-monitor schedule 1 schedule-period 60 start-time now

Related Commands

reply-mode

To specify the reply mode for an echo request packet of a Cisco IOS IP Service Level Agreements (SLAs) label switched path (LSP) Health Monitor operation, use the reply-mode command in auto IP SLA MPLS parameters configuration mode. To return to the default value, use the no form of this command.

reply-mode {ipv4 | router-alert}

no reply-mode {ipv4 | router-alert}

Syntax Description

Command Default

The reply mode for an echo request packet is an IPv4 UDP packet by default.

Command Modes

Auto IP SLA MPLS parameters configuration (config-auto-ip-sla-mpls-params)

Command History

Usage Guidelines

You must configure the type of LSP Health Monitor operation (such as LSP ping) before you can configure any of the other parameters of the operation.

Examples

The following example shows how to configure operation parameters, proactive threshold monitoring, and scheduling options using the LSP Health Monitor. In this example, LSP Health Monitor operation 1 is configured to automatically create IP SLAs LSP ping operations for all Border Gateway Protocol (BGP) next hop neighbors in use by all VPN routing and forwarding (VRF) instances associated with the source Provider Edge (PE) router. The reply mode of an echo request packet for IP SLAs operations created by LSP Health Monitor operation 1 is an IPv4 UDP packet with router alert.

mpls discovery vpn interval 60

mpls discovery vpn next-hop

!

auto ip sla mpls-lsp-monitor 1

 type echo ipsla-vrf-all

 timeout 1000

 scan-interval 1

 secondary-frequency connection-loss 10

 secondary-frequency timeout 10

 delete-scan-factor 2

 reply-mode router-alert

!

auto ip sla mpls-lsp-monitor reaction-configuration 1 react connectionLoss threshold-type 
consecutive 3 action-type trapOnly

auto ip sla mpls-lsp-monitor reaction-configuration 1 react timeout threshold-type 
consecutive 3 action-type trapOnly

ip sla logging traps

!

auto ip sla mpls-lsp-monitor schedule 1 schedule-period 60 start-time now

Related Commands

request-data-size

To set the protocol data size in the payload of a Cisco IOS IP Service Level Agreements (SLAs) operation's request packet, use the request-data-size command in the appropriate submode of IP SLA configuration, auto IP SLA MPLS configuration, IP SLA monitor configuration, or IP SLA template parameters configuration mode. To return to the default value, use the no form of this command.

request-data-size bytes

no request-data-size

Syntax Description

Command Default

The default data size varies depending on the type of IP SLAs operation you are configuring. See the CISCO-RTTMON-MIB documentation for more details.

Command Modes

IP SLA Configuration

DLSw configuration (config-ip-sla-dlsw)
ICMP echo configuration (config-ip-sla-echo)
ICMP path echo configuration (config-ip-sla-pathEcho)
ICMP path jitter configuration (config-ip-sla-pathJitter)
UDP echo configuration (config-ip-sla-udp)
UDP jitter configuration (config-ip-sla-jitter)
VCCV configuration (config-sla-vccv)

Auto IP SLA MPLS Configuration

MPLS parameters configuration (config-auto-ip-sla-mpls-params)

IP SLA Monitor Configuration

DLSw configuration (config-sla-monitor-dlsw)
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)

IP SLA Template Parameters Configuration

ICMP echo configuration (config-icmp-ech-params)
UDP echo configuration (config-udp-ech-params)
UDP jitter configuration (config-icmp-ech-params)

Command History

Usage Guidelines

The request-data-size command can be used to set the padding size for the data frame of an IP SLAs Ethernet operation. See the documentation for the request-data-size (Ethernet) command for more information.

The request-data-size command is supported in IPv4 networks. This command is also supported in IPv6 networks to configure an IP SLAs operation that supports IPv6 addresses.

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 23). If you are configuring an IP SLAs label switched path (LSP) Health Monitor operation, see Table 24 for information on Cisco IOS release dependencies. 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 request-data-size command varies depending on the Cisco IOS release you are running and the operation type configured.

If you are running Cisco IOS IP SLAs Engine 3.0, you must enter the parameters command in IP SLA template configuration mode before you can use the request-data size command.

Examples

The following examples show how to set the request packet size to 40 bytes for an IP SLAs ICMP echo 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 23).

IP SLA Configuration

ip sla 3

 icmp-echo 172.16.1.175

 request-data-size 40

!

ip sla schedule 3 life forever start-time now

IP SLA Monitor Configuration

ip sla monitor 3

 type echo protocol ipIcmpEcho 172.16.1.175

 request-data-size 40

!

ip sla monitor schedule 3 life forever start-time now

IP SLA Template Configuration

Router(config)# ip sla auto template type ip icmp-echo 1

Router(config-icmp-ech-tplt)# parameters

Router(config-icmp-ech-params)# request-data-size 40

Router(config-icmp-ech-params)# end

Router#

Router# show ip sla auto template type ip icmp-echo

IP SLAs Auto Template: 1

Measure Type: icmp-echo (control enabled)

    Description: 

    IP options:

        Source IP: 0.0.0.0      Source Port: 0

        VRF:    TOS: 0x0

    Operation Parameters:

        Request Data Size: 40 Verify Data: false

		Timeout: 5000           Threshold: 5000

    Statistics Aggregation option:

        Hours of statistics kept: 2

    History options:

        History filter: none

        Max number of history records kept: 15

        Lives of history kept: 0

    Statistics Distributions options:

        Distributions characteristics: RTT

        Distributions bucket size: 20

        Max number of distributions buckets: 1

    Reaction Configuration: None

Related Commands

request-data-size (Ethernet)

To set the padding size for the data frame of a Cisco IOS IP Service Level Agreements (SLAs) Ethernet operation, use the request-data-size (Ethernet) command in the appropriate submode of IP SLA configuration or auto IP SLA MPLS configuration mode. To return to the default value, use the no form of this command.

request-data-size bytes

no request-data-size

Syntax Description

Defaults

The default padding size will vary depending on the type of IP SLAs operation you are configuring. See the CISCO-RTTMON-MIB documentation for more details.

Command Modes

IP SLA Configuration

Ethernet echo (config-ip-sla-ethernet-echo)
Ethernet jitter (config-ip-sla-ethernet-jitter)

IP SLA Auto Ethernet Configuration

Ethernet parameters configuration (config-ip-sla-ethernet-params)

Command History

Usage Guidelines

You must configure the type of Ethernet operation (such as Ethernet ping) before you can configure any of the other parameters of the operation.

Examples

The following example shows how to set the padding size to 40 bytes for IP SLAs Ethernet ping operation 3:

ip sla 3

 ethernet echo mpid 23 domain testdomain vlan 34

 request-data-size 40

!

ip sla schedule 3 life forever start-time now

Related Commands

rtr

Note Effective with Cisco IOS Release 12.3(14)T and 12.2(31)SB2, the rtr command is replaced by the ip sla monitor command. Effective with Cisco IOS Release 12.2(33)SRB, the rtr command is replaced by the ip sla command. See the ip sla monitor and ip sla commands for more information.

To begin configuration for a Cisco IOS IP Service Level Agreements (IP SLAs) operation and enter RTR configuration mode, use the rtr command in global configuration mode. To remove all configuration information for an operation, including the schedule of the operation, reaction configuration, and reaction triggers, use the no form of this command.

rtr operation-number

no rtr operation-number

Syntax Description

Defaults

No IP SLAs operation is configured.

Command Modes

Global configuration

Command History

Usage Guidelines

The rtr command is used to configure Cisco IOS IP Service Level Agreements (IP SLAs) operations. Use this command to specify an identification number for the operation you are about to configure. After you enter this command, you will enter the RTR configuration mode.

IP SLAs allows a maximum of 2000 operations.

Debugging is supported only on the first 32 operation numbers.

After you configure a operation, you must schedule the operation. For information on scheduling a operation, refer to the rtr schedule and rtr group schedule global configuration commands. You can also optionally set reaction triggers for the operation. For information on reaction triggers, refer to the rtr reaction-configuration and rtr reaction-trigger global configuration commands.

Note After you schedule an operation, you cannot modify the configuration of the operation. To modify the configuration of the operation after it is scheduled, you must first delete the IP SLAs operation (using the no rtr command) and then reconfigure the operation with the new operation parameters.

To display the current configuration settings of the operation, use the show rtr configuration EXEC command.

Examples

In the following example, operation 1 is configured to perform end-to-end IP SLAs operations using an SNA LU Type 0 connection with the host name cwbc0a. Only the type RTR configuration command is required; all others are optional.

rtr 1

 type echo protocol snalu0echoappl cwbc0a

 request-data-size 40

 response-data-size 1440

Note If operation 1 already existed and it has not been scheduled, you are placed into RTR configuration mode. If the operation already exists and has been scheduled, this command will fail.

Related Commands

rtr group schedule

Note Effective with Cisco IOS Release 12.3(14)T and 12.2(31)SB2, the rtr group schedule command is replaced by the ip sla monitor group schedule command. Effective with Cisco IOS Release 12.2(33)SRB, the rtr group schedule command is replaced by the ip sla group schedule command. See the ip sla monitor group schedule and ip sla group schedule commands for more information.

To perform group scheduling for Cisco IOS IP Service Level Agreements (IP SLAs) operations, use the rtr group  schedule command in global configuration mode. To stop the operation and place it in the default state of normal scheduling, use the no form of this command.

rtr group schedule group-operation-number operation-id-numbers schedule-period schedule-period-range [ageout seconds] [frequency group-operation-frequency] [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}]

no rtr group schedule

Syntax Description

Defaults

The operation is placed in a pending state (that is, the operation is enabled but is not actively collecting information).

Command Modes

Global configuration

Command History

Usage Guidelines

Though IP SLAs multiple operations scheduling functionality helps in scheduling thousands of operations, you should be cautious while specifying the number of operations, the schedule period, and the operation group frequency to avoid CPU hogging.

For example, consider a scenario where you are scheduling 1 to 780 operations at a schedule period of 60 seconds, the command would be as follows:

rtr group schedule 2 1-780 schedule-period 60 start-now

IP SLAs calculates how many operations it should start in each 1-second interval by dividing the number of operations by the schedule period (780 operations divided by 60 seconds, which is 13 operations per second). Operations 1 to 13 in operation group 2 start after 0 seconds, operations 14 to 26 start after 1 second, operations 27 to 40 start after 2 seconds, and the iteration continues until operations 768 to 780 start after 59 seconds. This high value of operations starting at every 1-second interval (especially for jitter operations) can load the CPU to very high values.

The maximum recommended value of operations per second is 6 or 7. This is approximately 350 to 400 operations per minute. This value of 6 or 7 operation per second will be the maximum that does not have any major performance (CPU) impact. However, this value varies from platform to platform. The above value is verified and tested on a Cisco 2600 router.

Note No warning messages will be displayed if IP SLAs multiple operations scheduling leads to a high number of operations starting per second.

When you reboot the router, the IP SLAs multiple operations scheduling functionality schedules the operations in the same order as was done before the reboot. For example, assume the following operation had been scheduled:

rtr group schedule 2 1-20 schedule-period 40 start-time now

Over a range of 40 seconds, 20 operations have to be started (that is, one operation every 2 seconds). After the system reboot, operation 1 will start at t seconds and operation 2 starts at t+2 seconds, operation 3 starts at t+4 seconds, and so on.

The IP SLAs multiple operations scheduling functionality schedules the maximum number of operations possible without aborting. However, this functionality skips those IP SLAs operations that are already running or those that are not configured and hence do not exist. The total number of operations will be calculated based on the number of operations specified in the command, irrespective of the number of operations that are missing or already running. The IP SLAs multiple operations scheduling functionality displays a message showing the number of active and missing operations. However, these messages are displayed only if you schedule operations that are not configured or are already running.

Examples

The following example shows how to schedule IP SLAs operations 3, 4, and 6 to 10 in operation group 1:

rtr group schedule 1 3, 4, 6-10

The following example shows how to schedule IP SLAs operations 3, 4, and 6 to 10 in operation group 1, with a schedule period of 20 seconds:

rtr group schedule 1 3, 4, 6-10 schedule-period 20

The following example shows how to schedule IP SLAs operations 3, 4, and 6 to 10 in operation group 1, with a schedule period of 20 seconds with start time as now:

rtr group schedule 1 3, 4, 6-10 schedule-period 20 start-time now

Related Commands

rtr key-chain

Note Effective with Cisco IOS Release 12.3(14)T and 12.2(31)SB2, the rtr key-chain command is replaced by the ip sla monitor key-chain command. Effective with Cisco IOS Release 12.2(33)SRB, the rtr key-chain command is replaced by the ip sla key-chain command. See the ip sla monitor key-chain and ip sla key-chain commands for more information.

To enable Cisco IOS IP Service Level Agreements (IP SLAs) control message authentication and specify an MD5 key chain, use the rtr key-chain command in global configuration mode. To remove control message authentication, use the no form of this command.

rtr key-chain name

no rtr key-chain

Syntax Description

Defaults

Control message authentication is disabled.

Command Modes

Global configuration

Command History

Usage Guidelines

The authentication configuration on the IP SLAs source and IP SLAs Responder devices must be the same. In other words, both devices must be configured with the same key chain or both devices must not use authentication.

If the rtr key-chain command is entered, at least one key must be added to the specified MD5 key chain in order for MD5 authentication to occur.

Examples

In the following example, the IP SLAs control message uses MD5 authentication, and the key chain name is CSAA. The authentication string for key 1 is csaakey1.

rtr key-chain csaa

key chain csaa

key 1

key-string csaakey1

Related Commands

rtr logging traps

Note Effective with Cisco IOS Release 12.3(14)T and 12.2(31)SB2, the rtr logging traps command is replaced by the ip sla monitor logging traps command. Effective with Cisco IOS Release 12.2(33)SRB, the rtr logging traps command is replaced by the ip sla logging traps command. See the ip sla monitor logging traps and ip sla logging traps commands for more information.

To enable the generation of Simple Network Management Protocol (SNMP) system logging messages specific to Cisco IOS IP Service Level Agreements (SLAs) trap notifications, use the rtr logging traps command in global configuration mode. To disable IP SLAs system logging SNMP traps, use the no form of this command.

rtr logging traps

no rtr logging traps

Syntax Description

This command has no arguments or keywords.

Defaults

SNMP system logging messages specific to IP SLAs trap notifications are not generated.

Command Modes

Global configuration

Command History

Usage Guidelines

SNMP trap notifications for IP SLAs can be configured as a triggered action, to be sent when monitored values exceed an upper threshold or fall below a lower threshold, or when a set of defined conditions are met. For example, an SNMP trap can be triggered by five consecutive timeouts during an IP SLAs operation. The sending of SNMP traps is one of the options for triggered actions that can be configured for IP SLAs threshold violations. To configure proactive threshold monitoring parameters for an IP SLAs operation, use the rtr reaction-configuration command in global configuration mode.

SNMP traps for IP SLAs are supported by the CISCO-RTTMON-MIB and CISCO-SYSLOG-MIB. Use the snmp-server enable traps rtr command to enable the sending of IP SLAs SNMP trap notifications.

Examples

The following example shows the configuration of IP SLAs traps to be triggered for round-trip time (RTT) violations and Voice over IP (VoIP) mean opinion score (MOS) violations, and the necessary SNMP configuration for enabling these SNMP logging traps:

rtr 1

 type jitter dest-ipaddr 209.165.200.225 dest-port 9234 

!

rtr schedule 1 start now life forever 

rtr reaction-configuration 1 react rtt threshold-type immediate threshold-value 3000 2000 
action-type trapOnly 

rtr reaction-configuration 1 react MOS threshold-type consecutive 4 threshold-value 390 
220 action-type trapOnly 

!

rtr logging traps 

snmp-server enable traps rtr

Related Commands

rtr low-memory

Note Effective with Cisco IOS Release 12.3(14)T and 12.2(31)SB2, the rtr low-memory command is replaced by the ip sla monitor low-memory command. Effective with Cisco IOS Release 12.2(33)SRB, the rtr low-memory command is replaced by the ip sla low-memory command. See the ip sla monitor low-memory and ip sla low-memory commands for more information.

To specify how much unused memory must be available to allow Cisco IOS IP Service Level Agreements (IP SLAs) configuration, use the rtr low-memory command in global configuration mode. To remove the type configuration for the operation, use the no form of this command.

rtr low-memory value

no rtr low-memory

Syntax Description

Defaults

The default value is 25 percent of the memory available on the system.

Command Modes

Global configuration

Command History

Usage Guidelines

The rtr low-memory command allows the user to specify the amount of memory that IP SLAs can use. If the amount of available free memory falls below the value specified in the rtr low-memory command, then you will not be allowed to configure new IP SLAs operations. If this command is not used, the default low-memory value is 25 percent. This means that if 75 percent of system memory has been utilized you will not be able to configure any IP SLAs characteristics.

The value of the rtr low-memory command should not exceed the amount of free memory available on the system. To determine the amount of free memory available on the system, use the show memory EXEC command.

Examples

In the following example, the router is configured so that no less than 2 MB of memory will be free for IP SLAs configuration:

rtr low-memory 2000000

Related Commands

rtr mpls-lsp-monitor

Note Effective with Cisco IOS Releases 12.2(31)SB2 and 12.2(33)SRB, the rtr mpls-lsp-monitor command is replaced by the auto ip sla mpls-lsp-monitor command. See the auto ip sla mpls-lsp-monitor command for more information.

To begin configuration for an IP Service Level Agreements (SLAs) label switched path (LSP) Health Monitor operation and enter SAA Multiprotocol Label Switching (MPLS) configuration mode, use the rtr mpls-lsp-monitor command in global configuration mode. To remove all configuration information for an LSP Health Monitor operation, use the no form of this command.

rtr mpls-lsp-monitor operation-number

no rtr mpls-lsp-monitor operation-number

Syntax Description

Command Default

No LSP Health Monitor operation is configured.

Command Modes

Global configuration

Command History

Usage Guidelines

Entering this command automatically enables the mpls discovery vpn next-hop command.

After you configure an LSP Health Monitor operation, you must schedule the operation. To schedule an LSP Health Monitor operation, use the rtr mpls-lsp-monitor schedule command in global configuration mode. You can also optionally set reaction configuration for the operation (see the rtr mpls-lsp-monitor reaction-configuration command).

To display the current configuration settings of an LSP Health Monitor operation, use the show rtr mpls-lsp-monitor configuration command in EXEC mode.

Examples

The following example shows how to configure operation parameters, reaction conditions, and scheduling options using the LSP Health Monitor. In this example, LSP Health Monitor operation 1 is configured to automatically create IP SLAs LSP ping operations for all BGP next hop neighbors in use by all VRFs associated with the source Provider Edge (PE) router.

mpls discovery vpn interval 60

mpls discovery vpn next-hop

!

rtr mpls-lsp-monitor 1

 type echo saa-vrf-all

 timeout 1000

 scan-interval 1

 secondary-frequency connection-loss 10

 secondary-frequency timeout 10

!

rtr mpls-lsp-monitor reaction-configuration 1 react connectionLoss threshold-type 
consecutive 3 action-type trapOnly

rtr mpls-lsp-monitor reaction-configuration 1 react timeout threshold-type consecutive 3 
action-type trapOnly

rtr logging traps

!

rtr mpls-lsp-monitor schedule 1 schedule-period 60 start-time now

Related Commands

rtr mpls-lsp-monitor reaction-configuration

Note Effective with Cisco IOS Releases 12.2(31)SB2 and 12.2(33)SRB, the rtr mpls-lsp-monitor reaction-configuration command is replaced by the auto ip sla mpls-lsp-monitor reaction-configuration command. See the auto ip sla mpls-lsp-monitor reaction-configuration command for more information.

To configure proactive threshold monitoring parameters for a Cisco IOS IP Service Level Agreements (SLAs) label switched path (LSP) Health Monitor operation, use the rtr mpls-lsp-monitor reaction-configuration command in global configuration mode. To clear all threshold monitoring configuration for a specified LSP Health Monitor operation, use the no form of this command.

rtr mpls-lsp-monitor reaction-configuration operation-number react monitored-element [action-type option] [threshold-type {consecutive [occurrences] | immediate | never}]

no rtr mpls-lsp-monitor reaction-configuration operation-number

Syntax Description

Command Default

IP SLAs proactive threshold monitoring is disabled.

Command Modes

Global configuration

Command History

Usage Guidelines

You can configure the rtr mpls-lsp-monitor reaction-configuration command multiple times to enable proactive threshold monitoring for multiple elements for the same operation. However, disabling of individual monitored elements is not supported. In other words, the no rtr mpls-lsp-monitor reaction-configuration command will disable all proactive threshold monitoring configuration for the specified IP SLAs operation.

SNMP traps for IP SLAs are supported by the CISCO-RTTMON-MIB. Use the rtr logging traps command to enable the generation of SNMP system logging messages specific to IP SLAs trap notifications. Use the snmp-server enable traps rtr command to enable the sending of IP SLAs SNMP trap notifications.

To display the current threshold monitoring configuration settings for an LSP Health Monitor operation, use the show rtr mpls-lsp-monitor configuration command.

Examples

The following example shows how to configure operation parameters, proactive threshold monitoring, and scheduling options using the LSP Health Monitor. In this example, LSP Health Monitor operation 1 is configured to automatically create IP SLAs LSP ping operations for all BGP next hop neighbors in use by all VRFs associated with the source Provider Edge (PE) router. As specified by the reaction condition configuration, when three consecutive connection loss or timeout events occur, an SNMP logging trap is sent.

mpls discovery vpn interval 60

mpls discovery vpn next-hop

!

rtr mpls-lsp-monitor 1

 type echo saa-vrf-all

 timeout 1000

 scan-interval 1

 secondary-frequency connection-loss 10

 secondary-frequency timeout 10

!

rtr mpls-lsp-monitor reaction-configuration 1 react connectionLoss threshold-type 
consecutive 3 action-type trapOnly

rtr mpls-lsp-monitor reaction-configuration 1 react timeout threshold-type consecutive 3 
action-type trapOnly

rtr logging traps

!

rtr mpls-lsp-monitor schedule 1 schedule-period 60 start-time now

Related Commands

rtr mpls-lsp-monitor schedule

Note Effective with Cisco IOS Releases 12.2(31)SB2 and 12.2(33)SRB, the rtr mpls-lsp-monitor schedule command is replaced by the auto ip sla mpls-lsp-monitor schedule command. See the auto ip sla mpls-lsp-monitor schedule command for more information.

To configure the scheduling parameters for an IP Service Level Agreements (SLAs) label switched path (LSP) Health Monitor operation, use the rtr mpls-lsp-monitor schedule command in global configuration mode. To stop the operation and place it in the default state (pending), use the no form of this command.

rtr mpls-lsp-monitor schedule operation-number schedule-period seconds [frequency [seconds]] [start-time {after hh:mm:ss | hh:mm[:ss] [month day | day month] | now | pending}]

no rtr mpls-lsp-monitor schedule operation-number

Syntax Description

Command Default

The LSP Health Monitor operation is placed in a pending state (that is, the operation is enabled but is not actively collecting information).

Command Modes

Global configuration

Command History

Usage Guidelines

After you schedule an LSP Health Monitor operation with the rtr mpls-lsp-monitor schedule command, you cannot change the configuration of the operation. To change the configuration of the operation, use the no rtr mpls-lsp-monitor operation-number command in global configuration mode and then enter the new configuration information.

To display the current configuration settings of an LSP Health Monitor operation, use the show rtr mpls-lsp-monitor configuration command in EXEC mode.

Examples

The following example shows how to configure operation parameters, reaction conditions, and scheduling options using the LSP Health Monitor. In this example, LSP Health Monitor operation 1 is configured to automatically create IP SLAs LSP ping operations for all BGP next hop neighbors in use by all VRFs associated with the source Provider Edge (PE) router. As specified in the example configuration, the schedule period for LSP Health Monitor operation 1 is 60 seconds and the operation is scheduled to start immediately.

mpls discovery vpn interval 60

mpls discovery vpn next-hop

!

rtr mpls-lsp-monitor 1

 type echo saa-vrf-all

 timeout 1000

 scan-interval 1

 secondary-frequency connection-loss 10

 secondary-frequency timeout 10

!

rtr mpls-lsp-monitor reaction-configuration 1 react connectionLoss threshold-type 
consecutive 3 action-type trapOnly

rtr mpls-lsp-monitor reaction-configuration 1 react timeout threshold-type consecutive 3 
action-type trapOnly

rtr logging traps

!

rtr mpls-lsp-monitor schedule 1 schedule-period 60 start-time now

Related Commands

rtr reaction-configuration

Note Effective with Cisco IOS Release 12.3(14)T and 12.2(31)SB2, the rtr reaction-configuration command is replaced by the ip sla monitor reaction-configuration command. Effective with Cisco IOS Release 12.2(33)SRB, the rtr reaction-configuration command is replaced by the ip sla reaction-configuration command. See the ip sla monitor reaction-configuration and ip sla reaction-configuration commands for more information.

To configure proactive threshold monitoring parameters for a Cisco IOS IP Service Level Agreements (SLAs) operation, use the rtr reaction-configuration command in global configuration mode. To clear all threshold monitoring configuration for a specified IP SLAs operation, use the no form of this command.

rtr reaction-configuration operation-number [react monitored-element] [threshold-type {never | immediate | consecutive [consecutive-occurrences] | xofy [x-value y-value] | average [number-of-measurements]}] [threshold-value upper-threshold lower-threshold] [action-type {none | trapOnly | triggerOnly | trapAndTrigger}]

no rtr reaction-configuration operation-number

Syntax Description

Defaults

IP SLAs proactive threshold monitoring is disabled.

Command Modes

Global configuration

Command History

Usage Guidelines

You can configure the rtr reaction-configuration command multiple times to enable proactive threshold monitoring for multiple elements (for example, configuring thresholds for destination-to-source packet loss and MOS) for the same operation. However, disabling of individual monitored elements is not supported. In other words, the no rtr reaction-configuration command will disable all proactive threshold monitoring configuration for the specified IP SLAs operation.

SNMP traps for IP SLAs are supported by the CISCO-RTTMON-MIB. Use the rtr logging traps command to enable the generation of SNMP system logging messages specific to IP SLAs trap notifications. Use the snmp-server enable traps rtr command to enable the sending of IP SLAs SNMP trap notifications.

To display the current threshold monitoring configuration settings for an IP SLAs operation, use the show rtr configuration command.

Examples

In the following example, IP SLAs operation 10 (a Jitter operation) is configured to send an SNMP logging trap when the MOS value exceeds 4.9 (best quality) of falls below 2.5 (poor quality):

rtr reaction-configuration 10 react mos threshold-type immediate threshold-value 490 250 
action-type trapOnly

Related Commands

rtr reaction-trigger

Note Effective with Cisco IOS Release 12.3(14)T and 12.2(31)SB2, the rtr reaction-trigger command is replaced by the ip sla monitor reaction-trigger command. Effective with Cisco IOS Release 12.2(33)SRB, the rtr reaction-trigger command is replaced by the ip sla reaction-trigger command. See the ip sla monitor reaction-trigger and ip sla reaction-trigger commands for more information.

To define a second Cisco IOS IP Service Level Agreements (IP SLAs) operation to make the transition from a pending state to an active state when one of the trigger action-type options are defined with the rtr reaction-configuration command, use the rtr reaction-trigger command in global configuration mode. To remove the trigger combination, use the no form of this command.

rtr reaction-trigger operation-number target-operation

no rtr reaction-trigger operation

Syntax Description

Defaults

No trigger combination is defined.

Command Modes

Global configuration

Command History

Usage Guidelines

Triggers are usually used for diagnostics purposes and are not used in normal operation.

Examples

In the following example, the state of operation 1 is changed from pending state to active state when action-type of operation 2 occurs:

rtr reaction-trigger 2 1

Related Commands

rtr reset

Note Effective with Cisco IOS Release 12.3(14)T and 12.2(31)SB2, the rtr reset command is replaced by the ip sla monitor reset command. Effective with Cisco IOS Release 12.2(33)SRB, the rtr reset command is replaced by the ip sla reset command. See the ip sla monitor reset and ip sla reset commands for more information.

To perform a shutdown and restart of the Cisco IOS IP Service Level Agreements (SLAs) engine, use the rtr reset command in global configuration mode.

rtr reset

Syntax Description

This command has no arguments or keywords.

Defaults

No default behavior or values.

Command Modes

Global configuration

Command History

Usage Guidelines

The rtr reset command stops all operations, clears IP SLAs configuration information, and returns the IP SLAs feature to the startup condition. This command does not reread the IP SLAs configuration stored in startup-config in NVRAM. You must retype the configuration or load a previously saved configuration file.

Note The rtr reset command does not remove IP SLAs label switched path (LSP) Health Monitor configurations from the running configuration.

Caution Use the rtr reset command only in extreme situations such as the incorrect configuration of a number of operations.

Examples

The following example resets IP SLAs, clearing all stored IP SLAs information and configuration:

rtr reset

Related Commands

rtr responder

Note Effective with Cisco IOS Release 12.3(14)T and 12.2(31)SB2, the rtr responder command is replaced by the ip sla monitor responder command. Effective with Cisco IOS Release 12.2(33)SRB, the rtr responder command is replaced by the ip sla responder command. See the ip sla monitor responder and ip sla responder commands for more information.

To enable the Cisco IOS IP Service Level Agreements (IP SLAs) Responder on a destination (operational target) device, use the rtr responder command in global configuration mode. To disable the IP SLAs Responder, use the no form of this command.

rtr responder

no rtr responder

Syntax Description

This command has no arguments or keywords.

Defaults

Disabled.

Command Modes

Global configuration

Command History

Usage Guidelines

This command is used on the destination device for IP SLAs operations to enable the sending of receiving of IP SLAs Control packets. Enabling the IP SLAs Responder allows the generation of monitoring statistics on the device sending IP SLAs operations.

Examples

The following example enables the IP SLAs Responder:

rtr responder

Related Commands

rtr responder type tcpConnect

Note Effective with Cisco IOS Release 12.3(14)T and 12.2(31)SB2, the rtr responder type tcpConnect command is replaced by the ip sla monitor responder type tcpConnect ipaddress command. Effective with Cisco IOS Release 12.2(33)SRB, the rtr responder type tcpConnect command is replaced by the ip sla responder tcp-connect ipaddress command. See the ip sla monitor type tcpConnect ipaddress and ip sla responder tcp-connect ipaddress commands for more information.

To enable the Cisco IOS IP Service Level Agreements (IP SLAs) Responder for TCP Connect operations, use the rtr responder type tcpConnect command in global configuration mode. To disable the IP SLAs Responder, use the no form of this command.

rtr responder type tcpConnect ipaddress ip-address port port

no rtr responder type tcpConnect ipaddress ip-address port port

Syntax Description

Defaults

Disabled.

Command Modes

Global configuration

Command History

Usage Guidelines

This command is used on the destination device for IP SLAs operations to enable the acceptance and return of TCP Connect operation packets.

Examples

The following example shows how to enable the IP SLAs Responder for TCP connection operations:

rtr responder type tcpConnect ipaddress A.B.C.D port 1

Related Commands

rtr responder type udpEcho

Note Effective with Cisco IOS Release 12.3(14)T and 12.2(31)SB2, the rtr responder type udpEcho command is replaced by the ip sla monitor responder type udpEcho ipaddress command. Effective with Cisco IOS Release 12.2(33)SRB, the rtr responder type udpEcho command is replaced by the ip sla responder udp-echo ipaddress command. See the ip sla monitor type udpEcho ipaddress and ip sla responder udp-echo ipaddress commands for more information.

To enable the Cisco IOS IP Service Level Agreements (IP SLAs) Responder for User Datagram Protocol (UDP) Echo or Jitter operations, use the rtr responder command in global configuration mode. To disable the IP SLAs Responder, use the no form of this command.

rtr responder type udpEcho ipaddress ip-address port port

no rtr responder type udpEcho ipaddress ip-address port port

Syntax Description

Defaults

Disabled.

Command Modes

Global configuration

Command History

Usage Guidelines

This command is used on the destination device for IP SLAs operations to enable UPD Echo and Jitter (UDP+) operations on non-native interfaces.

Examples

The following example enables the IP SLAs Responder for Jitter operations:

rtr responder type udpEcho ipaddress A.B.C.D port 1

Related Commands

rtr restart

Note Effective with Cisco IOS Release 12.3(14)T and 12.2(31)SB2, the rtr restart command is replaced by the ip sla monitor restart command. Effective with Cisco IOS Release 12.2(33)SRB, the rtr restart command is replaced by the ip sla restart command. See the ip sla monitor restart and ip sla restart commands for more information.

To restart a Cisco IOS IP Service Level Agreements (IP SLAs) operation, use the rtr restart command in global configuration mode.

rtr restart operation-number

Syntax Description

Defaults

No default behavior or values.

Command Modes

Global configuration

Command History

Usage Guidelines

To restart an operation, the operation should be in an "active" state (as defined in the rtr reaction-configuration command).

IP SLAs allows a maximum of 2000 operations.

This command does not have a no form.

Examples

The following example restarts operation 12:

rtr restart 12

Related Commands

rtr schedule

Note Effective with Cisco IOS Release 12.3(14)T and 12.2(31)SB2, the rtr schedule command is replaced by the ip sla monitor schedule command. Effective with Cisco IOS Release 12.2(33)SRB, the rtr schedule command is replaced by the ip sla schedule command. See the ip sla monitor schedule and ip sla schedule commands for more information.

To configure the scheduling parameters for a Cisco IOS IP Service Level Agreements (IP SLAs) single operation, use the rtr schedule command in global configuration mode. To stop the operation and place it in the default state (pending), use the no form of this command.

rtr schedule group-operation-number [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] [ageout seconds] [recurring]

no rtr schedule group-operation-number

Syntax Description

Defaults

The operation is placed in a pending state (that is, the operation is enabled but not actively collecting information).

Command Modes

Global configuration

Command History

Usage Guidelines

After you schedule the operation with the rtr schedule command, you cannot change the configuration of the operation. To change the configuration of the operation, use the no form of the rtr global configuration command and reenter the configuration information.

If the operation is in a pending state, you can define the conditions under which the operation makes the transition from pending to active with the rtr reaction-trigger and rtr reaction-configuration global configuration commands. When the operation is in an active state, it immediately begins collecting information.

The following time line shows the age-out process of the operation:

W----------------------X----------------------Y----------------------Z

where:

•W is the time the operation was configured with the rtr global configuration command.

•X is the start time or start of life of the operation (that is, when the operation became "active").

•Y is the end of life as configured with the rtr schedule global configuration command (life seconds have counted down to zero).

•Z is the age out of the operation.

Age out starts counting down at W and Y, is suspended between X and Y, and is reset to its configured size at Y.

It is possible for the operation to age out before it executes (that is, Z can occur before X). To ensure that this does not happen, the difference between the operation's configuration time and start time (X and W) must be less than the age-out seconds.

Note The total RAM required to hold the history and statistics tables is allocated at the time of scheduling the IP SLAs operation. This prevents router memory problems when the router gets heavily loaded and lowers the amount of overhead an IP SLAs operation causes on a router when it is active.

The recurring keyword is only supported for scheduling single IP SLAs operations. You cannot schedule multiple IP SLAs operations using the rtr schedule command. The life value for a recurring IP SLAs operation should be less than one day. The ageout value for a recurring operation must be "never" (which is specified with the value 0), or the sum of the life and ageout values must be more than one day. If the recurring option is not specified, the operations are started in the existing normal scheduling mode.

Examples

In the following example, operation 25 begins actively collecting data at 3:00 p.m. on April 5. This operation will age out after 12 hours of inactivity, which can be before it starts or after it has finished with its life. When this operation ages out, all configuration information for the operation is removed (that is, the configuration information is no longer in the running-config in RAM).

rtr schedule 25 life 43200 start-time 15:00 apr 5 ageout 43200

In the following example, operation 1 begins collecting data after a 5-minute delay:

rtr schedule 1 start after 00:05:00

In the following example, operation 3 begins collecting data immediately and is scheduled to run indefinitely:

rtr schedule 3 start-time now life forever

In the following example, operation 15 begins automatically collecting data every day at 1:30 a.m.:

rtr schedule 15 start-time 01:30:00 recurring

Related Commands

samples-of-history-kept

To set the number of entries kept in the history table per bucket for a Cisco IOS IP Service Level Agreements (SLAs) operation, use the samples-of-history-kept command in the appropriate submode of IP SLA configuration or IP SLA monitor configuration mode. To return to the default value, use the no form of this command.

samples-of-history-kept samples

no samples-of-history-kept

Syntax Description

Defaults

16 entries

Command Modes

IP SLA Configuration

ICMP path echo configuration (config-ip-sla-pathEcho)

IP SLA Monitor Configuration

ICMP path echo configuration (config-sla-monitor-pathEcho)

Note The configuration mode varies depending on the Cisco IOS release you are running and the operation type configured. See the "Usage Guidelines" section for more information.

Command History

Usage Guidelines

An IP SLAs operation can collect history and capture statistics. By default, the history for an IP SLAs operation is not collected. If history is collected, each history bucket contains one or more history entries from the operation. When the operation type is ICMP path echo, an entry is created for each hop along the path that the operation takes to reach its destination. The type of entry stored in the history table is controlled by the filter-for-history command. The total number of entries stored in the history table is controlled by the combination of the samples-of-history-kept, buckets-of-history-kept, and lives-of-history-kept commands.

Note This command is supported by the IP SLAs ICMP path echo operation only.

Note Collecting history increases the RAM usage. Collect history only when you think there is a problem in the network.

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 25). 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 samples-of-history-kept command varies depending on the Cisco IOS release you are running (see Table 25) and the operation type configured. For example, if you are running Cisco IOS Release 12.4 and the ICMP path echo operation type is configured, you would enter the samples-of-history-kept command in ICMP path echo configuration mode (config-sla-monitor-pathEcho) within IP SLA monitor configuration mode.

Examples

In the following examples, ten entries are kept in the history table for each of the lives of IP SLAs ICMP path echo operation 1. 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 25).

IP SLA Configuration

ip sla 1

 path-Echo 172.16.1.176

 history lives-kept 3

 samples-of-history-kept 10

!

ip sla schedule 1 life forever start-time now

IP SLA Monitor Configuration

ip sla monitor 1

 type pathecho protocol ipIcmpEcho 172.16.1.176

 lives-of-history-kept 3

 samples-of-history-kept 10

!

ip sla monitor schedule 1 life forever start-time now

Related Commands

scan-interval

To specify the time interval at which the IP Service Level Agreements (SLAs) label switched path (LSP) Health Monitor checks the scan queue for Border Gateway Protocol (BGP) next hop neighbor updates, use the scan-interval command in auto IP SLA MPLS parameters configuration mode. To return to the default value, use the no form of this command.

scan-interval minutes

no scan-interval

Syntax Description

Command Default

Scan interval is 240 minutes.

Command Modes

Auto IP SLA MPLS parameters configuration (config-auto-ip-sla-mpls-params)

Command History

Usage Guidelines

At each scan interval, a new IP SLA operation is automatically created for each newly discovered BGP next hop neighbor listed in the LSP Health Monitor scan queue. If there is more than one IP SLAs operation created at a specific scan interval, the start time for each newly created IP SLAs operation is randomly distributed to avoid having all of the operations start at the same time.

Use the delete-scan-factor command in IP SLA monitor configuration mode to specify the number of times the LSP Health Monitor should check the scan queue before automatically deleting IP SLAs operations for BGP next hop neighbors that are no longer valid.

You must configure the type of LSP Health Monitor operation (such as LSP ping) before you can configure any of the other parameters of the operation.

Note The default interval of time that BGP neighbor statistics are updated is different for the IP SLAs LSP Health Monitor database and the BGP next hop neighbor discovery database. Use the scan-interval command to set the timer for the IP SLAs LSP Health Monitor database. Use the mpls discovery vpn interval command to set the timer for the BGP next hop neighbor discovery database.

Examples

The following example shows how to configure operation parameters, proactive threshold monitoring, and scheduling options using the LSP Health Monitor. In this example, LSP Health Monitor operation 1 is configured to automatically create IP SLAs LSP ping operations for all Border Gateway Protocol (BGP) next hop neighbors in use by all VPN routing and forwarding (VRF) instances associated with the source Provider Edge (PE) router. The time interval at which the LSP Health Monitor checks the scan queue for BGP next hop neighbor updates is set to 1 minute.

mpls discovery vpn interval 60

mpls discovery vpn next-hop

!

auto ip sla mpls-lsp-monitor 1

 type echo ipsla-vrf-all

 timeout 1000

 scan-interval 1

 secondary-frequency connection-loss 10

 secondary-frequency timeout 10

 delete-scan-factor 2

!

auto ip sla mpls-lsp-monitor reaction-configuration 1 react connectionLoss threshold-type 
consecutive 3 action-type trapOnly

auto ip sla mpls-lsp-monitor reaction-configuration 1 react timeout threshold-type 
consecutive 3 action-type trapOnly

ip sla logging traps

!

auto ip sla mpls-lsp-monitor schedule 1 schedule-period 60 start-time now

Related Commands

scan-period

To set the amount of time after which the label switched path (LSP) discovery process can restart for a Cisco IOS IP Service Level Agreements (SLAs) LSP Health Monitor operation, use the scan-period command in auto IP SLA MPLS LSP discovery parameters configuration mode. To return to the default value, use the no form of this command.

scan-period minutes

no scan-period

Syntax Description

Command Default

1 minute

Command Modes

Auto IP SLA MPLS LSP discovery parameters configuration (config-auto-ip-sla-mpls-lpd-params)

Command History

Usage Guidelines

When the LSP discovery process has completed one iteration of discovering the equal-cost multipaths for each applicable Border Gateway Protocol (BGP) next hop neighbors associated with a single LSP Health Monitor operation, the next iteration of the LSP discovery process will start immediately if the time period set by the scan-period command has expired. If this rediscovery time period has not yet expired, then the next iteration of the LSP discovery process will not start until the time period has expired.

Setting the LSP rediscovery time period to 0 will cause the LSP discovery process to always restart immediately after completing one iteration of discovering the equal-cost multipaths for each applicable BGP next hop neighbor associated with a single LSP Health Monitor operation.

Use the path-discover command to enable the LSP discovery option for an IP SLAs LSP Health Monitor operation and enter auto IP SLA MPLS LSP discovery parameters configuration mode.

Examples

The following example shows how to configure operation parameters, proactive threshold monitoring, and scheduling options using the LSP Health Monitor. In this example, the LSP discovery option is enabled for LSP Health Monitor operation 1. Operation 1 is configured to automatically create IP SLAs LSP ping operations for the equal-cost multipaths to all Border Gateway Protocol (BGP) next hop neighbors in use by all VPN routing and forwarding (VRF) instances associated with the source Provider Edge (PE) router. The LSP rediscovery time period is set to 30 minutes.

auto ip sla mpls-lsp-monitor 1

 type echo ipsla-vrf-all

 path-discover

!

 maximum-sessions 2

 session-timeout 60

 interval 2

 timeout 4

 force-explicit-null

 hours-of-statistics-kept 1

 scan-period 30

!

auto ip sla mpls-lsp-monitor schedule 1 schedule-period 60 frequency 100 start-time now

!

auto ip sla mpls-lsp-monitor reaction-configuration 1 react lpd tree-trace action-type 
trapOnly

auto ip sla mpls-lsp-monitor reaction-configuration 1 react lpd lpd-group retry 3 
action-type trapOnly

Related Commands

schedule

To add an auto IP Service Level Agreements (SLAs) scheduler to the configuration of an IP SLAs auto-measure group, use the schedule command in IP SLA auto-measure group configuration mode. To stop operations of the group, use the no form of this command.

schedule schedule-id

no schedule schedule-id

Syntax Description

Command Default

The operation in the group being configured is not scheduled.

Command Modes

IP SLA auto-measure group configuration (config-am-group)

Command History