|
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
|
