|
On Thu, 28 Oct 1999, Michael Sparks wrote:
> On Thu, 28 Oct 1999, Joseph Mack wrote:
> >
> > VS-DR is similar to VS-TUN. The difference between the two is that in
> > VS-DR the director sends a packet to the MAC address of the realserver
> > rather than to the IP address
>
> Hmm. So I take it with this setup, as long as the machine is listening on
> some device (like the recommended loopback one :-) for the address listed
> the machine interprets it as it's own and then replies to it using that?
> (effectively)
there's a few more "it"s and "that"s in the last line for me to be sure
what you're asking so let's try another round...
client's IP = CIP
director's IP = DIP
realserver's IP = RIP
virtual IP = VIP
The director looks up its tables and decides to send a packet , source
=CIP dest=VIP, to a particular realserver with IP=RIP. The director arps
for the MAC address of RIP and sends a link-layer packet to that MAC
containing an IP datagram with source=CIP dest=VIP. The packet arrives at
the realserver, the realserver recovers the IP datagram, looks up its
routing table, the realserver finds that the VIP (on an otherwise unused,
non-arping and nonfunctional device) is local.
I'm not sure what exactly happens next (it differs from one OS to
another), but I believe the Linux tcpip stack then delivers the packet
locally rather than to the device with the VIP. Presumably "locally" means
"to a socket", but I'm out of my depth now.
The role of DR is to allow the director to deliver a packet with
destination = VIP (the only arp'ing VIP being on the director), not to
itself, but to some machine that (as far as the director knows) doesn't
have the VIP address at all. The only difference between VS-DR and VS-TUN
is that instead of putting the IP datagram inside a link-layer packet with
destination = MAC of the RIP, for VS-TUN the IPdatagram from the client
(source =CIP, dest=VIP) is put inside another IPdatagram with dest = RIP,
source=DIP.
The choice of lo:0 and tunl0 to hold the VIP for VS-DR and VS-TUN
(respectively) is historical. The only role this device plays is to allow
the realserver's routing table to have an entry for a local device with
IP=VIP _AND_ that other machines can't see (ie it doesn't reply to arp
requests). The dummy device doesn't arp with the 2.2.x kernels (you don't
have to patch 2.2.x realservers) and works for all combinations of 2.0.36
and 2.2.x kernels (on directors and realservers) and VS-DR and VS-TUN
(except one setup which I think was VS-TUN with realserver=2.2.x).
There is nothing particularly local about the lo:0 device anymore than
there is anything tunnelling about a tunl0 device (a tunnel packet is
de-capsulated because it is marked type=IPIP, and will be decapsulated if
delivered to an lo device just as well as if delivered to a tunl device)
Joe
--
Joseph Mack mack@xxxxxxxxxxx
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
