EThernet Link Testing

Hi Guys,

Here is a little challenge for you. Own of my support partners is testing some of my companies kit (ethernet over leased line). According to their test our kit is losing too many packets. Initially this concerned me so I asked for details of their test set-up. This is shown below:

PC <---> EI-DM===2mb/s link===DM-EI<---> PC

PC = Win2k Dells with 3com NICs
EI = Ethernet Interface Unit
DM = Dynamic MUX, provide E1 (2mb/s) interface

As it stands the test rig is acceptable as it replicates the real world deployment.

In order to test the performance they are running:

Ping -t.

and counting the lost packets. When they told me this I did cry....

Can you guys please suggest:

1) Reasons why Ping -t is not a suitable testing method. (I've tried but it isn't sinking in)

2) How you would test this link

Today is turning out to be a challenge....

Thanks

R

I'm assuming your kit is the ethernet-to-leased-line converter. If so, they ought to be using a leased line emulator to be sure that no packets are being lost on the 2Mb WAN circuit. WANs are'nt 100% reliable so to include that variability in the test then blame your kit is unfair. Also of course a simple ping -t uses only 64 byte packets which isn't a true test. They should at least try a variety of packet sizes (-n option) to get a true picture of response under load. If I were testing it I would also want to try transferring bulk data and-to-end, perhaps by copying various sizes of file back and forth. And I'd want a packet capture running while I did it so I could see that the TCP retransmissions etc weren't excessive. Finally, it's a pity they're using Win 2000 PCs as they do tend to burble a bit on the network. Linux machines might be a better choice for this application

another reason ping's aren't always the best way to test for performance/latency/etc...on a wan circuit is because often the carrier (ISP) has given ICMP low priority on their routing/switching equipment. This could have the effect of dropping ICMP packets in order to process the more important 'real' traffic.

I'd suggest doing an FTP transfer of a known file size and noting the time it takes the transfer to complete.