|
Hello,
On Wed, 1 Nov 2000, Ard van Breemen wrote:
> Explanation:
> Machinelist:
> MACHINE MAC Real-IP Virtual IP Director IP
> router 0:d0:b7:26:b7:77 192.168.1.105/24
> machine1 0:d0:b7:b5:4:22 192.168.1.159/24 192.168.16.2/24 192.168.1.156/24
> machine2 0:d0:b7:b5:6:c2 192.168.1.160/24 192.168.16.2/24
> machine3 0:d0:b7:b5:3:e7 192.168.1.162/24 192.168.16.2/24
Hm, your setup is very interesting.
Here is my explanation why there is a problem with the
normal setup, i.e. when the gateway resolves VIP with ARP, not
your case. Your case requires using another logical network and
this is not always possible when the gateway is under ISP
control.
1. rfc826 - An Ethernet Address Resolution Protocol
Under "Packet Reception":
. ?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
. Yes:
. Swap hardware and protocol fields, putting the local
. hardware and protocol addresses in the sender fields.
. Set the ar$op field to ares_op$REPLY
. Send the packet to the (new) target hardware address on
. the same hardware on which the request was received.
The replies are send to the source hardware address. If not,
you have a loop sending ARP requests after each ARP request.
and later:
. probably have some reason to talk to A. Notice also that if an
. entry already exists for the <protocol type, sender protocol
. address> pair, then the new hardware address supersedes the old
. one. Related Issues gives some motivation for this.
Now look the ARP REQUEST from the real server:
> Real server3 arps router with source=VIP:
> 17:16:31.897060 0:d0:b7:b5:3:e7 ff:ff:ff:ff:ff:ff 0806 60: arp who-has
> 192.168.1.105 tell 192.168.16.2
The router has the right to replace the MAC address for
192.168.16.2 in its table with the new MAC address: 0:d0:b7:b5:3:e7
This will happen if your router has the 192.168.16.2 entry in
its neighbour table. Of course, not for your setup where 192.168.16 is
not defined in the gateway.
Again to rfc826:
. Related issue:
. ---------------
.
. It may be desirable to have table aging and/or timeouts. The
. implementation of these is outside the scope of this protocol.
. Here is a more detailed description (thanks to MOON@SCRC@MIT-MC).
And Linux has such timeouts, they are mentioned in
/usr/src/linux/Documentation/proc.txt:
locktime
An ARP/neighbor entry is only replaced with a new one if the old
is at least locktime old. This prevents ARP cache thrashing.
The default "locktime" in Linux is 100 (1 second).
And here is the explanation:
In your test all ARP issues happen at 17:16:31, so the 1 second period
is not expired and not possible to override the entry in the gateway
if it is already created (not for your setup where there is no entry
for 192.168.16.2).
So, why the other LVS users have ARP problem: because the
ARP requests from the real server can replace the VIP entry in the
gateway's neighbour table soon or later. The result will be rerouting
the traffic to the last real server resolving its gateway. You are lucky
the gateway does not ask for 192.168.16.2 and there is no entry for
this VIP in the neighbour table:
> Router looks for director:
> 17:16:31.896279 0:d0:b7:26:b7:77 ff:ff:ff:ff:ff:ff 0806 42: arp who-has
> 192.168.1.156 tell 192.168.1.105
> 17:16:31.896440 0:d0:b7:b5:4:22 0:d0:b7:26:b7:77 0806 60: arp reply
> 192.168.1.156 is-at 0:d0:b7:b5:4:22
This is the explanation why your setup is working and the
normal is not.
> --
> 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>
|
