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