From: Martin <mylists@itcom.com.ar>
To: Grant Taylor <gtaylor@riverviewtech.net>
Cc: Mail List - Netfilter <netfilter@vger.kernel.org>
Subject: Re: load balance [OT?] [Solution]
Date: Mon, 30 Jun 2008 12:34:31 -0300 [thread overview]
Message-ID: <1214840071.19463.112.camel@kr0sty> (raw)
In-Reply-To: <4868ED10.3020506@riverviewtech.net>
On Mon, 2008-06-30 at 09:26 -0500, Grant Taylor wrote:
> On 06/30/08 08:32, Martin wrote:
> > That's right, the ping part is to keep gateways in the arp table, so
> > arpinging them'd be the same as normal ping for the case. Probably (I
> > didn't tested it) adding MAC and IP with arp should work too.
>
> (See below.)
>
> > May be I'm missing something, but what do you mean with "kernel's
> > DGD"?
>
> DGD or Dead Gateway Detection, is a mechanism built in to the kernel
> that allows the kernel to detect if a gateway / router to a given (set
> of) destination(s) is no longer functioning and subsequently fall back
> to a different gateway.
>
> I have had the following test network in place and experienced failures
> using standard pings in a very weird way.
>
>
> +-----+ A.1 A.2 +-----+
> C.254 | 0+-----(Switch)-----(Switch)-----+0 | D.254
> -------+1 A | | B 1+-------
> | 2+-------------------------------+2 +
> +-----+ B.5 B.6 +-----+
>
> (Think of this configuration as two separate buildings (C & D) with two
> different connections tying them together, one slow wireless (B) and one
> new Metro Ether (A). As far as the A and B systems are concerned these
> are just simple ethernet connections.)
>
> I had the above scenario set up between two buildings with the A system
> pinging both of the B systems interfaces (A.2 and B.2). If I
> disconnected the cable connecting between the two switches both system A
> and B would still have link between them selves and their respective
> switch, however the channel between the two systems would be non functional.
>
> After about 45 - 90 seconds (depending on how tings were configured) the
> kernels on either system would realize that the link between systems A
> and B using the A (Metro Ether) network was down and fall back to
> routing all traffic out over the B (wireless) network. So when system A
> pinged the A.2 interface on the B system the traffic would go out across
> the wireless network, loop through the B system and hit the A.2
> interface on the B system.
>
> Where as if I used arping to do the testing, the kernel's routing table
> (and thus DGD) was ignored giving an accurate test of the link state
> even if the kernel had routed around the link failure between the switches.
>
> (The above configuration used a stock kernel with two equal routes
> (metric of 0) entered in reverse priority to get things to work.)
Well, I don't know if understood it ok, but I'll try to answer it.
Ping work pretty well for me. Ping each gateway and if them responds and
if them are not saturated, load balance works great.
If one gateway doesn't responds or it's saturated, traffic switch to the
other interface.
About the loop, if one of the gateways goes down, but it still responds
because it passes traffic between both nics internally in servers, you
can test some things.
1) try to block traffic between cards with "iptables -i eth1 -o
eth2" (not tested, but it can work)
2) do it with ip route. Configure each card with a route and a ip range
different to each one. Do it in a different table and play with some
prohibit rules. You can make an idea with this document:
http://ssi.bg/~ja/nano.txt
3) need the servers connected go further than themselves? If not you can
set off ip_forward.
Please, keep us updated about your tests or if you can solve it. May be
a different thread would be better to keep a track of this.
Cheers
Martin
next prev parent reply other threads:[~2008-06-30 15:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-26 15:05 load balance [OT?] [Solution] Martin
2008-06-29 2:00 ` Grant Taylor
2008-06-30 13:32 ` Martin
2008-06-30 14:26 ` Grant Taylor
2008-06-30 15:34 ` Martin [this message]
2008-06-30 15:58 ` Grant Taylor
2008-06-30 16:26 ` Martin
2008-06-30 17:51 ` Grant Taylor
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=1214840071.19463.112.camel@kr0sty \
--to=mylists@itcom.com.ar \
--cc=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