LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

problem with inktokmi

To: "LVS Users" <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: problem with inktokmi
From: "Mark Weaver" <mark@xxxxxxxxxx>
Date: Sat, 16 Mar 2002 07:17:22 -0000
I am experiencing a problem with this particular proxy and LVS 0.9.10.
Basically, I only seem to get the SYN from the traffic server at the
webserver and nothing more.  No packets seem to be being dropped (I've tried
it with firewalling turned off and the firewall logs anyway - no logs,
nothing dropped).  The configuration is a simple balancing to a pair of
servers (but is the same to just one server), using ip_vs_rr as the
balancing algorithm with masquerading to a windows 2000 server.  With a
direct connection, the load balancing works fine.  I have tried removing the
ipvs modules and reinserting them with no effect, mainly out of desparation
:-).  Also, browsing to other sites that go through the same router but do
not use LVS works ok.

The via header is:

Via: HTTP/1.0 ntl_site (Traffic-Server/4.0.15-M-12744 [cHs f ])

and tcpdump reports:

07:15:13.912390 eth0 < 62.253.128.4.47781 > 213.239.16.135.http: S
3083483110:3083483110(0) win 16060 <mss 1460,sackOK,timestamp 141595107
0,nop,wscale 0> (DF)
07:15:13.912467 eth1 > 62.253.128.4.47781 > 10.80.80.5.http: S
3083483110:3083483110(0) win 16060 <mss 1460,sackOK,timestamp 141595107
0,nop,wscale 0> (DF)
07:15:13.912609 eth1 < 10.80.80.5.http > 62.253.128.4.47781: S
3836000080:3836000080(0) ack 3083483111 win 17520 <mss 1460,nop,wscale
0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)
07:15:13.912636 eth0 > 213.239.16.135.http > 62.253.128.4.47781: S
3836000080:3836000080(0) ack 3083483111 win 17520 <mss 1460,nop,wscale
0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)

07:15:16.905423 eth0 < 62.253.128.4.47781 > 213.239.16.135.http: S
3083483110:3083483110(0) win 16060 <mss 1460,sackOK,timestamp 141595407
0,nop,wscale 0> (DF)
07:15:16.905512 eth1 > 62.253.128.4.47781 > 10.80.80.5.http: S
3083483110:3083483110(0) win 16060 <mss 1460,sackOK,timestamp 141595407
0,nop,wscale 0> (DF)
07:15:16.905624 eth1 < 10.80.80.5.http > 62.253.128.4.47781: . 1:1(0) ack 1
win 17520 <nop,nop,timestamp 11490353 141595407> (DF)
07:15:16.905653 eth0 > 213.239.16.135.http > 62.253.128.4.47781: . 1:1(0)
ack 1 win 17520 <nop,nop,timestamp 11490353 141595407> (DF)

07:15:17.163295 eth1 < 10.80.80.5.http > 62.253.128.4.47781: S
3836000080:3836000080(0) ack 3083483111 win 17520 <mss 1460,nop,wscale
0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)
07:15:17.163316 eth0 > 213.239.16.135.http > 62.253.128.4.47781: S
3836000080:3836000080(0) ack 3083483111 win 17520 <mss 1460,nop,wscale
0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)

07:15:22.905528 eth0 < 62.253.128.4.47781 > 213.239.16.135.http: S
3083483110:3083483110(0) win 16060 <mss 1460,sackOK,timestamp 141596007
0,nop,wscale 0> (DF)
07:15:22.905611 eth1 > 62.253.128.4.47781 > 10.80.80.5.http: S
3083483110:3083483110(0) win 16060 <mss 1460,sackOK,timestamp 141596007
0,nop,wscale 0> (DF)
07:15:22.905730 eth1 < 10.80.80.5.http > 62.253.128.4.47781: . 1:1(0) ack 1
win 17520 <nop,nop,timestamp 11490413 141596007> (DF)
07:15:22.905757 eth0 > 213.239.16.135.http > 62.253.128.4.47781: . 1:1(0)
ack 1 win 17520 <nop,nop,timestamp 11490413 141596007> (DF)
07:15:23.726005 eth1 < 10.80.80.5.http > 62.253.128.4.47781: S
3836000080:3836000080(0) ack 3083483111 win 17520 <mss 1460,nop,wscale
0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)
07:15:23.726042 eth0 > 213.239.16.135.http > 62.253.128.4.47781: S
3836000080:3836000080(0) ack 3083483111 win 17520 <mss 1460,nop,wscale
0,nop,nop,timestamp 0 0,nop,nop,sackOK> (DF)

07:15:34.905656 eth0 < 62.253.128.4.47781 > 213.239.16.135.http: S
3083483110:3083483110(0) win 16060 <mss 1460,sackOK,timestamp 141597207
0,nop,wscale 0> (DF)
07:15:34.905738 eth1 > 62.253.128.4.47781 > 10.80.80.5.http: S
3083483110:3083483110(0) win 16060 <mss 1460,sackOK,timestamp 141597207
0,nop,wscale 0> (DF)
07:15:34.905831 eth1 < 10.80.80.5.http > 62.253.128.4.47781: . 1:1(0) ack 1
win 17520 <nop,nop,timestamp 11490533 141597207> (DF)
07:15:34.905858 eth0 > 213.239.16.135.http > 62.253.128.4.47781: . 1:1(0)
ack 1 win 17520 <nop,nop,timestamp 11490533 141597207> (DF)

Best I can tell from this, the server is sending the acknowledgment to the
SYN but the proxy is never receiving it.  No idea why as the tcpdump reports
the packet as having gone out - I can't see where it has been dropped on the
floor.  So I'm stumped - as I said, it works fine with a direct connection.

Any ideas as to what is going on here would be great!

Mark
_________________________________________________________________________
WebQMS - next generation server monitoring, management and hotfixing.

For a 14 day free trial and more information: http://www.highopinions.com





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