LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Horm's method (REDIRECT)

To: Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: Horm's method (REDIRECT)
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Joseph Mack <mack@xxxxxxxxxxx>
Date: Fri, 14 Jan 2000 10:25:22 -0500 (EST)
On Fri, 14 Jan 2000, Julian Anastasov wrote:

> > 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).
> 
>       It must listen to 0.0.0.0 or to VIP. 

if the packet is processed locally, then this is not the
same thing as sending it to the lo device?

> For the software it
> seems that this IP is local. But there is some services which
> can make big troubles. They get the list of all local IP addresses
> from the kernel and bind to them. But with transparent proxy the VIP
> is not in this list!

why is the VIP not part of 0.0.0.0?

> > 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.
> 
>       Is it required that VIP must be configured on tunl0 ? 

I did this by testing (the results are in the HOWTO). For VS-Tun on 2.0.36
kernels the VIP can be on lo:0, dummy0 or tunl0 but with 2.2.x kernels the
VIP only works on a tunl0 device. With VS-DR on a 2.2.x kernel however the
VIP can be on lo:0, dummy0, tunl0, eth0:0 or eth1.

> Why?

no idea. I didn't understand it and when I asked on the list, I didn't get
a reply.

> May be the LVS documentation is incorrect too?

it will look a lot different after we understand this :-)

> 
>       You can try this setup for the real server:
> 
> - eth0 - REALIP
> - tunl0 - REALIP or another UNIQ IP

just did it. 
client, director, realservers all on 192.168.1.0/24 network

works if tunl0 is 1. 0.0.0.0, no entry for tunl0 in netstat
               or 2. IP=REALIP/255.255.255.0, 
                         netstat shows tunl0 routes the network REALIP/24
                         and eth0 routes the network REALIP/24
               or 3. UNIQIP/255.255.255.0
                         netstat shows tunl0 routes the network UNIQIP/24
            
 > - Transparent proxy for VIP
> 
>       The setup in the Director is same:
> 
> - eth0 - DIP
> - eth0:0 - VIP
> - VS/TUN -> REALIP
> 
>       The requirement is that the real server must accept
> connections destined for VIP. This is true when:
> 
> - VIP is local IP address (configured on any interface)
> - VIP is not local IP but we use Transparent proxy solution to
> accept connections. Very good solution!
> 
>       So, we must test these two variants for VS/TUN (we know that
> TRANSPARENT PROXY is working perfectly with VS/DR):
> 
> 1> With local VIP
> 
>       1.1> VIP on tunl0 interface, sorry, we can serve only
>       one VIP
> 
>               eth0 - REALIP
>               tunl0 - VIP, ARP problem => tunl0/hidden=1 (2.2.14)

this is the standard setup (with the arp problem handled)?

> 
>       1.2> We can serve many VIPs on 'lo' aliases or dummy
>       devices
> 
>               eth0 - REALIP
>               tunl0 - REALIP
>               lo:*/dummy* - VIP, ARP problem => lo/hidden=1 (2.2.14)
> 
>               Is this variant working? Can someone test it and
>               we can change the docs too.
>               I.e. the VS/TUN redirection for VIP to
>               REALIP?

can't test this right now, will try later
since you seem to understand this, what is the connection
between the VIP being on any device and tunl0 being on
the RIP and the IPIP packet having dst=VIP?

> 
> 2> No local VIP, use transparent proxy
> 
>       eth0 - REALIP
>       tunl0 - REALIP
>       -d VIP -j REDIRECT
> 
>       Again, not tested.

works (see above)

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>