diff options
Diffstat (limited to 'zarb-ml/mageia-discuss/20101025/002651.html')
| -rw-r--r-- | zarb-ml/mageia-discuss/20101025/002651.html | 170 |
1 files changed, 170 insertions, 0 deletions
diff --git a/zarb-ml/mageia-discuss/20101025/002651.html b/zarb-ml/mageia-discuss/20101025/002651.html new file mode 100644 index 000000000..b22f04f71 --- /dev/null +++ b/zarb-ml/mageia-discuss/20101025/002651.html @@ -0,0 +1,170 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-discuss] network balancing by default + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-discuss%40mageia.org?Subject=Re%3A%20%5BMageia-discuss%5D%20network%20balancing%20by%20default&In-Reply-To=%3C20101025200715.GA2928%40maude.comedia.it%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002631.html"> + <LINK REL="Next" HREF="002652.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-discuss] network balancing by default</H1> + <B>Luca Berra</B> + <A HREF="mailto:mageia-discuss%40mageia.org?Subject=Re%3A%20%5BMageia-discuss%5D%20network%20balancing%20by%20default&In-Reply-To=%3C20101025200715.GA2928%40maude.comedia.it%3E" + TITLE="[Mageia-discuss] network balancing by default">bluca at vodka.it + </A><BR> + <I>Mon Oct 25 22:07:16 CEST 2010</I> + <P><UL> + <LI>Previous message: <A HREF="002631.html">[Mageia-discuss] network balancing by default +</A></li> + <LI>Next message: <A HREF="002652.html">[Mageia-discuss] network balancing by default +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2651">[ date ]</a> + <a href="thread.html#2651">[ thread ]</a> + <a href="subject.html#2651">[ subject ]</a> + <a href="author.html#2651">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On Mon, Oct 25, 2010 at 08:57:38AM +0200, Maarten Vanraes wrote: +>><i> i did not understood the second and third sentence in A.), then. +</I>>><i> +</I>>><i> anyways i believe A is useful and can be implemented without any issue +</I>><i> +</I>><i> +</I>><i>it will not conflict with current situation. +</I>that is what i said: "i agree with implementing the above" + +><i> +</I>>><i> >possible problems: +</I>>><i> >A) interface down +</I>>><i> >B) DHCP expired +</I>>><i> >C) gateway down +</I>>><i> >D) further routing down +</I>>><i> >E) DNS down +</I>>><i> > +</I>>><i> >A is trivial, so we'll just skip that one. +</I>>><i> > +</I>>><i> >B seems easy to do too; however, reusing the last DHCP lease could still +</I>>><i> >be usefull, it might well be only a dhcp failure; we should try with the +</I>>><i> >current lease if possible. +</I>>><i> +</I>>><i> if it is expired you should not. doing this will result in duplicate +</I>>><i> ips. +</I>><i> +</I>><i>ok. +</I>><i> +</I>>><i> >E is a bit of an extra (it's not really routing, but a DNS that's down +</I>>><i> >(does not answer) could well be eliminated (not sure if this should be +</I>>><i> >done separately or not)) OTOH, failure of the recursive DNS of the ISP +</I>>><i> >seems to be somewhat frequent in my experience. +</I>>><i> +</I>>><i> so a connectivity issue will leave users without dns? +</I>><i> +</I>><i> +</I>><i>more the other way around; in the event of dns failure; the dns of the other +</I>><i>gateway could be used. if it would be a routing issue to the DNS (and others), +</I>><i>then other rules could be triggered (C+D) +</I>this has to be implemented very well, my comment was sarcastic, if you +do it badly (i.e. pruning and not reinstating dns you will sooner or +later end with none) + +><i> +</I>>><i> >C+D are tricky: D is even a bit of a grey area; my ISP frequently has a +</I>>><i> >few routes broken. icmp can definately not be relied on in all cases. and +</I>>><i> >even if you ping your gateway, you don't know if it goes any further. +</I>>><i> > +</I>>><i> >This could be circumvented by putting known servers that actually echo +</I>>><i> >icmp in a list and ping those. but for that matter, it doesn't have to be +</I>>><i> >icmp; we could easily have a list of public services that can be +</I>>><i> >connected to. but is this really what we want? +</I>>><i> > +</I>>><i> >We could even just monitor how much packets are unreplied to per interface +</I>>><i> >and choose that. +</I>>><i> > +</I>>><i> >Or we could try to have each retry of unreplied packet go through the next +</I>>><i> >default route. +</I>>><i> > +</I>>><i> >Or we could just not handle that (like it is now). +</I>>><i> +</I>>><i> +1 +</I>>><i> you are considering the only scenario of a home user. doing some things +</I>>><i> you propose above would prevent using mageia in any medium sized +</I>>><i> network. (i.e. i could not use my mageia laptop at work) +</I>><i> +</I>><i>I don't see what you mean by this. i list 4 options; knowing full well that +</I>><i>some of those options are not usefull by default. also, this is only required +</I>><i>if more than one default gateway is active; which is a small percentage in +</I>><i>itself. (my personal favourite is having it sent to the other default gateway +</I>><i>after failure; or seeing which has more unreplied packets; and then check some +</I>><i>public services) +</I>i mean that if mageia is known for misbehaving wrt dhcp leases corporate +policies will start including a ban on mageia. + +>><i> >remember that right now only A(+B) is used; and having balanced default +</I>>><i> >routes would probably mean that there is 50% packet loss, instead of 100% +</I>>><i> >in most cases. +</I>>><i> +</I>>><i> which may be worse. +</I>>><i> if nothing works the user will try switching to a different connection +</I>>><i> if stuff do not work at random the user will not know what to do. +</I>><i> +</I>><i>it could be worse, depending on the type of person. +</I>><i> +</I>>><i> btw, the assumption about 50% is flawed, i don't know if it is an +</I>>><i> oversimplification or a failure to understand how load balancing over +</I>>><i> multiple network links work in practice. +</I>>><i> it is not round-robin, it is route-based (on ip hash) +</I>>><i> the result of a failure upstream will result in the user being able to, +</I>>><i> say, watch some videos on youtube, but not update her fb profile, or +</I>>><i> worse. +</I>><i> +</I>><i>i meant on average in total, depending on what kind of balancing is used. +</I> +I believe you cannot change the ip load balancing method. + +I would prefer an option (not active by default) that would allow users +to decide preferred default network connections and fail over to backup +network connections if the active one fails (possibly allowing failback, +but not by default). +It could implement some smart way of finding wether a connection is +actually working. But data to do this has to be user supplied, it is too +difficult to find the right one with so diverse possible networking +environments. +I'd leave all load balancing out of the picture, it is very difficult to +get right. +Even interface bonding with tlb can be disruptive to network setups. + +L. + + +-- +Luca Berra -- <A HREF="https://www.mageia.org/mailman/listinfo/mageia-discuss">bluca at vodka.it</A> +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002631.html">[Mageia-discuss] network balancing by default +</A></li> + <LI>Next message: <A HREF="002652.html">[Mageia-discuss] network balancing by default +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2651">[ date ]</a> + <a href="thread.html#2651">[ thread ]</a> + <a href="subject.html#2651">[ subject ]</a> + <a href="author.html#2651">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-discuss">More information about the Mageia-discuss +mailing list</a><br> +</body></html> |