|
Yes, RTFM! ;-) Thanks for the tip - loading the ip_vs_ftp module did help
passive to work properly. In addition to www, I have also gotten telnet and
ssh working with no problems. I am seeing some strange ftp behavior,
however.
Regardless of the ftp client I use, it always takes 5 minutes and 23 seconds
to transfer a file.When using the standard ftp client, it will say
"connected to <VIP>", but I do not get a login prompt until 5:23 later.
Once the prompt is there, file transfers happen immediately. It takes the
same amount of time for an ncftpget to return, but the file does transfer
properly once it does. I thought I would try doing static NAT without using
ipvs at all (even unloaded the ip_vs* modules) for one of the real servers
to see if any of iptables/netfilter code could be causing this delay. With
static NAT to one real servers, transfers happen instantaneously. It seems
the delay must be related to ipvs or possibly masquerading somehow.
All other services (www/telnet/ssh) work properly with no delays and none of
my tcpdumps on the ftp sessions show anything obvious. Does anyone have a
clue as to what could delay an FTP by exactly 5:23 every time?
Thanks in Advance!
Regards,
Jon
----- Original Message -----
From: "Jon Burford" <jburford@xxxxxxxxxxx>
To: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, March 15, 2001 1:16 PM
Subject: FTP
> OK, I have been tinkering with FTP load balancing and have had no luck.
My
> setup is:
>
> 2.4.0 kernel cleanly patched with the 4 diff files included with
ipvs-0.2.5
> iptables 1.2
>
> eth0:1 = 10.1.10.11/16
(aliased
> VIP)
> eth0=10.1.10.1/16
> --------------
> | FW |
> --------------
> eth1=192.168.10.1
> |
> -----------------------
> | |
> eth0=192.168.10.11 eth0=192.168.10.12
> ----------- -----------
> | FTP1 | | FTP2
|
> ------------ -----------
>
> I have intentionally made my iptables and ipvsadm rules as simple as
> possible since I
> am just testing things on an internal net (as indicated by the
addressing).
> My iptables
> and ipvsadm setup is:
>
> modprobe iptables
> modprobe iptable_nat
> modprobe ipt_MASQUERADE
> modprobe ip_conntrack
> modprobe ip_nat_ftp
> modprobe ip_conntrack_ftp
> insmod ip_vs.o
> insmod ip_vs_rr.o
>
> iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0:1 -j MASQUERADE
> ipvsadm -A -t 10.1.10.11:ftp -s rr
> ipvsadm -a -t 10.1.10.11:ftp 192.168.10.11:21 -m -w 1
> ipvsadm -a -t 10.1.10.11:ftp 192.168.10.12:21 -m -w 1
>
>
> VERIFICATION:
>
> # lsmod
> Module Size Used by
> iptable_filter 1856 0 (autoclean) (unused)
> ip_vs_rr 1472 1
> ip_vs 63168 2 [ip_vs_rr]
> ipt_MASQUERADE 2016 0
> iptable_nat 19296 0 [ipt_MASQUERADE]
> ip_conntrack 23008 1 [ipt_MASQUERADE iptable_nat]
> ip_tables 13568 5 [iptable_filter ipt_MASQUERADE
> iptable_nat]
> 3c59x 24416 2 (autoclean)
>
> # iptables -t nat -L -n
> Chain PREROUTING (policy ACCEPT)
> target prot opt source destination
>
> Chain POSTROUTING (policy ACCEPT)
> target prot opt source destination
> MASQUERADE all -- 192.168.10.0/24 0.0.0.0/0
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
>
>
> # ipvsadm
> IP Virtual Server version 0.2.5 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP 10.1.10.11:ftp rr
> -> 192.168.10.12:ftp Masq 1 0 0
> -> 192.168.10.11:ftp Masq 1 0 0
>
> # ifconfig
> eth0 Link encap:Ethernet HWaddr 00:01:03:2A:70:67
> inet addr:10.1.10.1 Bcast:10.1.255.255 Mask:255.255.0.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:45895 errors:0 dropped:0 overruns:1 frame:0
> TX packets:11111 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> Interrupt:9 Base address:0xb800
>
> eth0:1 Link encap:Ethernet HWaddr 00:01:03:2A:70:67
> inet addr:10.1.10.11 Bcast:10.1.255.255 Mask:255.255.0.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> Interrupt:9 Base address:0xb800
>
> eth1 Link encap:Ethernet HWaddr 00:01:03:2A:70:3C
> inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:30312 errors:0 dropped:0 overruns:1 frame:0
> TX packets:2043 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> Interrupt:9 Base address:0xb400
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16192 Metric:1
> RX packets:12 errors:0 dropped:0 overruns:0 frame:0
> TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
>
>
> I have tried FTP with static NAT through the firewall for each of the FTP
> boxes individually, and the FTP works in both port and passive. All I
want
> to do is load balance for passive FTP with these boxes. I use a client
> machine (kilauea=10.1.0.105/16) to do the ftp and the client hangs after a
> connection initiation is attempted. I did a tcpdump to observe the first
> few packets exchanged on the CLIENT, FW and FTP machines. Here is what
they
> look like:
>
> CLIENT:
> 13:04:26.824618 eth0 > kilauea.office.xsilogy.com.3037 > 10.1.10.11.ftp: S
> 23805
> 66213:2380566213(0) win 32120 <mss 1460,sackOK,timestamp 26965479
> 0,nop,wscale 0
> > (DF)
> 13:04:26.824917 eth0 < 10.1.10.11.ftp > kilauea.office.xsilogy.com.3037: S
> 30263
> 01749:3026301749(0) ack 2380566214 win 5840 <mss 1460> (DF)
> 13:04:26.824959 eth0 > kilauea.office.xsilogy.com.3037 > 10.1.10.11.ftp: .
> 1:1(0
> ) ack 1 win 32120 (DF)
>
> FW:
> 13:14:23.674024 eth0 < kilauea.office.xsilogy.com.3037 >
192.168.10.11.ftp:
> S 23
> 80566213:2380566213(0) win 32120 <mss 1460,eol> (DF)
> 13:14:23.674063 eth1 > kilauea.office.xsilogy.com.3037 >
192.168.10.11.ftp:
> S 23
> 80566213:2380566213(0) win 32120 <mss 1460,eol> (DF)
> 13:14:23.674167 eth1 < 192.168.10.11.ftp >
kilauea.office.xsilogy.com.3037:
> S 30
> 26301749:3026301749(0) ack 2380566214 win 5840 <mss 1460> (DF)
> 13:14:23.674194 eth0 > 10.1.10.11.ftp > kilauea.office.xsilogy.com.3037: S
> 30263
> 01749:3026301749(0) ack 2380566214 win 5840 <mss 1460> (DF)
> 13:14:23.674352 eth0 < kilauea.office.xsilogy.com.3037 >
192.168.10.11.ftp:
> . 1:
> 1(0) ack 1 win 32120 (DF)
> 13:14:23.674374 eth1 > kilauea.office.xsilogy.com.3037 >
192.168.10.11.ftp:
> . 1:
> 1(0) ack 1 win 32120 (DF)
>
> FTP1:
> 13:14:37.761248 eth0 < kilauea.3037 > 192.168.10.11.ftp: S
> 2380566213:2380566213
> (0) win 32120 <mss 1460,eol> (DF)
> 13:14:37.761281 eth0 > 192.168.10.11.ftp > kilauea.3037: S
> 3026301749:3026301749
> (0) ack 2380566214 win 5840 <mss 1460> (DF)
> 13:14:37.761557 eth0 < kilauea.3037 > 192.168.10.11.ftp: . 1:1(0) ack 1
win
> 3212
> 0 (DF)
>
> If I try the FTP again, it goes to FTP2 and then back to FTP1, etc. So,
the
> RR algorithm is working
> and packets appear to be getting sent back and forth initially. The
tcpdump
> session is from an
> ncftpget -F command (passive ftp). I am hopping someone sees something
here
> that points out the
> problem. I could not see anything obvious in the mailing list archives.
>
> Thanks in advance!
> Jon
>
>
>
>
>
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
|
