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:

https://www.cisco.com/en/US/technologies/tk648/tk362/tk920/technologies_qas0900aecd8017bd5a.html

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 192.168.12.2

And:

R2#ttcp transmit 192.168.12.1

ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp  -> 192.168.12.1
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.

Rene

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!

Laz

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!

Laz

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!

Laz

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

ip sla 1
    udp-jitter 10.0.0.1 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!

Laz

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.

Rene

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!

Laz

1 Like

same config , same things as rene metnions, on 7200 Software (C7200-ADVENTERPRISEK9-M), Version 12.4(11)T, RELEASE SOFTWARE (fc2) on gns3 but only default class take pckts, looks like the classification does not work, anything is have to take care of due to thos platform? Thnx in advance!

Hello Konstantinos

In the lesson, the various class maps are being matched using the port number of the UDP stream that is being used for each IP SLA. Assuming you used the same port number scheme, the class map should separate those streams and measure each one individually. Can you check your configuration to make sure that this has been done? If you continue to have problems, please share your IP SLA and class map configurations with us so we can help you further.

I hope this has been helpful!

Laz