|
Hello,
On Fri, 2 Sep 2005, Jari Takkala wrote:
> # ipvsadm -l -n
> IP Virtual Server version 1.0.11 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP 10.99.23.64:80 wlc persistent 300
> -> 10.99.22.53:80 Masq 1 13 14
> -> 10.99.22.58:80 Masq 1 15 3
> -> 10.99.22.215:80 Masq 1 14 1
> TCP 10.99.23.54:80 wlc persistent 300
> TCP 10.99.23.51:80 wlc persistent 300
> -> 10.99.22.199:80 Masq 1 30 6
> -> 10.99.22.197:80 Masq 1 32 4
> TCP 10.99.23.98:5061 wlc
> -> 10.99.22.252:5061 Masq 1 0 0
> -> 10.99.22.251:5061 Masq 1 0 0
>
> Here is the output from the FTP service, which is not currently in the
> ipvsadm table because of the problems it's causing.
>
> TCP 10.99.23.57:21 wlc
> -> 10.99.22.208:21 Masq 1 0 0
> -> 10.99.22.207:21 Masq 1 0 0
Hm, this setup is different from your initial posting. May be
there is a problem with ip_vs_conn_in_get() hitting persistent template
because if (!cp && atomic_read(&ip_vs_conn_no_cport_cnt)) wants to hit ftp
connection with unknown cport. This can happen _ONLY_ if you have FTP
service on 10.99.23.64 which is not visible in your postings. Can you
confirm that you have persistent web service and ftp service on same VIP
address? If yes, then may be the web packet is forwarded according to the
persistent template without creating new connection. That is why the reply
does not see the web connection in hash. We see in log that there are no
messages showing scheduling attempt for new web connection. May be if we
avoid ip_vs_conn_in_get to return connection template the web connections
will be really created. Attached is a patch for testing this.
Regards
--
Julian Anastasov <ja@xxxxxx>
nocport-2.6.13-1.diff
Description: nocport for 2.6.13
|
