From: Grant Taylor <gtaylor@riverviewtech.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Load Balance and SNAT problem.
Date: Wed, 27 Jun 2007 06:43:00 +0000 [thread overview]
Message-ID: <468206F4.4090900@riverviewtech.net> (raw)
In-Reply-To: <7e47206b0706242007q487365d3gb7c12658b9669edd@mail.gmail.com>
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. ;)
> 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.
> 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.
However, after discussion in this thread, I question if ECMP will do
this or not.
> o NAT compatible - link hopping is not an option, traffic with a
> specific SRC/DST must stay where it started.
I think this is the simpler of the above "robust load balancing" as you
say. In my opinion, this should be the first of the things to be
achieved and then try to extend this to be the above.
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.
Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next prev parent reply other threads:[~2007-06-27 6:43 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 [this message]
2007-06-27 6:58 ` Peter Rabbitson
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=468206F4.4090900@riverviewtech.net \
--to=gtaylor@riverviewtech.net \
--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.