From: Ard van Breemen <ard@kwaak.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] load sharing: ARP problem
Date: Wed, 20 Aug 2003 09:53:36 +0000 [thread overview]
Message-ID: <marc-lartc-106137619805893@msgid-missing> (raw)
In-Reply-To: <marc-lartc-106128930321985@msgid-missing>
On Tue, Aug 19, 2003 at 01:32:58PM +0100, Ojasi wrote:
> yes and sorry I forgot to mention that it is about load
> sharing of routing and not webserver.
Allright.
First of all: I cannot think of a case when a single linux box is
not fast enough to route. So I assume you have hit the wirespeed
in routing. Or your packets are plain to small. (Like haveing
about 130000 packets per second or so....)
> If I use same MAC addresses, then it will be a problem when
> there is a connection between switches. (that's why
> linux-bonding driver does not help in this case as it forces to
> use same MAC addresses)
Well, there you have the problem: how are you going to do
transparent route loadbalancing, if you don't want the switch to
co-operate?
> Also, I did not understand "configure your switch to have a lag
> on those ports...."
LAG is the IEEE term for bonding (linux), teaming (intel et
others), etherchannel (cisco), trunk (sun), etc...
It means that you have multiple ports acting as one big port...
But don't be fooled: having 4 ports does not mean you have
quadrepled your throughput: to make sure that packets are sent
in the right order, the switches use a hash: there is only on
route for a specific source-destination mac, it always goes out
over the same port.
> One ethernet switch connects all eth0 ports and other switch
> connects all eth1 ports as shown in figure in previous mail.
> So, could you please explain little more about how the
> configuration of switch to add lag should be used ?
Come to think of it: you can fix it:
You either have to answer arps using a hashing algorithm if that
is possible (I've seen some arp support in iptables now, but I
don't know if that works...).
If that does not work: you can use a multicast address for the
ip address (and yes, make them al the same), and use a blocking
mechanism on ip level...
Anyway: your tasks to figure out what is ok:
- learn what arp is al about: mac-address vs ip address
- Learn something about lag...
- Look at iptables if it supports blocking of arp-requests...
--
mail up 16:33, 7 users, load 0.00, 0.05, 0.04
mistar1 down 45+02:14
Let your government know you value your freedom: sign the petition:
http://petition.eurolinux.org
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2003-08-20 9:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-19 10:33 [LARTC] load sharing: ARP problem Ojasi
2003-08-19 11:00 ` Ard van Breemen
2003-08-19 12:32 ` Ojasi
2003-08-20 9:53 ` Ard van Breemen [this message]
2003-08-24 8:07 ` Bart De Schuymer
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=marc-lartc-106137619805893@msgid-missing \
--to=ard@kwaak.net \
--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.