On Sun, 2007-06-10 at 19:14 +0300, Omar Al-Tabari wrote: > 1) I didn't allow me to do that
I didn't think it would :) > 2) changed that, at which point I couldn't access the machine remotely, That slightly odd, but see further down... > this is what the route table looked like: > C:\Documents and Settings\Administrator>route print > > IPv4 Route Table > =========================================================================== > Interface List > 0x1 ........................... MS TCP Loopback interface > 0x10003 ...00 0c 29 dc ca 1f ...... VMware Accelerated AMD PCNet Adapter > =========================================================================== > =========================================================================== > Active Routes: > Network Destination Netmask Gateway Interface Metric > 0.0.0.0 0.0.0.0 172.16.5.126 172.16.5.215 2 > 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 > 172.16.5.0 255.255.255.0 172.16.5.215 172.16.5.215 10 > 172.16.5.0 255.255.255.0 172.16.5.126 172.16.5.215 1 > 172.16.5.215 255.255.255.255 127.0.0.1 127.0.0.1 10 > 172.16.255.255 255.255.255.255 172.16.5.215 172.16.5.215 10 > 224.0.0.0 240.0.0.0 172.16.5.215 172.16.5.215 10 > 255.255.255.255 255.255.255.255 172.16.5.215 172.16.5.215 1 > Default Gateway: 172.16.5.126 > =========================================================================== > Persistent Routes: > None Which is what you would want, yes. > and also did this on the director: > echo 0 > /proc/sys/net/ipv4/conf/eth0/accept_redirects Aha! You want "/proc/sys/net/ipv4/conf/eth0/send_redirects" to be 0. Your director is probably still sending out redirects to the client and/or the realserver so may not be getting the full 3-way handshake and both ends of the conversation. > this is the output of "tcpdump -n -i eth0:1 port 80|grep 172.16.5.17": > 10:51:07.396645 IP 172.16.5.17.50791 > 172.16.5.215.http: S > 2000627253:2000627253(0) win 65535 <mss 1260,nop,nop,sackOK> > 10:51:07.402992 IP 172.16.5.215.http > 172.16.5.17.50791: S > 3830052267:3830052267(0) ack 2000627254 win 16384 <mss 1460,nop,nop,sackOK> > 10:51:07.404017 IP 172.16.5.17.50791 > 172.16.5.215.http: . ack 1 win 65535 > 10:51:07.404025 IP 172.16.5.17.50791 > 172.16.5.215.http: P 1:167(166) > ack 1 win 65535 > 10:51:07.621725 IP 172.16.5.215.http > 172.16.5.17.50791: . ack 167 win > 65369 > 10:51:09.156539 IP 172.16.5.215.http > 172.16.5.17.50791: P 1:201(200) > ack 167 win 65369 > 10:51:09.232508 IP 172.16.5.17.50791 > 172.16.5.215.http: . ack 201 win > 65335 > 10:52:56.544817 IP 172.16.5.215.http > 172.16.5.17.50791: R 201:201(0) > ack 167 win 0 > > still doing the same wrong thing it seems. I don't get you with this one. Summarising your tcpdump: 172.16.5.17.50791 > 172.16.5.215.http: SYN 172.16.5.215.http > 172.16.5.17.50791: SYN/ACK 172.16.5.17.50791 > 172.16.5.215.http: ACK 172.16.5.17.50791 > 172.16.5.215.http: PSH/ACK 172.16.5.215.http > 172.16.5.17.50791: ACK 172.16.5.215.http > 172.16.5.17.50791: PSH/ACK 172.16.5.17.50791 > 172.16.5.215.http: ACK 172.16.5.215.http > 172.16.5.17.50791: RST I'm assuming there that: 172.16.5.17 is the client 172.16.5.215 is the VIP eth0:1 is the interface alias on the director to which the VIP is bound If so, the above looks like a perfectly good transaction to me; the fact that you isolated the traffic so tightly with your dump on eth0:1, port 80 and grep means you're not seeing any additional traffic such as redirects or ICMP error messages. With everything "unloaded" - ie. only your test client involved - you need to run tcpdump on eth0 on the director (assuming it only has a single interface), not on eth0:1; don't just dump port 80, dump all traffic; and don't grep out the client alone. You need to see what the realservers are doing, too, to make sense of this. I'd also recommend using the "-q" option to tcpdump, it makes the dumps much easier to read :) You may want to run a similar dump on the realservers at the same time, for correlation (making sure the clocks are synchronised first). > 3) Does not allow this, I did add this though to the routing table: > 172.16.5.0 255.255.255.255 172.16.5.126 172.16.5.215 2 > > didn't do much good either way. No, it wouldn't. Graeme _______________________________________________ LinuxVirtualServer.org mailing list - [email protected] Send requests to [EMAIL PROTECTED] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
