LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Syn SynAck SynAck Reset Reset

To: Karl <karl.mueller@xxxxxxxxxxxxxx>
Subject: Re: Syn SynAck SynAck Reset Reset
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Sat, 2 Sep 2000 09:23:57 +0000 (GMT)
        Hello,

On Fri, 1 Sep 2000, Karl wrote:

> I'm stuck..
>
> I have 2 real servers, 1 LVS running ldirectord.
> I am using wlc to schedule, w/ persistence.  I am using masq for routing
> etc.
>
> I want to add a third server and I'm having some problems.  Here is a
> trace from the LVS (watto is my workstation)
>
> >>>> 11:25:51.676684 eth1 > watto.asynchrony.com.3449 > 
> >>>> web3.asynchrony.com.https: S 1486189652:1486189652(0) win 32120 <mss 
> >>>> 1460,sackOK,timestamp 9074700 0,nop,wscale 0> (DF) (ttl 63, id 35494)
> >>>> 11:25:51.676848 eth1 < web3.asynchrony.com.https > 
> >>>> watto.asynchrony.com.3449: S 1404060072:1404060072(0) ack 1486189653 win 
> >>>> 32120 <mss 1460,sackOK,timestamp 330940 9070200,nop,wscale 0> (DF) (ttl 
> >>>> 64, id 6122)
> >>>> 11:25:51.676878 eth0 > web3.asynchrony.com.https > 
> >>>> watto.asynchrony.com.3449: S 1404060072:1404060072(0) ack 1486189653 win 
> >>>> 32120 <mss 1460,sackOK,timestamp 330940 9070200,nop,wscale 0> (DF) (ttl 
> >>>> 63, id 6122)
> >>>> 11:25:51.677009 eth0 < watto.asynchrony.com.3449 > 
> >>>> web3.asynchrony.com.https: R 1486189653:1486189653(0) win 0 (ttl 255, id 
> >>>> 35495)
> >>>> 11:25:51.677052 eth1 > fw-199.asynchrony.com.62109 > 
> >>>> web3.asynchrony.com.https: R 1486189653:1486189653(0) win 0 (ttl 254, id 
> >>>> 35495)
>
> from the client browser, no data is ever received (It does work if you
> avoid the LVS).  I've checked my ipchains ruleset and I've checked the

        There is something broken in your setup but from the
information provided we can't understand the problem. You have to
show the network topology. May be the client and the real server
can talk directly avoiding the director. Don't forget that the
external IP can be accessed from the internal side but that doesn't
mean the masquerading is used in this case. The masquerading is
used only from external clients, i.e. clients that are reached
through the masq box via forwarding. But LVS always demasquerades.
This can be a good reason to work without LVS and not to work
with LVS.

> tcpip config in /proc against a working web server, and everything looks
> good to me.  Any suggestions where to go next ?

        More information, please. This is a problem in your
setup/test.

>
> btw:  the working server is running on RH 6.1, the new one is running on
> RH 6.2.  I know there are some arping issues if you are using LVS-DR,
> but I'm not.  I use MASQ.

        MASQ has other issues :) The in and out traffic must reach
the director.


Regards

--
Julian Anastasov <ja@xxxxxx>



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