From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-discuss/20101025/002631.html | 181 ++++++++++++++++++++++++++++ 1 file changed, 181 insertions(+) create mode 100644 zarb-ml/mageia-discuss/20101025/002631.html (limited to 'zarb-ml/mageia-discuss/20101025/002631.html') diff --git a/zarb-ml/mageia-discuss/20101025/002631.html b/zarb-ml/mageia-discuss/20101025/002631.html new file mode 100644 index 000000000..bc57897ad --- /dev/null +++ b/zarb-ml/mageia-discuss/20101025/002631.html @@ -0,0 +1,181 @@ + + + + [Mageia-discuss] network balancing by default + + + + + + + + + +

[Mageia-discuss] network balancing by default

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Oct 25 08:57:38 CEST 2010 +

+
+ +
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,
+
+ + + +
+

+ +
+More information about the Mageia-discuss +mailing list
+ -- cgit v1.2.1