Yo! Julian Anastasov wrote: >> why should the timer expire, if there are packets transmitted? also, i >> set the timer to 8 minutes, longer than those connections. still the >> same behaviour: > May be it is not only the timeout, there are retransmission > counters used in Netfilter.
ok, i set all netfilter tcp timeouts to 10min, retransmissions to 50 and tcp_be_liberal + ipvs tcpfin timeout to 10min. it seemed to make the situation better (not perfect though). looking at packet traces and traceroutes to those clients that still have trouble, it seems they are a from far away (network path wise), have packet loss or instability with latency to us. those conditions could cause a lot of retransmissions and and also time out at various connection states. looking at it from this perspective: if you have some clients with a really bad link to you, it probably makes sense to have longer timeouts for fin_wait and close_wait (and possibly higher max_retrans). also last_ack, close and time_wait if you like to get the connections closed properly. or just accept the fact, that if their links (to us) suck and no amount of netfilter tuning will help if the cables/hw between us and them are broken. >> i log the dropped packets and take the last one with tail. i search for >> it from ipvsadm connection tables and conntrack: > > Any error message why packets are dropped in Netfilter? It is because of the firewall. It accepts all ESTABLISHED packets and drops the rest (logging them): Chain FORWARD (policy DROP) target prot opt source destination ACCEPT 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED DROP 0 -- 0.0.0.0/0 0.0.0.0/0 ctstate INVALID LOG 0 -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `forward: ' There are NAT connections on the LVS and I want to allow only the LVS connections and the NAT connections to pass. nfct patches make it possible to ACCEPT ESTABLISHED packets and first packets of any new NAT connection (outgoing) and drop the rest. The problem seems to be that ipvs tables are not at sync with conntrack tables and some connections are forgotten by netfilter that are still forwarded by ipvs. > IPVS tries to drop netfilter conn only at one place: > ip_vs_nfct_conn_drop(), called when IPVS connection is removed. > So, I assume it is not happening in your case because IPVS conn > is still present. would it make sense to have a true ipvs state match for netfilter? that way we can make a fw policy that accepts known outgoing ipvs traffic on the same basis as ipvs would accept incoming? Siim _______________________________________________ LinuxVirtualServer.org mailing list - [email protected] Send requests to [EMAIL PROTECTED] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
