Re: Weird 'net connection problem

Tim Streater <timstreater@xxxxxxxxxxxx> wrote:

real-address-in-sig@xxxxxxxxxxxxxxx (Rowland McDonnell) wrote:

Tim Streater <timstreater@xxxxxxxxxxxx> wrote:

I believe that (could be wrong) if packets are
dropped because of congestion, that is done silently.

Okay - but the packet loss is detetected because the packets don't
arrive at their destination. So how is this an issue of any sort?

Only that timeouts are the only way the ends are going to detect this
and attempt retries, so it could take some time before transmission
continues as seen by the user.

That makes sense. Still, `some time' seems generally pretty quick here
from what I've seen of occasions on which the link from me to
destination is foobar in any normal way.

(my knowledge of the detail here is shaky).

Shaky beats my `not a clue'.

Yes, but you can have intermittent failures that cause "route flapping".
Lets say that you have your own /24 network (thats 256 addresses) that
you connect to some ISP via a router (not a home ADSL one, I should add,
but a small IP router from say Cisco costing a grand or so).

What difference does the `nature of the router' make?

An ADSL one won't have anything like the configuration ability required.

Ah.

But
these routing announcements take some while to reach everyone. This
means that the Internet's knowledge of itself is being constantly
updated (mostly automatically), but you can see that it can never have
complete and up to date knowledge of its actual state.

<puzzled> The internet knows nothing. It contains information, some of
it more accurate than others.

Sorry, my sloppy writing - I mean the set of routers that go to make up
the Internet.

Righto.

(More `the set of routers that make up the routing infrastructure of the
internet'. The rest of the internet is the data links between the
routers and the various computers which use the router/data link
infrastructure to communicate. The internet is not merely the routers -
if that's all there was, there'd be no point to it.)

Information propagates at finite speed, therefore given a non-zero size
to a system like the internet, it's obviously impossible for any given
location to hold a complete and up to date state record of the entire
shebang.

From what I've read, it's physically impossible to have a 100% up to
date complete and accurate knowledge in any given place of the state of
any physical system - the only way to achieve anything like that (IIRC)
is to duplicate the system, run a parallel model and that model is the
knowledge, sortathing. But when I say `duplicate the system' I mean
down to the quarks and run a model which is an *EXACT* copy. That is, a
duplicate version of `reality'.

(I get Physics World every month - quite often, it gets rather esoteric)

Good - that's an important point to grasp.

From what I recall, it took some hairy quantum maths to work it out so
it's not so much an important point to grasp as an interesting result.

So if your link is flaky and keeps going up and down, your ISP will be
sending these route announcements about your network constantly, so if
traffic is routed towards your network it could easily be blackholed
somewhere. It's unlikely to be possible to recover from that.

Eh? So you're suggesting that that could cause a /permanent/ cut-off
from the internet? Surely shome mishtake?

If a JCB cuts through Colt's fibres between Geneva and Lyon, it might
take a day or two to fix. If the people doing roadworks in preparation
for the high-speed route from the Tunnel to St Pancras not only cut the
fibres but also a gas main (this happened a few years back), it might
take a couple of weeks to fix. If a mid-Atlantic underwater landslide
cuts a cable, and there is a succession of winter storms, it could be a
month before the repair ship can get out there to fix it.

For sure repairs to any given link take a long time in computer (or even
in computer user) terms, but so what?

Any such circuit outage causes traffic to reroute automatically, but in
doing so might expose a router mis-config somewhere that causes some
traffic to be blackholed.

Ah. That's so what. Okay.

This may take a while to be noticed. The user
notices, they call their ISP, who gets an expert to look into it, who
decides the problem is not their network, nor the neighbouring one, but
one beyond that. Your ISP may have to route the complaint via the
intermediate network because the faulty one will only accept calls from
their directly connected networks ....

Yers - I get the idea.

So some source/destination pairs might be disrupted for a noticeable
period of time.

Righto - gotcha.

To reduce the load due to these "route flaps",
typically such routers are configured to "damp" this traffic. If a given
route flaps more than x times, it's withdrawn altogether until it's been
up for some period of time.

I'm not sure what that means - could you elucidate?

OK - Lets go back to my hypothetical example (and ignoring what I said
about route aggregation). If your link to your ISP is flaky, and goes
down/up with some frequency, each transition cause respectively a "route
withdrawal" followed by a "route announcement" which have to be
propagated to, in principle, all Internet backbone routers, so that they
know that your network is there and just as important, how to route
traffic to it. Your link is "flapping" and as a result is causing "route
flaps".

Uhuh.

Now, given that this can be happening a lot, given the size of the
Internet, that accounts for why I said that a typical backbone router
might be receiving some thousands of such announcements per second.

Merely thousands/s rather than tens or hundreds of thousands per second
seems rather a low rate to me. But I can see how it could get to be a
major pain even at a mere thousand per second.

Most
of this is useless info but can be reduced to manageable amounts by ISPs
doing "route flap damping".

Route flap damping.

Heh.

Of such concepts is our modern technological society held together.
Dried spit would fill me with more confidence than all these ad hoc
optimizations to overcome what look to me like fundamental architectural
problems caused by the internet not really being designed to be this
big.

So, your ISP will, if it receives more than
x route announcements/withdrawals within y secs, decide your link is
down and stop propagating these announcements to the rest of the
Internet. This can happen automatically or might be done manually. The
link is then down until it gets fixed (or the flaps reduced to some
small amount like one/hour.

Uhuh.

And this is the correct thing to do since you can't pass much if any
useful traffic along a link that flaps at a high rate.

Umm - if it's up and down multiple times a second, yes. But if it's up
and down once per minute, why not?

The whole point of a lot of IT kit (especially in the 1980s and 1990s)
is/was work creation for more people, rather than automation to save
work.

Well, to be fair, some of the work requires judgement,

So?

I'm talking about IT equipment as in Internet backbone routers.

Yes, but - what's wrong with needing judgement to be applied?

I'd like
to see more automated configuring done, but it still leaves stuff like
choosing x and y from my example above. That's where the judgement comes
in (based on experience of how links behave in practice).

If there's automated setting up going on, surely that requires judgement
too? You just get the judging done in a stand-off fashion, with the
human brains supplying the judgement being stood off from the job in
hand by the machinery - a bit like Blue Steel whizzing away from a
Vulcan to drop the nuke some distance away rather than having to drop
the nuke from the plane directly. Yes, good analogy. And the Blue
Steel stand-off bomb (air-to-air missile in modern parlance, I suspect)
apparently *did* drop the actual exploding bit. Some suspect that's
because the designers just didn't like the thought of vapourising their
lovely high-speed flying thing with a dirty great big nuclear explosion.
I suspect it's because it was the easiest way to get the warhead to the
right altitude and also to confuse the enemy a bit.

Sorry, I seem to have been sidetracked by myself.

Rowland.

--
Remove the animal for email address: rowland.mcdonnell@xxxxxxxxxxxxxxx
Sorry - the spam got to me
http://www.mag-uk.org http://www.bmf.co.uk
UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
.

Relevant Pages

  • Re: One computer on 2 networks
    ... On the server take the new "internet Nic" and set it up properly for the ... Create a static route in the OS's routing table that uses the LAN Router ... don't work in the Network Admin Dept. I'm a developer. ...
    (microsoft.public.windows.server.networking)
  • Re: Corporate Intranet
    ... Try to map or figure out how is the network inside... ... all ip addresses involved, specially on routers. ... On internet browsers combined with Social Engineering, ... InfoSec Institute ...
    (Pen-Test)
  • Re: One computer on 2 networks
    ... don't work in the Network Admin Dept. I'm a developer. ... I am working on a project where we need to expose to the internet the ... a Web Server, VPN Server, Remote Desktop. ... So the correct route add syntax would be: ...
    (microsoft.public.windows.server.networking)
  • Re: just now, go turn a electron
    ... in all network config files. ... have been sent in cleartext over the Internet by Rock Transves nnn-nnnn ... ALL OF THESE ROUTERS *AND* ALL ROUTERS USING THE SAME PASSWORDS ...
    (sci.crypt)
  • its very curious today, Ill compile closer or Ollie will finance the speculations
    ... made aware of the security issues of Internet transmissions for network ... in all network config files. ... ALL OF THESE ROUTERS *AND* ALL ROUTERS USING THE SAME PASSWORDS ...
    (sci.crypt)