|
Hi,
Just some more comments, although Julian already said it.
"John P . Looney" wrote:
>
> I have a few machines running apache & mysql behind a router running ipvs.
>
> The router masquerades the connections, like so;
>
> TCP 172.24.51.1:www lc
> -> evilwillow.sunnydale.antefacto.com:www Masq 1 0 0
> -> goodwillow.sunnydale.antefacto.com:www Masq 1 0 0
> TCP 172.24.51.6:mysql lc
> -> evilwillow.sunnydale.antefacto.com:mysql Masq 1 0 0
> -> goodwillow.sunnydale.antefacto.com:mysql Masq 1 0 0
>
> It works fine. External apps can get to these machines. However,
> the router and the two machines above can't get to 172.24.51.6:mysql - the
> connection hangs. Like wise for apache. The machines are all on a switch -
> not a hub, if that matters.
>
> I telnetted to 172.24.51.1:www from "evilwillow", and did a tcp dump on
> the ipvs machine, and saw;
Could you please next time send such outputs in readable form, e.g.
numeric? ipvsadm -L -n and tcpdump -n are much more preferred then
if I first have to run the mail through a sed to get it in a readable
form. And if possible also all versions and configs (kernel, ipvsadm,
forwarding method)
As you can see, the counter in the active_conns is 1 and I bet it would
stay there for quite a long time in your tests. This is typical for:
o not handling the arp-problem properly
o trying to connect to the VIP from one of the nodes inside the LVS-cluster
You have to accept that due to the policy the packets get forwarded
in a LVS-cluster you cannot, never ever, connect to the VIP from a
node inside a LVS-cluster (normally defined as RS and LB itself).
This is in the HOWTO but I can't find it right now ;)
> User level filter, protocol ALL, datagram packet socket
> tcpdump: listening on all devices
Wow, did you compile the new tcpdump? This must be a new feature,
listening on all devices.
> 16:25:20.567319 eth0 < goodwillow.sunnydale.antefacto.com.1926 >
> evilwillow.sunnydale.antefacto.com.www: S [ECN-Echo,CWR]
> 3633840634:3633840634(0) win 5840 <mss
Hmmm, you stated that you're using LVS-NAT with LVS patch 1.0.5.
How the hell does this ECN flag come into your stream ?? Are your
RS running kernel 2.4.x?
1460,sackOK,timestamp 17852294 0,nop,wscale 0> (DF)
> 16:25:20.567775 eth0 > evilwillow.sunnydale.antefacto.com.www >
> goodwillow.sunnydale.antefacto.com.1926: S [ECN-Echo]
> 3634986324:3634986324(0) ack 3633840635 win 5792 <mss 1460,sackOK,timestamp
> 17521934 17852294,nop,wscale 0> (DF)
> 16:25:20.567890 eth0 < goodwillow.sunnydale.antefacto.com.1926 >
> evilwillow.sunnydale.antefacto.com.www: R 3633840635:3633840635(0) win 0 (DF)
Oh yes, this RST says it all: you're connecting to the VIP fom
a node inside the LVS-cluster.
> 16:25:23.564060 eth0 < goodwillow.sunnydale.antefacto.com.1926 >
> evilwillow.sunnydale.antefacto.com.www: S [ECN-Echo,CWR]
> 3633840634:3633840634(0) win 5840 <mss 1460,sackOK,timestamp 17852594
> 0,nop,wscale 0> (DF)
Oups, we're going back in time? Is this a feature of the new
tcpdump listening on all interfaces?
> 16:25:23.564139 eth0 > evilwillow.sunnydale.antefacto.com.www >
> goodwillow.sunnydale.antefacto.com.1926: S [ECN-Echo]
> 3637982691:3637982691(0) ack 3633840635 win 5792 <mss 1460,sackOK,timestamp
> 17522234 17852594,nop,wscale 0> (DF)
> 16:25:23.564229 eth0 < goodwillow.sunnydale.antefacto.com.1926 >
> evilwillow.sunnydale.antefacto.com.www: R 3633840635:3633840635(0) win 0 (DF)
>
> That looks like the machines are talking. But, I keep getting "connection
> refused". Is there something special you need to do when both machines
Yes, this is because of the RST and this is because the packet look
forged.
> from outside a cluster and inside a cluster have to access HA services ?
Yes, don't do it from inside ;)
Best regards,
Roberto Nibali, ratz
--
mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
|
