LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: arp problems

To: Alison Smith <alisonns@xxxxxxxxxx>
Subject: Re: arp problems
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Thu, 5 Jul 2001 20:50:56 +0300 (EEST)
        Hello,

On Thu, 5 Jul 2001, Alison Smith wrote:

> > value in
> > /proc/sys/net/ipv4/conf/all/hidden is set to 1 for the real-servers and 0
> > for the director.
>
>      all/hidden enables the feature and the flag also must be set to
> some device on the real servers where your VIPs reside. Is that true?
> ------------------
>
> Sorry!  I forgot to include that.
>
> yes -
> [arl@arlx044 arl]$  cat /proc/sys/net/ipv4/conf/eth1/hidden
> 1
> [arl@arlx044 arl]$
>
> is true on both real-servers.

        Then check whether the ARP probes come through eth1 in the
real server(s). The hidden flag does reply by definition to probes
coming from the same hidden device. It is explained in bad english in
proc.txt:

"Hide addresses attached to this device from another devices"

        By this way you can control the ARP in setups where the
Linux box has many NICs on same hub but in other setups this can
be done also with rp_filter. I recommend you using rp_filter even
for trusted devices. This avoids problems.

        The probes can be replied from eth1 when eth1/rp_filter=0
because eth1/hidden can't ignore probes coming from eth1.

        If the both NICs are on same hub (I assume so) then you
have to define the VIPs on device where the broadcast probes are
not received. In most of the LVS examples this is the "lo" device.
Then put your link route on eth1 but only with unique addresses.

> thanks,
> alison


Regards

--
Julian Anastasov <ja@xxxxxx>



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