|
On Mon, 22 Nov 1999, Stephen D. Williams wrote:
> Great exhaustive work! Putting the MAC address of the DR LVS as a permanent
> entry in the server arp tables sounds like a good alternative to the patch.
> You end up with an extra reply from each server, but that shouldn't be a
> problem.
Actually I'm putting the MAC address of the director's VIP into the
incoming router (or in my case the test client) and leaving everything
else alone.
My setup works no matter what I do as it seems like the director always
replies to arp requests first, so I'd be interested in confirmation that
this works for someone else before unleashing it on the unwitting public.
Are you saying that the realservers need to have the MAC address of the
director's VIP too?
> Of course the ARP code in the kernel really does need to be fixed.
yes
> Another reason you still might need the patch, and probably the newest one
> that I haven't made public yet, is if you have two ethernet interfaces. The
> 2.2.* kernels up to at least 2.2.13 will allow multiple ethernet interfaces
> to arp for each other, sending the traffic back and forth and wasting the
> interfaces. I really wonder if this is an issue in some of the Linux vs. NT
> benchmarks.
One of the setups I tested was with the realserver VIP on a 2nd NIC (these
are the eth1 columns) where the LVS worked whether the VIP had a
route/no_route to it in the realserver's netstat -rn table, or whether it
had a cable connected to it or not. I didn't watch to see if any of these
cards were arp'ing.
Joe
--
Joseph Mack mack@xxxxxxxxxxx
|
