Cisco IOS IP SLA Traffic Generator

What about it? :slight_smile:

I had the same experience as Ruben above. I only saw traffic register on R2 in the policy map statistics when I added ip sla responder to R2’s config. I tested a couple of times (Cisco VIRL iosv version 15.6(2)T). Great tool though! I’ll definitely find this useful in my QoS studies.

HI Rene,

Thank you for your article. I was looking for something to generate traffic like 200Mbps or more. I’ve tried iperf seems is not good. Do you have anything else to suggest or any approach to configure inside the routers?

Hi Daniel,

Generating ~200 Mbps of traffic from the router will be difficult. I usually use Iperf for this, what went wrong with Iperf for you?

Rene, when you say 200 mbps is difficult, is it still possible? Or depends upon platform? Generating traffic from cisco end to end itself comes really handy when you have other Linux devices in between. I see the IP SLA options too for TCP too? Any idea will this work, whatever lower.

Also I could not find lesson on TTCP or am I missing somewhere? That would not be bad either, whatever lower traffic it can generate.

IP SLA is great to generate some traffic so that you can test QoS with different traffic types and DSCP values but it really isn’t suitable for high bandwidth since it uses the CPU to generate traffic. For some more information, take a look at this article:

UDP-Jitter Probe for VoIP (G.729a) Running Eng 3-Cisco IOS Release 15.1(4)M Default Parameters: Frequency 60secs), Codec Packet Size (32bytes), Codec Interval (20ms), Codec Number of Packets (1000)

1921 2921 3925 3945 3945E
Operations (Total) 150 225 275 400 900
Operations/Second 2.5 3.75 4.58 6.7 15.0
Packets per Second 2500 3750 4583 6733 15000
Operations/Min 150 225 275 400 900
CPU Usage ~59% ~61% ~43% ~54% ~43%

You might get some different results with larger packets but there is quite a hit on the CPU.

TTCP is a simple tool you can use to generate some traffic:

R1#ttcp receive

ttcp-r: buflen=8192, align=16384/0, port=5001
rcvwndsize=0, delayedack=yes  tcp
ttcp-r: accept from


R2#ttcp transmit

ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp  ->
ttcp-t: connect

If you don’t specify a parameter, you can do some things like setting a different TCP port number or window size. I think it’s a bit of a hassle so I never use it :smiley:

1 Like

Rene, the image file named as “ethernet-ip-udp-payload-sizes.png” in this post is broken!

Hi Marcus,

Thanks for letting us know. I just fixed it.


I was very motivated to try this interesting feature. But, it seems on GNS3, it’s a little bit harder. Depending on examples ; when I ran sh ip sla moni stat (on 3600) or sh ip sla stat (on 7200), I got one of the errors below :

  • Latest RTT: NoConnection/Busy/Timeout
  • Latest operation return code: No connection
  • Latest operation return code: Timeout
  • Latest operation return code: Socket connect error

I tried also the stuff in the link below. I got almost the same errors, unfortunately.

Hello Maodo

Sometimes GNS3 just doesn’t want to cooperate :frowning: . This can often be the case. I see that your error codes are always different which is kind of strange. I suggest you try to duplicate the scenario using a different IOS image/device or on a different GNS3 platform to see if it is your setup or a more general issue.

Take a look at this Cisco Community post that may also give you a clue in your troubleshooting procedure.

I hope this has been helpful!


Hi Lazaros,

In the GNS3vault article, Renee says :

IP SLA will also allow you to monitor jitter/delay for voice traffic, if you want you need to enable “ip sla responder” on your destination router.

Did he omit to configure “ip sla responder” somewhere in the the NetworkLessons lab ?

Hello Maodo

In order to see such statistics of jitter and delay, you would indeed need to enable the responder. However, for this lesson, all that was needed was to generate some traffic. Take a look at this post.

I hope this has been helpful!


Hello Rene,
This is indeed great tool for practicing.

When I lab your configuraion, it seems like the destination device is blocking port 1967 which used for establishing IP SLA control connection via UDP.

should the policy-map that you had configured block this port and allow only 17001? or is it used only to capture the traffic?

it seems odd that my device blocking that port num 1967 when there is no access-group applied to the interface, only service-policy.

All I get from my SLA operation is a reply that indicates “port is unreachable”.

What could be the cause for that to happen?

Hello Nitay

In order to get the jitter configuration to work, you will require an IP SLA responder on the destination device. Otherwise, the destination will drop the UDP packets. This is clarified in the following lesson which also includes a jitter example:

I will let Rene know to add this piece of information.

I hope this has been helpful!


Hi Laz,
That wasn’t true because I configured the jitter option with the keywords “control disable” this way:

ip sla 1
    udp-jitter 17001 control disable num-packet 50

and after that my Policy-map did worked and the source started to transmit the data without waiting for the control session to be established with the destination.

Hello Nitay

Perfect, that’s great. Thanks for letting us know your solution!


Hello Nitay,

Like Laz explained, you will need the IP SLA responder if you generate IP SLA traffic and want to see some statistics in IP SLA. The only exception is ICMP echo traffic, you don’t need a responder for that.

In this example, the only goal is to generate traffic from one source to one destination. The reason I use the policy-map is so we can see the incoming data rates without generating any additional traffic. It’s a nice clean example to generate traffic for QoS without any overhead.


Which is better to use track or bfd in VRRP?
How would the configuration with BFD be done in VRRP?

Hello Alex

BFD is supported by VRRP on Cisco devices and provides a much faster response time than IP SLA. It is always best practice to introduce a delay in the response to an IP SLA detection as a single lost ping may not be an indication of a loss of connectivity, and could result in undesirable flapping. BFD on the other hand is more reliable in this and provides sub-second response times.

You can find out more about using BFD for VRRP at the following Cisco documentation:

You just have to ensure that the platform and IOS that you are using support the use of BFD for VRRP.

I hope this has been helpful!


1 Like