LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Horm's method (REDIRECT)

To: Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Horm's method (REDIRECT)
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Joseph Mack <mack@xxxxxxxxxxx>
Date: Tue, 11 Jan 2000 11:51:58 -0500 (EST)
        I'm trying to figure out the kernel transparent proxy and am about
to start putting printk statements into the code. Before I did I thought
I'd see if I had my assumptions right.

With VS-DR, if you run this script on a realserver which doesn't have the
VIP

VIP=192.168.1.110
PORT=80
/sbin/ipchains -A input -j REDIRECT $PORT -d $VIP $PORT -p tcp

then a packet with dst=VIP:PORT which arrives on the realserver (from the
director) will be processed locally (ie on the realserver).

My understanding of tcpip is this...

Without the REDIRECT and without the VIP on the realserver, a packet with
src=CIP,dst=VIP will be seen as destined for another machine and will be
forwarded according to the routing table.

With a (non-arping) VIP on the realserver, the tcpip layer will recognise
that the packet should be processed locally. The body of the packet will
be recovered, the src/dst saved to make the reply packet and the body of
the packet along with the port and IP sent to the socket layer. (The IP
information must be sent too, I imagine, as some demons eg httpd, must
send back a different reply for each IP on a multi-homed machine).

With the above REDIRECT and no VIP on the realserver, the instructions to
forward the packet are bypassed and the packet is processed locally.
Presumably the dst=VIP is saved for the reply. If the body is sent to an
httpd, what IP must the httpd be listening on for it to accept the
packet - 127.0.0.1, the VIP? (I can check this myself in a minute).

I was wondering if it would be possible to adapt Horms' REDIRECT for
VS-Tun to bypass the arp problem. With 2.0.36 kernels on the realserver
and an LVS running VS-Tun, the VIP can be on a lo:0 (or dummy0) device. I
presume this works because the incoming packet is recognised as being of
type IPIP and is decapsulated and it doesn't matter whether the packet
arrives on a tunl, dummy or lo device. With 2.2.x kernels the VIP must be
on a tunl (and not lo or dummy) device for VS-Tun to work. I don't know
why IPIP packets are treated differently in 2.0.36 and 2.2.x kernels.

I tried Horms' REDIRECT method with VS-Tun on a 2.2.x realserver and as I
expected it didn't work. Presumably the REDIRECT has to send the packet to
a tunl device for VS-Tun to work (any other way of getting an IPIP packet
processed?). That would mean another IP on the realserver (different IP to
the VIP so it can be an arping tunl device). This would mean that the
kernel transparent proxy code would have to be modified to change the IP
of the packet. I don't know enough to know wether this would work, as the
correct src/dst have to be saved for the reply packet. 

Anyone know if I'm on the right track?

thanks 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

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