Help Interpreting traceroute output

[dsr at tao.merseine.nu (dsr at tao.merseine.nu)]

On Mon, Oct 18, 2004 at 11:36:38PM -0400, trlists at clayst.com wrote:
> On 18 Oct 2004 dsr at tao.merseine.nu wrote:
> 
> > Suppose that your app occasionally sends data that is just larger than
> > one packet-payload, requiring a second packet. And suppose that
> > there is a router somewhere in the middle which always drops
> > that second packet. But a single packet from traceroute always
> > gets through...
> 
> OK, I see your point!  Now how would you figure that out?  I presume by 
> looking at a packet-level log.

Sure. Run ethereal or tcpdump and (in this contrived case) you
would see that a second packet never gets an ack.

> > httperf is a good tool for testing HTTP connectivity and
> > performance.
> > www.hpl.hp.com/personal/David_Mosberger/httperf.html
> 
> Thanks.  I looked at the docs and it looks like it might provide some 
> useful results.  However to be most useful I really ought to run it 
> from the mirror, which is POSTing the files to our server.  If we are 
> trying to model the real-life issue carefully then initiating the 
> connections from our end will only provide partial info, at best.

Well, you run httperf from the client end, directed at the
server. It should tell you a fair number of useful things.

> > But your best bet is to talk to your ISP and their upstream (if
> > any) and see what they say.
> 
> Well in this case my client is the ISP (a hosting provider) and the 
> upstream is multiple OC3 and DS3 connections to 3 different backbone 
> providers.  Performance generally is not a problem during our attempts -
> - the only problem is this one specific operation. So it has to be 
> something in the installer, at the mirror, or a routing problem from us 
> to the mirror or back.

OK. I would run httperf here as a "is HTTP working well?"
diagnostic. You should expect results peaking close to the limit
of the smallest pipe in the chain.

-dsr-