|
Hi,
While trying to implement a load-balancer based on ipvs-0.2.4 I found some
bugs in the code. The testing environment used is: kernel 2.4.2-pre[34] for
load balancer and NAT as load-balancing method
1. TCP state transition diagrams in ipvs/ip_vs_conn.c have initial states in
the wrong order (according to ipvs/ip_vs.h). The problem is that
IP_VS_S_SYNACK should be the 5th state in the table and it is the last. I have
observed this because a close request initiated by the client leaves the
connection open on the director. Here are the debug messages:
IPVS: Schedule fwd:M s:NONE c:172.18.1.62:3206 v:172.18.1.58:21
d:172.18.1.231:21 flg:140 cnt:2
IPVS: TCP input [S...] 172.18.1.231:21->172.18.1.62:3206 state: NONE->SYN_RECV
cnt:2
IPVS: TCP input [..A.] 172.18.1.231:21->172.18.1.62:3206 state:
SYN_RECV->ESTABLISHED cnt:2
IPVS: TCP input [.FA.] 172.18.1.231:21->172.18.1.62:3206 state:
ESTABLISHED->CLOSE_WAIT cnt:2
IPVS: TCP output [..A.] 172.18.1.231:21->172.18.1.62:3206 state:
CLOSE_WAIT->LAST_ACK cnt:2
IPVS: TCP output [.FA.] 172.18.1.231:21->172.18.1.62:3206 state:
LAST_ACK->LISTEN cnt:2
IPVS: TCP input [..A.] 172.18.1.231:21->172.18.1.62:3206 state:
LISTEN->ESTABLISHED cnt:2
You can see that the last 2 lines are not exactly a correct behaviour.
2. The ftp module does not work for passive mode (it doesn't work at all but
the active mode can be managed using standard masquerading). The FTP handling
code does not properly deal with the new connection (the director doesn't
handle it at all).
There is an attached patch that solves the two above-mentioned problems. I'm
not sure that the second problem is resolved the right way, but at least it
works.
Bye
Radu-Adrian Feurdean
mailto: raf@xxxxxxxx
-------------------------------------------------------------------
"If the night is silent enough you can hear a Windows NT rebooting"
ipvs-0.2.4.diff
Description: Text document
| 