RE: Round Robin Load Balancing

RE: Round Robin Load Balancing

[Daniel Chemko]

Because of the nature of your setup, you cannot have a perfect equal
load balance setup. This is because you cannot control the inbound flow
of data. If one user makes a request out of line X then the return
packet HAS to come back through line X. So, if one guy sends a huge
request taking minutes to fulfill, he / she will tie up the line until
the job is finished. The load balancer should be smart enough to not
send any more requests to that line, but you are still seeing the line
being monopolized by this single connection, hence it is not balanced
over all lines equally.

In order to have fair balancing of all lines, I think you need to set up
a deal with your ISP to load balance on their end as well.

You could also setup something like BGP to allow multiple routes to the
same return address, but I am not familiar enough with BGP to be much
help in this area. In all likelihood, you are better off with your
current solution or maybe the ISP solution if it is supported by them
(more money usually).



-----Original Message-----
From: Javier Govea [mailto:jgovea@magma.ca] 
Sent: Tuesday, July 15, 2003 12:34 PM
To: netfilter@lists.netfilter.org
Subject: Round Robin Load Balancing 

Hi,

I'm trying to do some load balancing with four ppp connections. Here is
what i have: a LAN
connected to a redhat box which has four ppp interfaces. All the boxes
in the LAN are
accesing internet through the ppp interfaces in the redhat box. I'm
using iproute2, in my
redhat box, to setup the the four ppp interfaces as my default out going
route (as
described in LART http://lartc.org/howto/index.html) and I'm using
iptables to masquerade
all the traffic comming from the LAN. 

My setup is working fine, ie. my LAN can access the net throught the
four ppp interfaces.
My problem is that i don't know how is the load balancing working. Some
times one of the
ppp interfaces is used more than the others (and that is my problem).
According to LART
the routes are cached, can someone go a bit into more details in this
caching thing??? how
does it work?  which particular files in the kernel are doing this?  

I would like to implement a simple round robing algorithm (with no
caching) for doing the
laod balancing. That is first connection established gose through ppp0,
the second
connection on ppp1 and so on. 

I could hack iproute2 and/or iptables, but i'm not sure about which
particular files i
should hack in order to implement this round robin algorithm. I actually
don't know if
what i want makes any sense

Any ideas or pointers are all very well appreaciated.
Thanx to all
X

logging mac address

[Antonio Paulo Salgado Forster]

Hello all,

      Is there any known way to log the mac address for packets blocked on
the forward table just like in the input table? I've been searching the
archives and documentations but found nothing so far.

Thanks in advance.

Forster

Re: Round Robin Load Balancing

[Ramin Dousti]

Absolutely. Perfect load balancing needs to be coordinated on _all_ the
endpoints of the links involved. In this case, 4 endpoints.

For a regular load balancing (which is going to be the case here)
we still have lots of unknown variables. Do these two ppp
accounts belong to the same ISP? Does the ISP drop forign src?
Is the gateway doing nat? Do you have any preference on one of
the ppp's than the other? Can you bond (mppp)? And so on.
But a fun project, though, for someone who has time...

Ramin

On Tue, Jul 15, 2003 at 12:44:40PM -0700, Daniel Chemko wrote:

> Because of the nature of your setup, you cannot have a perfect equal
> load balance setup. This is because you cannot control the inbound flow
> of data. If one user makes a request out of line X then the return
> packet HAS to come back through line X. So, if one guy sends a huge
> request taking minutes to fulfill, he / she will tie up the line until
> the job is finished. The load balancer should be smart enough to not
> send any more requests to that line, but you are still seeing the line
> being monopolized by this single connection, hence it is not balanced
> over all lines equally.
> 
> In order to have fair balancing of all lines, I think you need to set up
> a deal with your ISP to load balance on their end as well.
> 
> You could also setup something like BGP to allow multiple routes to the
> same return address, but I am not familiar enough with BGP to be much
> help in this area. In all likelihood, you are better off with your
> current solution or maybe the ISP solution if it is supported by them
> (more money usually).
> 
> 
> 
> -----Original Message-----
> From: Javier Govea [mailto:jgovea@magma.ca] 
> Sent: Tuesday, July 15, 2003 12:34 PM
> To: netfilter@lists.netfilter.org
> Subject: Round Robin Load Balancing 
> 
> Hi,
> 
> I'm trying to do some load balancing with four ppp connections. Here is
> what i have: a LAN
> connected to a redhat box which has four ppp interfaces. All the boxes
> in the LAN are
> accesing internet through the ppp interfaces in the redhat box. I'm
> using iproute2, in my
> redhat box, to setup the the four ppp interfaces as my default out going
> route (as
> described in LART http://lartc.org/howto/index.html) and I'm using
> iptables to masquerade
> all the traffic comming from the LAN. 
> 
> My setup is working fine, ie. my LAN can access the net throught the
> four ppp interfaces.
> My problem is that i don't know how is the load balancing working. Some
> times one of the
> ppp interfaces is used more than the others (and that is my problem).
> According to LART
> the routes are cached, can someone go a bit into more details in this
> caching thing??? how
> does it work?  which particular files in the kernel are doing this?  
> 
> I would like to implement a simple round robing algorithm (with no
> caching) for doing the
> laod balancing. That is first connection established gose through ppp0,
> the second
> connection on ppp1 and so on. 
> 
> I could hack iproute2 and/or iptables, but i'm not sure about which
> particular files i
> should hack in order to implement this round robin algorithm. I actually
> don't know if
> what i want makes any sense
> 
> Any ideas or pointers are all very well appreaciated.
> Thanx to all
> X
> 
> 

Re: logging mac address

[Ramin Dousti]

On Tue, Jul 15, 2003 at 05:06:04PM -0300, Antonio Paulo Salgado Forster wrote:

> 
> 
> Hello all,
> 
>       Is there any known way to log the mac address for packets blocked on
> the forward table just like in the input table? I've been searching the
> archives and documentations but found nothing so far.

forward and input are chains and not tables. nat, mangle and filter are
tables. But anyhow, you just use the same rule for logging that you
used for INPUT logging and replace INPUT with FORWARD. You also need
to make sure what and where you're logging so that you don't DoS yourself.

Ramin

> 
> Thanks in advance.
> 
> Forster
> 
> 

Re: logging mac address

[Antonio Paulo Salgado Forster]

Hi Ramin,

      Thanks for the response.  I'm using the same rule for logging on the
input and forward  CHAINS ;-) but the behavior of the rule is different
depending on what chain it's in.. for input, by default it shows the MAC
addresses, but for forward, no MAC address is shown.

      For instance:

iptables -A INPUT -j LOG --log-level notice --log-prefix " INPUT BLOCK: "
iptables -A FORWARD -j LOG --log-level info --log-prefix " FORWARD BLOCK: "


Jul 15 17:51:25 fw kernel:  INPUT BLOCK: IN=eth0 OUT=
MAC=00:xx:xx:xx:xx:xx:00:yy:yy:yy:yy:yy:yy:00 SRC=t.t.t.t DST=r.r.r.r
LEN=64 TOS=0x00 PREC=0x00 TTL=128 ID=57828 PROTO=UDP SPT=1756 DPT=53 LEN=44

Jul 15 18:22:31 fw kernel:  FORWARD BLOCK: IN=eth0 OUT=eth1 SRC=x.x.x.x
DST=y.y.y.y LEN=1492 TOS=0x00 PREC=0x00 TTL=253 ID=37603 DF PROTO=ICMP
TYPE=8 CODE=0 ID=0 SEQ=2

Any hints? Thanks

Forster




Ramin Dousti <ramin@cannon.eng.us.uu.net>@lists.netfilter.org on 07/15/2003
05:59:36 PM

Sent by:    netfilter-admin@lists.netfilter.org


To:    aforster@br.ibm.com
cc:    netfilter@lists.netfilter.org
Subject:    Re: logging mac address



On Tue, Jul 15, 2003 at 05:06:04PM -0300, Antonio Paulo Salgado Forster
wrote:

>
>
> Hello all,
>
>       Is there any known way to log the mac address for packets blocked
on
> the forward table just like in the input table? I've been searching the
> archives and documentations but found nothing so far.

forward and input are chains and not tables. nat, mangle and filter are
tables. But anyhow, you just use the same rule for logging that you
used for INPUT logging and replace INPUT with FORWARD. You also need
to make sure what and where you're logging so that you don't DoS yourself.

Ramin

>
> Thanks in advance.
>
> Forster
>
>

Re: logging mac address

[Ramin Dousti]

On Tue, Jul 15, 2003 at 06:25:20PM -0300, Antonio Paulo Salgado Forster wrote:

>       Thanks for the response.  I'm using the same rule for logging on the
> input and forward  CHAINS ;-) but the behavior of the rule is different
> depending on what chain it's in.. for input, by default it shows the MAC
> addresses, but for forward, no MAC address is shown.

OK. I think I learned something today. It seems the only chains giving you
the MAC is INPUT in filter and PREROUTING in mangle.

It makes sense though that you don't get that in FORWARD since the routing
decision has not yet been made.

On the other hand it also makes sense that you don't get it for the outgoing
packets (POSTROUTING) as the MAC info belongs to another subsystem and is
"apparently" not available to netfilter...

Ramin

> 
>       For instance:
> 
> iptables -A INPUT -j LOG --log-level notice --log-prefix " INPUT BLOCK: "
> iptables -A FORWARD -j LOG --log-level info --log-prefix " FORWARD BLOCK: "
> 
> 
> Jul 15 17:51:25 fw kernel:  INPUT BLOCK: IN=eth0 OUT=
> MAC=00:xx:xx:xx:xx:xx:00:yy:yy:yy:yy:yy:yy:00 SRC=t.t.t.t DST=r.r.r.r
> LEN=64 TOS=0x00 PREC=0x00 TTL=128 ID=57828 PROTO=UDP SPT=1756 DPT=53 LEN=44
> 
> Jul 15 18:22:31 fw kernel:  FORWARD BLOCK: IN=eth0 OUT=eth1 SRC=x.x.x.x
> DST=y.y.y.y LEN=1492 TOS=0x00 PREC=0x00 TTL=253 ID=37603 DF PROTO=ICMP
> TYPE=8 CODE=0 ID=0 SEQ=2
> 
> Any hints? Thanks
> 
> Forster
> 
> 
> 
> 
> Ramin Dousti <ramin@cannon.eng.us.uu.net>@lists.netfilter.org on 07/15/2003
> 05:59:36 PM
> 
> Sent by:    netfilter-admin@lists.netfilter.org
> 
> 
> To:    aforster@br.ibm.com
> cc:    netfilter@lists.netfilter.org
> Subject:    Re: logging mac address
> 
> 
> 
> On Tue, Jul 15, 2003 at 05:06:04PM -0300, Antonio Paulo Salgado Forster
> wrote:
> 
> >
> >
> > Hello all,
> >
> >       Is there any known way to log the mac address for packets blocked
> on
> > the forward table just like in the input table? I've been searching the
> > archives and documentations but found nothing so far.
> 
> forward and input are chains and not tables. nat, mangle and filter are
> tables. But anyhow, you just use the same rule for logging that you
> used for INPUT logging and replace INPUT with FORWARD. You also need
> to make sure what and where you're logging so that you don't DoS yourself.
> 
> Ramin
> 
> >
> > Thanks in advance.
> >
> > Forster
> >
> >
> 
> 
> 

Re: logging mac address

[Ramin Dousti]

On Wed, Jul 16, 2003 at 09:23:38AM +1000, George Vieira wrote:

> >>It makes sense though that you don't get that in FORWARD since the routing
> decision has not yet been made.
> 
> Sorry, that's not true, routing decision HAS been made

Absolutely. This was my nonsense of the day...

RE: logging mac address

[George Vieira]

>>It makes sense though that you don't get that in FORWARD since the routing
decision has not yet been made.

Sorry, that's not true, routing decision HAS been made which is why it's FORWARDing onto another interface. But remember that MAC addresses are visible only as they come off the wire.. that's what I've found.. so INPUT and PREROUTING see it but once they are in, the macs are dropped off into limbo...

Thanks,
____________________________________________
George Vieira
Systems Manager
georgev@citadelcomputer.com.au

Citadel Computer Systems Pty Ltd
http://www.citadelcomputer.com.au

Phone   : +61 2 9955 2644
HelpDesk: +61 2 9955 2698
 

RE: logging mac address

[Daniel Chemko]

I don't recommend it, but I guess it is possible to filter them on the
nat prerouting chain instead if you really must have the MAC address
recorded...

-----Original Message-----
From: Antonio Paulo Salgado Forster [mailto:aforster@br.ibm.com] 
Sent: Tuesday, July 15, 2003 1:06 PM
To: netfilter@lists.netfilter.org
Subject: logging mac address



Hello all,

      Is there any known way to log the mac address for packets blocked
on
the forward table just like in the input table? I've been searching the
archives and documentations but found nothing so far.

Thanks in advance.

Forster