[Mageia-discuss] network balancing by default

Maarten Vanraes maarten.vanraes at gmail.com
Mon Oct 25 00:00:46 CEST 2010


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.

> >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.
 
> >B.) if we have multiple gateways (like in that case), have them use both
> >balancedly. ie: start a small daemon which checks which of the gateways is
> >up or down; and change the default gateway accordingly, or even both in
> >some kind of balanced mode. (with advanced routing.)
> 
> This could go wrong in so many ways i would not even try:
> i.e. how do you determine if a gateway is up? dont tell me icmp, many
> firewall refuse it, and vrrp standard says the backup gateway should not
> answer icmp echo.

there are alot of different aspects to what we consider as a "working" isp 
connection.

this isn't about having perfection; it's about improving what we have now.


Consider a laptop user; the user has a network connection and also has his wifi 
up.

You will notice that there are in fact 2 default gateways (possibly with 
different metric, but we cannot be sure).

what i propose is to use both together balanced by default.

this in itself is an improvement; the parts about detection of "up" or "down" 
(except the interface itself) are extras, after all, the same issues can even 
happen with one gateway.


Balancing is even more usefull if there are ways of automatically detecting 
which interfaces are unwanted for routing.

(TBH you assumed icmp is what would be used; we all know icmp can be blocked 
and is never relied on..)

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.

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.

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).

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.


also remember that if the metrics are the same for some reason, you will get 
much stranger things when both are working perfectly.


More information about the Mageia-discuss mailing list