Introduction and Overview
IP SLAs are used to measure and verify network performance. IP SLAs operate in real-time by generating simulated network traffic such as VoIP, ICMP (echo, jitter, path echo, path jitter), TCP Connection, UDP (echo, jitter, jitter for VoIP), DNS, DHCP, HTTP, FTP. Network performance can then be determined by the statistics generated from the network in response to the IP SLA traffic. Statistics generated include; delay (round-trip and one-way), packet loss, jitter, voice quality scores etc. IP SLAs are used to collect information about: reachability, response times to probes, latency ( one-way or round-trip), jitter (inter-packet variation), voice quality scoring, etc. These measurements can be leaveraged to influence routing decisions such as static routing, policy-based routing (PBR).
IP SLA stores this information in the CLI and SNMP MIBs. IP SLA collects data that can then be used by enhanced object tracking to take a defined action. When the IP SLA is configured, object tracking can reference the IP SLA to implement an action based on the outcome or status of the IP SLA operation.
IP SLA consists of two distinct parts; a probe and schedule.
- Probe: consists of the operation that will be carried out on the network for example reachability test, measurement of delay, measurement of delay variation (jitter). Response times of network services can be measured such as application behaviour of DNS, HTTP, DHCP. The different types of probes used depend on the application being monitored; the main types are ICMP, TCP and UDP.
- Schedule: deals with when, how long and recurrence of this operation. When scheduling an IP SLA, default life of a probe is 3600 seconds (1 hour).
Types of SLA Traffic
IP SLA operations measure the following network parameters:
- Delay (one-way or round-trip)
- Jitter (direction)
- Packet loss (direction)
- Sequencing (packet order)
- Path (per hop)
- Connectivity (directional)
- Server load times
- Voice quality scores (MOS)
These aforementioned parameters are measured using the following categories of IP SLA operations:
- ICMP (echo, jitter)
- UDP (echo, jitter)
- TCP connection: can be used to test the availability and response times of an application rather than just reachability.
- DNS
- FTP
- DHCP
- HTTP
Use the command show ip sla application to verify the
IP SLA operations supported by the IOS image.
R1#show ip sla application
IP Service Level Agreements
Version: Round Trip Time MIB 2.2.0, Infrastructure Engine-III
Supported Operation Types:
icmpEcho, path-echo, path-jitter, udpEcho, tcpConnect, http
dns, udpJitter, dhcp, ftp, VoIP, rtp, lsp Group, icmpJitter
lspPing, lspTrace, 802.1agEcho VLAN, Port
802.1agJitter VLAN, Port, pseudowirePing, udpApp, wspApp
mcast, generic
Supported Features:
IPSLAs Event Publisher
IP SLAs low memory water mark: 75481422
Estimated system max number of entries: 55284
Estimated number of configurable operations: 54925
Number of Entries configured : 1
Number of active Entries : 1
Number of pending Entries : 0
Number of inactive Entries : 0
Time of last change in whole IP SLAs: *15:05:44.253 UTC Sat Mar 13 2021
R1#
IP SLAs that are based on connectivity tests do not require a responder. However, for IP SLA operations that do require a responder, this should be configured first before scheduling the IP SLA operation.
IP SLA responder and SLA Control Protocol
An IP SLA responder is an active device in the network specifically configured to interprete and respond to specific probes. Cisco devices configured as responders use the IP SLA control protocol. The IP SLA control protocol allows the responder and sender to agree on various parameters such as port number and respond to IP SLA request packets. This results in IP SLA operations having greater accuracy in measurements not available to standard ICMP-based probes. The IP SLA responder listens on UDP port 1967 for control protocol messages sent by an IP SLA operation. Upon receipt of the control message, the responder will enable the specified UDP or TCP port for the specified IP SLA operation. During this time, the responder accepts the requests and sends responses. The responder disables the port after it responds to the IP SLA request or when the specified time expires.
Time synchronization is required between the source and target device to provide accurate measurements. NTP may be required to be configured on the source and target device to ensure that the two devices have their time synchronized.
Some IP SLA operations do not require the configuration of an IPSLA responder. These include HTTP, DHCP where the application itself acts as a responder to requests.
MD5 authentication of control messages can be configured to provide security to the SLA operation.
Response Time Computation
Devices may take tens of milliseconds to process incoming packets due to other higher-priority processes. Under these conditions, the response times do not accurately represent the true network delays.
Devices give ICMP packets lower priorities when processing incoming traffic; as such, the use of ICMP packets for IP SLA operations may result in inaccurate measurements due to the lower priority given to these packets. It is therefore recommended to use UDP based IP SLA operations when trying to determine accurate network performance.
IP SLA test packets use time stamping to more precisely calculate the processing delays. Responders have different types of timers:
- T1: this is the time when the IP SLA operation was started by the source device.
- T2: timer on the target device that the request is received.
- T3: responder timer
- T4: time packet arrives at the source device.
When processing round-trip time, all four timers are utilized. At the target device, with the responder functionality enabled, time stamp 2(TS2) is subtracted from TS3 to produce the time spent processing the test packet as represented by delta. The source device calculates the round-trip time by subtracting TS1 from TS4.
Implementing IP SLA
To implement IP SLA network performance measurement, the following steps should be completed;
- On the target device, configure the IP SLA responder. This may not be required for some IP SLA operations.
- Configure the IP SLA operation:
- Configure the IP SLA operation type
- Specify IP SLA operation parameter values: these include threshold, timeout. IP SLA can be configured to send SNMP traps if the configured parameters are exceeded. Exceeding these parameters can also trigger another IP SLA operation such as increasing the monitoring frequency, or ICMP path jitter and echo probes.
- Schedule the IP SLA start-time and operating period.
ICMP Echo Operation
ICMP echo operations are useful for testing network connectivity and end-to-end
response time.
The response time is determined by measuring the time taken between sending an
ICMP-Echo request packet to a target device and receiving the ICMP-Echo reply.
The response time calculated from the icmp-echo operation
provides a general picture of the response time. However, its results may not
necessarily be accurate because some systems may not prioritize the processing of
ICMP packets, resulting in apparent higher delay values. The use of the udp-echo operation is a preferred
method to measure network connectivity and response time.
Any network device that supports ICMP echo protocol can be used as a destination. No IP SLA responder configuration is needed on the target device. To configure an ICMP echo operation:
- Configure the IP SLA with an operation number using the global configuration
command
ip sla <sla-number>.R1(config)#ip sla 100- Define the ICMP echo operation using the IP SLA mode configuration command
icmp-echo <destination-ip-address> [source-ip <ip-address> | source-interface <interface-name>].R1(config-ip-sla)#icmp-echo 4.4.4.4 source-ip 1.1.1.1 - Define the rate at which the ICMP echo packets are sent in seconds using the
IP SLA ICMP-echo submode command
frequency <1-604800>; the frequency value is in seconds:R1(config-ip-sla-echo)#frequency 10
- Define the ICMP echo operation using the IP SLA mode configuration command
- Timeout: Define a timeout value using ICMP echo mode command
timeout <0-604800000>where the value is in milliseconds. This optional step defines the maximum amount of time an IP SLA operation waits for a response to its request packet. The timeout value cannot be greater than the frequency value.R1(config-ip-sla-echo)#timeout 10000 - Threshold: Define the threshold using the IP SLA ICMP echo sub mode command
threshold <0-60000>; where the threshold value is in milliseconds. This optional step defines the upper value for the threshold for calculating network monitoring statistics. Threshold is the boundary value that gets measured over the operation result; this is the value that is collected during the actual operation. If, for instance, we would like to test for delay, we can set a threshold of, say, 30ms. If the delay result(for icmp-echo) is greater than this threshold, we can consider the test to be a failure.R1(config-ip-sla-echo)#threshold 9000The threshold parameter can be used to trigger other IP SLA operations. Additionally, the threshold value should be equal to or less than the timeout value.
The value for frequency should be greater than the timeout which is greater than the threshold.
- TOS: (Optional) Configure the
tosvalue; this is the type of service value. Packets may be treated differently if the TOS value varies for instance such as VOIP traffic.
ip sla schedule <operation-number> life [forever | seconds]
start-time [<hh:mm:ss> <month> <day> | now | pending | after <hh:mm:ss>].
R1(config)#ip sla schedule 100 start-time now life forever
Verification
show ip sla summary
R1#show ip sla summary
IPSLAs Latest Operation Summary
Codes: * active, ^ inactive, ~ pending
ID Type Destination Stats Return Last
(ms) Code Run
-----------------------------------------------------------------------
*100 icmp-echo 4.4.4.4 RTT=60 OK 8 seconds ago
show ip sla statistics
Displays the number of successes and failures and operation time to live. The displayed results may be "unknown" if the probe is not operational.
R1(config)#do-exec show ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 100
Latest RTT: 388 milliseconds
Latest operation start time: 15:10:54 UTC Sat Mar 13 2021
Latest operation return code: OK
Number of successes: 30
Number of failures: 1
Operation time to live: Forever
show ip sla configuration
A source address of 0.0.0.0 implies that the IP SLA probe
will use whichever interface is closest to the destination.
R1(config)#do-exec show ip sla configuration
IP SLAs Infrastructure Engine-III
Entry number: 100
Owner:
Tag:
Operation timeout (milliseconds): 10000
Type of operation to perform: icmp-echo
Target address/Source interface: 4.4.4.4/1.1.1.1
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 10 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
ICMP Path Echo Operations
An ICMP path echo operation measures the end-to-end and hop-by-hop response time
between a Cisco device and other devices along the path to a destination device.
ICMP Path Echo is useful for determining the network path, and for
troubleshooting network connectivity issues along the path between a device and the destination
or target of the icmp-path echo operation.
In ICMP path-echo operation, a source
device uses traceroute to discover the path to the destination device. A ping is
then used to measure the response time between the source IP SLA device and each
subsequent hop in the path to the destination device.
The IP SLAs ICMP Path Echo operation records statistics for each hop along the path that the IP SLAs
operation takes to reach its destination. The ICMP Path Echo operation determines this hop-by-hop response
time between a Cisco device and any IP device on the network by discovering the path using the traceroute
facility.
Configuration of the ICMP Path-Echo operation is similar to that of the ICMP echo operation.
R1(config)#ip sla 200
R1(config-ip-sla)#path-echo 4.4.4.4 source-ip 1.1.1.1
R1(config-ip-sla-path-echo)#frequency 15
R1(config-ip-sla-path-echo)#exit
R1(config)#ip sla schedule 200 start-time now life forever
Verification
To verify ICMP Path Echo operation;
show ip sla statistics
R1#show ip sla statistics 200 details
IPSLAs Latest Operation Statistics
IPSLA operation id: 200
Latest RTT: 232 milliseconds
Latest operation start time: 15:53:39 UTC Sat Mar 13 2021
Latest operation return code: OK
Over thresholds occurred: FALSE
Number of successes: 5
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
show ip sla configuration
R1#show ip sla configuration 200
IP SLAs Infrastructure Engine-III
Entry number: 200
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: path-echo
Target address/Source address: 4.4.4.4/1.1.1.1
Type Of Service parameters: 0x0
Request size (ARR data portion): 28
Verify data: No
Loose Source Routing: Disabled
Vrf Name:
LSR Path:
Schedule:
Operation frequency (seconds): 15 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic paths kept: 5
Number of statistic hops kept: 16
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
Number of history Samples kept: 16
History Filter Type: None
R1#
ICMP Path Jitter Operations
IP SLA ICMP Path Jitter provides hop-by-hop jitter, packet loss and delay measurement statistics in network. ICMP path jitter can be used to supplement standard UDP jitter operations. For example, high jitter values from a UDP jitter operation could be used to trigger an ICMP path jitter operation that could be used to troubleshoot the network path and determine if a particular segment of the path is a bottleneck to traffic. ICMP Path Jitter default values are:
- Number of echo probes: 10
- Interval (time between echo probes in milliseconds): 20
- frequency (seconds): 60
ICMP Path Jitter Restrictions
- Jitter values obtained by ICMP Path Jitter are approximate values because ICMP does not provide the capability to embed processing times of devices along the path in the packet. If the destination device does not prioritize ICMP packets, the delay values may be higher.
- ICMP Path Jitter is not supported in RTTMON MIB for SNMP operation. So, cli commands have to be used.
- ICMP Path Jitter does not support hourly statistics and hop information, IP SLA History feature because of the large data volume generated during jitter operations.
R1(config)#ip sla 300
R1(config-ip-sla)#path-jitter 4.4.4.4 source-ip 1.1.1.1 num-packets 15 interval 20
R1(config-ip-sla-path-jitter)#frequency 10
R1(config)#ip sla schedule 300 start-time now life forever
The optional targetOnly keyword to the path-jitter
command is used to bypass the hop-by-hop measurements; echo probes
are sent to the destination device only.
Verification
show ip sla statistics
R1#show ip sla statistics 300
IPSLAs Latest Operation Statistics
IPSLA operation id: 300
Latest RTT: 142 milliseconds
Latest operation start time: 16:19:58 UTC Sat Mar 13 2021
Latest operation return code: OK
---- Path Jitter Statistics ----
Hop IP 192.168.12.2:
Round Trip Time milliseconds:
Latest RTT: 56 ms
Number of RTT: 15
RTT Min/Avg/Max: 8/56/128 ms
Jitter time milliseconds:
Number of jitter: 14
Jitter Min/Avg/Max: 4/31/116 ms
Packet Values:
Packet Loss (Timeouts): 0
Out of Sequence: 0
Discarded Samples: 0
Hop IP 192.168.23.2:
Round Trip Time milliseconds:
Latest RTT: 148 ms
Number of RTT: 15
RTT Min/Avg/Max: 16/148/268 ms
Jitter time milliseconds:
Number of jitter: 14
Jitter Min/Avg/Max: 4/48/252 ms
Packet Values:
Packet Loss (Timeouts): 0
Out of Sequence: 0
Discarded Samples: 0
Hop IP 192.168.34.2:
Round Trip Time milliseconds:
Latest RTT: 142 ms
Number of RTT: 15
RTT Min/Avg/Max: 16/142/272 ms
Jitter time milliseconds:
Number of jitter: 14
Jitter Min/Avg/Max: 8/34/188 ms
Packet Values:
Packet Loss (Timeouts): 0
Out of Sequence: 0
Discarded Samples: 0
Operation time to live: Forever
R1#
show ip sla configuration
R1#show ip sla configuration 300
IP SLAs Infrastructure Engine-III
Entry number: 300
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: path-jitter
Target address/Source address: 4.4.4.4/1.1.1.1
Packet Interval (milliseconds)/Number of packets: 20/15
Target Only: Disabled
Request size (ARR data portion): 28
Oper timeout (milliseconds): 5000
Type Of Service parameters: 0x0
Verify data: No
Loose Source Routing: Disabled
Vrf Name:
LSR Path:
Schedule:
Operation frequency (seconds): 10 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
R1#
UDP Echo Operation
UDP echo operation is used to monitor the end-to-end response time between a Cisco device and devices using IPv4 or IPv6. It is also used to test end-to-end connectivity. The destination device is any device that supports RFC 862 Echo operation.
Response time (round-trip time) is computed by measuring the time taken between sending a UDP echo request message from source device to the destination device and receiving a UDP echo reply from the destination device. UDP echo accuracy is enhanced by using the IP SLAs Responder at the destination. If the destination device is a Cisco device, then IP SLA operation sends a UDP datagram to the configured port on the destination device. Using the IP SLAs Responder is optional for a UDP echo operation when using Cisco devices. The IP SLAs Responder cannot be configured on non-Cisco devices. The results of a UDP echo operation can be useful in troubleshooting issues with business-critical applications by determining the round-trip delay times and testing connectivity to both Cisco and non-Cisco devices.
Responder
Configuring UDP-echo on the responder may require configuration of the UDP port number on which to listen:
- Configure the responder without specifying the UDP port using the
command
ip sla responder. This command should be used if the control protocol is enabled at the source. - Configure the responder specifying the UDP port using the command
ip sla responder udp-echo ipaddress <ip-address> port <port> vrf <vrf>.The UDP port may be required if SLA control protocol is disabled on the source. IP SLA can be configured for a specific VRF as indicated by the VRF option.R4(config)#ip sla responder udp-echo ipaddress 192.168.34.2 port 8080
Source Device
- Define the IP SLA:
R1(config)#ip sla 400
- Define the udp-echo operation: the udp-echo operation is enabled using
the command
udp-echo <destination-ip-address|hostname> <destination-port> source-ip <[ip-address | hostname]> source-port <port> control [enable|disable].-
The UDP port is optional if the control protocol is enabled.
R1(config-ip-sla)#udp-echo 1.1.1.1 8080 source-ip 4.4.4.4 control enable
R1(config-ip-sla-udp)#frequency 60
R1(config-ip-sla-udp)#
The control protocol message exchanges between the IP SLA operation and the responder dynamically determine the port numbers. In its most basic configuration
ip sla responderglobal config command is all that is needed. UDP echo operations send initial control packets before the IP SLA UDP echo packets are sent. The control packets inform the responder on the planned port to be used. To eliminate the sending of control packets in UDP echo operations add thecontrol disablekeywords. -
If the control protocol is disabled, the UDP port number must be configured on the
operation as well as on the responder:
R1(config-ip-sla)#udp-echo 1.1.1.1 8080 source-ip 4.4.4.4 control disable
R1(config-ip-sla-udp)#frequency 60
-
The UDP port is optional if the control protocol is enabled.
- Schedule the IP SLA operation:
R1(config)#ip sla schedule 400 start-time now life forever
Verification
show ip sla statistics
The following output shows the difference in RTT values as processed by ICMP-Echo (IPSLA 100) operation and UDP-Echo operation (IPSLA 400).
R1#show ip sla statistics details
IPSLAs Latest Operation Statistics
IPSLA operation id: 100
Latest RTT: 88 milliseconds
Latest operation start time: 02:42:38 UTC Thu May 11 2023
Latest operation return code: OK
Over thresholds occurred: FALSE
Number of successes: 5
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
IPSLA operation id: 400
Latest RTT: 25 milliseconds
Latest operation start time: 02:42:08 UTC Thu May 11 2023
Latest operation return code: OK
Over thresholds occurred: FALSE
Number of successes: 14
Number of failures: 3
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
R1#
show ip sla responder
R4#show ip sla responder
General IP SLA Responder on Control port 1967
General IP SLA Responder is: Enabled
Number of control message received: 18 Number of errors: 0
Recent sources:
192.168.12.1 [02:36:08.095 UTC Thu May 11 2023]
192.168.12.1 [02:35:08.095 UTC Thu May 11 2023]
192.168.12.1 [02:34:08.139 UTC Thu May 11 2023]
192.168.12.1 [02:33:08.087 UTC Thu May 11 2023]
192.168.12.1 [02:32:08.107 UTC Thu May 11 2023]
Recent error sources:
Permanent Port IP SLA Responder
Permanent Port IP SLA Responder is: Enabled
udpEcho Responder:
IP Address Port
4.4.4.4 8080
192.168.34.2 8080
R4#
show ip sla configuration
R1#show ip sla configuration
IP SLAs Infrastructure Engine-III
Entry number: 100
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source address: 192.168.34.2/0.0.0.0
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 60 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
Entry number: 400
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: udp-echo
Target address/Source address: 192.168.34.2/0.0.0.0
Target port/Source port: 8080/0
Type Of Service parameter: 0x0
Request size (ARR data portion): 16
Verify data: No
Data pattern:
Vrf Name:
Control Packets: enabled
Schedule:
Operation frequency (seconds): 60 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
R1#
UDP Jitter
The UDP Jitter operation is used to measure the jitter experienced by traffic between the source device and the destination. UDP Jitter operation diagnoses network suitability for real-time traffic applications such as VoIP, video over IP or real-time conferencing. These parameters can be monitored to assess whether they are within acceptable thresholds.
If multiple packets are sent consecutively from a source to a destination, for example, 10 ms apart, and if the network is behaving ideally, the destination should receive the packets 10 ms apart. But if there are delays in the network (like queueing, arriving through alternate routes, and so on), the arrival delay between packets might be greater than or less than 10 ms. Using this example, a positive jitter value indicates that packets arrived greater than 10 ms apart. If packets arrive 12 ms apart, then positive jitter is 2 ms; if packets arrive 8 ms apart, negative jitter is 2 ms. For delay-sensitive networks like VoIP, positive jitter values are undesirable, and a jitter value of 0 is ideal.
The UDP jitter operation includes data returned by the IP SLAs UDP operation therefore it can be used as a multipurpose data gathering operation. UDP jitter operations are capable of measuring the following:
- Per-direction jitter (source to destination and destination to source)
- Per-direction packet loss
- Per-direction delay (one-way delay)
- Round-trip delay (average round-trip time)
UDP-Jitter Responder
The IP SLA responder can be enabled with or without specifying the UDP port using
commands ip sla responder or ip sla responder udp-echo
ipaddress <ip-address> port <port> vrf <vrf> respectively.
R4(config)#ip sla responder
UDP-Jitter Source
UDP-jitter is configured using the command
udp-jitter <ip-address> <port> source-ip <ip-address>
num-packets <num> interval <interval> request-data-size <size>
response-data-size <size> where:
- num-packets: number of packets sent in the request
- request-data-size: payload size per request packet
- response-data-size: payload size per response packet. This value is the same as the request-data-size if it is not configured. However, it may vary depending on the type of operation configured.
- interval: time between packets(in milliseconds).
- frequency: elapsed time before the operation repeats
R1(config)#ip sla 500
R1(config-ip-sla)#udp-jitter 192.168.32.2 32767 interval 20 num-packets 10 control enable
R1(config-ip-sla-jitter)#frequency 60
R1(config-ip-sla-jitter)#ip sla schedule 500 start-time now life forever
Verification of UDP-Jitter Operations
show ip sla configuration
R1#show ip sla configuration
IP SLAs Infrastructure Engine-III
Entry number: 500
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: udp-jitter
Target address/Source address: 192.168.34.2/0.0.0.0
Target port/Source port: 32767/0
Type Of Service parameter: 0x0
Request size (ARR data portion): 32
Packet Interval (milliseconds)/Number of packets: 20/10
Verify data: No
Vrf Name:
Control Packets: enabled
Schedule:
Operation frequency (seconds): 60 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
R1#
show ip sla statistics
Unlike path-jitter, UDP jitter does not include the following statistics:
- Packet late arrival
- Out of sequence packets
- Packet loss (source-to-destination and destination-to-source).
- One way latency (source-to-destination and destination-to-source).
- Jitter (source-to-destination and destination-to-source).
- Voice score values: calculated planning impairment factor (ICPIF), mean opinion score (MOS)
udp-jitter and icmp-jitter
operations for purposes of comparison:
R1#show ip sla statistics details
IPSLAs Latest Operation Statistics
IPSLA operation id: 100
Type of operation: icmp-jitter
Latest RTT: 35 milliseconds
Latest operation start time: 03:47:53 UTC Thu May 11 2023
Latest operation return code: OK
Over thresholds occurred: FALSE
RTT Values:
Number Of RTT: 8 RTT Min/Avg/Max: 14/35/57 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Source to Destination Latency one way Sum/Sum2: 0/0
Destination to Source Latency one way Sum/Sum2: 0/0
Jitter Time:
Number of SD Jitter Samples: 5
Number of DS Jitter Samples: 5
Source to Destination Jitter Min/Avg/Max: 4/20/32 milliseconds
Destination to Source Jitter Min/Avg/Max: 6/8/11 milliseconds
Source to destination positive jitter Min/Avg/Max: 13/25/32 milliseconds
Source to destination positive jitter Number/Sum/Sum2: 3/77/2217
Source to destination negative jitter Min/Avg/Max: 4/10/16 milliseconds
Source to destination negative jitter Number/Sum/Sum2: 2/20/272
Destination to Source positive jitter Min/Avg/Max: 6/6/8 milliseconds
Destination to Source positive jitter Number/Sum/Sum2: 4/27/185
Destination to Source negative jitter Min/Avg/Max: 11/11/11 milliseconds
Destination to Source negative jitter Number/Sum/Sum2: 1/11/121
Interarrival jitterout: 0 Interarrival jitterin: 0
Jitter AVG: 14
Packet Late Arrival: 0
Out Of Sequence: 0
Source to Destination: 0 Destination to Source 0
In both Directions: 0
Packet Skipped: 0 Packet Unprocessed: 0
Packet Loss: 2
Loss Periods Number: 2
Loss Period Length Min/Max: 1/1
Inter Loss Period Length Min/Max: 2/0
Number of successes: 19
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
IPSLA operation id: 500
Type of operation: udp-jitter
Latest RTT: 64 milliseconds
Latest operation start time: 03:47:17 UTC Thu May 11 2023
Latest operation return code: OK
Over thresholds occurred: FALSE
RTT Values:
Number Of RTT: 10 RTT Min/Avg/Max: 52/64/84 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Source to Destination Latency one way Sum/Sum2: 0/0
Destination to Source Latency one way Sum/Sum2: 0/0
Jitter Time:
Number of SD Jitter Samples: 9
Number of DS Jitter Samples: 9
Source to Destination Jitter Min/Avg/Max: 0/17/31 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/8/29 milliseconds
Source to destination positive jitter Min/Avg/Max: 11/21/31 milliseconds
Source to destination positive jitter Number/Sum/Sum2: 4/86/2058
Source to destination negative jitter Min/Avg/Max: 5/15/20 milliseconds
Source to destination negative jitter Number/Sum/Sum2: 4/63/1147
Destination to Source positive jitter Min/Avg/Max: 7/18/29 milliseconds
Destination to Source positive jitter Number/Sum/Sum2: 2/36/890
Destination to Source negative jitter Min/Avg/Max: 3/7/19 milliseconds
Destination to Source negative jitter Number/Sum/Sum2: 5/35/427
Interarrival jitterout: 0 Interarrival jitterin: 0
Jitter AVG: 13
Packet Loss Values:
Loss Source to Destination: 0
Source to Destination Loss Periods Number: 0
Source to Destination Loss Period Length Min/Max: 0/0
Source to Destination Inter Loss Period Length Min/Max: 0/0
Loss Destination to Source: 0
Destination to Source Loss Periods Number: 0
Destination to Source Loss Period Length Min/Max: 0/0
Destination to Source Inter Loss Period Length Min/Max: 0/0
Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0
Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 0
Mean Opinion Score (MOS): 0
Number of successes: 21
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
R1#
show ip sla responder
R4>show ip sla responder
General IP SLA Responder on Control port 1967
General IP SLA Responder is: Enabled
Number of control message received: 64 Number of errors: 0
Recent sources:
192.168.12.1 [03:54:53.903 UTC Thu May 11 2023]
192.168.12.1 [03:53:37.447 UTC Thu May 11 2023]
192.168.12.1 [03:52:22.055 UTC Thu May 11 2023]
192.168.12.1 [03:51:07.019 UTC Thu May 11 2023]
192.168.12.1 [03:49:51.259 UTC Thu May 11 2023]
Recent error sources:
Permanent Port IP SLA Responder
Permanent Port IP SLA Responder is: Disabled
TCP Connect Operations
The TCP Connect operation is to measure the response time taken to perform a TCP Connect operation between a Cisco router and IP/IPv6 device. The destination of the TCP Connect operation can be any device using IP/IPv6 or an IP SLA responder. The response time is determined by measuring the time taken between sending a TCP request message and receiving a response from the target device.
If the destination device is a Cisco device, then IP SLAs makes a TCP connection to any port number specified. If the destination is not a Cisco IP host, then a known destination port number such as 21 for FTP, 23 for Telnet, or 80 for an HTTP server must be specified. Using the IP SLAs Responder is optional for a TCP Connect operation when using Cisco devices. TCP Connect is used to test virtual circuit availability or application availability. Server and application connection performance can be tested by simulating Telnet, SQL, and other types of connection to help you verify your IP service levels. Just because we have local link reachability does not mean that we have upper layer connectivity.
Responder
The IP SLA responder for the TCP Connect operation is configured using the command:
ip sla responderwithout the TCP port specified. In this configuration, the device determines the port using control messages from the source.- For TCP port specified, the command is
ip sla responder tcp-connect ipaddress <ip-address> port <port> vrf <vrf>.
Source
- Configure the TCP Connect operation using the command
tcp-connect <destination-ip-address|destination-hostname> <destination-port> [source-ip <ip-address|hostname>] source-port <port> [control {enable|disable}]. - Configure the frequency:
frequency <value>where value is in seconds. -
Optional parameters include:
history lives-kept <value>: sets the number of lives maintained in the history table for an IP SLA operationhistory buckets-kept <value>: Number of history buckets that are kept during the lifetime of an IP SLAs operation.history hours-of-statistics-kept <value>: Number of hours for which statistics are maintained for an IP SLA operation.
- Schedule the IP SLA TCP Connect operation
DHCP Operation
IP SLA DHCP operation is used to measure the response time of a DHCP server in issuing IP configuration parameters. The IP SLA acts as a DHCP client and requests for an IP address from available DHCP servers. It measures the round-trip time(RTT) taken to discover a DHCP server and obtain a leased IP address from it. IP SLA releases the leased IP address after the operation. The IP SLA waits till its next iteration and requests for a DHCP server again. The RTT information can be used to determine DHCP performance levels. With DHCP operation, there is no need to configure the responder on the destination device as the DHCP server is the responder.
If tracking is enabled, a standby DHCP router can start issuing IP addresses if the primary DHCP server fails to respond within a configured period.
The DHCP operation can be configured as follows:
- Ensure IP access to an existing DHCP server.
- Configure the DHCP operation using the command
dhcp <destination-ip-address|destination-hostname> [source-ip <ip-address|hostname>] - Configure frequency
- Configure other optional features
tag: Creates a user-specified identifier for an IP SLA operation.threshold: Sets the upper threshold value for calculating network monitoring statistics created by an IP SLA operation.timeout: Sets the amount of time an IP SLA operation waits for a response from its request packet.history filter {none | all | overThreshold | failures}: Defines the type of information kept in the history table for an IP SLA operation.
- Schedule the DHCP operation.
Verification
show ip dhcp bind
show ip sla schedule
show ip sla configuration
HTTPS Operations
IP SLA HTTPS operation can be used to monitor the response time between a Cisco device and an HTTPS server to retrieve a web page. The IP SLA HTTPS operation supports both the normal GET and RAW requests. HTTPS server response time measurements consist of three types:
- The HTTPS operation measures the RTT between a Cisco device and an HTTPS server to retrieve a web page.
- The IP SLA HTTPS operation uses the Cisco IOS XE HTTPS secure client to send the HTTPS request, process the response from the HTTPS server and pass the response back to the IP SLA.
- The HTTPS server response time measurements consist of two types:
- DNS look: RTT taken to perform domain name lookup.
- HTTPS Transaction time: RTT taken by IOS HTTP secure client to send HTTPS request to the HTTPS server, get the response from the server. This RTT includes the time taken for the SSL handshaken, TCP connection to the server and HTTPS transactions.
HTTPS Operation Configuration
Use the command http secure [get|head|raw] <url> name-server <ip-address>
version <ip-address> source-ip <interface-name>.
If a proxy server is used, the HTTP RAW Operation through the proxy server can be
configured as follows:
http raw url http://www.proxy.cisco.com
http-raw-request
GET http://www.yahoo.com HTTP/1.0\r\n
\r\n
end
ip sla schedule 9 life forever start-time now
Troubleshooting
When troubleshooting Cisco IOS IP SLA, consider the following:
- The correct operation needs to be chosen based on the metrics you intend to measure.
- The destination IP address needs to be reachable and correctly defined.
- The source IP address needs to be reachable from the destination and correctly defined.
- Any necessary port numbers need to be correctly identified.
- The SLA instance needs to be started for it to work.
- If the operation needs an IP SLA responder, one must be configured and reachable.
To verify which operations are supported on the platform in addition to how many
operations are configured and how many are currently active, use the
show ip sla application command.
Use debug ip sla trace and debug ip sla error
to help troubleshoot IP SLA operation issues.
R1#debug ip sla trace 100
R1#
*Mar 13 15:34:34.261: IPSLA-INFRA_TRACE:OPER:100 slaSchedulerEventWakeup
*Mar 13 15:34:34.265: IPSLA-INFRA_TRACE:OPER:100 Starting an operation
*Mar 13 15:34:34.265: IPSLA-OPER_TRACE:OPER:100 source IP:1.1.1.1
*Mar 13 15:34:34.269: IPSLA-OPER_TRACE:OPER:100 Starting icmpecho operation - destAddr=4.4.4.4, sAddr=1.1.1.1
*Mar 13 15:34:34.269: IPSLA-OPER_TRACE:OPER:100 Sending ID: 6865
*Mar 13 15:34:34.429: IPSLA-OPER_TRACE:OPER:100 ID:6865, RTT=156
*Mar 13 15:34:34.437: IPSLA-INFRA_TRACE:OPER:100 Updating result
R1#
*Mar 13 15:34:44.265: IPSLA-INFRA_TRACE:OPER:100 slaSchedulerEventWakeup
*Mar 13 15:34:44.265: IPSLA-INFRA_TRACE:OPER:100 Starting an operation
*Mar 13 15:34:44.265: IPSLA-OPER_TRACE:OPER:100 source IP:1.1.1.1
*Mar 13 15:34:44.265: IPSLA-OPER_TRACE:OPER:100 Starting icmpecho operation - destAddr=4.4.4.4, sAddr=1.1.1.1
*Mar 13 15:34:44.265: IPSLA-OPER_TRACE:OPER:100 Sending ID: 6866
*Mar 13 15:34:44.425: IPSLA-OPER_TRACE:OPER:100 ID:6866, RTT=160
*Mar 13 15:34:44.433: IPSLA-INFRA_TRACE:OPER:100 Updating result
R1#
*Mar 13 15:34:54.261: IPSLA-INFRA_TRACE:OPER:100 slaSchedulerEventWakeup
*Mar 13 15:34:54.265: IPSLA-INFRA_TRACE:OPER:100 Starting an operation
*Mar 13 15:34:54.265: IPSLA-OPER_TRACE:OPER:100 source IP:1.1.1.1
*Mar 13 15:34:54.269: IPSLA-OPER_TRACE:OPER:100 Starting icmpecho operation - destAddr=4.4.4.4, sAddr=1.1.1.1
*Mar 13 15:34:54.269: IPSLA-OPER_TRACE:OPER:100 Sending ID: 6867
*Mar 13 15:34:54.485: IPSLA-OPER_TRACE:OPER:100 ID:6867, RTT=212
*Mar 13 15:34:54.493: IPSLA-INFRA_TRACE:OPER:100 Updating result
R1#
