|
sorry I have to rescind this!
The problem is occurring with all windows 2000 servers that we have but not
linux, presumably therefore nothing to do with LVS.
Muchly apologies again.
Mark
> -----Original Message-----
> From: lvs-users-admin@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:lvs-users-admin@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Mark Weaver
> Sent: 16 March 2002 07:17
> To: LVS Users
> Subject: problem with inktokmi
>
>
> 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
>
>
>
>
> _______________________________________________
> 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
>
|
