Cisco IP SLA — Using a Cisco Router to generate traffic

Recently, I got a chance to play around with some features of Cisco IP SLA and wanted to share a few things I learned. Namely, how to use a Cisco Router to generate mock traffic for testing.

In the past, I had only used this feature to send a few pings to test connectivity and/or remove static routes. But there is another way to use the IP SLA feature which allows you to generate mock traffic.

Cisco IP SLA configuration components

There are two elements to the Cisco IP SLA configuration: the IP SLA source and the IP SLA Responder. These correlate to the router sending the traffic and the router receiving the traffic, respectively.

IP SLA Source

The configuration of the IP SLA Source follows this configuration construct (for each type of traffic you wish to generate):

ip sla <#>
  <Type of Test> <Destination IP [port]>
  <Additional Parameters>

The <#> is simply a number between 1 and 2,147,483,647. This will group all the additional parameters of the test together. This will also be used later to actually start generating the traffic.

The <Type of Test> can be any number of tests available, which each correlate to a different type of traffic the router can generate:

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

The options we are going to focus on in this article are icmp-echo, tcp-connect, and udp-echo.

Finally, the <Additional Parameters> can be any number of additional tweaks, depending on which test you are using. The ones we’ll be focusing on in this article are:

  frequency    Frequency of an operation
  timeout      Timeout of an operation
  threshold    Operation threshold in milliseconds

The frequency correlates to how often the test is performed (i.e., how often packets are sent). The router won’t let you set this value lower than the timeout value.

The timeout value correlates to how long the router will work for any response after sending packets. The router won’t let you set this value lower than the threshold.

The threshold value correlates to the limit the administrator sets as what would be a successful test.

The definition of the timeout vs the threshold can be confusing. And for the simple traffic generation we are trying to do in this article the difference is somewhat irrelevant. But for the sake of completeness:

Within IP SLA, you can configure a certain acceptable threshold for a successful test. For example, let’s say you want to test that sending an ICMP echo results in receiving an ICMP echo-response, and that the response must come back within 500ms.

That 500ms would be your threshold. The timeout would be the total duration the Router will wait for a response. So if you set a timeout of 2000ms, you might receive an ICMP echo-response at 1000 milliseconds which would satisfy the timeout but fail the threshold. If the response had come back at 2500 milliseconds, it would fail both the timeout and the threshold.

In any case, for the simple traffic generation we’re going to provide examples of, we’ll be simply setting the threshold and the timeout to the same duration.

Starting the packet generation

Configuring the IP SLA Source simply defines a set of traffic that will be sent — it does not actually start sending the traffic.

To actually start sending the data, you would schedule it’s start-time using this syntax:

ip sla schedule <#> start-time <Start Time> life <Duration of traffic generation>

The <#> correlates to the entry number of the specific IP SLA test you want to start.

The <Start Time> and <Duration of Traffic Generation> can be specified many different ways, but the most frequent iteration of this command looks like this:

ip sla schedule <#> start-time now life forever

Using the keywords now and forever instructs the router to start the traffic generation immediately, and continue sending traffic indefinitely. The Administrator can stop the traffic generation by using the no version of this command.

Alternatively, you can schedule the start-time to occur at some point in the future. You can use an absolute date and time, or even a specific amount of hours/minutes/seconds to wait from the current time:

ip sla schedule <#> life forever start-time after 00:02:04

This will start IP SLA traffic, set it to reoccur indefinitely, and send the first packet after 00 hours, 02 minutes, 04 seconds.

Note that you may configure the start-time and life in any order.

IP SLA Responder

Configuring the IP SLA Responder is optional. If you simply mean to have a Router send traffic and aren’t concerned with responses coming back, then you merely need to configure the IP SLA Source.

Otherwise, you can configure the IP SLA Responder with only one command:

ip sla responder

That is all you need. That will configure a Cisco Router to respond to any IP SLA tests, regardless of which test.

This is possible because by default, the IP SLA Source will send control traffic to the IP SLA Responder to inform the IP SLA Responder which IP address and/or ports it should listen on. This IP SLA Control traffic occurs over UDP/1967.

If this traffic is troublesome for you, you can omit the command above and manually specify which IP address and Ports you mean for the Responder to listen on:

ip sla responder tcp-connect ipaddress <IP Address> port <Port#>
ip sla responder udp-echo ipaddress <IP Address> port <Port#>

You would need to repeat the command for every IP address and port you mean to generate traffic for that you wish to to see a response to.

This is not necessary for the icmp-echo test, as that is merely a regular Ping sent by the IP SLA Source.

It should be noted that before sending traffic using the tcp-connect and udp-echo tests, the Source Router will attempt to connect to the Responder Router over UDP/1967. If this “connection” is unsuccessful, the Source will not attempt to generate traffic. There is a way to disable the attempt at the control traffic connection by specifying the disable control argument in the IP SLA Source configuration. An example of this is provided later in this article.

Configuration Examples

Here is the Topology I am using for the commands and output in this article:

Cisco IP SLA -- Topology

The details of the topology are irrelevant, it is simply the topology I had loaded in GNS3 when I was playing with Cisco IP SLA. All you need to know is R1 and R7 have IP connectivity, and each have a Loopback IP address of 1.1.1.1 and 7.7.7.7 configured, respectfully.

R1# ping 7.7.7.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/6 ms

R7# ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/6/6 ms

Additionally, I am running a packet capture on the link between R1 and R2 and will provide screenshots of the relevant traffic being generated.

IP SLA — icmp-echo

We’ll apply this configuration to R1:

R1(config)# ip sla 1
R1(config-ip-sla)# icmp-echo 7.7.7.7
R1(config-ip-sla-echo)# threshold 1000
R1(config-ip-sla-echo)# timeout 1000
R1(config-ip-sla-echo)# frequency 10

We are configuring this test using IP SLA entry number 1. It is performing an icmp-echo test to the IP address 7.7.7.7. The Threshold and Timeout are 1000 ms, and the test will be repeated every 10 seconds.

As soon as that is configured…. nothing will happen. Not until we schedule it, that is:

R1(config)# ip sla schedule 1 start-time now life forever

As soon as that command is run, ICMP Echos (and their correlating echo-replies) appear on the wire:

Using a Cisco Router to generate ICMP traffic -- icmp-echo

The Time column is set to display the time since the previous displayed packet, which makes it easy to see the ping is occurring every 10~ seconds.

It should be noted that at this point, nothing has been configured on R7. This test is as simple as it gets, and unless R7 has been configured not to respond to pings, the IP SLA test will be successful.

R1 can confirm the result of the IP SLA test using the command 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
-----------------------------------------------------------------------
*1           icmp-echo   7.7.7.7           RTT=2       OK          4 seconds ago

Notice the Source IP address of the ICMP packets from R1 is 10.1.2.1. By default, Routers will use the closest IP address to the target as their source. In this case, it is the IP address of the link between R1 and R2.

If I instead wanted the traffic to use a different Source IP address, I can modify the command we used to configure the IP SLA. But before I do that…

R1(config)# ip sla 1
Entry already running and cannot be modified
        (only can delete (no) and start over)
        (check to see if the probe has finished exiting)

Notice, once the test is running, the router won’t let you modify any of the configuration. You have to stop it first using the no version of the schedule command which started it:

R1(config)# no ip sla schedule 1 start-time now life forever

Alternatively, you could have also simply blown away the entire IP SLA configuration:

R1(config)# no ip sla 1

Either way, to reconfigure the IP SLA such that it uses a particular Source IP address, you would use the source-ip argument:

R1(config)# ip sla 1
R1(config-ip-sla)# icmp-echo 7.7.7.7 source-ip 1.1.1.1
R1(config-ip-sla-echo)# threshold 1000
R1(config-ip-sla-echo)# timeout 1000
R1(config-ip-sla-echo)# frequency 10

And then of course, start the test:

R1(config)# ip sla schedule 1 start-time now life forever

Which now gets you the desired results:

Using a Cisco Router to generate ICMP traffic -- icmp-echo -- changing the IP SLA Source IP

IP SLA — tcp-connect

The tcp-connect test creates a simple TCP connection to the IP address and Port of your choosing.

We’ll configure and start a second IP SLA test between R1 and R7 creating a TCP connection on port 80:

R1(config)# ip sla 2
R1(config-ip-sla)# tcp-connect 7.7.7.7 80
R1(config-ip-sla-tcp)# threshold 1000
R1(config-ip-sla-tcp)# timeout 1000
R1(config-ip-sla-tcp)# frequency 10
R1(config-ip-sla-tcp)# exit
R1(config)#
R1(config)# ip sla schedule 2 start-time now life forever

But despite using the schedule command to start this test, this won’t actually send the TCP packets. Not yet at least. Here is what appears on the wire:

Cisco IP SLA -- control traffic over UDP 1967

You’ll notice what appeared is a UDP packet to R7, on port 1967. We mentioned earlier, this is the IP SLA Control traffic. R1 is trying to communicate with R7 to let R7 know it should listen on TCP port 80.

But of course, since R7 is not configured as an IP SLA Responder yet, the UDP “connection” failed, and the TCP connection was not even attempted.

We’ll go ahead and configure R7 as the IP SLA Responder in a moment. First I want to show you how to force sending the traffic without using an IP SLA Responder (because as I said earlier, configuring a Responder is optional if you only mean to send traffic and don’t care for a response).

R1(config)# ip sla 2
R1(config-ip-sla)# tcp-connect 7.7.7.7 80 control disable

The control disable argument after the tcp-connect command instructs R1 to send the traffic without attempting the control communication on UDP 1967. (The rest of the configuration is identical to what is above)

The result:

Using a Cisco Router to generate ICMP traffic -- tcp-connect -- control disable

Since R7 is not actually listening on Port 80, it rejects the connection by responding with TCP Reset ([RST, ACK]). The SLA test is currently failing, this can be verified with the show ip sla summary command:

R1# show ip sla summary
IPSLAs Latest Operation Summary
Codes: * active, ^ inactive, ~ pending

ID           Type        Destination       Stats       Return      Last
                                           (ms)        Code        Run
-----------------------------------------------------------------------
*1           icmp-echo   7.7.7.7           RTT=2       OK          5 seconds ago
*2           tcp-connect 7.7.7.7           RTT=0       Socket conn 0 seconds ago
                                                       ect error

We could manually tell R7 to listen on Port 80 using the commands we discussed prior:

R7(config)# ip sla responder tcp-connect ipaddress 7.7.7.7 port 80

The result is a successful TCP connection between R1 and R7:

Using a Cisco Router to generate ICMP traffic -- tcp-connect -- successful connection packet capture

Notice as soon as the three way handshake completes ([SYN], [SYN, ACK], [ACK]) R1 initiates the four way closure ([FIN, ACK], [ACK], [FIN, ACK], [ACK]). No data was actually sent, as this IP SLA is merely a test to see if a successful TCP connection was possible.

R1# show ip sla summary
IPSLAs Latest Operation Summary
Codes: * active, ^ inactive, ~ pending

ID           Type        Destination       Stats       Return      Last
                                           (ms)        Code        Run
-----------------------------------------------------------------------
*1           icmp-echo   7.7.7.7           RTT=2       OK          5 seconds ago
*2           tcp-connect 7.7.7.7           RTT=2       OK          1 second ago

The control disable option we used on R1 also exists for the udp-echo test. That said, we won’t show or use it again since you’ve seen it’s effect above. We’re going to continue with the rest of the article with automatic IP SLA enabled, which requires the control communication.

We’ll start by removing the manual IP SLA Responder comand on R7:

R7(config)# no ip sla responder tcp-connect ipaddress 7.7.7.7 port 80

Then we’ll tell R7 it will act as our IP SLA Responder:

R7(config)# ip sla responder

Then we’ll re-configure the IP SLA on R1 with the control left to it’s default behavior (which is enabled). And we’ll go ahead and start the tcp-connect tests:

R1(config)# no ip sla 2
R1(config)# ip sla 2
R1(config-ip-sla)# tcp-connect 7.7.7.7 80
R1(config-ip-sla-tcp)# threshold 1000
R1(config-ip-sla-tcp)# timeout 1000
R1(config-ip-sla-tcp)# frequency 10
R1(config-ip-sla-tcp)# exit
R1(config)# ip sla schedule 2 life forever start-time now

The result is R1 sending a connection on UDP/1967 to R7, to let R7 know an incoming TCP/80 connection follows. Which allows R7 to listen for that connection and respond:

Using a Cisco Router to generate ICMP traffic -- tcp-connect -- packet capture with IP SLA responder

Notice, even though the traffic came in on TCP port 80, Wireshark did not identify it as HTTP traffic. If it had, Wireshark would have claimed all the packets were malformed, since the exchange between the IP SLA Source (R1) and Responder (R7) does not adhere to the HTTP protocol.

IP SLA — udp-echo

The majority of the options available in the IP SLA were covered in the prior section (or at least, the majority of the options I plan to cover in this article). In this section, we’ll just show you how it works with the udp-echo test.

We’ll configure R1 with a new IP SLA to connect to R7 (7.7.7.7) on UDP port 53:

R1(config)# ip sla 3
R1(config-ip-sla)# udp-echo 7.7.7.7 53
R1(config-ip-sla-udp)# threshold 1000
R1(config-ip-sla-udp)# timeout 1000
R1(config-ip-sla-udp)# frequency 10
R1(config-ip-sla-udp)#exit
R1(config)#
R1(config)#ip sla schedule 3 life forever start-time now

And on the wire, we see this:

Using a Cisco Router to generate ICMP traffic -- udp-echo -- control-traffic

Notice first there is a UDP “connection” on port 1967 (the IP SLA control channel). Then there is the actual UDP “connection” we are testing in our configuration on port 53.

Furthermore, notice Wireshark claims this is a Malformed Packet. This is due to Wireshark trying to interpret this UDP/53 packet as a DNS packet.

Either way, since R1 is receiving a response, IP SLA #3 is resulting in a Return Code of OK.

R1# show ip sla summary
IPSLAs Latest Operation Summary
Codes: * active, ^ inactive, ~ pending

ID           Type        Destination       Stats       Return      Last
                                           (ms)        Code        Run
-----------------------------------------------------------------------
*1           icmp-echo   7.7.7.7           RTT=2       OK          2 seconds ago
*2           tcp-connect 7.7.7.7           RTT=1       OK          7 seconds ago
*3           udp-echo    7.7.7.7           RTT=6       OK          6 seconds ago

Summary

In total, we discussed three types of IP SLA tests: icmp-echo, tcp-connect, and udp-echo. These three tests can be used as a simplistic traffic generator for your lab environments.

Despite the length of this article, it still only scratches the surface of what IP SLA can do. There are tests that can initiate DNS queries, request HTTP webpages, perform DHCP requests, or retrieve files via FTP.

To read up on some of the more advanced features of IP SLA, check out Cisco’s Configuration Guide for IP SLA.

Otherwise, I hope you enjoy the content of this article. I will leave you with a quick copy and paste configuration that you can paste on to a Cisco Router which will generate a basic set of reoccurring traffic. I’ll be using this in an upcoming video where I’ll be discussing access-lists, and I want you to be able to recreate what I teach in the video as well.

Copy and Paste — Cisco Router Traffic Generator with IP SLA:

SourceResponderSource NCTResponder NCT
Click tabs to view the configuration for each router.

This configuration will generate six conversations, evenly distributed throughout 10 second intervals. The traffic includes one ICMP Ping, one UDP connection over port 53, and four TCP connections over port 22, 80, 443, & 3389.

The Source is the Router generating the traffic. The Responder is the Router receiving it and responding.

NCT (No Control Traffic) tabs perform the traffic generation without sending control traffic over UDP/1967.

Replace the IP 7.7.7.7 with the target IP address you wish to send traffic to.

ip sla 1
  icmp-echo 7.7.7.7
  threshold 1000
  timeout 1000
  frequency 10

ip sla 22
  tcp-connect 7.7.7.7 22
  threshold 1000
  timeout 1000
  frequency 10

ip sla 80
  tcp-connect 7.7.7.7 80
  threshold 1000
  timeout 1000
  frequency 10

ip sla 443
  tcp-connect 7.7.7.7 443
  threshold 1000
  timeout 1000
  frequency 10

ip sla 3389
  tcp-connect 7.7.7.7 3389
  threshold 1000
  timeout 1000
  frequency 10

ip sla 53
  udp-echo 7.7.7.7 53
  threshold 1000
  timeout 1000
  frequency 10

ip sla schedule 1 life forever start-time now
ip sla schedule 22 life forever start-time after 00:00:01
ip sla schedule 53 life forever start-time after 00:00:03
ip sla schedule 80 life forever start-time after 00:00:05
ip sla schedule 443 life forever start-time after 00:00:07
ip sla schedule 3389 life forever start-time after 00:00:09


ip sla responder

ip sla 1
  icmp-echo 7.7.7.7
  threshold 1000
  timeout 1000
  frequency 10

ip sla 22
  tcp-connect 7.7.7.7 22 control disable
  threshold 1000
  timeout 1000
  frequency 10

ip sla 80
  tcp-connect 7.7.7.7 80 control disable
  threshold 1000
  timeout 1000
  frequency 10

ip sla 443
  tcp-connect 7.7.7.7 443 control disable
  threshold 1000
  timeout 1000
  frequency 10

ip sla 3389
  tcp-connect 7.7.7.7 3389 control disable
  threshold 1000
  timeout 1000
  frequency 10

ip sla 53
  udp-echo 7.7.7.7 53 control disable
  threshold 1000
  timeout 1000
  frequency 10

ip sla schedule 1 life forever start-time now
ip sla schedule 22 life forever start-time after 00:00:01
ip sla schedule 53 life forever start-time after 00:00:03
ip sla schedule 80 life forever start-time after 00:00:05
ip sla schedule 443 life forever start-time after 00:00:07
ip sla schedule 3389 life forever start-time after 00:00:09

ip sla responder udp-echo ipaddress 7.7.7.7 port 53
ip sla responder tcp-connect ipaddress 7.7.7.7 port 80
ip sla responder tcp-connect ipaddress 7.7.7.7 port 443
ip sla responder tcp-connect ipaddress 7.7.7.7 port 22
ip sla responder tcp-connect ipaddress 7.7.7.7 port 3389

5 2 votes
Article Rating
Subscribe
Notify of
8 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments

If we have NOC team to monitor 100 routers. Can we simply configure IP SLA responder on 100 routers and IP SLA initiator on NOC side router for monitoring? What all features/parameters can be monitored using IP SLA?

Will the ACL take precedence over IP SLA ?

If there is ACL on the router but I configured “ip sla responder”, the router will reply ?

Hi. Fan of your work. Do you plan to expand this guide into IP SLA reactions? For example to create syslog events when there is a change in the IP SLA result. And another when it recovers. Without flooding the local logging buffer with repeated success/fails. This would be neat in a case the device loses outbound connections and can not send anything to an external syslog server.

For example: Ping fails 3 times -> create syslog event -> test recovers -> create syslog event. Later on when you come check the routers local logs, you can see when it happened and how long it lasted. Make similar IP SLA for DHCP, ping, tcp ports, DNS etc. and that would collect you crucial information when the problem occurs. Without the need of requesting users for the usual ping, nslookup, ipconfig stuff. Useful when the network problem comes and goes and you are without any data of what actually happened. Other than the useful description from the users “internet is not working”. 🙂

Here is one example of my attempt of achieving it, but I lack test devices so haven’t been able to confirm if it generates the logs in a way I want.

#icmp google
ip sla 8888
icmp-echo 8.8.8.8
frequency 10
timeout 2000
threshold 200


ip sla schedule 8888 life forever start-time now
ip sla reaction-configuration 8888 react timeout threshold-type consecutive 3 action-type trapOnly
ip sla logging traps

Basicly I want to write “sh logging” and see events when the reaction was first triggered and cleared. I’ll post more if I figure this out.

Hi

About the config. I managed to get some test results from real environment.
And the above configuration is indeed all you need for this solution.

In my example

ip sla reaction-configuration 8888 react timeout threshold-type consecutive 3 action-type trapOnly

this will trigger and create trap when there has been three consecutive timeouts on IP SLA 8888

This command will then create syslogs from the IP SLA traps.

ip sla logging traps

With the command

sh logging | include RTT

you will see these events from local log buffer.

Below is an event when the ping failed to the DC server (via third party SDWAN) from one office router.

023249: Oct 14 2021 04:33:03.272 UTC: %RTT-4-OPER_TIMEOUT: condition occurred, entry number = 1
023250: Oct 14 2021 04:33:03.274 UTC: %RTT-3-IPSLATHRESHOLD: IP SLAs(1): Threshold Occurred for timeout

It will not spam more events and instead waits until the ping goes below threshold value.

When that happens, it will generate another log with the recovery.

023254: Oct 14 2021 04:43:41.426 UTC: %RTT-4-OPER_TIMEOUT: condition cleared, entry number = 1
023255: Oct 14 2021 04:43:41.427 UTC: %RTT-3-IPSLATHRESHOLD: IP SLAs(1): Threshold Cleared for timeout

You are correct about the monitoring aspect. SNMP could be used along with these to send the relevant events to some outside server.

But there is some hidden potential in this feature. 🙂

Most monitoring is done from data centers to devices/services. (and mostly checking device health itself)
And not from user network to services.

The whole idea of using IP SLA locally would be to give myself data of what happened from the perspective of the office itself. Like I had a computer doing ping/telnet continuously in the office and I could get info what worked and what did not, during the incident. Even when connections are down from the office and the router would be unable to sent any SNMP’s to outside.

The IP SLA reaction will make sure the buffer only contains relevant down/up events without filling the buffer until I get to read them. And there is no need to ask users for ping, nslookup etc. (usually too late as the incident is already over).

I made a set of IP SLA’s that are pinging/testing several targets around the world (via that third party SDWAN).

  • data center (our DHCP and monitoring in another region)
  • DNS (azure on local region)
  • fileshare port (azure)
  • google 8.8.8.8

We had a major outage in one site due to that SDWAN breaking partially.

With the IP SLA I was able to tell exactly when different services and connections were down for the office.
In this case

  • Internet was available all the time
  • Azure connection was down 1-2 hours, no DNS or fileshares. And went up and down couple of times.
  • data center connection was down for 6 hours, so no dhcp to the users. The connection actually worked when azure went first down. Then the IPS dropped this connection to recover Azure and left this down until they fixed it later on.

I wouldn’t get this information from the user and it would have been too late when I received the ticket to investigate this.

All our monitoring shows green light on these services as they indeed were up and running, from data center viewpoint. Just the ping to the router was red. But from the viewpoint of the office, they were unable to do anything and different services were partially available at different times.

With time the IPS was able to recover different parts of the SDWAN connections. And now I have detailed list of what was down at what time excatly.

One reason I write here is because after googling for couple of weeks, I couldn’t find examples for what I was looking for. Hopefully someone in the future benefits from this post.

https://xkcd.com/979/ 😉