IP SLA (Service-Level Agreement) on Cisco IOS

IP SLA (Service-Level Agreement) is a great feature on Cisco IOS devices that can be used to “measure” network performance.

This can be something simple like a ping where we check the round-trip time or something more advanced like a VoIP RTP packet where we check the delay, jitter and calculate a MOS score that gives you an indication what the voice quality will be like.

Measuring network performance is pretty cool but what makes IP SLA even more powerful is that you can combine it with static routes, policy based routing and routing protocols like OSPF or EIGRP.

Let me give you an example why this is a great feature to use. Take a look at the image below:

Customer ISP1 ISP2 Default Route

Above we have a customer router connected to two ISPs. Somewhere on the Internet there’s a server we’d like to reach. In a scenario like this, typically we use two default routes with different ADs. Whenever ISP1 fails, we switch over to ISP2.

The problem with this setup is that it’s not very reliable. The default route will be in the routing table as long as the interface is up and/or the next hop is reachable. It’s possible that ISP1 is having connectivity issues and unable to reach that remote server but we still use them for all our traffic.

To prevent this from happening we can combine default routes with IP SLA. Here’s an example:

Customer ISP1 ISP2 IP SLA ICMP

Our customer router is now using IP SLA to ping the remote server. As long as we get a reply, we will keep using ISP1 as our main route. When the ping fails, we switch over to ISP2. This method is far more reliable as we check end-to-end connectivity.

Here’s another example where IP SLA might be useful:

HQ Branch IP SLA RTP Probe

Above we have two ISPs that we can use to reach a remote branch router. Instead of a simple ping, we can send RTP packets and check these for a certain delay, jitter and calculate a MOS score. When we get below a certain threshold we will switch from ISP1 to ISP2.

Each measurement that we do with IP SLA is called an operation. For each operation we have to configure the type of traffic, source IP, destination IP, port numbers, etc. We can then configure when to run the operation…24/7, 9-to-5, etc.

When you use IP SLA for a simple ping then you only have to configure your local router. However when you want to use it for some more advanced things like sending RTP packets then you have to configure the remote router to respond to your IP SLA traffic.

Besides pings and RTP, there are a lot of different operations we can use:

  • TCP Connections
  • UDP
  • DNS
  • DHCP
  • HTTP
  • FTP

Now you have an idea what IP SLA is about, let’s take a look how we can configure an operation.

Configuration

I will show you two examples so you will learn how to configure IP SLA operations. We’ll try an example with pings and an example with UDP jitter.

ICMP echo Operation

We will use the following topology:

R1 R2 FastEthernet

All I need is two routers, R1 will send ICMP echo requests and R2 will reply to them. Here’s how to configure IP SLA:

R1(config)#ip sla 1
R1(config-ip-sla)#?
IP SLAs entry configuration commands:
  dhcp         DHCP Operation
  dns          DNS Query Operation
  ethernet     Ethernet Operations
  exit         Exit Operation Configuration
  ftp          FTP Operation
  http         HTTP Operation
  icmp-echo    ICMP Echo Operation
  icmp-jitter  ICMP Jitter Operation
  mpls         MPLS Operation
  path-echo    Path Discovered ICMP Echo Operation
  path-jitter  Path Discovered ICMP Jitter Operation
  tcp-connect  TCP Connect Operation
  udp-echo     UDP Echo Operation
  udp-jitter   UDP Jitter Operation
  voip         Voice Over IP Operation

First we have to choose an operation number, let’s pick number 1. You can see that there are a lot of different operations we can choose from. Let’s start with the icmp echo:

R1(config-ip-sla)#icmp-echo 192.168.12.2 
R1(config-ip-sla-echo)#?  
IP SLAs Icmp Echo Configuration Commands:
  default            Set a command to its defaults
  exit               Exit operation configuration
  frequency          Frequency of an operation
  history            History and Distribution Data
  no                 Negate a command or set its defaults
  owner              Owner of Entry
  request-data-size  Request data size
  tag                User defined tag
  threshold          Operation threshold in milliseconds
  timeout            Timeout of an operation
  tos                Type Of Service
  verify-data        Verify data
  vrf                Configure IP SLAs for a VPN Routing/Forwarding instance

Let’s send ICMP echos to 192.168.12.2. There are a lot of optional parameters you can configure for an operation, for example let’s change the frequency:

R1(config-ip-sla-echo)#frequency 10

We’ll send an ICMP echo every 10 seconds. The only thing left to do is to start our IP SLA operation. This is how you do it:

R1(config)#ip sla schedule 1 ?
  ageout      How long to keep this Entry when inactive
  life        Length of time to execute in seconds
  recurring   Probe to be scheduled automatically every day
  start-time  When to start this entry
  <cr>

You have to use the ip sla schedule command to start your operation. You can schedule it but we will start our operation right now and let it run forever:

R1(config)#ip sla schedule 1 start-time ?
  after     Start after a certain amount of time from now
  hh:mm     Start time (hh:mm)
  hh:mm:ss  Start time (hh:mm:ss)
  now       Start now
  pending   Start pending
R1(config)#ip sla schedule 1 start-time now ?
  ageout     How long to keep this Entry when inactive
  life       Length of time to execute in seconds
  recurring  Probe to be scheduled automatically every day
R1(config)#ip sla schedule 1 start-time now life ?
  <0-2147483647>  Life seconds (default 3600)
  forever         continue running forever
R1(config)#ip sla schedule 1 start-time now life forever

It should now be up and running. You can check your IP SLA configuration like this:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 660 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

503 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: , , ,


Forum Replies

  1. Hi Rene,
    Fantastic article. This is the senerio I am trying. I have a site that is using a primary link as MPLS and a secondary backup link as VPN (IPsec site-to-site). Due to some erformance issues I would like to change the primary as the VPN and keep the MPLS as the backup. In my case I have a Fortigate Firewall at one site where the MPLS and VPN links terminate and at my head office I have a Core switch where the MPLS terminates and another fortigate where the VPN terminates. I have decreased the Administrative distance on the Fortigates to 18 so that it is

    ... Continue reading in our forum

  2. Hi Ian,

    Static routes will send ALL traffic for a certain prefix in a certain direction. It doesn’t care what kind of traffic it is…PBR (Policy Based Routing) lets you change the next hop IP address for specific traffic, for example something that matches an access-list.

    The “backup” time depends on the timers that you configured for IP SLA.

    For your internal networks, OSPF is a good solution because it will automatically deal with failed links and such. IP SLA + Static routes however can be useful for the edge of your network. Imagine you have two ISPs and you

    ... Continue reading in our forum

  3. Hi Sahar,

    BFD is useful for local networks where you use protocols like OSPF or EIGRP. IP SLA is more useful for WAN connections, you can use it to check if your Internet connection is operational.

    Rene

  4. Hi Laz

    //cdn-forum.networklessons.com/uploads/default/original/2X/a/ac98801ce4d97073221452a70f8d8a86955d11c9.png

    I follow your introduction, but it still the problem once My IP SLA which ping to 8.8.8.8 through ISP1 using source interface that direct connect to ISP1 fail, it will use secondary route , after failover to secondary route, IP SLA keep fail, as it never can reach 8.8.8.8 with source interface connect to ISP1 using secondary route which go through ISP2.
    Please help on this problem
    Thank you
    Sovandara Heng

  5. Hello Dominique

    The answer is yes, even for one fail, the action is taken immediately. It is

    ... Continue reading in our forum

38 more replies! Ask a question or join the discussion by visiting our Community Forum