netfilter.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: Mail List - Netfilter <netfilter@vger.kernel.org>
Subject: Re: Load Balance
Date: Tue, 17 May 2011 13:07:48 -0500	[thread overview]
Message-ID: <4DD2B974.7060105@riverviewtech.net> (raw)
In-Reply-To: <BANLkTi=gB609MZNzuJ-277B23wCiB5EhOQ@mail.gmail.com>

On 05/17/11 12:00, Usuário do Sistema wrote:
> but I still wonder what is the metric used to do the load balance I
> guess that the point is in line below

(I'd have to go back and re-read to know for sure what the "metric" is 
that you are referring to and how it effects things.)

> iptables -t mangle -A PREROUTING -p tcp -m state --state NEW -m
> statistic --mode nth --every 2 --packet 0 -j CONNMARK1
> iptables -t mangle -A PREROUTING -p tcp -m state --state NEW -m
> statistic --mode nth --every 2 --packet 1 -j CONNMARK2
>
> I understand that each  two new connections the third go out to next
> link making the load balance.
>
> right ??

In (basic) theory, yes.

If we limit the scope to be just new connections (that will match the 
above rules), yes, they will alternate between the connections (via 
marks) thus hypothetically equalizing the load on the connections.

The thing that this does not take in to account is what type of traffic 
a given connection is nor how long lived and active it is.

Let's say that I have the following (new) connections in the following 
sequence.

   1)  Simple SMTP test email.
   2)  HTTP download of kernel source.
   3)  Simple DNS query.
   4)  VPN connection.

You will find that connections #1 and #3 are marked with CONNMARK1 and 
that connections #2 and #4 are marked with CONNMARK2.  So what you end 
up with is two very ""light connections on CONNMARK1 and two much 
heavier connections on CONNMARK2.

The connections did end up "load balanced" (in a manner of speaking), or 
"distributed" (is probably a better way to describe it) across the 
multiple CONNMARKs.  However, if you look at the utilization of the two 
CONNMARKs or the physical connections they represent, you will find that 
one is way under utilized and the other is probably saturated.

However, with out doing some relatively nasty things (i.e. spoofing 
which requires support upstream) there is little that you can do about this.

So, you do end up distributing the connections, but not necessarily load 
balancing.

> thank!

You are welcome.



Grant. . . .

  reply	other threads:[~2011-05-17 18:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-17 23:22 Load Balance Usuário do Sistema
2011-05-15 17:23 ` Andrew Beverley
2011-05-16 20:24   ` Usuário do Sistema
2011-05-16 21:38     ` Andrew Beverley
2011-05-16 22:42       ` Usuário do Sistema
2011-05-17  0:45       ` Grant Taylor
2011-05-17 17:00         ` Usuário do Sistema
2011-05-17 18:07           ` Grant Taylor [this message]
2011-05-17 20:06             ` Usuário do Sistema

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=4DD2B974.7060105@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=netfilter@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).