|
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.155 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.155 up
>
> 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
> 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.
Wensong
> Jess and Jim
> bend.com
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|
