Op maandag 25 oktober 2010 08:41:01 schreef Luca Berra: > 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
imho, this in itself is wrong; i want network-scripts to be split off from initscripts; especially if we're going to use systemd later on. > >> >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 it will not conflict with current situation. > >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. ok. > >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? more the other way around; in the event of dns failure; the dns of the other gateway could be used. if it would be a routing issue to the DNS (and others), then other rules could be triggered (C+D) > >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) I don't see what you mean by this. i list 4 options; knowing full well that some of those options are not usefull by default. also, this is only required if more than one default gateway is active; which is a small percentage in itself. (my personal favourite is having it sent to the other default gateway after failure; or seeing which has more unreplied packets; and then check some public services) > >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. it could be worse, depending on the type of person. > 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. i meant on average in total, depending on what kind of balancing is used. > >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. sorry,
