All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Rabbitson <rabbit@rabbit.us>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Load Balance and SNAT problem.
Date: Wed, 27 Jun 2007 06:58:48 +0000	[thread overview]
Message-ID: <46820AA8.7020305@rabbit.us> (raw)
In-Reply-To: <7e47206b0706242007q487365d3gb7c12658b9669edd@mail.gmail.com>

Grant Taylor wrote:
> On 6/27/2007 12:54 AM, Peter Rabbitson wrote:
>> I am actually simply jealous that some people apparently get it to 
>> work in-kernel, and I can't seem to.
> 
> Ah, so the truth comes out.  ;)

Hehe

>> My requirements are pretty simple:
>> o As transparrent as possible DGD, that can detect 2nd and 3rd hop 
>> failures
> 
> Think about what you just asked for.  "Dead Gateway Detection" is used 
> to detect dead (upstream) (default) gateway(s).  Rather it is not meant 
> to detect dead routes beyond your gateway(s).  To do this you will need 
> some sort of utility to monitor things for you.  I.e. you will not be 
> able to get the kernel to detect that a gateway is good for some things 
> but not for others.  Actually if you stop to think about it, this is 
> beyond the scope of what the kernel should do.  This is more the scope 
> of a routing protocol and / or a route management daemon.
> 
> In short, use something to test reachability to destinations and use ip 
> rules to choose routing tables accordingly.  I.e. have a default routing 
> table that will try to use any / all interfaces routes and have 
> alternative routing tables that will try fewer interfaces / routes.

This is the most fragile part of my current setup. And DGD based on 
packet counts IMO is an extremely simple thing to do, I discussed it 
recently with you. If something like this was present in-kernel the 
world would be a better place.

>> o Robust load balancing - connections are distributed over all 
>> available links, regardless of source and destination, with the 
>> possibility of assigning relative channel priorities
> 
> I think this is close to being possible depending on your scenario (NAT 
> or not) and a few other things.
> 
> It was my understanding that equal cost multi path routing was suppose 
> to accomplish this very thing.  I.e. if you had globally routable IP 
> addresses behind the router, you could send traffic out either link, 
> hopefully in such a fashion as to (hopefully) fully utilize all links. 
> ECMP does include weight options to assign ratios to routes.

For globally routable addresses it doesn't really matter, because you 
can not usually detect it (things still work).

> What you have proposed with load balancing via Netfilter should be able 
> to achieve this with out any problems.  Or at least I would think such.

It actually does work in production for quite some time now. But as said 
before - it is ugly and fragile.

I understand that we are coming from different environments, but I still 
think that my figure of 90% is rather accurate. If you can afford not to 
do NAT, means that most likely you also have access to the ISPs dynamic 
routing protocols as well, and the entire discussion becomes pointless. 
On the contrary if you run NAT, most likely you are a poor-mans-ISP or 
smaller, running off two consumer DSL links, and all of the above applies.

Either way I rest my case here, as we are comparing apples to dinosaurs, 
and went too far OT :)

Peter
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

  parent reply	other threads:[~2007-06-27  6:58 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-25  3:07 [LARTC] Load Balance and SNAT problem John Chang
2007-06-25 14:47 ` Grant Taylor
2007-06-25 21:30 ` VladSun
2007-06-26  6:46 ` Peter Rabbitson
2007-06-26 11:36 ` John Chang
2007-06-26 14:37 ` Grant Taylor
2007-06-26 15:04 ` Patrick Brandão
2007-06-26 17:44 ` Peter Rabbitson
2007-06-27  1:24 ` Grant Taylor
2007-06-27  1:51 ` Grant Taylor
2007-06-27  2:07 ` Grant Taylor
2007-06-27  2:22 ` Salim S I
2007-06-27  2:34 ` Grant Taylor
2007-06-27  2:39 ` Grant Taylor
2007-06-27  3:07 ` Salim S I
2007-06-27  3:16 ` Grant Taylor
2007-06-27  5:54 ` Peter Rabbitson
2007-06-27  6:41 ` Salim S I
2007-06-27  6:43 ` Grant Taylor
2007-06-27  6:58 ` Peter Rabbitson [this message]
2007-06-27  7:28 ` Grant Taylor
2007-06-27  7:37 ` Grant Taylor
2007-06-27  7:53 ` Grant Taylor
2007-06-27  7:57 ` Grant Taylor
2007-06-27  8:03 ` Peter Rabbitson
2007-06-27  8:03 ` Grant Taylor
2007-06-27  8:11 ` Grant Taylor
2007-06-27  8:24 ` Grant Taylor
2007-06-27  8:26 ` Grant Taylor
2007-06-27  9:09 ` Peter Rabbitson
2007-06-27 10:19 ` Grant Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46820AA8.7020305@rabbit.us \
    --to=rabbit@rabbit.us \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.