Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Tracking down Internet problems

0 views
Skip to first unread message

Roedy Green

unread,
Aug 26, 2009, 9:46:18 PM8/26/09
to
Sometimes a site is up for some users but not for others. Let us say
as webmaster you get such a report. There should be some way of
finding out quickly where you can and cannot access the site, then
hand that to your AIP for resolution.

Has anyone ever heard of such a tool?

Does someone routinely check the Internet to prove the consistency of
the routing tables to make sure everyone is accessible from everyone
else?


--
Roedy Green Canadian Mind Products
http://mindprod.com

"There is an evil which ought to be guarded against, in the indefinite accumulation of property,
from the capacity of holding it in perpetuity by... corporations.
The power of all corporations aught to be limited in this respect.
The growing wealth acquired by them never fails to be a source of abuses."
~ James Madison (born: 1751-03-16 died: 1836-06-28 at age: 85)

David Lamb

unread,
Aug 27, 2009, 1:15:53 PM8/27/09
to
Roedy Green wrote:
> Does someone routinely check the Internet to prove the consistency of
> the routing tables to make sure everyone is accessible from everyone
> else?

I'm not sure that's even possible.

Roedy Green

unread,
Aug 27, 2009, 7:33:24 PM8/27/09
to
On Thu, 27 Aug 2009 13:15:53 -0400, David Lamb <dal...@cs.queensu.ca>
wrote, quoted or indirectly quoted someone who said :

It would require co-operating nodes. I thought it might even be a tool
for maintenance people who work for an Internet provider.

Wojtek

unread,
Aug 31, 2009, 12:16:38 PM8/31/09
to
Roedy Green wrote :

> Sometimes a site is up for some users but not for others. Let us say
> as webmaster you get such a report. There should be some way of
> finding out quickly where you can and cannot access the site, then
> hand that to your AIP for resolution.

Wow.

You would need a client at each "access" point which regularily sends
out a ping (and to really prove it, you would need to use the same
ports), and if the ping gets lost, the client would need to report
this, but NOT to the same place that lost the ping. This would take a
lot of cooperation between ISPs, and moreover would create a huge
amount of heartbeat traffic.

And a loss of access means that something is REALLY bad as the
architecture is supposed to route around an injury. And a loss like
that would quickly be reported up and down the line.

Though in the real world, loss of DNS creates a critical problem, and
most people rely on the typical two servers at the ISP.

--
Wojtek :-)


Roedy Green

unread,
Sep 1, 2009, 11:11:32 PM9/1/09
to
On Mon, 31 Aug 2009 09:16:38 -0700, Wojtek <now...@a.com> wrote,

quoted or indirectly quoted someone who said :

>


>And a loss of access means that something is REALLY bad as the
>architecture is supposed to route around an injury. And a loss like
>that would quickly be reported up and down the line.

An outage is easily detected. A wrong entry in a routing table is not.


--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, it�s an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.

Wojtek

unread,
Sep 2, 2009, 11:37:04 AM9/2/09
to
Roedy Green wrote :

> On Mon, 31 Aug 2009 09:16:38 -0700, Wojtek <now...@a.com> wrote,
> quoted or indirectly quoted someone who said :
>
>>
>> And a loss of access means that something is REALLY bad as the
>> architecture is supposed to route around an injury. And a loss like
>> that would quickly be reported up and down the line.
>
> An outage is easily detected. A wrong entry in a routing table is not.

Hmmm, then you would need the "ping" to also gather route information
(tracert). The return could be stored in a linked list. Then if a ping
tracert goes missing, you could compare whatever results you got back
to the saved results. That should give you the point of failure.

Do this several times, with the packet being routed differently each
time, and you could build up a picture of where the fault lies.

Over time, take all of this info and plot it to get a nice picture of
what is connected to what.

The tracert to you:

1 <1 ms <1 ms <1 ms 192.168.1.3
--snip--
4 1 ms 1 ms 1 ms 64.114.203.185
5 2 ms 1 ms 1 ms zz20920590081.cipherkey.net
[209.205.90.81]
6 1 ms 1 ms 1 ms xx6651142139.cipherkey.com
[66.51.143.139]
7 6 ms 5 ms 6 ms pix-gw.data-fortress.com
[206.223.127.5]
8 8 ms 7 ms 7 ms a.cust.65-110-0-2.van.data-fortress.com
[65.110.0.2]
9 9 ms 12 ms 102 ms 65.110.21.43

I ran this several times and that seems to be the only path taken. Just
the return times changed. Seems to be a pretty direct path, but then we
are both in Canada, just the Rocky Mountians to go over :-)

Here is a link to a site which has these types of tools:
http://www.archive.org/search.php?query=subject%3A%22TRACE%20ROUTE%22

I Googled javascript traceroute, and it was one of the hits. From a
quick look, you could embed some Javascript in your pages, which would
then return to you the route from the client to your site (some AJAX
code). There should not be any privacy concerns as you already get the
client's IP, this would just get all the hops between.

So if a given client phones up and complains he cannot get to your
site, a quick loopup of his/hers IP would give you the "normal" routing
path. After a couple of calls you should have a failry good idea which
router is lying.

PATENT PATENT!!, aw heck, too late now :-))

--
Wojtek :-)


0 new messages