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://joe@10.11.12.13://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.
Best Answer
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.