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