WAN link bandwidth testing

[j.england]

Hello,

I have a 10Mb WAN link that is experiencing packet loss.  This link is not in production but is connected to production devices.  These routers are also connected via alternate WAN links that are currently routing production traffic.  Our ISP would like me to verify throughput for their troubleshooting so they may provide information to the other two ISPs from whom they're purchasing legs of the circuit (Alaska to southern California).

I've attempted to use TTCP between routers, but the default settings don't allow for 10Mb link saturation and I'm hesitant to alter window size on production devices.  The ISP wants point-to-point throughput data, so even if I could figure out a good way to run ttcp between Windows endpoints I don't think they'd like that data.  Is there a safe way to test accurately between the routers or a more efficient way to perform this test or gather the information?

Thanks in advance!

Justin

[johnwcorl]

Try using iperf or jperf. I have tested many wan links with it and even pushed up to couple hundred megs.  John

[j.england]

Thanks a lot for the response John.  Unfortunately for this I won't be able to use an application on LAN hosts to perform the test.  I'm still researching a way to saturate the link with ttcp short of opening 20 different sessions, but that may be my only recourse!

[Latchum Naidu]

Hi Justin,

For your scenario, I would suggest the TTCP throughput test is better choice for between two routers / between two LAN's.

Please find the below link for more informaiton.
http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080094694.shtml

Please rate the helpfull posts.

Regards,
Naidu.

[j.england]

Hi Naidu,

Thanks very much for the response.  I agree that TTCP would be the most appropriate tool for this instance, however my issue lies in my inability to saturate the link and get a proper throughput test for the 10Mb circuit using TTCP.  I'm not sure what each TTCP stream's bandwidth is, but it seems insufficient for my needs.  Do you know if there's a way to saturate the link with TTCP?  The link you provided speaks of altering window size, but even when I do I still experience about 0.5Mbps of throughput.  Unless that's the real throughput (which I doubt unless the link was provisioned incorrectly, 3% packet loss wouldn't cause that large of a degradation on a 10Mb circuit), then the TTCP stream isn't sufficient to saturate the link and get an accurate test.  Again, thanks for the assistance everyone!

Regards,

Justin

[manish arora]

Hi Justin,

Since you mentioned, the  links are not in production and that you still seeing a 3% drop. Then I think that if you run a tool called "mtr" on a red hat/centos linux between two endpoints , it will show you enough information on where the Packet loss if occuring and then you can inform your ISP to check that node out. As far as 10 mb connection, normally the ISP 10mb speed as they say is only for their Administartive domains ( ISP AS only ).

This is real life , I was trying to download something on my 20 mbps connection and was getting around 5 mbps , on calling my ISP , I was told that I can use on of their FTP server and check speed , if it's 20 mbps then that's what the SLA is for. But for packet loss , they say that it will be 99.0% guaranty.

If you do not have access to "mtr" , then run a traceroute to your destination and then ping each hop around 50 times , you will see where the drops are occuring. Here's an example of good MTR :-

                                                      My traceroute  [v0.71]
968 (0.0.0.0)                                                                                             Fri Feb 18 16:53:04 2011
Resolver: Received error response 2. (server failure)er of fields   quit
                                                                                                 Packets               Pings
Host                                                                                          Loss%  Last   Avg  Best  Wrst StDev
1. 173.255.5.1                                                                                 0.0%   0.9   1.0   0.9   1.0   0.1
2. 208.84.48.213                                                                               0.0%   0.7   0.9   0.7   1.5   0.3
3. 64.209.110.17                                                                               0.0%   0.8   0.7   0.7   0.8   0.0
4. te-4-1.car4.LosAngeles1.Level3.net                                                          0.0%   1.0   1.0   0.9   1.0   0.0
5. ae-41-90.car1.LosAngeles1.Level3.net                                                        0.0%   1.6   1.1   0.9   1.6   0.3
6. vnsc-bak.sys.gtei.net                                                                       0.0%   1.1   1.1   1.0   1.1   0.1

Manish

[j.england]

Manish - Thank you for taking the time to reply, that's a very comprehensive answer and would likely be very helpful in most cases.  However we're utilizing TLS with our ISP and unfortunately due to that our next hop is our routing endpint in Anchorage on our own equipment.  This is a point to point link also, not an internet circuit, so I believe the 10Mb is guaranteed at each demarc.

Your suggestion of using mtr may be useful, however.  It seems as if my only recourse for saturating and testing the link is to use machines on the LAN side of each endpoint, as opposed to a test between the two Cisco routers.

Thanks again for the response, it's much appreciated.

Justin

[gerald.suiza]

hi,

it seems strange to me that the ISP wants to test throughput with a link that is in non production with a packet loss issue. i assume there is no traffic traversing the link since it is in non prod. if there is packet loss have the basics been checked like errors, speed and duplex settings etc? is there qos on the interface and how does packet loss present itself? when you do a normal ping does it have packet loss? those are the questions that come to mind.

that aside, you can saturate a link by telnetting into the routers with multiple sessions and with each session you can ping the far end device using large size pings (something like size 15000 to 18024) and using timeout 0. dont be alarmed when you see dots on your pings (example: ................................... something like this). that is normal. you can then check the load of the interface when you do the ping if it gets saturated.

hth

[rsgamage1]

Hello Gerald,

While this being one of the easiest and most practical for WAN bandwidth testing I would like to emphasize that it can be CPU intensive.

What i have seen is as soon as tried with size18000/timeout 0 CPU jumped to over 50% of an aggregated services router.

    211111111155555511111111111111111111111111111111111111111111
      788888888889889887888888887878788878888887888888888877888888
  100                                                          
   90                                                          
   80                                                          
   70                                                          
   60           ******                                         
   50           *####*                                         
   40           *#####                                         
   30 *         ######                                         
   20 ##########################################################
   10 ##########################################################
     0....5....1....1....2....2....3....3....4....4....5....5....6
               0    5    0    5    0    5    0    5    0    5    0
               CPU% per minute (last 60 minutes)
              * = maximum CPU%   # = average CPU%

So my suggestion would be that care should be taken while testing router to router WAN in production (even if the link uner test is off production).

Thanks

rg