Cisco IOS IP SLA Traffic Generator

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.