What do all those "* * *" mean on a traceroute log?

[Albretch Mueller]

I have found a few examples and "explanations" but in the cases of
the examples I have seen by other people, like:

https://serverfault.com/questions/733005/what-does-having-mean-in-the-command-traceroute-and-how-can-you-cope-wit

It is not with every site and it is mostly with one hop. I my case it
is with all sites and once the packets reach the web (from hop 5 to
30), from wherever I connect to the Internet. Why would that happen
and why would that -consistently- "happen" to me?

$ traceroute google.com
traceroute to google.com (172.217.0.174), 30 hops max, 60 byte packets
1 _gateway (199.83.128.1) 6.687 ms 6.660 ms 6.683 ms
2 199.83.240.2 (199.83.240.2) 6.101 ms 6.622 ms 6.610 ms
3 ad.nypl.org (199.254.254.1) 6.600 ms 6.588 ms 6.577 ms
4 199.254.252.1 (199.254.252.1) 6.566 ms 6.590 ms 6.738 ms
5 * * *
. . .
30 * * *

$ traceroute microsoft.com
traceroute to microsoft.com (20.81.111.85), 30 hops max, 60 byte packets
1 _gateway (199.83.128.1) 12.353 ms 12.319 ms 12.306 ms
2 199.83.240.2 (199.83.240.2) 11.803 ms 12.281 ms 12.268 ms
3 ad.nypl.org (199.254.254.1) 12.256 ms 12.244 ms 12.231 ms
4 199.254.252.1 (199.254.252.1) 12.255 ms 12.243 ms 12.511 ms
5 * * *
. . .
30 * * *

$ traceroute debian.org
traceroute to debian.org (149.20.4.15), 30 hops max, 60 byte packets
1 _gateway (199.83.128.1) 16.821 ms 17.804 ms 17.784 ms
2 199.83.240.2 (199.83.240.2) 4.739 ms 5.086 ms 5.070 ms
3 ad.nypl.org (199.254.254.1) 5.054 ms 5.389 ms 5.023 ms
4 199.254.252.1 (199.254.252.1) 6.805 ms 6.282 ms 6.773 ms
5 * * *
. . .
30 * * *

lbrtchx

[Michel Verdier]

Le 12 avril 2023 Albretch Mueller a écrit :

> It is not with every site and it is mostly with one hop. I my case it
> is with all sites and once the packets reach the web (from hop 5 to
> 30), from wherever I connect to the Internet. Why would that happen
> and why would that -consistently- "happen" to me?

The last hop doesn't forward your packet. If you still can ping a site or
simply consult it it should be the last hop filtering the packet type
used by traceroute. You can try traceroute with icmp or tcp packet to
check if this is the point.

[to...@tuxteam.de]

On Wed, Apr 12, 2023 at 05:37:32PM +0000, Albretch Mueller wrote:
> I have found a few examples and "explanations" but in the cases of
> the examples I have seen by other people, like:

Quoth the man page:

This program attempts to trace the route an IP packet would
follow to some internet host by launching probe packets with
a small ttl (time to live) then listening for an ICMP "time
exceeded" reply from a gateway. We start our probes with a
ttl of one and increase by one until we get an ICMP "port
unreachable" (or TCP reset), which means we got to the "host",
or hit a max (which defaults to 30 hops) [...]
If there is no response within a certain timeout, an "*"
(asterisk) is printed for that probe.

So that means that the probe for the TTL in question "got lost":
either the router at that distance doesn't want to send an ICMP
our way or there's something in between eating ICMPs.

Cheers
--
t

[Greg Wooledge]

On Wed, Apr 12, 2023 at 05:37:32PM +0000, Albretch Mueller wrote:

> It is not with every site and it is mostly with one hop.

> $ traceroute google.com
> traceroute to google.com (172.217.0.174), 30 hops max, 60 byte packets
> 1 _gateway (199.83.128.1) 6.687 ms 6.660 ms 6.683 ms
> 2 199.83.240.2 (199.83.240.2) 6.101 ms 6.622 ms 6.610 ms
> 3 ad.nypl.org (199.254.254.1) 6.600 ms 6.588 ms 6.577 ms
> 4 199.254.252.1 (199.254.252.1) 6.566 ms 6.590 ms 6.738 ms
> 5 * * *
> . . .
> 30 * * *

First you have to understand how traceroute works. It's like ping,
except that instead of just sending out a stream of normal packets, one
per second, and noting the reply times, it sends out a bunch of packets
with increasing Time To Live fields.

Each router along the path to the destination decreases the TTL field,
and if it's negative (or zero?) at any given point, that hop is supposed
to return a "Time Exceeded" response. (Time is a badly chosen word here;
it's a hop number, not an actual time interval, that's being counted.)

So, in theory, you should get one Time Exceeded response from each router
along the path. That's what traceroute shows you.

However, some routers may choose not to honor this, and do not send a
Time Exceeded response to you. Or, in some cases, the response packet
may simply be lost in transit. Those are the hops where traceroute
shows * * *.

An example from my system:

unicorn:~$ traceroute www.google.com
traceroute to www.google.com (142.250.190.4), 30 hops max, 60 byte packets
1 routerlogin.net (10.0.0.1) 0.413 ms 0.355 ms 0.415 ms
2 65-131-222-254.mnfd.centurylink.net (65.131.222.254) 38.070 ms 39.776 ms 36.299 ms
3 75.160.81.21 (75.160.81.21) 41.687 ms 45.801 ms 39.873 ms
4 * * *
5 ae0.11.bar2.Toronto1.level3.net (4.69.151.242) 56.715 ms ae14.14.bar2.Toronto1.level3.net (4.69.216.246) 56.550 ms ae0.11.bar2.Toronto1.level3.net (4.69.151.242) 58.637 ms
[...]

No response was received from hop number 4, so traceroute shows me * * *
there.

[Albretch Mueller]

On 4/12/23, Greg Wooledge <gr...@wooledge.org> wrote:
> unicorn:~$ traceroute www.google.com
> traceroute to www.google.com (142.250.190.4), 30 hops max, 60 byte packets
> 1 routerlogin.net (10.0.0.1) 0.413 ms 0.355 ms 0.415 ms
> 2 65-131-222-254.mnfd.centurylink.net (65.131.222.254) 38.070 ms 39.776
> ms 36.299 ms
> 3 75.160.81.21 (75.160.81.21) 41.687 ms 45.801 ms 39.873 ms
> 4 * * *
> 5 ae0.11.bar2.Toronto1.level3.net (4.69.151.242) 56.715 ms
> ae14.14.bar2.Toronto1.level3.net (4.69.216.246) 56.550 ms
> ae0.11.bar2.Toronto1.level3.net (4.69.151.242) 58.637 ms
> [...]
> No response was received from hop number 4, so traceroute shows me * * *
there.

Yes, but should it happen on every hop? In my case it happens while I
am trying to reach every site and from wherever I have the chance to
get some relatively decent Internet access?

A descriptive metaphor would be. You can see the traffic light once
you get out of your home's drive way, but the rest of all of them
misfunction regardless of where you are driving and the time of the
day and it always, consistently and apparently, exclusively happens to
-you- ;-)

lbrtchx

[debia...@howorth.org.uk]

I was playing with the addresses listed by Albretch and found that
199.254.252.1 is interesting. whois says it belongs to "Alexandria Sash
& Door (ASD-1)" and
https://opencorporates.com/companies/us_wa/601161047 (via google) tells
me that firm was dissolved in 2005. But the whois entry was updated in
2021. So something's a little odd there. ping says "From 51.148.77.136
icmp_seq=1 Destination Net Unreachable" when I try to ping it.

[Alexander V. Makartsev]

On 13.04.2023 00:00, Albretch Mueller wrote:

 Yes, but should it happen on every hop? In my case it happens while I
am trying to reach every site and from wherever I have the chance to
get some relatively decent Internet access?

There is a chance your trace packets were filtered (rate-limited), because by default "traceroute" sends them without delay and remote hosts could "see" them as flood.
Try to test same route again, but with a send delay set to a reasonable 1 second using "-z" parameter, like so:
    # traceroute -z 1 8.8.8.8

--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[David Wright]

On Wed 12 Apr 2023 at 20:18:19 (+0100), debia...@howorth.org.uk wrote:
> I was playing with the addresses listed by Albretch and found that
> 199.254.252.1 is interesting. whois says it belongs to "Alexandria Sash
> & Door (ASD-1)" and
> https://opencorporates.com/companies/us_wa/601161047 (via google) tells
> me that firm was dissolved in 2005. But the whois entry was updated in
> 2021. So something's a little odd there. ping says "From 51.148.77.136
> icmp_seq=1 Destination Net Unreachable" when I try to ping it.

After googling them, I gave Moxee a call. They answer to a subtly
different name, but it's the same business: a Canadian/US company
that's been family-owned through three generations. Their website
is now hosted by godaddy, so I guess they just hang on to those old
addresses. I don't know why they have their Moxee plant's street
address on it. (Their godaddy registration is buttoned up in the
modern manner.)

Cheers,
David.

[Albretch Mueller]

On 4/12/23, debia...@howorth.org.uk <debia...@howorth.org.uk> wrote:
> I was playing with the addresses listed by Albretch ...

On 4/12/23, David Wright <deb...@lionunicorn.co.uk> wrote:
> After googling them, I gave Moxee a call. They answer to a subtly
> different name, but it's the same business: a Canadian/US company
> that's been family-owned through three generations. Their website
> is now hosted by godaddy, so I guess they just hang on to those old
> addresses. I don't know why they have their Moxee plant's street
> address on it. (Their godaddy registration is buttoned up in the
> modern manner.)

Once again, "social" issues remind me of my dear grandpa Hegel ;-).
There must be idiotic people like me for "smart" people out there to
"be themselves".

The issue at hand was the traceroute exaggerated "* * *" output, no?
BTW, I made sure to put a "'little' tin hat" on my post and phrased it
knowing well "it would be archived", but, in case you want to believe
me, those actions weren't directed at you.

Here are my candidate elucidations (and from the little corner from
which I see reality Occam's Razor doesn't really apply); either the
"international community" (tm) doesn't like that niggah me has to
download vast amounts of data items (it is almost exclusively text
anyway, so I don't know what the big deal is and I have noticed people
on the same network (using windows terminals) with more than one
browser window open watching high def videos) so, it might be my usage
patterns which is flagged as "dangerous" dude misbehaving.

There is also some idiotic perp invariably dressed on a pink shirt
that USG is paying to occupy a relatively retired seat where I used to
sit my days. Unfortunately, I couldn't take a picture of him for you
to "analyze it" ...

lbrtchx

[Lee]

On 4/12/23, Albretch Mueller <lbr...@gmail.com> wrote:
> I have found a few examples and "explanations" but in the cases of
> the examples I have seen by other people, like:
>
> https://serverfault.com/questions/733005/what-does-having-mean-in-the-command-traceroute-and-how-can-you-cope-wit
>
> It is not with every site and it is mostly with one hop. I my case it
> is with all sites and once the packets reach the web (from hop 5 to
> 30), from wherever I connect to the Internet. Why would that happen

you should probably start off with
https://archive.nanog.org/sites/default/files/10_Roisman_Traceroute.pdf
A Practical Guide to (Correctly)
Troubleshooting with Traceroute

> and why would that -consistently- "happen" to me?

Ask your ISP - or VPN provider or whatever it is that you're using..
I did a search on your _gateway (199.83.128.1) address and found
https://www.sitelock.com/blog/sitelock-trueshield-web-application-firewall-updates/
SiteLock TrueShield Complete IP Range in long form:
199.83.128.1-199.83.135.254

Maybe they can explain what's going on?

Interestingly enough, I tried a traceroute to the last ip address that
answered in your traceroute and got an answer from
1. my router
2. my ISP's router
and nothing else !??

It seems that Verizon doesn't have a route to 199.83.128.1 --
https://www.verizon.com/business/why-verizon/looking-glass/
doesn't show anything for 199.83.128.1, so I'm guessing verizon is
doing some form of Unicase Reverse Path Filtering (URPF) and dropping
all those packets that don't have a route to the destination

I also tried a traceroute to your _gateway (199.83.128.1) and got
$ traceroute 199.83.128.1
traceroute to 199.83.128.1 (199.83.128.1), 30 hops max, 60 byte packets
<.. snip ..>
4 0.ae5.BR2.IAD8.ALTER.NET (140.222.6.175) 12.963 ms
0.ae1.BR2.IAD8.ALTER.NET (140.222.239.85) 9.400 ms
0.ae5.BR2.IAD8.ALTER.NET (140.222.6.175) 12.919 ms
5 ash-b2-link.ip.twelve99.net (80.239.135.178) 9.211 ms 9.334 ms 9.424 ms
6 imperva-svc087369-lag004786.ip.twelve99-cust.net (62.115.55.139)
9.612 ms 7.612 ms 7.445 ms
7 * * *
8 * * *
9 * * *
10 * * *
... etc

And finally
https://bgp.tools/prefix/199.83.128.0/24#connectivity

Anycast Detected

When bgp.tools scanned this prefix, we found that 199.83.128.0 was anycasted.

Upstreams This info take up to 6 hours to fully update
ASN Description
AS2914 NTT America, Inc.
AS1299 Arelion (fka. Telia Carrier)

So it seems you're doing something ... different.

Regards,
Lee

[Albretch Mueller]

On 4/13/23, Lee <ler...@gmail.com> wrote:
> you should probably start off with
> https://archive.nanog.org/sites/default/files/10_Roisman_Traceroute.pdf
> A Practical Guide to (Correctly)
> Troubleshooting with Traceroute

thank you, lbrtchx