|
> Al Kwiatkowski wrote:
> >
> > That makes sense, but the gateway routing entry is pointing to the right
> > place:
> >
> > netstat -nr of realserver:
> > Kernel IP routing table
> > Destination Gateway Genmask Flags MSS Window irtt
> > Iface
> > 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0
> > eth0
> > 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0
> > lo
> > 0.0.0.0 192.168.1.2 0.0.0.0 UG 40 0 0
> > eth0
>
> I assume 192.168.1.2 is your director here.
>
That's correct.
> > Would you say the issue is definitely with the realserver's settings, or
> > could the problem still lie with the director's forwarding of packets?
>
> You don't have the usual problem as shown by the output of ipvsadm.
> I don't know from here. You'll have to run tcpdump to see where the
> problem is.
>
Well, all tcpdump shows (to me - maybe I'm missing something?) is that the
initial TCP/IP packet gets through the director to the real server, who
for whatever reason doesn't send off a reply packet. Here's the tcpdump
output (at its most verbose) for the director:
NOTE: CIP=192.168.16.10, DIP=SGW=192.168.1.2, RIP=192.168.1.12
17:41:53.473160 192.168.16.10.3578 > 192.168.1.12.23: S
3673364109:3673364109(0) win 32120 <mss 1460,sackOK,timestamp 96620562[|tcp]>
(DF) (ttl 64, id 54820, len 60)
17:41:56.463160 192.168.16.10.3578 > 192.168.1.12.23: S
3673364109:3673364109(0) win 32120 <mss 1460,sackOK,timestamp 96620862[|tcp]>
(DF) (ttl 64, id 54826, len 60)
17:42:02.463160 192.168.16.10.3578 > 192.168.1.12.23: S
3673364109:3673364109(0) win 32120 <mss 1460,sackOK,timestamp 96621462[|tcp]>
(DF) (ttl 64, id 54831, len 60)
17:42:14.463160 192.168.16.10.3578 > 192.168.1.12.23: S
3673364109:3673364109(0) win 32120 <mss 1460,sackOK,timestamp 96622662[|tcp]>
(DF) (ttl 64, id 54837, len 60)
17:42:38.463160 192.168.16.10.3578 > 192.168.1.12.23: S
3673364109:3673364109(0) win 32120 <mss 1460,sackOK,timestamp 96625062[|tcp]>
(DF) (ttl 64, id 54842, len 60)
.
.
And here's the output on the realserver:
17:40:44.725218 192.168.16.10.3572 > 192.168.1.12.23: S
3580175695:3580175695(0) win 32120 <mss 1460,sackOK,timestamp 96619973[|tcp]>
(DF) (ttl 64, id 54809, len 60)
17:40:50.625218 192.168.16.10.3578 > 192.168.1.12.23: S
3673364109:3673364109(0) win 32120 <mss 1460,sackOK,timestamp 96620562[|tcp]>
(DF) (ttl 64, id 54820, len 60)
17:40:53.615218 192.168.16.10.3578 > 192.168.1.12.23: S
3673364109:3673364109(0) win 32120 <mss 1460,sackOK,timestamp 96620862[|tcp]>
(DF) (ttl 64, id 54826, len 60)
17:40:59.615218 192.168.16.10.3578 > 192.168.1.12.23: S
3673364109:3673364109(0) win 32120 <mss 1460,sackOK,timestamp 96621462[|tcp]>
(DF) (ttl 64, id 54831, len 60)
17:41:11.615218 192.168.16.10.3578 > 192.168.1.12.23: S
3673364109:3673364109(0) win 32120 <mss 1460,sackOK,timestamp 96622662[|tcp]>
(DF) (ttl 64, id 54837, len 60)
17:41:35.615218 192.168.16.10.3578 > 192.168.1.12.23: S
3673364109:3673364109(0) win 32120 <mss 1460,sackOK,timestamp 96625062[|tcp]>
(DF) (ttl 64, id 54842, len 60)
17:41:40.615218 arp who-has 192.168.1.12 tell 192.168.1.2
17:41:40.615218 arp reply 192.168.1.12 is-at 0:6:5b:ed:a:28
17:42:23.615218 192.168.16.10.3578 > 192.168.1.12.23: S
3673364109:3673364109(0) win 32120 <mss 1460,sackOK,timestamp 96629862[|tcp]>
(DF) (ttl 64, id 54866, len 60)
17:42:28.615218 arp who-has 192.168.1.12 tell 192.168.1.2
17:42:28.615218 arp reply 192.168.1.12 is-at 0:6:5b:ed:a:28
17:43:59.615218 192.168.16.10.3578 > 192.168.1.12.23: S
3673364109:3673364109(0) win 32120 <mss 1460,sackOK,timestamp 96639462[|tcp]>
(DF) (ttl 64, id 54919, len 60)
.
.
So it looks like the realserver isn't following up on the initial packet
it recieves. Might this be an issue with the TCP/IP parameters in the
realserver's kernel?
Al
|
