Re: ip_vs & NAT

To: john@xxxxxxxxxxxxx
Subject: Re: ip_vs & NAT
Cc: "lvs-users@xxxxxxxxxxxxxxxxxxxxxx" <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Roberto Nibali <ratz@xxxxxx>
Date: Mon, 26 Feb 2001 09:52:04 +0100

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 lc
>   -> Masq    1      0          0
>   -> Masq    1      0          0
> TCP lc
>   -> Masq    1      0          0
>   -> 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 - the
> connection hangs. Like wise for apache. The machines are all on a switch -
> not a hub, if that matters.
>  I telnetted to 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 < > 
> 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 > > 
> 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 < > 
> 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 < > 
> 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 > > 
> 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 < > 
> 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

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

<Prev in Thread] Current Thread [Next in Thread>