Table Of Contents
rtr mpls-lsp-monitor reaction-configuration
session-timeout (LSP discovery)
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 60mpls discovery vpn next-hop!auto ip sla mpls-lsp-monitor 1type echo ipsla-vrf-alltimeout 1000scan-interval 1secondary-frequency connection-loss 10secondary-frequency timeout 10delete-scan-factor 2reply-dscp-bits 5!auto ip sla mpls-lsp-monitor reaction-configuration 1 react connectionLoss threshold-type consecutive 3 action-type trapOnlyauto ip sla mpls-lsp-monitor reaction-configuration 1 react timeout threshold-type consecutive 3 action-type trapOnlyip sla logging traps!auto ip sla mpls-lsp-monitor schedule 1 schedule-period 60 start-time nowRelated Commands
auto ip sla mpls-lsp-monitor
Begins configuration for an IP SLAs LSP Health Monitor operation and enters auto IP SLA MPLS configuration mode.
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
ipv4
Replies with an IPv4 User Datagram Protocol (UDP) packet (default).
router-alert
Replies with an IPv4 UDP packet with router alert.
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 60mpls discovery vpn next-hop!auto ip sla mpls-lsp-monitor 1type echo ipsla-vrf-alltimeout 1000scan-interval 1secondary-frequency connection-loss 10secondary-frequency timeout 10delete-scan-factor 2reply-mode router-alert!auto ip sla mpls-lsp-monitor reaction-configuration 1 react connectionLoss threshold-type consecutive 3 action-type trapOnlyauto ip sla mpls-lsp-monitor reaction-configuration 1 react timeout threshold-type consecutive 3 action-type trapOnlyip sla logging traps!auto ip sla mpls-lsp-monitor schedule 1 schedule-period 60 start-time nowRelated Commands
auto ip sla mpls-lsp-monitor
Begins configuration for an IP SLAs LSP Health Monitor operation and enters auto IP SLA MPLS configuration mode.
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, or IP SLA monitor 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
bytes
Size (in bytes) of the protocol data in the payload of the request packet of the operation. The range is from 0 to the maximum of the protocol.
Defaults
The default data 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
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)
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
The request-data-size command is also 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 when configuring 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 16). Note that if you are configuring an IP SLAs label switched path (LSP) Health Monitor operation, see Table 17 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. For example, if you are running Cisco IOS Release 12.4 and the ICMP echo operation type is configured, you would enter the request-data-size command in ICMP echo configuration mode (config-sla-monitor-echo) within IP SLA monitor configuration mode.
Examples
The following examples show how to set the request packet size to 40 bytes for IP SLAs ICMP echo operation 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 16).
IP SLA Configuration
This example shows the request-data-size command being used in an IPv4 network in ICMP echo configuration mode within IP SLA configuration mode:
ip sla 3icmp-echo 172.16.1.175request-data-size 40!ip sla schedule 3 life forever start-time nowIP SLA Monitor Configuration
This example shows the request-data-size command being used in an IPv4 network in ICMP echo configuration mode within IP SLA monitor configuration mode:
ip sla monitor 3type echo protocol ipIcmpEcho 172.16.1.175request-data-size 40!ip sla monitor schedule 3 life forever start-time nowRelated 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
bytes
Padding size (in bytes) for the data frame of the operation. The range is from 0 to the maximum of the protocol.
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 3ethernet echo mpid 23 domain testdomain vlan 34request-data-size 40!ip sla schedule 3 life forever start-time nowRelated Commands
rtr
Note
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
operation-number
Operation number used for the identification of the IP SLAs operation you wish to configure.
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
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 1type echo protocol snalu0echoappl cwbc0arequest-data-size 40response-data-size 1440
Note
Related Commands
rtr group schedule
Note
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
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-10The 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 20The 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 nowRelated Commands
rtr key-chain
Note
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 csaakey chain csaakey 1key-string csaakey1
Related Commands
rtr logging traps
Note
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 1type jitter dest-ipaddr 209.165.200.225 dest-port 9234!rtr schedule 1 start now life foreverrtr reaction-configuration 1 react rtt threshold-type immediate threshold-value 3000 2000 action-type trapOnlyrtr reaction-configuration 1 react MOS threshold-type consecutive 4 threshold-value 390 220 action-type trapOnly!rtr logging trapssnmp-server enable traps rtrRelated Commands
rtr low-memory
Note
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
value
Specifies amount of memory, in bytes, that must be available to configure IP SLAs. The range is from 0 to the maximum amount of free memory bytes available.
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 2000000Related Commands
rtr mpls-lsp-monitor
Note
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
operation-number
Number used for the identification of the LSP Health Monitor operation you wish to configure.
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 60mpls discovery vpn next-hop!rtr mpls-lsp-monitor 1type echo saa-vrf-alltimeout 1000scan-interval 1secondary-frequency connection-loss 10secondary-frequency timeout 10!rtr mpls-lsp-monitor reaction-configuration 1 react connectionLoss threshold-type consecutive 3 action-type trapOnlyrtr mpls-lsp-monitor reaction-configuration 1 react timeout threshold-type consecutive 3 action-type trapOnlyrtr logging traps!rtr mpls-lsp-monitor schedule 1 schedule-period 60 start-time nowRelated Commands
rtr mpls-lsp-monitor reaction-configuration
Note
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 60mpls discovery vpn next-hop!rtr mpls-lsp-monitor 1type echo saa-vrf-alltimeout 1000scan-interval 1secondary-frequency connection-loss 10secondary-frequency timeout 10!rtr mpls-lsp-monitor reaction-configuration 1 react connectionLoss threshold-type consecutive 3 action-type trapOnlyrtr mpls-lsp-monitor reaction-configuration 1 react timeout threshold-type consecutive 3 action-type trapOnlyrtr logging traps!rtr mpls-lsp-monitor schedule 1 schedule-period 60 start-time nowRelated Commands
rtr mpls-lsp-monitor schedule
Note
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 60mpls discovery vpn next-hop!rtr mpls-lsp-monitor 1type echo saa-vrf-alltimeout 1000scan-interval 1secondary-frequency connection-loss 10secondary-frequency timeout 10!rtr mpls-lsp-monitor reaction-configuration 1 react connectionLoss threshold-type consecutive 3 action-type trapOnlyrtr mpls-lsp-monitor reaction-configuration 1 react timeout threshold-type consecutive 3 action-type trapOnlyrtr logging traps!rtr mpls-lsp-mon
