Testing TCP Connectivity on Cisco Devices

Ever thought you might be having some Layer 4 connectivity issues? Pings as you should know are ICMP transmissions and ICMP is a Layer 3 protocol (commonly used to send error messages). Luckily Cisco has a hidden ( as in it wont show up when using IOS help ) utility for testing TCP connectivity.

The command, ttcp is actually a very powerful tool for testing TCP connections, it requires IOS 11.2 or higher with IP Plus or Service Provider images. Here is an example of it being used to test connectivity between two locations.

SiteA#ttcp
transmit or receive [receive]:
buflen [8192]:
bufalign [16384]:
bufoffset [0]:
port [5001]:
sinkmode [y]:
rcvwndsize [2144]: 4096
show tcp information at end [n]:
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001, rcvwndsize=4096  tcp
SiteA#

SiteB#ttcp
transmit or receive [receive]: trans
Target IP address: 137.112.32.66
buflen [8192]:
nbuf [2048]: 50
bufalign [16384]:
bufoffset [0]:
port [5001]:
sinkmode [y]:
buffering on writes [y]:
show tcp information at end [n]:
ttcp-t: buflen=8192, nbuf=50, align=16384/0, port=5001  tcp  -> 137.112.32.66
SiteB#

SiteA#
ttcp-r: accept from 137.112.32.65 (mss 1460, sndwnd 2144, rcvwnd 4096)
ttcp-r: 409600 bytes in 61064 ms (61.064 real seconds) (~5 kB/sec) +++
ttcp-r: 301 I/O calls
ttcp-r: 0 sleeps (0 ms total) (0 ms average)
SiteA#

SiteB#
ttcp-t: connect (mss 1460, sndwnd 4096, rcvwnd 2144)
ttcp-t: 409600 bytes in 60504 ms (60.504 real seconds) (~5 kB/sec) +++
ttcp-t: 50 I/O calls
ttcp-t: 0 sleeps (0 ms total) (0 ms average)
SiteB#

The downside of ttcp is that it really makes me miss tcpspray for Linux / on ImageStream routers. As you see in this example ttcp requires that you start the receiver process on the remote end, while tcpspray just uses the echo and discard inetd services. I’ll cover some details about tcpspray in a future post.

Obviously another advantage of this utility is speed testing. Obviously, this is not a reliable means to test high bandwidth links as the router needs enough CPU to generate the packets. If your bandwidth tests are not pegging the router and you’re still not happy with the results, latency could be the issue. Check our my previous post on the relationship between latency and throughput.