IP SLA CLI Operations

This section describes the most important configuration commands to enable the IP SLA feature on the Cisco routers. It explains configuring the operations and their characteristics (type, frequency, precision, ToS, VRF), operation scheduling, operation reactions, and the IP SLA Responder and its optional authentication. After the name change from "SAA" to "IP SLA," the CLI commands were modified extensively. The following list summarizes the changes, starting with Cisco IOS Software Releases 12.4(2)T, 12.2SX, and 12.2SB:

  • The rtr keyword has been changed to ip sla.

  • The removal of the type keyword lets you enter operations directly under the IP SLA definition.

  • The number of CLI sublevels has been reduced so that individual operations are easy to configure. For example, the protocol keyword for Internet Control Message Protocol (ICMP) operations has been removed.

  • History features are grouped under the history keyword.

  • The monitor keyword (ip sla monitor), which was introduced as an interim solution, has been removed. For example, router(config-sla-monitor-type) became router(config-ip-sla-type).

  • The keywords destination-ip and destination-port are now optional, but source-ip and source-port are still mandatory.

  • The new show ip sla statistics [details] command replaces the show rtr operational-state command.

  • The new show ip sla statistics aggregated [details] command replaces the show rtr collection-history command. This command is very similar to the show ip sla monitor statistics command. In addition, it includes distribution statistics and an aggregated view of data.

  • The previous CLI formats are accepted in configuration mode. Note that a show run or show start command outputs the new CLI formats. This allows backward compatibility.


The configuration commands explained in this section were taken from the latest available image—Cisco IOS Software Release 12.4(11)T.

The most important configuration commands to enable the IP SLA feature on the Cisco routers are as follows:

  • router(config)# ip sla operation-number

    configures an IP SLA operation, where the operation-number specifies the operation instance of interest. When configured, the IP SLA Monitor configuration mode is entered, as indicated by the (config-ip-sla) router prompt.

  • router(config-ip-sla)#type

    configures the type of IP SLA operation. The possible IP SLA types are dhcp, dns, frame-relay, ftp, http, icmp-echo, icmp-jitter, path-echo, path-jitter, slm, tcpconnect, udp-echo, udp-jitter, and voip. When configured, the IP SLA Monitor configuration mode for the specific type is entered, as indicated by the (config-ip-sla-type) router prompt. Note that SLM stands for Service Level Monitor and configures the Layer 2 operation for Frame Relay and ATM. The following examples are configured with udp-jitter type operation.

  • router(config-ip-sla-type)# frequency seconds

    sets the rate at which a specified IP SLA operation repeats. The default is 60 seconds.

  • router(config-ip-sla-type)# precision {milliseconds | microseconds}

    sets the level of accuracy at which the statistics for an IP SLA operation are measured. Note that this command applies only to the jitter operation.

  • router(config-ip-sla-type)# timeout milliseconds

    sets the amount of time the IP SLA operation waits for a response from its test packet.

  • router(config-ip-sla-type)# tos number

    defines the type of service (ToS) byte in the IP header of IP SLA operations.

  • router(config-ip-sla-type)# vrf vrf-name

    allows monitoring within MPLS VPNs using IP SLA operations.

  • router(config-ip-sla-type)# request-data-size bytes

    sets the payload size of the IP SLA operation's test packet. This applies to the UDP Jitter, UDP Echo, and ICMP Echo operations.

  • router(config)# ip sla responder

    is used on the destination device for IP SLA operations to enable the sending and receiving of IP SLA Control packets. Enabling the IP SLA Responder allows the generation of packet loss statistics on the device sending IP SLA operations.

  • router(config)# ip sla 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}]

    performs group scheduling for IP SLA operations. (The group scheduling function is explained in the later section "Scheduling.")

  • router(config)# ip sla key-chain name

    enables IP SLA control message authentication and specifies an MD5 key chain.

  • router(config)# ip sla logging traps enables the generation of system logging SNMP notifications (Syslog traps) specific to IP SLA thresholds.

  • router(config)# ip sla reaction-trigger operation-number target-operation

    defines a second IP SLA operation to make the transition from a pending state to an active state when one of the trigger action-type options is defined with the ip sla reaction-configuration command. (The triggers are explained in the "Thresholds and Notifications" section.)

  • router(config)# ip sla reaction-configuration operation-number [react monitored-element] [threshold-type {never | immediate | consecutive [consecutive-occurrences] | xofy [x-value y-value] | average [number-of-probes]}] [threshold-value upper-threshold lower-threshold] [action-type {none | trapOnly | triggerOnly | trapAndTrigger}]

    configures certain actions to occur based on events under the control of the IP SLA. The possible events, configured with react monitored-element, are connectionLoss, jitterAvg threshold, jitterDSAvg threshold (jitter from destination to source), jitterSDAvg threshold (jitter from source to destination), mos threshold (Mean Opinion Score), PacketLossDS threshold (from destination to source), PacketLossSD threshold (from source to destination), and timeout threshold. The possible actions are trapOnly, triggerOnly (activate the target operation configured by the ip sla reaction-trigger command), and trapAndTrigger.

Part II: Implementations on the Cisco Devices