LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Fw: ipvs / LVS-DR / LVS-TUN problems

To: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Fw: ipvs / LVS-DR / LVS-TUN problems
From: "listgetter" <listgetter@xxxxxxxx>
Date: Thu, 18 Oct 2001 15:04:20 -0700
 
----- Original Message -----
From: Jim Lucas
Sent: Thursday, October 18, 2001 12:58 PM
Subject: ipvs / LVS-DR / LVS-TUN problems

Nope, didn't work.
 
If you could, could you tell us why you use the commands you do? 
Not being knowledgable about what the route command does, is not helping here.
 
>
>On Tue, 16 Oct 2001 listgetter@xxxxxxxx wrote:
>
>> Here is our situation:
>> We have a network block of public ip's that range from x.x.x.128 to
>> x.x.x.159.
>> We are wanting to setup LVS-TUN so we can distribute the load of our
>> website between two machines.
>> Which the first machine, the director, is going to be a local node.
>>
>> gargamel: running with kernel 2.4.12, IP = x.x.x.155, running ipvsadm
>> software.
>>
>> smurfette: running with kernel 2.4.5, IP = x.x.x.147
>>
>> Both machines have been patched with linux-2.4.5-ipvs-0.8.1.patch.gz and
>> hidden-2_4_5-1_diff.
>>
>> The first way we set it up was this:
>>
>> Director Setup
>> gargamel# /sbin/ipvsadm -A -t x.x.x.155:80 -s wlc
>> gargamel# /sbin/ipvsadm -a -t x.x.x.155:80 -r 127.0.0.1 -i -w 1
>> gargamel# /sbin/ipvsadm -a -t x.x.x.155:80 -r x.x.x.147 -i -w 1
>> gargamel# echo 1 > /proc/sys/net/ipv4/ip_forward
>
>It is wrong to configure the following block.
>
>====>BEGIN-OF-BLOCK
>> gargamel# /sbin/insmod ipip
>> gargamel# /sbin/ifconfig tunl0 x.x.x.155 netmask 255.255.255.224 broadcast
>> x.x.x.159 up
>> gargamel# /sbin/route add -host x.x.x.155 dev tunl0
>> gargamel# echo 1 > /proc/sys/net/ipv4/conf/all/hidden
>> gargamel# echo 1 > /proc/sys/net/ipv4/conf/tunl0/hidden
>====>END-OF-BLOCK
>
>Do the following command instead
>
>ifconfig eth0:1 x.x.x.155 netmask 255.255.255.255 broadcast x.x.x.159 up
 
Why do we need to set this up?
What purpose will this device serve?
 
>
>>
>> Real Server Setup
>> smurfette# echo 1 > /proc/sys/net/ipv4/ip_forward
>> smurfette# /sbin/insmod ipip
>> smurfette# /sbin/ifconfig tunl0 x.x.x.147 netmask 255.255.255.224 broadcast
>> x.x.x.147 up
>
>ifconfig tunl0 x.x.x.155 netmask 255.255.255.255 broadcast x.x.x.155 up
>route add -host x.x.x.155 dev tunl0
 
with this, it would be nice if we understood what route did/does...
 
>
>> smurfette# /sbin/route add -host x.x.x.147 dev tunl0
>> smurfette# echo 1 > /proc/sys/net/ipv4/conf/all/hidden
>> smurfette# echo 1 > /proc/sys/net/ipv4/conf/tunl0/hidden
>>
>> With this we have not been able to get either machine to pass back a web
>> page.
>>
>>
>> The way we think it works, is that the director receives a packet on
>> x.x.x.155:80, and schedules the packet for either itself or smurfette. At
>> that point we're not certain if LVS will encapsulate the packet itself and
>> then deliver to x.x.x.147, or if it will want to use an IP-tunneling
>> interface that we've already set up. One of the reasons we suspect that LVS
>> doesn't do the encapsulation step internally is because we haven't seen
>> anywhere that tells LVS if it is running in TUN or NAT mode, so we're
>> assuming that those distinctions are in the environment setup, and do not
>> affect LVS's internal operations. We're also not certain how such an
>> interface works, our background with ifconfig is limited to configuring an
>> ethernet adapter for more than one IP :(. We're not even sure how we'll
>> convince Smurfette to decapsulate the incoming packets.
>>
>> One of the biggest reasons that we can't just tinker and figure these
>> things out for ourselves is that when the director isn't talking to the
>> realservers, we don't have a way to diagnose where the problem is (or if
>> it's the tunnel, whats the matter with it). I don't think we can set up
>> tcpdump to identify encapsulated packets for instance.
>>
>> So I guess that outlines where our situation is. If anybody help us down
>> the path to enlightenment, it would greatly be appreciated :)
>>
>
>Finally, browse http://x.x.x.155/ on the third machine. It should work.
 
you mean from the local machine or from the net?  It doesn't seem to work either way.
 
Sorry to be such a pain, but we cannot find any online documentation or information in OS manuals about these technologies such as ip tunneling, exotic routing rules.
 
>
>Wensong
>
>> Jess and Jim
>> bend.com
 
 
 
 
<Prev in Thread] Current Thread [Next in Thread>
  • Fw: ipvs / LVS-DR / LVS-TUN problems, listgetter <=