All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Salim S I" <salim.si@cipherium.com.tw>
To: lartc@vger.kernel.org
Subject: FW: [LARTC] Load balancing using connmark
Date: Thu, 10 May 2007 09:22:59 +0000	[thread overview]
Message-ID: <001901c792e4$cdc161b0$5964a8c0@SalimSi> (raw)
In-Reply-To: <1178722806.7492.55.camel@vulcan.aspl>



-----Original Message-----
From: Salim S I [mailto:salim.si@cipherium.com.tw] 
Sent: Thursday, May 10, 2007 5:22 PM
To: 'Francis Brosnan Blazquez'
Subject: RE: [LARTC] Load balancing using connmark

"I think the main advantage of shorewall solution is that it applies
connmark to incoming packets from the wan as you point, leaving load
balancing to outgoing connections to the main table"

Actually, the main table/multipath route only routes the first packet of
a connection. The subsequent routing for that connection is done based
on connmark, for outgoing packets too. Otherwise replies to packets
coming from WAN1 may go through WAN2. The difference in the two
solutions is only in where packets are marked and which packets are
marked. Routing is the same.

For a detailed discussion on the first approach, you can refer to this
thread. 

http://mailman.ds9a.nl/pipermail/lartc/2006q2/018964.html


-----Original Message-----
From: Francis Brosnan Blazquez [mailto:francis@aspl.es] 
Sent: Thursday, May 10, 2007 5:07 PM
To: Salim S I
Cc: lartc@mailman.ds9a.nl
Subject: RE: [LARTC] Load balancing using connmark

El jue, 10-05-2007 a las 16:01 +0800, Salim S I escribió:
Hi Salim,

Thanks for your reply,

> On closer look, I am wrong about shorewall. It seems to be a different
> approach to load balancing. They connmark the incoming packets from
> WAN, rather than outgoing packets. I think it should work well, but I
> wonder why this approach is not popular. There must be some drawback
> to it. I can’t think of one,though.

I think the main advantage of shorewall solution is that it applies
connmark to incoming packets from the wan as you point, leaving load
balancing to outgoing connections to the main table.

In any case, with this second solution I don't see wrong routed packages
on wan interfaces using tcpdump, whereas with the first solution I do.
More testing is required.

Regarding to your previous reply, can you elaborate more on "...This
approach will work, but you need some sort of stateful-ness in
netfilter..."

Cheers!

-- 
Francis Brosnan Blazquez <francis@aspl.es>
Advanced Software Production Line, S.L.


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

  parent reply	other threads:[~2007-05-10  9:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-09 15:00 [LARTC] Load balancing using connmark Francis Brosnan Blazquez
2007-05-09 16:33 ` Peter Rabbitson
2007-05-10  6:15 ` Salim S I
2007-05-10  8:01 ` Salim S I
2007-05-10  9:06 ` Francis Brosnan Blazquez
2007-05-10  9:22 ` Salim S I [this message]
2007-05-10 10:25 ` Peter Warasin
2007-05-10 10:51 ` Peter Rabbitson
2007-05-10 10:59 ` Peter Rabbitson
2007-05-10 11:25 ` Salim S I
2007-05-10 12:04 ` David Ford
2007-05-10 12:06 ` Peter Rabbitson

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='001901c792e4$cdc161b0$5964a8c0@SalimSi' \
    --to=salim.si@cipherium.com.tw \
    --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.