Pages

Wednesday 5 May 2021

Cisco IOS IP SLAs

Introduction and Overview

IP SLAs are used to measure and verify network performance. These measurements can be leaveraged to influence routing decisions such as static routing, policy-based routing(PBR). 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 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 SLAs are used to collect information about: reachability, response times to probes, one-way latency, jitter(inter-packet variation), voice quality scoring, etc.

IP SLA consists of two distinct parts; a probe and schedule.

  1. 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. Different types of probes used depend on the application being monitored; the main types are ICMP, TCP and UDP.
  2. 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.

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.

An 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. It that 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 duration. 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 prove accurate measurements. NTP may be required to be configured on the source and target device to ensure that two devices have the same time.

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 increase security.

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. IP SLA minimizes these processing delays on the source and target device when trying to determine accurate round-trip times by using UDP instead of ICMP to test latency and jitter.

IP SLA test packets use time stamping to more precisely calculate the processing delays. Responders have different types of timers:

  • T1 timer: this is the exit timer on request generated by the source router.
  • T2 timer: timer on the target router that the request is received.
  • T3: responder timer
  • T4: time packet arrives at the source router.

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;

  1. On the target device, configure the IP SLA responder. This may not be required for some IP SLA operations.
  2. Create the IP SLA
    1. Configure the IP SLA operation type
    2. 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.
  3. 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 causing these delays. A better method to measure network performance is through UDP traffic.

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.

  1. Create the IP SLA with an operation number using the global configuration command ip sla <sla-number>.

    R1(config)#ip sla 100

    1. 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

    2. 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

    3. 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 from its request packet. It is the timeout waiting period for the probe response. The timeout value cannot be greater than the frequency value.

      R1(config-ip-sla-echo)#timeout 10000

      The frequency is greater than the timeout which is greater than the threshold.

    4. 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 9000

      The 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.

    5. TOS: (Optional) Configure the tos value. This is the type of service value. Packets may be treated differently if the TOS value varies for instance such as VOIP traffic.
  2. Schedule the IP SLA operation using the global configuration command ip sla schedule <operation-number> life [forever | seconds] start-time [<hh:mm:ss> <month> <day> | 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

Shows the number of successes and failures and operation time to live. It shows unknown if probe is not wrong.

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. ICMP Path Echo is useful for determining network availability and for troubleshooting network connectivity issues 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 traffic is bottlenecking in a particular segment along the path. ICMP Path Jitter default values include;

  • number of echo probes: 10
  • Interval (time between echo probes (in milliseconds)): 20
  • frequency (seconds): 60
No IP SLA responder is required to be configured on the destination or intermediate devices.

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 be 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 SLAs sends a UDP datagram to any port number that you specified. 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>.

    R4(config)#ip sla responder udp-echo ipaddress 192.168.34.2 port 8080

    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.

Source Device

  1. Define the IP SLA:

    R1(config)#ip sla 400

  2. 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 responder global 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 the control disable keywords.

    • 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

  3. Schedule the IP SLA operation:

    R1(config)#ip sla schedule 1 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 target. UDP Jitter operation diagnoses network suitability for real-time traffic applications such as VoIP, video over IP or real-time conferencing. These paramters 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 queuing, 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)
As paths for sending and receiving data may be different (asymmetric), the per-direction data allows you to more readily identify where congestion or other problems are occurring in the network. The UDP jitter operation functions by generating synthetic (simulated) UDP traffic. Asymmetric probes support custom-defined packet sizes per direction with which different packet sizes can be sent in request packets (from the source device to the destination device) and in response packets (from the destination device to the source device).

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
However, it includes detailed information such as:
  • 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)
The following output shows RTT values for 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 responder without 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

  1. 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}].
  2. Configure the frequency: frequency <value> where value is in seconds.

  3. Optional parameters include:

    • history lives-kept <value>: sets the number of lives maintained in the history table for an IP SLA operation
    • history 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.

  4. 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:

  1. Ensure IP access to an existing DHCP server.
  2. Configure the DHCP operation using the command dhcp <destination-ip-address|destination-hostname> [source-ip <ip-address|hostname>]

    dhcp <server-ip>

  3. Configure frequency
  4. 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 amound 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.

  5. 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:
    1. DNS look: RTT taken to perform domain name lookup.
    2. 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.
    The total RTT is a sum of the DNS RTT and the HTTPS transaction RTT.
The results of the HTTPS operation can be displayed and analyzed to determine how an HTTPS server is performing. The configuration of an IP SLA responder for this operation is not required.

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.

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#

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#

References

  1. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/xe-16/sla-xe-16-book.pdf
Posted by at
Labels: , , , , , , ,
Location: Gulu, Uganda

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)