|
Hello,
On Fri, 3 Nov 2000, Ard van Breemen wrote:
> Some investigation revealed however that in the normal setting up,
> the real-servers can use the VIP on the ip level when connecting to
> outside. Using the ip tool instead of ifconfig and route reveals why:
> On every route we can define the preferred IP-source ourselves. In
> this case somehow (with network IP reconfigurations, putting real-ip
> (i.e. not the 192.168 range) addresses on the "primary" interface) the
> VIP became the preferred source address. But reading the IP manual
> revealed that setting up preferred source addresses is really easy:
> ip route change ..... src realserver-ip. In the case we are setting
> up it is not necessary because on the realserver, the kernel sees
> that both the DIP and the VIP are secondary addresses of the primary
> real-server ip and hence will not be used as source-ip. Only the
Oh, yes, this is a known issue, handled from hidden=1:
Documentation/proc.txt:
hidden
Hide addresses attached to this device from another devices.
Such addresses will never be selected by source address autoselection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
mechanism, host does not answer broadcast ARP requests for them,
^^^^^^^^^
does not announce it as source address of ARP requests, but they
are still reachable via IP. This flag is activated only if it is
enabled both in specific device section and in "all" section.
> router will think that the VIP is not directly acccesible, but in fact,
> every local system can reach it directly (in the same subnet).
> Arping the VIP is not a problem now, but a mere tool to see which hosts
> are up and useable for loadbalancing for that particular VIP :).
> --
> Ard van Breemen, T(elegraaf)E(lektronische)M(edia)
> http://www.faqs.org/rfcs/rfc1855.html
> **THIS E-MAIL MESSAGE IS VIRUS FREE BY COMPLYING TO THE ASCII STANDARD**
Regards
--
Julian Anastasov <ja@xxxxxx>
|
