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 