Intermittent Connection Issues

Hello!

It might be interesting run a program call "tracert" or "traceroute" to the sites that are not reachable at the same time that other sites are.

tracert foxnews.com

or

traceroute foxnews.com

The output might indicate where the path to the inaccessable site is failing.

Take care!

John

It souds like your using the address translator in the cable modem.  Your symptoms are classic NAT over loading.  What happens is every time you connect to a site you chew up a small amount of ram in the modem for a translation entry.  Since the modem has limited memory it can only support a couple hundred translation entries.  Normally the garbage colleciton and translation entry expiration in the router will clear the old entries and keep the memory in the translator from being overloaded.

But if you run bittorrent, or you have a machine behind it that's compromised with a virus, you can rapidly create so many translation entries in the router that it start dropping active entries, which you will experience as the symptoms you related.

if you regularly run bittorrent get a static IP on the account and run a real router behind the cable modem.

I just acquired some info on one of these connection issues.  I used traceroute -n to obtain the following traces to well-known public sites that probably weren't down at the time:

vanadium:~ dhm$ traceroute -n woot.com
traceroute: Warning: woot.com has multiple addresses; using 75.101.146.4
traceroute to woot.com (75.101.146.4), 64 hops max, 52 byte packets
 1  172.23.32.254  4.351 ms  1.303 ms  1.317 ms
 2  10.2.10.254  2.235 ms  5.983 ms  2.493 ms
 3  73.90.88.1  11.665 ms  18.051 ms  14.606 ms
 4  68.85.149.49  12.586 ms  11.696 ms  11.682 ms
 5  68.85.243.162  12.591 ms
    68.85.243.157  12.868 ms
    68.85.243.162  11.590 ms
 6  68.87.218.158  12.633 ms
    68.85.243.165  12.381 ms
    68.87.218.162  24.477 ms
 7  68.86.95.97  16.987 ms  19.782 ms
    68.86.90.213  15.972 ms
 8  68.86.84.78  16.138 ms  17.394 ms  15.776 ms
 9  67.135.42.153  29.135 ms  15.497 ms  15.928 ms
10  *^C

vanadium:~ dhm$ traceroute -n businesshelp.comcast.com
traceroute to smb.g.comcast.com (69.252.205.55), 64 hops max, 52 byte packets
 1  172.23.32.254  1.571 ms  1.323 ms  1.618 ms
 2  10.2.10.254  1.900 ms  1.836 ms  1.997 ms
 3  73.90.88.1  16.226 ms  12.663 ms  17.944 ms
 4  68.85.149.57  13.674 ms  18.283 ms  12.161 ms
 5  68.85.243.165  12.657 ms  36.815 ms  15.316 ms
 6  68.86.95.97  20.862 ms
    68.86.95.89  20.805 ms
    68.86.95.17  16.953 ms
 7  68.86.88.69  45.065 ms  45.851 ms  43.354 ms
 8  68.86.85.245  65.899 ms  64.596 ms  64.444 ms
 9  68.86.94.182  65.593 ms  65.917 ms  65.256 ms
10  69.139.179.150  64.233 ms  66.127 ms  67.106 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * *^C

It looks like routing loops and/or confusion within Comcast's network (which is what I suspected anyway). It was like this for 5-10 minutes just now, but seems to be resolved.

It would be wonderful if the Comcast backbone would settle enough that we don't have problems like this -- it's really frustrating, and Customer Service can't do anything about it by telling people to reboot their routers.

Neither of those traces shows a routing loop.  And businesshelp.comcast.com is behind a firewall that blocks traceroute, your trace terminates at 69.139.179.150, which is the same place mine terminates at, and I am not seeing this problem.

---

@tmittelstaedt wrote:

Neither of those traces shows a routing loop.

OK, I'll give you that. But it doesn't change the underlying problem, which is that I (and apparently others) are seeing intermittent issues reaching some (but not all) other sites. In other words, I'll be surfing away, and some page-retrieval will hang. Other browser tabs will continue to work (i.e., I can load new pages into them), so the problem must be upstream of my local modem. (I know how to distinguish DNS hangs from TCP/IP problems, and these seem to be TCP/IP problems.)

Since it's intermittent, I know it's tempting for sysadmins to blow it off because it'll probably fix itself somehow pretty soon. But it happens often enough to seriously impact my work; I wish somebody would take the time to figure out what's going on and repair it.

Hello!

Is it possible to run the tracert to the same targets when they _are_ accessible? You could compare the results to the "failed" output and see where they diverge. Letting traceroute resolve the IPs to hostnames (drop -n) could also be helpful.

Take care!

John