Practical Networking .net
post

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

Speak Your Mind

*