traceroute question

Hi,

I have some very slow network. I did a traceroute and this is
part of output:

14 193.ATM4-0.BR2.SJC1.ALTER.NET (152.63.51.181) 163.651 ms 164.542 ms
160.822 ms
15 204.255.174.50 (204.255.174.50) 163.756 ms 247.200 ms 159.939 ms
16 snvcr1-ge0-snvrt1.es.net (134.55.209.89) 130.835 ms 129.653 ms
160.237 ms
17 gac-pos-snv.es.net (134.55.209.242) 206.610 ms 206.476 ms *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *


I thought that the asterisks mean there is a hang at
gac-pos-snv.es.net.
Someone told me that this is not necessarily so, and
said that asterisks mean the firewall is declining
to display trace information. Is that true?

If so, then how do I find where the bottleneck is?

Thanks ...

Ju

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

JaSeong Ju wrote:

> Hi,
>
> I have some very slow network. I did a traceroute and this is
> part of output:
>
> 14 193.ATM4-0.BR2.SJC1.ALTER.NET (152.63.51.181) 163.651 ms 164.542 ms
> 160.822 ms
> 15 204.255.174.50 (204.255.174.50) 163.756 ms 247.200 ms 159.939 ms
> 16 snvcr1-ge0-snvrt1.es.net (134.55.209.89) 130.835 ms 129.653 ms
> 160.237 ms
> 17 gac-pos-snv.es.net (134.55.209.242) 206.610 ms 206.476 ms *
> 18 * * *
> 19 * * *
> 20 * * *
> 21 * * *
> 22 * * *
> 23 * * *
>
>
> I thought that the asterisks mean there is a hang at
> gac-pos-snv.es.net.

No.

> Someone told me that this is not necessarily so, and
> said that asterisks mean the firewall is declining
> to display trace information. Is that true?

Yes and no. Maybe.

The asterisks mean that, for the hop in question, you did not receive a
response from the router servicing that hop. This /may/ be because of a
firewall or some other IP filter interposed between that hop and you, or
it /may/ be a routing problem that sends the responses off into
never-never land.

> If so, then how do I find where the bottleneck is?

Well, you found it, sort of.

The best you can tell from that traceroute is that something happened
after the gac-pos-snv.es.net waystop in your route. The next step is to
contact their NOC to find out what's happening. Usually, this would be
something that your ISP would do, if you had a corporate contract.


- --

Lew Pitcher, IT Consultant, Enterprise Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD4DBQFA/T4EagVFX4UWr64RApTNAKCG3EO9ZiBzNTRidKPJpqN60kiTrQC YtmZg
mt//VD1aoVqiDWjIg5/xJA==
=765a
-----END PGP SIGNATURE-----

JaSeong Ju <(E-Mail Removed)> wrote:
> If so, then how do I find where the bottleneck is?

I would ping every hop with series of several hundred
ICMP echo-request's, first standard size packets (small),
then 1 Kb, or larger. You might see excessive losses
at some point. Or something else, that might help
diagnosing the problem.

--
andrei

In article <(E-Mail Removed)>, Andrei Ivanov wrote:
>JaSeong Ju <(E-Mail Removed)> wrote:
>> If so, then how do I find where the bottleneck is?
>
>I would ping every hop with series of several hundred
>ICMP echo-request's, first standard size packets (small),
>then 1 Kb, or larger.

Please do not do that. Some people understand that as a "denial of
service" attack. There is simply NO REASON to abuse the network like
that. Three pings should tell you enough - so try

ping -c 3 -s 1480 IP.ADD.RE.SS

>You might see excessive losses at some point. Or something
>else, that might help diagnosing the problem.

Using a more appropriate tool is often a better solution.

[compton ~]$ whatis tcptraceroute
tcptraceroute (8) - A traceroute implementation using TCP packets
[compton ~]$ tcptraceroute --help
tcptraceroute 1.4 (2002-07-30)
Copyright (c) 2001, 2002 Michael C. Toren <(E-Mail Removed)>
Updates are available from http://michael.toren.net/code/tcptraceroute/

Usage: tcptraceroute [-nNFSAE] [-i <interface>] [-f <first ttl>]
[-l <packet length>] [-q <number of queries>] [-t <tos>]
[-m <max ttl>] [-pP] <source port>] [-s <source address>]
[-w <wait time>] <host> [destination port] [packet length]
[compton ~]$

A quick look at sunsite shows that version 1.5beta5 has been out for
about a year. I'm still using 1.4 simply because it works.

Old guy

Moe Trin <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed)>, Andrei Ivanov wrote:
>>JaSeong Ju <(E-Mail Removed)> wrote:
>>> If so, then how do I find where the bottleneck is?
>>
>>I would ping every hop with series of several hundred
>>ICMP echo-request's, first standard size packets (small),
>>then 1 Kb, or larger.
>
> Please do not do that. Some people understand that as a "denial of
> service" attack. There is simply NO REASON to abuse the network like
> that. Three pings should tell you enough - so try
>
> ping -c 3 -s 1480 IP.ADD.RE.SS

If I'll send one hundred ICMP echo requests, and will get back 80
responses, it will mean that at that particular hop 20% of packets
were lost. It's terrible condition, and definitely something would
be wrong right at that hop. Your three ping's in this case will
[very likely] reveal nothing at all. It's not network abuse, it's
just proper use for proper tool.

--
andrei

In article <(E-Mail Removed)>, Andrei Ivanov wrote:
>Moe Trin <(E-Mail Removed)> wrote:
>> In article <(E-Mail Removed)>, Andrei Ivanov wrote:
>>>
>>>I would ping every hop with series of several hundred
>>>ICMP echo-request's, first standard size packets (small),
>>>then 1 Kb, or larger.
>>
>> Please do not do that. Some people understand that as a "denial of
>> service" attack. There is simply NO REASON to abuse the network like
>> that. Three pings should tell you enough - so try
>>
>> ping -c 3 -s 1480 IP.ADD.RE.SS
>
>If I'll send one hundred ICMP echo requests, and will get back 80
>responses, it will mean that at that particular hop 20% of packets
>were lost. It's terrible condition, and definitely something would
>be wrong right at that hop.

But what would you do about it? Source routing has been ignored for
more than ten years, and trying to send mail to the owner of the routers
at each end of the "bad link" is nearly useless, even assuming you gat
figure out what a working address might be..

>Your three ping's in this case will [very likely] reveal nothing at all.

I also look for hints in the round trip delays. If I see _anything_ in
three pings, I would likely inventigate further, but would use a more
appropriate tool. Ping, and the crippled version of 'tracerout' that
comes with windoze and uses ICMP echos in place of UDP packets are not
reresentative of what is happening to your _data_ packets.

>It's not network abuse, it's just proper use for proper tool.

Have you noticed how many hosts no longer reply to pings? We drop them
(inbound) at the border router because of abuse. The two ISPs I use at
home do the same, mainly because of abuse, but also because of windoze
worms. The (American) National Security Agency recommends _rejecting_
ICMP echo (as well as 'ICMP redirect', ICMP mask-request) both in AND
outbound. http://www.nsa.gov/snac/index.html. Before you get to
parinoid, this is the same outfit that brings you SELinux.

On our internal LAN, we permit pings, but none of the servers or
routers will answer. Ten years ago, on booting a host that had been
moved, or repaired or whenever there was a question of communication,
we'd blast away, with

ping -c 25 -s 20480 some.nearby.host

and be worried if even one ping (note the -size which means each ping
gets fragmented, and generates 14 packets each way, and all had to come
back IN THE CORRECT ORDER to be considered a success) failed. That was
on a 255.255.252.0 subnet that often had over three hundred active hosts
on the same 10Base5 Thicknet wire. Times have changed, and I don't do that
any more, even on my home network with just six hosts.

Old guy