Hello,
this is copied over from stack exchange:
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). I believe that IOS is built on top of some *NIX, so it might be reasonable to consider the null: filesystem the same thing as /dev/null, no?
/dev/null is implemented in the kernel, so it can throw data away pretty fast and thus no worry about some write buffer.
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). TTCP is not avail in this version of IOS-XE.
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.
