3

Long ago, I read (I don't recall where now) that one may test a link's throughput by copying a file from a remote source to a local Cisco router's null: file system. I thought it was a great suggestion but never really had the chance to use it. REcently, I've been troubleshooting a link where the customer has been complaining of slow connectivity. I dusted off this nugget stored in my brain and tried it out. I'm slightly concerned about the results, however.

Truly, the connection was slow, but it was FAR slower than I expected it to be, slower even than the customer's report of a similarly-sized file. The command I used was something like:

copy scp://[email protected]://home/joe/randomfile.100m null:

So, is this a valid test? I am making assumptions that the TCP/IP stack and SSH/SCP processes are optimized well enough to handle the reception of data at or close to the line speed of the link in the direction of the remote host. Since the router is throwing the data away, I think I should be able to ignore write speed to the FS (as one may not be able to do when writing to flash, for example).

extra info: The link in question is a 1Gig interface towards the provider with a 50Mbps CIR. Traffic shaping is configured outbound, but this data direction is inbound. ISR4331, running 15.4-3 (isr4300-universalk9.03.13.02.S.154-3.S2-ext.SPA.bin).

If this IS a valid test, I could ask the provider to check the link to ensure shaping/policing outbound is correct.

Thanks for you thoughts.

Improve this question
1
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin ♦
    Aug 12, 2017 at 20:17

2 Answers 2

Reset to default
4

This is not a valid test, because you are using the router process to handle all the overhead of copying, decrypting, etc using scp. Normally, the router can forward packets without involving the processor (as much) for "ordinary" routing.

If you looking for a general sense of link quality (as opposed to actual throughput) I think you're better off doing pings with large packet sizes and looking for drops/errors.

Improve this answer
2

copy process you did not involved in link speed only but Buffer size and Que Rate of the file system memory as well which will provide slower result than you expected . so may you have two valid speed test.

1- Using Test TCP (TTCP) to Test Throughput as described in this link

2- use jperf server client speed test as described in this link

Improve this answer
3
  • Thanks for the response. This was really the unasked question, "what kind of overhead is there under the hood?" Of course, this is not well documented by Cisco. My assumption was the router should be able to throw data away (null:) as fast as it receives the data, thus write buffers could be ignored. Sadly, ttcp isn't available in this version of IOS-XE and I using iperf/jperf will require customer involvement. As we know, it's nice to be able to run useful tests without the constraints of external entities. Thanks again!
    – hrtednrup
    Oct 28, 2015 at 13:57
  • ok let me check again
    – Gadeliow
    Oct 28, 2015 at 14:25
  • May you use NETFLOW configuration on your router and use some sort of free Netflow analyzers like in CCP, may you also make use of this link software.ccschmidt.de
    – Gadeliow
    Oct 29, 2015 at 8:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.