It's a sign.
It means: go for a stroll in the park. Stay away from your office,
phone, computer, Usenet for one entire day.
:-)

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vo. O resto imperfeito.
- Renato Russo -

yes - it it's a sign of impending collapse :(

Just found out Pipex customers also piggyback onto the Telewest network.

eek!

Anyway - phone gone quiet now. A quick check reveals that the offending
router is no longer in the loop (so to speak).

--
William Tasso

Short of it being resolved (no pun intended!), I wonder why I don't get
into that loop when I access from here.

traceroute to 62.31.32.194 (62.31.32.194), 30 hops max, 38 byte packets
1 * * *
2 207.217.56.1 161.488 ms 98.954 ms 99.399 ms
3 209.165.111.65 99.985 ms 99.942 ms 99.903 ms
4 209.165.101.17 100.438 ms 100.981 ms 98.876 ms
5 209.86.83.62 99.948 ms 99.880 ms 99.820 ms
6 209.165.110.65 161.454 ms 159.405 ms 160.032 ms
7 209.165.110.78 210.056 ms 268.553 ms 329.945 ms
8 206.223.115.131 251.279 ms 248.935 ms 251.126 ms
9 194.117.136.125 269.294 ms 268.951 ms 270.080 ms
10 62.30.244.5 250.034 ms 252.157 ms 247.896 ms
11 62.31.32.194 249.801 ms * 252.370 ms

[root@thurston tmp]# traceroute 62.31.32.40 -n
traceroute to 62.31.32.40 (62.31.32.40), 30 hops max, 38 byte packets
1 * * *
2 207.217.56.1 100.363 ms 99.643 ms 99.944 ms
3 209.165.111.1 99.879 ms 100.517 ms 99.865 ms
4 209.165.101.1 99.902 ms 99.618 ms 100.027 ms
5 209.86.83.62 99.779 ms 99.996 ms 99.814 ms
6 209.165.110.65 160.055 ms 160.381 ms 159.777 ms
7 209.165.110.78 171.591 ms 168.635 ms 169.176 ms
8 206.223.115.131 250.533 ms 271.364 ms 248.457 ms
9 194.117.136.125 269.674 ms 259.655 ms 260.016 ms
10 * * 62.30.244.5 251.691 ms

--
Blinky Linux Registered User 297263
Killing all Usenet posts from Google Groups
Info: http://blinkynet.net/comp/uip5.html
*ALSO contains links for access to the NON-BETA GG archive interface*

Ignore my traceroute paste. :)

--
Blinky Linux Registered User 297263
Killing all Usenet posts from Google Groups
Info: http://blinkynet.net/comp/uip5.html
*ALSO contains links for access to the NON-BETA GG archive interface*

probably because routes /to/ those boxes are working fine.

It was not even the entire network - just links through to one datacentre
- of course, I can't tell from here what else was affected. Only takes
one misplaced cable or routing entry to spoil the day for a shed-load of
people.

--
William Tasso

Educate me a bit, if you have a moment: assuming for the sake of
discussion that the same situation still ongoing that you found,
why once I got to that loop from anywhere would I not have been in
it as you were? Thanks.

I read that; I'm still unclear.

--
Blinky Linux Registered User 297263
Killing all Usenet posts from Google Groups
Info: http://blinkynet.net/comp/uip5.html
*ALSO contains links for access to the NON-BETA GG archive interface*

ok - there are several networks involved here.

1 - My local network
2 - ISP
3 - Intermediate backbone networks
4 - Target network

I know it's not a problem with #1 and #4 because I'm in a position to
independently verify that both are otherwise behaving.

All networks have (or should have) a default route (or gateway) which
enables access to other networks.

In this case it would appear that those two routers were configured to
find non-loacal (to them) addresses by routing traffic through each other
- if that makes any sense at all. Of course, it could be that no traffic
should have been routed to either of these two in the first place which
would indicate that the problem lies in a third router.

There's more to it than this simple explanation. Backbone networks make
use of something called least-cost-routing which enables network
administrators to specify preferential routes for one particular segment
of non-local addresses. For example, there's no point in traffic from
central europe being routed via the far-east or the states to reach a
data-centre in London - although I've seen that (and worse) happen. If
your ISP is a tier-1 provider then they will have many such routes
configured. Alternativly, the Internet is supposed to work like that.
Preferential routes are not supposed to be the 'only' route, although most
back-bone providers do like to keep your traffic on their own networks
because it keeps their costs down.

Your local LAN, if you have such a thing, can easily be configured with
fallback internet connections - there are several routers available for
SME market that have the ability to make an ISDN/Pots connection should
the b/band link go down.

Incoming redundancy is not so trivial - for those that are interested: I
suggest researching "BGP Routing"

Did that help?


--
William Tasso

I'm wiff you so far. :)

Still good...

It doesn't to me, if that config was intentional. If it wasn't, I'm
still on the case, here. :)

Okay.

I'm still okay with this.

Hokay.

Uh...well, no, despite the heroic effort, because while that all made
sense, I'm still not clear why that loop wouldn't work the same for
everyone, once it was entered. I really appreciate the work; I'm just
not net savvy enough to get it. Sorry -- it's certainly not for lack of
effort on your part. It's just that my simplistic image of the two
machines playing data tennis, back and forth, just doesn't allow for the
significance of who tossed them the data ball to get it started. I'll
just fall back on "I got there after the problem was resolved", and stop
scratching my head. :) Thank you again, though.

--
Blinky Linux Registered User 297263
Killing all Usenet posts from Google Groups
Info: http://blinkynet.net/comp/uip5.html
*ALSO contains links for access to the NON-BETA GG archive interface*

Recently, for a few months, I had sporadic trouble reaching my website
or email for hours at a time because of a server problem 300 miles
from here. Googling showed that plenty of other people were having
that problem, but things were not being rerouted nor was the server
being fixed. It was a pain in the neck, because although I could
reach my site via one of the anonymizer sites, I couldn't reach my
email.

Yes, the problems were far reaching and, because the problem was being
caused by people who none of the affected had accounts with, we had no
leverage to try to get the frigging company to fix its frigging
machine.

--

MGW

Well, apparently they don't, because one broken server in Maryland
wreaked havoc for weeks without the hops before them rerouting around
it.

In the case I experienced, the problem was several hops after the
route left my ISP's network.

So, at least in the case I and many others experienced, the problem
was not with "monopolies" - it was with lack of alternative routing
and lack of caring about a problem that affected other people's
customers.

--

MGW

Well let's be clear about this. The connection between your ISP and your
web host uses a third party backbone to make the connection? In that case
you do have leverage - you tell your ISP to buy bandwidth from a different
supplier or lose your account. An ISP probably won't listen to a lone
voice, but if enough of you complain they will jump on their supplier to
fix it.

--
William Tasso

I use cable - although I'm lucky enough to live somewhere that has a
choice between two companies (most places have only one), switching to
the other would be jumping from the frying pan into the fire, as far
as I'm concerned.

--

MGW

But, but, but....It's a "no single point of failure network"
established by the US military...Oh hang on, silly me! The clues are
there!

Matt

--
The Probert Encyclopaedia
Free, extensive, searchable and illustrated
http://www.probertencyclopaedia.com