All of lore.kernel.org
 help / color / mirror / Atom feed
From: "William L. Thomson Jr." <wlt@obsidian-studios.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Load-banancing. two ip's from one isp
Date: Tue, 28 Mar 2006 15:53:37 +0000	[thread overview]
Message-ID: <1143561218.9467.12.camel@wlt.obsidian-studios.com> (raw)
In-Reply-To: <20060328013941.CB4311B58DB@poczta.interia.pl>

Kirk,

On Tue, 2006-03-28 at 10:46 -0500, Kirk Reiser wrote:
> "William L. Thomson Jr." <wlt@obsidian-studios.com> writes:
> 
> > Somethings is not setup correctly then. Outgoing packets should use the
> > same interface as incoming packets either SNAT or DNAT. If it is not,
> > then that's because rules and tables are not setup properly.
> 
> Well, would this interface tracking be something provided by Julian
> Andresson's patches?

YES, that is exactly what provides it. Julians patches with no nat, no
go. Nat with no patches no go ;) It's his patches with the natting that
allows for proper lookup and route back out the proper interface.

>   I haven't applied those yet because up until now
> I didn't think they applied to my situation.  I don't know how
> differently I could set up the DNAT'ing than what I am doing but it
> sure isn't interface tracking currently.

Nope leave DNAT'ting alone. Just look into patching a kernel and booting
it. Then see what you get. I would imagine the results you want if have
all the rules setup properly.

> > Sure that's a nasty way of load balancing. Which will cause multiple
> > problems. Since you can't flush the clients catch easily and they will
> > still have a route in their cache to the first interface/isp. Despite
> > the response coming from the other.
> 
> Oh yes.  It really screws up udp connections because the various
> packets go out different interfaces when nexthopping.

I have seen that and came across it during my painful trial and errors
as I was trying to get load balancing working.

-- 
Sincerely,
William L. Thomson Jr.
Obsidian-Studios, Inc.
http://www.obsidian-studios.com

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

  parent reply	other threads:[~2006-03-28 15:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-28  1:39 [LARTC] Load-banancing. two ip's from one isp sAwAr
2006-03-28  3:26 ` William L. Thomson Jr.
2006-03-28  9:27 ` sAwAr
2006-03-28 14:16 ` William L. Thomson Jr.
2006-03-28 14:59 ` Kirk Reiser
2006-03-28 15:10 ` William L. Thomson Jr.
2006-03-28 15:53 ` William L. Thomson Jr. [this message]
2006-03-28 16:58 ` sAwAr
2006-03-28 17:06 ` William L. Thomson Jr.
2006-03-28 17:55 ` sAwAr
2006-03-28 18:56 ` William L. Thomson Jr.
2006-03-28 19:37 ` sAwAr
2006-03-29  1:11 ` sAwAr
2006-03-29  4:08 ` William L. Thomson Jr.
2006-03-29 17:12 ` [LARTC] Load-banancing. two ip's from one isp - solution sAwAr
2006-03-29 18:18 ` William L. Thomson Jr.
2006-03-29 19:32 ` Szymon Mroofka
2006-03-29 19:47 ` William L. Thomson Jr.

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=1143561218.9467.12.camel@wlt.obsidian-studios.com \
    --to=wlt@obsidian-studios.com \
    --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.