On Mon, Oct 25, 2010 at 12:00:46AM +0200, Maarten Vanraes wrote:
Op zondag 24 oktober 2010 22:39:29 schreef Luca Berra:
On Sun, Oct 24, 2010 at 11:43:28AM +0200, Maarten Vanraes wrote:
>I would propose the following:
First off, the timing of this proposal is probably too soon, i just wanted to
get it out there, in case i forgot later.
open an enhancement on initscripts :P
>A.) by default, add for every interface, a little advanced routing which
>makes packets return from the same way they came.
>This usually is only useful with incoming packets, but can still be useful
>if laptops have for example 2 gateways because the wifi is still on and
>the cable is too. That would mean that from both interfaces it'd be
>possible to use ssh or vnc or whatever.
this is possible with incoming packets, but, how do you select the
source of a new one?
this step is only for the replies of incoming packets and never has any effect
on new outgoing packets; this step doesn't change anything for new outgoing
packets. and this can even be used on interfaces that aren't used as default
gateway.
i did not understood the second and third sentence in A.), then.
anyways i believe A is useful and can be implemented without any issue
possible problems:
A) interface down
B) DHCP expired
C) gateway down
D) further routing down
E) DNS down
A is trivial, so we'll just skip that one.
B seems easy to do too; however, reusing the last DHCP lease could still be
usefull, it might well be only a dhcp failure; we should try with the current
lease if possible.
if it is expired you should not. doing this will result in duplicate
ips.
E is a bit of an extra (it's not really routing, but a DNS that's down (does
not answer) could well be eliminated (not sure if this should be done
separately or not)) OTOH, failure of the recursive DNS of the ISP seems to be
somewhat frequent in my experience.
so a connectivity issue will leave users without dns?
C+D are tricky: D is even a bit of a grey area; my ISP frequently has a few
routes broken. icmp can definately not be relied on in all cases. and even if
you ping your gateway, you don't know if it goes any further.
This could be circumvented by putting known servers that actually echo icmp in
a list and ping those. but for that matter, it doesn't have to be icmp; we
could easily have a list of public services that can be connected to. but is
this really what we want?
We could even just monitor how much packets are unreplied to per interface and
choose that.
Or we could try to have each retry of unreplied packet go through the next
default route.
Or we could just not handle that (like it is now).
+1
you are considering the only scenario of a home user. doing some things
you propose above would prevent using mageia in any medium sized
network. (i.e. i could not use my mageia laptop at work)
remember that right now only A(+B) is used; and having balanced default routes
would probably mean that there is 50% packet loss, instead of 100% in most
cases.
which may be worse.
if nothing works the user will try switching to a different connection
if stuff do not work at random the user will not know what to do.
btw, the assumption about 50% is flawed, i don't know if it is an
oversimplification or a failure to understand how load balancing over
multiple network links work in practice.
it is not round-robin, it is route-based (on ip hash)
the result of a failure upstream will result in the user being able to,
say, watch some videos on youtube, but not update her fb profile, or
worse.
also remember that if the metrics are the same for some reason, you will get
much stranger things when both are working perfectly.
L.
btw, there is no need to cc me on discussions, in fact it breaks my
filters.
--
Luca Berra -- [email protected]
