Re: Arp a problem?

To: Ard van Breemen <ard@xxxxxxxxxxxxxxx>
Subject: Re: Arp a problem?
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Mon, 30 Oct 2000 22:37:21 +0000 (GMT)

On Mon, 30 Oct 2000, Ard van Breemen wrote:

> Hi,
> In many of the howto-s, and other such documents, people are constantly
> refering to the arp-problem.
> I'm currently setting up a load balanced direct-routing scheme where
> each real-web-server can act as the load-balancer. Meaning: with 20
> web-servers (okay, only 4 around here), not only 19 webservers can die,
> but also 19 load balancers :).
> But in the current setup I did not find anything resembling the
> arp-problem.

        Read the docs again!

        The "ARP problem" has two parts:

1. The real servers must not answer for shared addresses (VIP)

        No ARP requests - no problem.

2. The real servers must send ARP requests with uniq source address

        These requests are usually for the director or the local

real server to all: who-has ROUTER/CLIENT tell VIP

        If you have static ARP entry for the default gateway and the
local clients in all real servers, you solve the 2nd problem. This
problem occurs usually with Linux 2.2+ real servers.

> My setup is this:
> All web-servers have their own IP's. Next to that, they all have the
> VIP's that are loadbalanced. The webserver doing the balancing also
> has an alias for the DIP. On the router the routeing to the VIP net
> is gatewayed to the DIP. So no arp-problems there.
> Actually: no machine is ever going to arp for the VIP. And when they
> still do, it can only be local traffic, and hence, it would not be
> a problem :).
> Now I have to fail-over the load-balancer, and choose a new
> load-balancer from many...

        I'm not sure whether you solve problem #2, you don't mention
how you avoid using ARP requests from the real servers.

> But for now: no crashes, no memory leaks. For 3 servers currently a
> top of 955 req/sec. No connection problems. Max. streaming speed:
> 9 MegaByte/s, which is actually the max of the switch, not of the
> systems...
> It runs rock-solid :)...

        Possible with ARP problem too.

> Future tests:
> A lot of editing the ipvsadm tables, and changing weight etc...
> --
> Ard van Breemen, T(elegraaf)E(lektronische)M(edia)


Julian Anastasov <ja@xxxxxx>

<Prev in Thread] Current Thread [Next in Thread>