Frustrated that I don't UNDERSTAND why my network times out - Page 2

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View
Re: Frustrated that I don't UNDERSTAND why my network times out
Quoted text here. Click to load it

Which was why I suggested  
telnet centos.org 80
but that did not return anything for him. Everyone else in the world has
no trouble connecting but he does and he wants to know why.

Quoted text here. Click to load it

Re: Frustrated that I don't UNDERSTAND why my network times out
unruh wrote:

Quoted text here. Click to load it

That's a perfect summary!
I can't imagine that I'm singled out in this world for not
connecting, for months at a time, to centos.org (it happened
with one other web site - but it was so long ago that I've
forgotten which it was).

One question I have is WHICH site is dropping my packets?

Is it the last site that returns traceroute values?
Os is it the first site that has all asterisks?

# traceroute -M icmp www.centos.org
traceroute to www.centos.org (72.232.194.162), 30 hops max, 60 byte  
packets
 1  192.168.1.1 (192.168.1.1)  2.840 ms  2.832 ms  2.829 ms
 2  MYIPADDRESS (xxx.xxx.xxx.xxx)  2.827 ms  5.830 ms  5.834 ms
 3  10.50.0.1 (10.50.0.1)  9.369 ms  14.568 ms  14.566 ms
 4  10.25.0.1 (10.25.0.1)  14.562 ms  18.614 ms  18.610 ms
 5  10.20.0.1 (10.20.0.1)  79.603 ms  83.180 ms  83.177 ms
 6  10.0.0.1 (10.0.0.1)  454.682 ms  251.479 ms  251.450 ms
 7  69.36.226.193 (69.36.226.193)  251.420 ms  402.683 ms  402.652 ms
 8  vl2.core1.scl.layer42.net (69.36.225.129)  402.624 ms  397.148 ms  
397.127 ms
 9  216.156.84.141.ptr.us.xo.net (216.156.84.141)  397.107 ms  284.336  
ms  284.314 ms
10  207.88.14.233.ptr.us.xo.net (207.88.14.233)  287.164 ms  153.090 ms  
162.910 ms
11  vb15.rar3.dallas-tx.us.xo.net (207.88.12.45)  162.878 ms  156.560  
ms  156.544 ms
12  207.88.14.34.ptr.us.xo.net (207.88.14.34)  156.516 ms  2751.856 ms  
2751.839 ms
13  207.88.185.74.ptr.us.xo.net (207.88.185.74)  2586.242 ms  97.179 ms  
97.152 ms
14  border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19)  97.123 ms  
border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81)  74.418 ms  
border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19)  87.348 ms
15  layered-11.border1.dal004.pnap.net (63.251.44.74)  87.329 ms  
65.781 ms  120.012 ms
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
#

Is it hop 15 or 16 above which is dropping my packets?





Re: Frustrated that I don't UNDERSTAND why my network times out
Mike Easter wrote:

Quoted text here. Click to load it

I'm beginning to wonder if anything after about 15 hops is  
dropping the connection for me?

Could it be that the path to centos.org just happens to be  
longer than any other path I've tried?

The path to the centos bug server you gave me worked fine, but
it only took 15 hops.

Do you have a way for me to pick somewhere far far away from  
San Francisco CA to see if it's simply the long path that is  
causing the problem (i.e., more than 16 hops)?


Re: Frustrated that I don't UNDERSTAND why my network times out
Chris Davies wrote:

Quoted text here. Click to load it

Hi Chris,
I posted my "traceroute -M centos.org" results
because I truly want to UNDERSTAND what is going
on.

If the problem is that my packets are too large,  
how does one control that in a web browser?

The ping is merely my diagnostic tool.  

The *real* problem is that, for months at a time, I
can't connect (via any web browser not on TOR) to:  
 http://centos.org

With TOR, I can connect easily - so it's not the  
Centos site itself.

QUESTION: How do I control packet size in Firefox?



Re: Frustrated that I don't UNDERSTAND why my network times out
Chris Davies wrote:

Quoted text here. Click to load it

Hi Chris,

I appreciate your help as I'm trying to UNDERSTAND the problem,  
which is that, for months on end, I can't connect via the web
to http://centos.org where a traceroute shows that the penultimate  
connection is dropping me. (So I am forced to use TOR and all
works fine - albeit slowly.)

Then, for months at a time, I *can* connect to centos.org,  
where the traceroute shows the connection going through.

Googling for what an MTU is, I see it's the max size of a packet:
 http://en.wikipedia.org/wiki/Maximum_transmission_unit

Ethernet has an MTU limit, it appears, of 1500 bytes, so I can  
see why you're suggesting 1400 bytes.

I don't have much ethernet in the picture though, as I'm on
a laptop connected by WiFi to my home broadband router which  
itself is wired by POE to a rooftop antenna which goes over
WiFi about five miles to the WISP antenna where I lose control.

So, I assume you would want me to modify that command:
 ifconfig eth0 mtu 1400
To:
 "ifconfig wlan0 mtu 1400

Here's what ifconfig just reported:
# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:a0:00:3a:4f:23  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000  
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:11 Memory:f2600000-f2620000  

wlan0     Link encap:Ethernet  HWaddr 00:a0:00:6a:9b:3d  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:267437 errors:0 dropped:0 overruns:0 frame:0
          TX packets:167343 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000  
          RX bytes:311152648 (296.7 MiB)  TX bytes:29413063 (28.0 MiB)

So I ran the following:
# ifconfig wlan0 mtu 1400
# ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 00:a0:00:6a:9b:3d  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1400  Metric:1
          RX packets:267437 errors:0 dropped:0 overruns:0 frame:0
          TX packets:167343 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000  
          RX bytes:311152648 (296.7 MiB)  TX bytes:29413063 (28.0 MiB)

And, then I tried to connect via Firefox to centos.org, but it still
timed out.

Should I change the mtu even further down, say, to 1000 so that
Firefox can connect to http://www.centos.org?

Re: Frustrated that I don't UNDERSTAND why my network times out
Your basic problem in this entire discussion
is that you have no concept of the very basics in networking -
called - a protocol stack -

Here is the TCP/IP version -

Application (like email, browser, etc)
Transport (specify ports on computers)
Internet (addressing & routing)
Link (physical)

The browser lives at the very top - as an Application
and has NO knowledge of ANY protocol issues at the lower layers.
So, to keep asking about how the fix the browser is meaningless.

The lower layers are where TCP (Transport Control Protocol)
and the IP (Internet Protocol) address live.

Next - is the physical and link....   this is the magic of "transmit" and  
"receive" -

SO - some routers and website might turn of their responses to ICMP messages  
(ping/echo etc)
and it might appear they are not responding to those tools - but in fact -  
they are "ignoring" them.

On the topic of MTU (the size of the packets transmitted)
I have never had a website not respond,
but have had probs with a school system called Blackboard
that would not function properly on a DSL line
due to a MTU being less than the Blackboard required value of 1500.

WEIRD -
I can ping and traceroute to -->  centos.org
but it does NOT reply to my browser request ??

This page cannot be displayed due to an internal error.

If you are the administrator of this site, please visit the Xoops  
Troubleshooting Page for assistance.

Error [Xoops]: Unable to connect to database in file  
class/database/databasefactory.php line 34




Re: Frustrated that I don't UNDERSTAND why my network times out
Quoted text here. Click to load it

He may not have, but it is irrelevant. He is not able to connect. Can
you give him the cause? Can you suggest how he fix it? It is like if you
brought me your car to fix and I told you that you had no concept of the
basics of the Standard Model of particle phyics as if such knowledge
would help you fix your car.  

Quoted text here. Click to load it

And you now call this weird. I thought you had an intimate knowledge of
the protocol layers. Why is this weird?

Note that I have absolutely no trouble connecting to centos.org.

Quoted text here. Click to load it

Re: Frustrated that I don't UNDERSTAND why my network times out
this is an interesting discussion -
you mean like -
please fix my car - the lugnuts don't fit into the key slot - so I can't  
start it -
"different layers" - but guess I'll just keep throwing tech words around...

weird - yup -
it times out from my network - and other "online testing sites" -
so... ????

Ping -          centos.org - 85.12.30.227       --> Amsterdam
Ping - www.centos.org - 72.232.194.162 ---> ????

So, where does the - 72.232.194.162 come from ??
vs my DNS lookup is showing 85.12.30.227   ??

  2  NS1.LAYEREDTECH.COM  72.232.1.236
AUTH  0 ms  Received 1 Answers , rcode=
PTR: PointerName=www.centos.org,

cname:www.centos.org
Lookup failed after 1 name server timed out or responded non-authoritatively

-----------
Here's his traceroute run:
knoppix@Microknoppix:~$ traceroute www.centos.org
traceroute to www.centos.org (72.232.194.162), 30 hops max, 60 byte

----------
      HopCount IP Address HostName
      1 208.123.79.34 net208-123-79-34.static-customer.corenap.com
      2 198.252.182.180 aus-core-10-v12.corenap.com
      3 24.155.184.106 xe-0-0-2-509.AUSTTXMIM002.aggr09.austtx.grandecom.net
      4 24.155.121.76 xe-0-0-0-0.aggr08.austtx.grandecom.net
      5 4.30.74.53 ae5-868.edge9.Dallas1.Level3.net
      6 4.69.145.200 ae-4-90.edge3.Dallas1.Level3.net
      7 4.71.170.6 LAYERED-TEC.edge3.Dallas1.Level3.net
      8 * * * * * *
      9 72.232.194.162 www.centos.org


---------

their TCP/IP world seems messed up somewhere within their DNS records -



  



Re: Frustrated that I don't UNDERSTAND why my network times out
Quoted text here. Click to load it

I have.

Chris

Re: Frustrated that I don't UNDERSTAND why my network times out
Chris Davies wrote:

Quoted text here. Click to load it

Bearing in mind, the problem is that I'm trying to understand  
*why* my web traffic is not connecting to centos.org, I'll try
any suggested diagnostic procedure using whatever tools I have
at hand.

I set my packet size on my laptop to a low value:
# ifconfig wlan0 mtu 500

And, then ran the traceroute:
# traceroute -M icmp centos.org
traceroute to centos.org (72.232.194.162), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  5.042 ms  5.029 ms  5.017 ms
 2  WISP_IP_REDACTED (xxx.xxx.xxx.xxx)  5.022 ms  8.227 ms  8.227 ms
 3  10.50.0.1 (10.50.0.1)  13.820 ms  23.623 ms  25.771 ms
 4  10.25.0.1 (10.25.0.1)  25.767 ms  30.879 ms  30.877 ms
 5  10.20.0.1 (10.20.0.1)  44.616 ms  46.995 ms  46.992 ms
 6  10.0.0.1 (10.0.0.1)  52.204 ms  27.862 ms  31.134 ms
 7  69.36.226.193 (69.36.226.193)  35.862 ms  50.007 ms  49.971 ms
 8  vl2.core1.scl.layer42.net (69.36.225.129)  49.951 ms  74.962 ms  77.875 ms
 9  216.156.84.141.ptr.us.xo.net (216.156.84.141)  77.857 ms  25.678 ms  25.643 ms
10  207.88.14.233.ptr.us.xo.net (207.88.14.233)  71.468 ms  91.228 ms  95.624 ms
11  vb15.rar3.dallas-tx.us.xo.net (207.88.12.45)  155.916 ms  85.719 ms  101.926 ms
12  207.88.14.34.ptr.us.xo.net (207.88.14.34)  95.461 ms  97.164 ms  103.047 ms
13  207.88.185.74.ptr.us.xo.net (207.88.185.74)  103.028 ms  63.041 ms  107.573 ms
14  border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81)  107.556 ms  70.772 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19)  70.744  
ms
15  layered-11.border1.dal004.pnap.net (63.251.44.74)  70.725 ms  89.757 ms  89.726 ms
16  * * *  <=== from experience, I know this is centos.org
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

BTW, I know that, in the case above, hop 16 is centos.org because I've asked  
neighbors in the past (who are on the same WISP) to run a traceroute, and,  
every few months, I can connect - so I can see it on my own laptop.


Re: Frustrated that I don't UNDERSTAND why my network times out
On 9.10.13 2:18 , billy wrote:
Quoted text here. Click to load it

Get a goot text on TCP/IP protocols and learn how TCP does it.
There is an ICMP message 'fragmentation needed but DF bit is on'.
The segment auto-sizing is an essential part of TCP.

If a sysadmin has killed the whole ICMP somewhere in the path,
there is little you can do, except whine to him.

Traceroute is not of much help here.

--  

Tauno Voipio


Re: Frustrated that I don't UNDERSTAND why my network times out
On Wed, 09 Oct 2013 15:16:33 +0300, Tauno Voipio wrote:

Quoted text here. Click to load it

Just so I understand, are you saying that the web
(i.e., http://centos.org ) is using ICMP?


Re: Frustrated that I don't UNDERSTAND why my network times out
Quoted text here. Click to load it

Yes and no.

The data for a website is carried over TCP. The control commands
(e.g. "slow down you're filling up the pipe", or "that packet's waayyy
too big; make it smaller") are sent over ICMP. Pings and some traceroute
programs also use ICMP, but they use a different ICMP message type.

A competently configured firewall might be set up to block ICMP ping
requests. But there's no way that same firewall should be completely
and naively blocking all ICMP packets.

Re: Frustrated that I don't UNDERSTAND why my network times out
On Wed, 09 Oct 2013 19:22:48 +0100, Chris Davies wrote:

Quoted text here. Click to load it

Thanks for that explanation.

What I gather is that the "problem" isn't how I'm running ping
or traceroute. The network problem is something more abstract.

Here's what I know:
- I seem to be the only one with this problem.
- It does NOT happen when I go to my neighbor's house using my PC.
- The problem comes and goes (and stays for months).
- Nothing gets past the hop before centos.org.
- I can't go around that penultimate router without using Tor.
- Since TOR works on all the PCs in the house, it's not the PCs.
and
- It's not how I'm running the web, traceroute, or ping.

Since the problem seems to be at the penultimate hop, is there
any way, other than TOR, to get around that hop (from my own
home network)?

Are there public proxies I can set up for Firefox?






Re: Frustrated that I don't UNDERSTAND why my network times out

The protocols layer and in some cases intertwine.  What you call "the
web" sits on top of a protocol called HTTP (HyperText Transfer
Protocol).  HTTP makes use of the services of TCP (Transmission
Control Protocol).  TCP makes use of IP (Internet Protocol).  IP will
make use of whatever link-layer protocol is available in its
sitaution.  For your end systems that will be "Ethernet" protocol over
your WiFi connection.

HTTP
TCP
IP
Ethernet/WiFi/whatnot

Within/alongside IP is ICMP (Internet Control Message Protocol).  ICMP
is used to provide some "Hey, you should know this" kinds of messages
back to traffic sources.

So, simplifying a bit, when you try to access www.centos.org from your
web browser, the browser will generate an HTTP message the browswer
wants to get to HTTP at www.centos.org.  That HTTP message will be
handed-off to TCP to transmit in one or more TCP segments to TCP at
www.centos.org (segment = what a packet is called in the context of
TCP).  The TCP segment(s) will be handed off to IP, which will
encapsulate them in one or more IP datagrams (datagram = what a packet
is called in the context of IP) destined to the IP address of
www.centos.org.  IP will then hand its datagrams to the "data link"
layer (eg Ethernet etc) which will do its encapsulation.  It will then
go across the data link destined for IP at the "next hop" where the
data-link layer message will decapsulate the IP datagram and hand it
to IP at that hop.  IP at that hop will then decide what to do with
the datagram, which is being sent to the/an IP address for
www.centos.org.  There will probably be another "next hop" and so on
until the traffic arrives at www.centos.org.  IP at www.centos.org
will then decapsulate the TCP segment from the IP datagram, and TCP
will decapsulate the HTTP message and hand it to the HTTP server.

The HTTP response will flow back to you via a similar mechanism.

Those different lines you see in the output of traceroute are the
"next hops" along the way from your system to www.centos.org.

Now, the data links at all those next hops may have different limits
for how large a packet they can transmit.  If an IP datagram arrives
at a "next hop" (aka an IP router), and IP there determines that where
it needs to be sent-out next is over a data link with a packet size
smaller than the IP datagram it needs to send, IP decides to send back
to the traffic's source an ICMP message saying "Hey, the datagram you
sent is too large for me to send, you should send smaller IP
datagrams" (There is more to it than this, but I'm simplifying).

There are other sorts of ICMP "Hey!" messages.  One of them is
"Maximum Hop Count Reached" - that is the ICMP message that (default)
traceroute relies upon receiving.  In the header of an IP datagram
there is a field called the "TTL" (Time To Live) which is really a
maximum hop count.  As the IP datagram passes through an IP router,
the router decrements the count by one, and when it hits zero, that IP
is supposed to send back an ICMP message that says "Hey! The datagram
you sent had its maximum hop count expire before it reached its
destination."  Traceroute works by sending an IP datagram over and
over again, with the TTL increased by one each time.

Ping sends a different sort of ICMP message, one that says "Please
tell me that you got this" - more formally known as an ICMP Echo
Request.  The destination IP will send an ICMP Echo Response back to
the originator when it receives one.

Now, all these things I've described rely on ICMP messages making it
back to the source of the IP/ICMP datagram triggering them.  But some
network administrators feel that allowing (certain) ICMP traffic to
pass represents a security vulnerablity, so they block ICMP traffic.

If ICMP traffic is blocked at a point part-way between you and
www.centos.org, you will see the traceroute "stop" (those '*' lines
starting indicating there was no response with the TTL set to that
many hops).  You will also not have ping "work" - it won't see any
ICMP Echo Reply messages.

If TCP tries to send a TCP segment that was carried in an IP datagram
which needed to be fragmented somewhere in the middle there, then when
it goes to send traffic it will appear to disappear - it hits an IP
router (next hop) that tried to send it but couldn't and the "Hey!"
message that IP router tried to send back was blocked.

Now, by default, ping and traceroute do not send very large IP
datagrams, so the chances of those packets arriving at a next hop
where fragmentation is needed is pretty small.

Also, not all TCP segments are the same size - the TCP segments used
to setup a TCP connection for example are pretty small.  That is what
was behind some of the "try telnet www.centos.org 80" suggestions -
that is an old school way to just try establishing a TCP connection
but not actually send any data on it.  Those TCP segments will be
small.

Why try that?  (Or for that matter the pings or traceroutes with
options set to send larger packets) Because it is how one tries to see
if 'the problem" centers on packets which are too large arriving at a
small data link somewhere, or simply a routing issue somewhere in the
middle of the Internet.  If the "telnet www.centos.org 80" establishes
the TCP connection, you can assume that it isn't a routing issue.  In
that case, a/the remedy is to ensure that TCP at your system and TCP
at the system(s) to which you are connecting never try to send TCP
segments which become IP datagrams which are too large to send without
fragmentation.  One can do that by shrinking the MTU of the network
interface of your system.  When TCP establishes a connection, part of
that is exchanging with the other side (eg www.centos.org) the Maximum
Segment Size (MSS) for the connection.  There are several inputs to
that exchange, one of which is the MTU of your local interface.  The
smallest MSS (your's or that of www.centos.org) is the one that will
be used for traffic in both directions.

Now, if the telnet www.centos.org 80 does not succeed, that means
there is some sort of routing issue.  That was already partially
suggested by the ping and traceroute "failures" you've already
reported (if memory serves) but since the ICMP traffic on which they
rely can be blocked, their failure is not conclusive.

What sort of routing issue might it be?  Well, one could be that there
is a simply problem at or after one of those next hops you see in the
traceroute output.  That is why some have suggested you lookup the
information about who runs those and contact them.

It is possible that your source IP has been "black listed" for some
reason or other - either at/past the ISP responsible for the last
"next hop" you see in traceroute or perhaps even at www.centos.org.
Perhaps at one point the IP address you have from your ISP was
involved in something considered nefarious or anti-social.

That you could still get to www.centos.org using TOR would remain
consistent with your IP address (the one being assigned to your home
gateway by your ISP) being blacklisted because the entire point of TOR
(as I understand it) is to hid your actual IP address.  It does that
by adding some additional layers to the top of what I mentioned
above. (As I understand it, I don't actually have any practical
experience with TOR).

rick jones
--  
denial, anger, bargaining, depression, acceptance, rebirth...
                                     where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com  but NOT BOTH...

Re: Frustrated that I don't UNDERSTAND why my network times out
Quoted text here. Click to load it

Well, no. He tried
telnet centos.org 80
which generates no HTTP message. Just a bare connection request.  
It fails.


Quoted text here. Click to load it

He sent really small packets.  
ping is I believe 80 bytes.
And they are not rejecting ping packets (I just checked.)


Quoted text here. Click to load it

Except they do not. They come back to me with no trouble. They come back
to his neighbour with no trouble.  

Quoted text here. Click to load it

Yup, but why only to him?


Quoted text here. Click to load it

And they failed as well, so I think we can eliminate packet size as an
issue.  


Quoted text here. Click to load it

So, why does the route up to the last hop work, but not that last hop?
And why does it work for everyone else. It is really really hard to see
it as a routing issue.  



Quoted text here. Click to load it

Yes, I does look like a firewall issue, but he claims that centos claims
that there is no such issue.


Quoted text here. Click to load it

Re: Frustrated that I don't UNDERSTAND why my network times out
unruh wrote:

Quoted text here. Click to load it
hop?
Quoted text here. Click to load it
see

Everything you said is right on the money.
It's frustratingly hard to figure out.

The only two ideas "I" can come up with are:
1. Someone is blocking me (but I can't imagine why)
2. The path is too long for something (but I don't know what).

In the first case, I'm not sure if the blocker would be the  
15th hop (which returns packets) not forwarding them on to  
the Centos server or if it's the 16th hop (the Centos server)
not responding back. Is there a way to tell?

In the second case, it would be useful to test a similarly  
long (at least 16 hops) path. Or, maybe there's a way to slow
down my pings so that I can reproduce the problem in fewer hops?


Re: Frustrated that I don't UNDERSTAND why my network times out
unruh wrote:

Quoted text here. Click to load it

I understand and agree with your use of "claims", as you
don't know what I've been told.

I can google for the public thread where I asked them  
(and they responded in email privately also) and point
you to that. It was about six months to a year ago.

Gimme a minute to find it (Google will find it but I won't
be able to open it up - but you should be able to).

OK. Found it with Google on CentOS.org
Title: What can I do to UNDERSTAND why www.centos.org fails for me
Date: MaMar 1, 2013 - 12 posts - ?4 authors

Of course, I can't "go" to that URL (since it's on CentOS.org)  
but it looks like it's mirrored here:
 linuxreference.com/modules/newbb/viewtopic.php?topic_id=41677&forum=55

Hey! Guess what? I can't get to "linuxreference.com" either!
Just like centos.org, it goes to asterisks on the 16th hop!

I'm getting tired of redacting my IP address, so I'm letting it
show here. I hope I don't regret that! :)

# traceroute -M icmp linuxreference.com
traceroute to linuxreference.com (72.232.194.162), 30 hops max, 60 byte  
packets
 1  192.168.1.1 (192.168.1.1)  2.851 ms  2.836 ms  2.839 ms
 2  67-218-118-85.ridgewireless.net (67.218.118.85)  5.849 ms  5.849 ms  
5.846 ms
 3  10.50.0.1 (10.50.0.1)  5.845 ms  19.117 ms  19.115 ms
 4  10.25.0.1 (10.25.0.1)  19.111 ms  19.108 ms  26.045 ms
 5  10.20.0.1 (10.20.0.1)  58.291 ms  60.735 ms  60.733 ms
 6  10.0.0.1 (10.0.0.1)  70.816 ms  10.336 ms  15.323 ms
 7  69.36.226.193 (69.36.226.193)  15.291 ms  77.227 ms  140.765 ms
 8  vl2.core1.scl.layer42.net (69.36.225.129)  148.204 ms  32.072 ms  
32.025 ms
 9  216.156.84.141.ptr.us.xo.net (216.156.84.141)  35.854 ms  82.604 ms  
137.427 ms
10  207.88.14.233.ptr.us.xo.net (207.88.14.233)  137.395 ms  77.731 ms  
86.088 ms
11  vb15.rar3.dallas-tx.us.xo.net (207.88.12.45)  92.609 ms  105.335 ms  
105.305 ms
12  207.88.14.34.ptr.us.xo.net (207.88.14.34)  105.262 ms  130.219 ms  
145.768 ms
13  207.88.185.74.ptr.us.xo.net (207.88.185.74)  145.746 ms  66.089 ms  
83.514 ms
14  border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19)  83.485 ms  
border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81)  75.311 ms  75.275  
ms
15  layered-11.border1.dal004.pnap.net (63.251.44.74)  75.241 ms  
68.198 ms  85.547 ms
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *


Re: Frustrated that I don't UNDERSTAND why my network times out
unruh wrote:

Quoted text here. Click to load it

I can google just fine, so I found the original request way  
back in March on the Centos site (I subsequently got an email
from the admins saying there's nothing wrong with my IP address).

Here's what Google says the Centos article URL is:
https://www.centos.org/modules/newbb/print.php?form=1&topic_id=43977&forum=58&order=ASC&start=0

It's looking more and more like anything longer than about 15
hops is dying for me. At least that's a preliminary guess.

Notice I can get to this Centos mirror just fine:
 http://www.spinics.net/lists/centos/msg133862.html

When I traceroute to it, I see a MUCH SHORTER route!

# traceroute -M icmp www.spinics.net
traceroute to www.spinics.net (66.135.57.166), 30 hops max, 60 byte  
packets
 1  192.168.1.1 (192.168.1.1)  2.849 ms  2.835 ms  2.831 ms
 2  67-218-118-85.ridgewireless.net (67.218.118.85)  2.855 ms  5.644 ms  
5.642 ms
 3  10.50.0.1 (10.50.0.1)  10.434 ms  10.432 ms  10.428 ms
 4  10.25.0.1 (10.25.0.1)  11.707 ms  15.285 ms  15.284 ms
 5  10.20.0.1 (10.20.0.1)  15.280 ms  19.197 ms  19.193 ms
 6  10.0.0.1 (10.0.0.1)  66.277 ms  60.195 ms  113.259 ms
 7  69.36.226.193 (69.36.226.193)  103.422 ms  213.710 ms  235.362 ms
 8  vl2.core2.scl.layer42.net (69.36.225.130)  235.334 ms  251.949 ms  
251.924 ms
 9  xe3-4.core1.mpt.layer42.net (69.36.239.110)  255.382 ms  134.485 ms  
134.458 ms
10  peer1.com.any2ix.coresite.com (206.223.143.79)  149.430 ms *  
180.892 ms
11  10ge.xe-2-3-0.lax-600w-sbcor-2.peer1.net (216.187.124.121)  180.882  
ms  226.325 ms  226.300 ms
12  10ge-ten1-2.dal-eqx-cor-1.peer1.net (216.187.88.131)  240.823 ms  
156.853 ms *
13  * 10ge-xe-2-3-0.sat-8500v-sbcor-1.peer1.net (216.187.124.39)  
106.930 ms  106.903 ms
14  10ge.xe-0-0-1.sat-8500v-sbdis-1.peer1.net (216.187.124.66)  106.884  
ms  141.148 ms  190.401 ms
15  www.spinics.net (66.135.57.166)  131.264 ms  74.009 ms  83.791 ms



Re: Frustrated that I don't UNDERSTAND why my network times out
Quoted text here. Click to load it


I was, perhaps, being overly simplistic in my use of terms.  I was
lumping-in "classic" routing issues like loops and what not in with
things like deliberate blacklisting.

Quoted text here. Click to load it

Anywhere between that 15th hop in the traceroute and centos.org I
would think.

That it comes and goes for months at a time has me wondering about the
rate at which his ISP might be changing his assigned IP address (the
one his gateway gets), and whether or not the "blackouts" correlated
with that.  That would require having kept a log of the noticed start
and end of the blackouts and a log of the IP assigned by the ISP.

rick jones
--  
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Site Timeline