From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Salim S I" Date: Thu, 10 May 2007 06:15:23 +0000 Subject: Re: [LARTC] Load balancing using connmark Message-Id: <000401c792ca$9ba1cdb0$5964a8c0@SalimSi> MIME-Version: 1 Content-Type: multipart/mixed; boundary="===============1855801016==" List-Id: References: <1178722806.7492.55.camel@vulcan.aspl> In-Reply-To: <1178722806.7492.55.camel@vulcan.aspl> To: lartc@vger.kernel.org This is a multi-part message in MIME format. --===============1855801016== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7930D.A9C69450" This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C7930D.A9C69450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Francis Brosnan Blazquez wrote: > Hi, >=20 > I've been implementing a load balancing solution using CONNMARK, based > on solution described by Luciano Ruete at [1]. Gracias por el post y por > apuntar en la direcci=F3n correcta Luciano! >=20 > Once implemented, I've found that due to some reason packets aren't > properly marked (or improperly remarked) and sent out using the wrong > interface.=20 >=20 > >=20 > iptables -t mangle -A POSTROUTING -m mark --mark ! 0 -j ACCEPT=20 > iptables -t mangle -A POSTROUTING -o eth1 -j MARK --set-mark 0x1 > iptables -t mangle -A POSTROUTING -o eth2 -j MARK --set-mark 0x2 > iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark =20 This is wrong. POSTROUTING is exactly what is is _POST_ routing. By the time you do your marks and stuff the kernel has _already_ assigned a packet to an interface, and you can not alter this anymore. =20 > After a bit of testing with the second solution, it seems to behave > better, doing all marking job at the PREROUTING and OUTPUT. =20 This is flawed too. OUTPUT suffers from the very same problem as POSTROUTING - by the time the packets hit the NF stack the process has already bound itself to an interface, which you can not change anymore. =20 Peter =20 Disagree with Peter. The marking in postrouting table is CONNMARK. This is for marking the connection, which has already had a route decided for it, so that all packets of the connection passes through this interface. This marking is done for packets with NEW state, see the check for mark=3D=3D0 in the prev. line. The restore mark in PREROUTING will = restore the connmark and route the subsequent packets. This approach will work, but you need some sort of stateful-ness in netfilter. =20 The second point in Brosnan Blazquez=92s mail about shorewall: They seem to be doing Policy Routing, not real load balancing. ------=_NextPart_000_0005_01C7930D.A9C69450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Francis Brosnan =
Blazquez =
wrote:
> =
Hi,
> =

> I've =
been implementing a load balancing solution using CONNMARK, =
based
> =
on solution described by Luciano Ruete at [1]. Gracias por el post y por
> apuntar en la direcci=F3n correcta Luciano!
> =

> Once =
implemented, I've found that due to some reason packets =
aren't
> =
properly marked (or improperly remarked) and sent =
out using the wrong
> =
interface. 
> =

> =
<snip>
> =

> =
iptables -t mangle -A =
POSTROUTING -m mark=A0 --mark ! =
0 -j ACCEPT 
> =
iptables -t mangle -A =
POSTROUTING -o eth1 -j MARK --set-mark =
0x1
> =
iptables -t mangle -A =
POSTROUTING -o eth2 -j MARK --set-mark =
0x2
> =
iptables -t mangle -A =
POSTROUTING -j CONNMARK =
--save-mark
 
This is =
wrong. POSTROUTING is exactly what is is _POST_ routing. By =
the
time you do your marks =
and stuff the kernel has _already_ assigned a
packet to an interface, =
and you can not alter this anymore.
 
> =
After a bit of testing with the second solution, it seems to =
behave
> =
better, doing all marking job at the PREROUTING and =
OUTPUT.
 
This is =
flawed too. OUTPUT suffers from the very same problem =
as
POSTROUTING - by the time the packets hit the =
NF stack the process has
already bound itself to =
an interface, which you can not change =
anymore.
 

Peter

 

Disagree with Peter. The marking in postrouting table is CONNMARK. This is for marking the connection, which has already = had a route decided for it, so that all packets of the connection passes through this interface. This marking is done for packets with NEW state, see the check for mark=3D=3D0 in the prev. line. The restore mark in PREROUTING will restore the connmark and route the subsequent packets.

This approach will work, but you need some sort of stateful-ness in netfilter.

 

The second point in Brosnan Blazquez’s mail about shorewall: They seem to be doing Policy Routing, not real load = balancing.

------=_NextPart_000_0005_01C7930D.A9C69450-- --===============1855801016== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc --===============1855801016==--