Home » Network Services » IP SLA

IP SLA

IP SLA stands for IP Service Level Agreement and it is a built in tool for  testing and analyzing various network parameters like overall health of the network, or verify if the QoS is working properly. It is also a very handy tool in troubleshooting various network problems.

IP SLA can generate traffic for network testing depending on what you want to test. It can run sampling against this IP SLA traffic and reports can be seen using the CLI. IP SLA can also store information in syslog or it can be also accessed via SNMP.

IP SLA Components
1. IP SLA Source (mandatory) , this is the source of the SLA traffic.
2. IP SLA Responder (optional)

IP SLA Types
IP SLA Probes  can be generated  for testing  and analyzing the following

ICMP Path Jitter
IP SLA generates ICMP traffic and measures
a. Hop by Hop Jitter
b. Packet Loss
c. Total Delay

ICMP Echo
IP SLA generates ICMP traffic and measures Round Trip Delay for entire path

ICMP Path Echo
IP SLA generates ICMP traffic and measures Round Trip Delay by breaking it down on a hop by hop basis

UDP Jitter
IP SLA generates UDP traffic and measures
a. Round Trip Delay
b. One Way Delay
c. One Way Jitter
d. One Way packet loss

UDP Jitter For VoIP
IP SLA generates UDP traffic and measures
a. Round Trip Delay
b. One Way Delay
c. One Way Packet loss
d. One Way Jitter
e. Has the capability to simulate various codecs
f. Has the capability to do Voice quality Scoring

UDP Echo
IP SLA generates UDP traffic and measures Round Trip Delay for UDP Traffic.

HTTP
IP SLA  measures the round trip time for the web page

FTP
IP SLA measures the round trip time for the file transfers

DHCP
IP SLA measures the total time for the DHCP address acquisition

TCP Connect
IP SLA measures the time to connect to a destination using TCP

IP SLA Source and Responder.

IP SLA source is mandatory as it will be generating the IP SLA traffic for testing and analysis. The IP SLA source has to be a Cisco router or a switch.

IP SLA Responder is optional, it is a software component that runs on the Cisco router or switch. The responder will communicate with the IP SLA source using a separate control protocol. The IP SLA control protocol allows the source and destination to give you clean and most accurate result of the IP SLA test.

IP SLA Operation Overview

Step 1: IP SLA source initiates the test specifying the target device, SLA operation to be performed and the port number for the IP SLA control protocol. The IP SLA source sends a message to port 1967 of the IP SLA responder with the port number and destination. Optionally MD5 authentication can take place between the IP SLA source and destination.

Step 2: If authentication passes and everything checks out properly, then the IP SLA responder replies with an OK message

Step 3: The IP SLA operation can kick in and gather the data also the IP SLA source and responder work together to clean up the data for more accurate and clean results. By cleaning up the data, both the IP SLA source and Destination will give you most accurate timestamps in milli-seconds.

IP SLA Responder Required Operations

The Following IP SLA operations require an IP SLA responder to be configured
1. UDP Jitter
2. VoIP Jitter

Note: UDP Echo and TCP Connect operations can be performed without an IP responder but you will get better and more accurate results with the IP SLA responder.

Non IP SLA Responder Operations

Operations for monitoring specific traffic types like HTTP, FTP, DHCP do not need an IP SLA responder to be configured. TCP Connect operations where the targets are Servers also do no need an IP SLA responder since the target is not a Cisco router or switch. If the Cisco router is acting as a DHCP server then you can run an IP SLA responder.

IP SLA Configuration

Testing VoIP Jitter between 2 locations

1. Configure the IP SLA Source

# config t
# ip sla 1
# udp-jitter <Destination IP> <Port Number> <codec>
# frequency  30  — ! Defines how often you want to generate the synthetic traffic (default is 60 seconds)

A this time the IP SLA is configured but not generating any traffic. To actually kick in the test the second step is to do the IP SLA scheduling where the IP SLA will start generating the traffic and the Jitter test defined above will kick in. Before we kick in the test, we need to configure the destination as IP SLA responder

2. Configure the IP SLA Destination
(Responder)
# config t
# ip sla responder

3. Start the IP SLA by starting the scheduler on the IP SLA source Device
# config t
# ip sla schedule 1 start-time now life forever

4. Verify IP SLA Data
# show ip sla statistics
# show ip sla configuration 1

5. Finally to Stop the SLA test after collecting the data
# config t
# no ip sla schedule 1

Rare and Antiquarian 234x60

Sample Configuration
Below is the diagram which I will use to configure a few IP SLA operations and for verifying the results.  Please keep in mind that I am using dynamips/GNS3 to do this configuration when viewing the results.

 

Simple UDP Reachability Test for a UDP Port

IP SLA will measure the reachablity and RTT for the destination on a particular UDP Port (UDP Port 15000 in this scenario). The test is scheduled to start now and go on for 300 seconds.

Configuration
R4(config)#ip sla responder
R4(config)#end

R1(config)#ip sla 21
R1(config-ip-sla)#udp-echo 192.168.4.4 15000 source-ip 192.168.1.1
R1(config-ip-sla-udp)#frequency 30
R1(config-ip-sla-udp)#exit
R1(config)#ip sla schedule 21 start-time now life 300

Verification:
R1#sh ip sla statistics

Round Trip Time (RTT) for       Index 21
Latest RTT: 32 milliseconds
Latest operation start time: *00:16:32.499 UTC Fri Mar 1 2002
Latest operation return code: OK
Number of successes: 6
Number of failures: 0
Operation time to live: 125 sec

R1#sh ip sla configuration
IP SLAs Infrastructure Engine-II
Entry number: 21
Owner:
Tag:
Type of operation to perform: udp-echo
Target address/Source address: 192.168.4.4/192.168.1.1
Target port/Source port: 15000/0
Request size (ARR data portion): 16
Operation timeout (milliseconds): 5000
Type Of Service parameters: 0x0
Verify data: No
Data pattern:
Vrf Name:
Control Packets: enabled
Schedule:
Operation frequency (seconds): 30  (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): 300
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
! — output omitted–

ICMP Echo Test and Threshold Action
IP SLA Operation will Ping the Destination and react to the RTT values where it goes over (upper boundary) 300 msec and if it is less than (lower boundary) 1 sec, then do an SMP trap immediately.

1. Enable SNMP traps for the IP SLA for this test.
R1(config)#snmp-server enable traps ipsla

2. Configure the IP SLA ICMP Echo
R1(config)#ip sla 22
R1(config-ip-sla)#icmp-echo 192.168.4.4 source-ip 192.168.1.1

3. Configure the Reaction Threshold and the Action to take
R1(config)#ip sla reaction-configuration 22 react rtt threshold-value 300 1 threshold-type immediate action-type traponly

4. Schedule the SLA to start now and end in 300 seconds
R1(config)#ip sla schedule 22 start-time now life 300

Verify:
R1#sh ip sla statistics
Round Trip Time (RTT) for       Index 22
Latest RTT: 43 milliseconds
Latest operation start time: *00:07:21.695 UTC Fri Mar 1 2002
Latest operation return code: OK
Number of successes: 1
Number of failures: 0
Operation time to live: 275 sec

IP SLA Test For measuring the VoIP Jitter.

Configuration

R4(config)#ip sla responder

R1(config)#ip sla 999
R1(config-ip-sla)#udp-jitter 192.168.4.4 16384 codec g729a source-ip 192.168.1.1
R1(config-ip-sla-jitter)#frequency 30  –! send packet every 30 seconds
R1(config-ip-sla-jitter)#timeout 500     –! time out in 500 sec
R1(config-ip-sla-jitter)#exit
R1(config)#ip sla schedule 999 start-time now life 300

Verify:

R1#sh ip sla statistics
Round Trip Time (RTT) for       Index 999
Latest RTT: 48 milliseconds
Latest operation start time: *00:17:32.631 UTC Fri Mar 1 2002
Latest operation return code: OK
RTT Values:
Number Of RTT: 963              RTT Min/Avg/Max: 1/48/266 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
Jitter Time:
Number of SD Jitter Samples: 937
Number of DS Jitter Samples: 924
Source to Destination Jitter Min/Avg/Max: 0/17/119 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/14/145 milliseconds
Packet Loss Values:
Loss Source to Destination: 0           Loss Destination to Source: 0
Out Of Sequence: 0      Tail Drop: 1
Packet Late Arrival: 0  Packet Skipped: 36
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 11
MOS score: 4.06
Number of successes: 4
Number of failures: 0
Operation time to live: 159 sec

Few notes of caution when running IP SLA.
Running IP SLA can cause high CPU and memory utilization on the Routers.
IP SLA can give inaccurate results if the CPU utilization is very high on the IP SLA source device.
The Clocks needs to be Sync when running IP SLA on the Source and Responder devices.
You can deploy a shadow router in the network whose purpose is just to do the IP SLA so that the production routers do no get overloaded with the SLA operations.

Below is the CPU snapshot to give an idea of how much the router cpu can spike up when running these tests.

Snapshot of CPU utilization While the test was running

R1#sh processes cpu
CPU utilization for five seconds:  22%/100%; one minute: 14%; five minutes: 10%

R1#sh processes cpu | inc SLA
PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
72       25688     23843       1077         11.30%  4.55%  3.56%   0 IP SLAs Event Pr

Snapshot of CPU utilization When  the test was complete

R1#sh processes cpu
CPU utilization for five seconds: 0%/100%; one minute: 10%; five minutes: 9%

148964_Primary

Incoming search terms for the article:

2 thoughts on “IP SLA

  1. Aman says:

    Hey thanks for your post. Really valuable for me.
    I have a query,
    1. Using the same setup, is it possible to measure the icmp response time on the link between R3 and R4.If yes, Please explaion how. If no, what could be the alternative.

    Thanks in advance for your reply

  2. Amit Rai says:

    Not on the same setup – but using two directly connected routers (R1 and R2) to get this output below. You can use the Path Echo operation of IP SLA as below. In this setup i have R1—–Connected to——R2. R1 has an ip address of 10.10.10.1/24 on Fa0/1 and connects to R2 on Fa0/1 which has an ip of 10.10.10.2/24

    R1#sh run | sec ip sla 2
    ip sla 2
    path-echo 10.10.10.2 source-ip 10.10.10.1
    timeout 2000
    frequency 5

    R1#sh ip sla statistics 2

    Round Trip Time (RTT) for Index 2
    Latest RTT: 4 milliseconds
    Latest operation start time: *00:19:09.339 UTC Fri Mar 1 2002
    Latest operation return code: OK
    Operation time to live: Forever

    ICMP Path-Echo determines hop by hop ICMP response time between the two devices.
    You can compare these path-echo results with the results of regular ICMP-Echo Operation which is listed below.

    R1#sh run | sec ip sla 1
    ip sla 1
    icmp-echo 10.10.10.2 source-ip 10.10.10.1
    timeout 2000
    frequency 30

    R1#sh ip sla statistics 1
    Round Trip Time (RTT) for Index 1
    Latest RTT: 16 milliseconds
    Latest operation start time: *00:20:29.767 UTC Fri Mar 1 2002
    Latest operation return code: OK
    Number of successes: 24
    Number of failures: 0
    Operation time to live: 2888 sec

Leave a Reply