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.
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:
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:
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:
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:
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:
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:
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:
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:
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:
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
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?
Yes. You could do that. But with 100+ routers, you’d be better off configuring SNMP for network monitoring.
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 ?
This sounds like perfect questions to test in a lab =). I’m afraid I do not know the answer off hand.
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.
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 Ari, glad you’ve enjoyed my content =).
I like what you’re doing. It’s a great use case to spring board to from this article. I encourage you to find lab gear or virtualize some (using GNS3 or EVE-NG).
That said, in enterprise scenarios, you would use SNMP or SDN other automation based tools to validate device health and connectivity. These tools can do “so much more” than mere IP SLA on local Cisco Routers. To that end, I don’t see IP SLA used super often outside for smaller environments or limited test cases.
Still a cool feature though =)
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
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.
With the command
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.
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.
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).
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
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/ 😉
Whoa, nicely done! Way to take an idea and a technology and turn it into a service. Well done, Ari. And thank you for taking the time to write about it here!
I’m curious as to why Wireshark decoded UDP 53 packets as DNS and not the TCP packets as HTTP in your example above ?
Likely Wireshark looked into the application data to see the port 80 traffic didn’t include standard HTTP commands, but didn’t do so for the UDP 53 traffic.