On Sun, Aug 01, 2010 at 10:26:22AM -0600, Jerry Champlin wrote: > Some additional information: > > We are using conntrac and iptables for firewalling on this box. Our typical > environment has a pair of load balancing firewalls in front of the > application. We are trying to switch from ipvs to haproxy. > r...@lb1:/proc/sys# cat ./net/nf_conntrack_max > 65536 > r...@lb1:/proc/sys# cat ./net/netfilter/nf_conntrack_max > 65536 > r...@lb1:/proc/sys# cat ./net/netfilter/nf_conntrack_count > 4468 > r...@lb1:/proc/sys# cat ./net/ipv4/netfilter/ip_conntrack_count > 4389 > r...@lb1:/proc/sys# cat ./net/ipv4/netfilter/ip_conntrack_buckets > 16384
OK so that could be one reason. You'd have to check the firewall logs. It's possible that it considers some SYNs as invalid and that the firewall rules then decide to react with a reject, thus sending an RST. This could typically happen after a session was forced closed (eg: upon a timeout), while still not closed on the server and the source port is reused in between. For the local system and the firewall it's in FIN_WAIT2 and soon closed. For the remote one it's in CLOSE_WAIT. If the system closes earlier than the firewall, the firewall may send a RST depending on its rules. Otherwise the remote system will send either an ACK or an RST. Anyway, that means that a network capture is required. Regards, Willy
