Found a nifty hidden command on Cisco IOS routers that
generates TCP traffic from router to router.
TTCP Receiver
To setup a server to accept a connection do the following on a router:
To setup a server to accept a connection do the following on a router:
R2#ttcp receive
ttcp-r: buflen=8192,
align=16384/0, port=5001
rcvwndsize=4128,
delayedack=yes tcp
ttcp-r: accept from 10.2.1.2 (mss
536, sndwnd 4128, rcvwnd 3592)
ttcp-r: 16777216 bytes in 1296360
ms (1296.360 real seconds) (~11 kB/s) +++
ttcp-r: 32293 I/O calls
ttcp-r: 0 sleeps (0 ms total) (0
ms average)
TTCP Transmitter
To initiate a connection do the following on a second router:
To initiate a connection do the following on a second router:
R6#ttcp tran 2.2.2.2
ttcp-t: buflen=8192, nbuf=2048,
align=16384/0, port=5001 tcp -> 2.2.2.2
ttcp-t: connect (mss 536, sndwnd
4128, rcvwnd 4128)
ttcp-t: 16777216 bytes in 1296140
ms (1296.140 real seconds) (~11 kB/s) +++
ttcp-t: 2048 I/O calls
ttcp-t: 0 sleeps (0 ms total) (0
ms average)
You can just use TTCP command by itself to access more specific configuration options (change port/etc).
R2#ttcp
transmit or receive [receive]:
perform tcp half close [n]:
receive buflen [8192]:
bufalign [16384]:
bufoffset [0]:
port [5001]:
sinkmode [y]:
rcvwndsize [4128]:
delayed ACK [y]:
show tcp information at end [n]:
To quit the connection you do the “Ctrl+Shift+6, X” break sequence
and you get the following:
ttcp-t: buflen=8192, nbuf=2048,
align=16384/0, port=5002 tcp -> 3.3.3.3
ttcp-t: connect (mss 536, sndwnd
4128, rcvwnd 4128)
ttcp-t: 16777216 bytes in 1415708
ms (1415.708 real seconds) (~10 kB/s)
+++
ttcp-t: 2048 I/O calls
ttcp-t: 0 sleeps (0 ms total) (0
ms average)
The rate is presented in Bytes per second… so to get bits per second :
(Total bytes transmitted * 8) /
Total Seconds = bits per second.
Summary
This was very handy in a virtual lab when trying to generate traffic matching QoS marking/scheduling policy. Throughput-wise I’ve been able to generate around 450Kbps in the virtual lab which is good enough for my situation/testing. Since it is pretty raw you have to figure out optimal TCP sliding window sizes in order to congest links with more latency. This is more of a consideration for doing it on live routers with some real distance between them (i.e. RTT higher than 50ms).
You can also configure a PC to be a receiver/transmitter as well but I haven't tried this. I believe there is an application you can get from Cisco's download page.
This was very handy in a virtual lab when trying to generate traffic matching QoS marking/scheduling policy. Throughput-wise I’ve been able to generate around 450Kbps in the virtual lab which is good enough for my situation/testing. Since it is pretty raw you have to figure out optimal TCP sliding window sizes in order to congest links with more latency. This is more of a consideration for doing it on live routers with some real distance between them (i.e. RTT higher than 50ms).
You can also configure a PC to be a receiver/transmitter as well but I haven't tried this. I believe there is an application you can get from Cisco's download page.
Full details here: http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080094694.shtml
Thanks for reading.
