LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Source IP address

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: Source IP address
From: Horms <horms@xxxxxxxxxxxx>
Date: Tue, 28 Nov 2000 11:52:46 -0500
On Tue, Nov 28, 2000 at 11:39:47AM -0500, Nathan Polonski wrote:
> I'm currently using a Piranha based LVS system. NAT configuration, kernel
> 2.2.17 with patches. VS patch 1.0.0.
> 
> The main use of the system is ftp. The system is to be behind a firewall and
> I have run into an interesting problem. 
> In my testing I have found that the source IP address of some of the "load
> balanced" data does not come from the VIP, but from the IP address of one of
> the directors. 
> 
> If I open up an FTP connection to my cluster, all of the packets are sent to
> and come from the VIP. Data looks good. However, when I try to run an "ls"
> or "dir" command against the FTP server, I get a "Cannot build Data
> Connection" error. 
> My packet sniffing has shown me that all of the data going to and from the
> cluster is addressed to the VIP.
> This holds true, up until the directory listing request. 
> When I run either command, packets come from the IP address of the active
> LVS director. 
> 
> Is this supposed to happen? Does anyone know why it happens. 
> I'm sure there is a plausible explanation. 

The problem is that when you do an ls your client tries to open
another connection to the ftp server, the VIP. The Linux Director
is allocating that connection to a different real server to the
original control connection, that real server isn't listening for
the data conenction. boom.

From the near to latest revision of the ipvsadm man page:

              Note: If a virtual service is to handle FTP connec-
              tions then persistence must be set for the  virtual
              service  if  Direct  Routing  or NAT is used as the
              forwarding mechanism. If masquerading  is  used  in
              conjunction with an FTP service than persistence is
              not necessary, but the  ip_masq_ftp  kernel  module
              must be used.  This module may be manually inserted
              into the kernel using insmod(8).



Of course reading that I notice a bug, "NAT" should read "Tunnelling".

Wensong can you update the tree.

Thanks


-- 
Horms


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