# Cisco IOS IP SLA Traffic Generator

Lesson Contents

IP SLA is a great tool that you can use to make things like static routing more reliable but did you know you can also use it as a traffic generator?

When you configure IP SLA with the correct number of packets and payload sizes, you can use it to create certain traffic streams. This can be very useful when you want to practice QoS since you don’t have to mess around with traffic generator tools.

Before we look at the configuration, let’s do some calculations. Imagine we want to send 16 kbps of traffic from one router to another over Ethernet. How many packets should we send and what should the payload size be? Let’s take a look at the different header sizes first:

Here is an example of a frame, an Ethernet header has 14 bytes, IP is 20 bytes and UDP is 8 bytes.

## Calculate total frame size

My routers will be connected using Ethernet so that’s 14 bytes. IP adds another 20 bytes and UDP requires 8 bytes. The reason that I use UDP is that I will configure IP SLA to use UDP jitter.

14 + 20 + 8 = 42 bytes.

To keep the calculation simple, I’ll use a payload of 58 bytes so that the total packet will be 42 + 58 = 100 bytes.

## Calculate Bandwidth

Bandwidth = frame size x number of packets

We know our frame size is 100 bytes so how many packets should we send per second? Our goal is to generate 16 kbps of traffic, that’s 16.000 bits per second. This is how we calculate it:

Number of packets = bandwidth / frame size

Before we can do this, we need to convert our 16.000 bits to bytes:

16.000 bits / 8 = 2000 bytes.

Our packet size is 100 bytes and we need 2000 bytes per second to reach 16 kbps:

2000 / 100 = 20

We need to send 20 packets per second with a frame size of 100 bytes to hit 16 kbps!

So far so good? Let’s start the configuration…

## Configuration

To demonstrate IP SLA we will use two routers connected to each other with Ethernet, R1 and R2:

``````ip sla 1
udp-jitter 192.168.12.2 17001 num-packets 20
request-data-size 58
threshold 500
timeout 500
frequency 1
ip sla schedule 1 life forever start-time now``````

As calculated we will send 20 packets per second with a payload size of 58. This will be good for 16 kbps but I will show you how to verify this in a bit. I used destination port 17002 (pick whatever you like) for this instance.

Let me give you another example for a bandwidth rate of 32 kbps:

### We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

• Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
• Try for Just \$1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
• Content created by Rene Molenaar (CCIE #41726)

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.

Tags: , ,

## Forum Replies

1. Hi Hongfei,

Thanks for letting me know, I just re-uploaded this image.

Rene

2. 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.

3. 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
... Continue reading in our forum

4. 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.

https://gns3vault.com/blog/gns3-ip-sla-traffic-generator

5. 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: