[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-virtual-server
Subject:    Re: [lvs-users] question about LVS
From:       Michiel van Es <mve () pcintelligence ! nl>
Date:       2010-05-11 8:41:06
Message-ID: 4BE91822.8090500 () pcintelligence ! nl
[Download RAW message or body]

Hello: a small but important update on this issue:

I finally got it working:
The problem was that server1 was on a different host (XEN server) then 
the loadbalancer and server2.
Perhaps there is a problem with bridging and XEN server (version 4).
Moving the server1 vps to the same VPS Host as the load balancer and 
server 2 fixed my problem and LVS is working perfectly!

I don't know how to fix this on the XEN host servers but perhaps someone 
else has this issue and know how to fix this.

A small but important note for LVS users on VPS systems.

Kind regards,

Michiel

-------- Original Message --------
Subject: Re: [lvs-users] question about LVS
From: mve@pcintelligence.nl
To: leon@linux.nl
Date: 05/04/2010 09:35 PM

>> On Tue, 2010-05-04 at 20:30 +0200, mve@pcintelligence.nl wrote:
>>>> Please post the bash script you're using to setup the loopback device
>>>> etc. so i can take a look and maybe adjust it.
>>>
>>> echo "0">/proc/sys/net/ipv4/ip_forward
>>> cat       /proc/sys/net/ipv4/ip_forward
>>> echo 1>  /proc/sys/net/ipv4/conf/eth0/arp_ignore
>>> echo 2>  /proc/sys/net/ipv4/conf/eth0/arp_announce
>>> echo 1>  /proc/sys/net/ipv4/conf/all/arp_ignore
>>> echo 2>  /proc/sys/net/ipv4/conf/all/arp_announce
>>> /sbin/ifconfig lo:110 194.145.200.87 broadcast 194.145.200.87 netmask
>>> 0xffffffff up
>>> /sbin/ifconfig lo:110
>>> /sbin/route add -host 194.145.200.87 dev lo:110
>>>
>>> I also run this script on server2 in exact the same way.
>>
>> Looks okay to me.
>
> Ok..thanks for checking.
>
>>
>>> When I stop Iptables orflush them the reaction from the client is
>>> different(as stated before).
>>>
>>> With iptables on:
>>> [root@knox01 ~]# telnet 194.145.200.87 25
>>> Trying 194.145.200.87...
>>> telnet: connect to address 194.145.200.87: No route to host
>>> telnet: Unable to connect to remote host: No route to host
>>> [root@knox01 ~]# telnet 194.145.200.87 25
>>>
>>> With iptables off (service iptables stop) on server1:
>>> (takes a long time)
>>> Nothing happens:
>>> root@knox01 ~]# telnet 194.145.200.87 25
>>> Trying 194.145.200.87...
>>
>> Just realising something. Have you configured the mailserver service on
>> the failing realserver to listen on _all_ interfaces? To be sure,
>> compare the output of:
>>
>> $ netstat -tulpen | grep 25
>
> Both servers are the same (0.0.0.0:25)
>
>>
>> on both realservers.
>>
>>
>>> Could I run some tcpdumps on real servers and LVS dr to check what is
>>> going wrong?
>>
>> Running tcpdump never hurt anyone :)
>>
> What kind of tcpdump should I do on the real servers and perhaps load
> balancer?
> (a tcpdump -n | grep *dest ip* | grep smtp gives too much output)
> Here is where my expertise lacks.. :(
>
>>
>> Léon
>>
>
> Michiel
>
>>

>
>
>
> _______________________________________________
> Please read the documentation before posting - it's available at:
> http://www.linuxvirtualserver.org/
>
> LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
> Send requests to lvs-users-request@LinuxVirtualServer.org
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users

_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

[prev in list] [next in list] [prev in thread] [next in thread]