Hi Jean-Baptiste,
On Fri, Sep 04, 2009 at 12:44:26PM +0200, Jean-Baptiste Quenot wrote:
> 2009/9/4 Jean-Baptiste Quenot <[email protected]>:
> >
> > I'm using haproxy 1.3.15.9 on Ubuntu.
>
> FYI I just upgraded to 1.3.20, and the problem persists.
Good, this is an important piece of information, because one of
the problem I was suspecting was a clock jumping back-and-forth,
which is the reason why I implemented the monotonic clock in
1.3.16.
Tcpdump will not show you any RST precisely because a timeout
is detected on inactivity. Also, the absence of RST indicates
that there is no remains of an old session on the remote host,
because if the remote host has an old session with your source
port, it will respond either by an RST or by an ACK, depending
on the SYN sequence number. And if it replies with an ACK, then
your system will send it an RST. This case is common when
running firewalls which randomize sequence numbers (eg: PIX,
FWSM), as they completely break the TCP rules between the client
and the server.
Among the things I could think of, one of them would be the
local system sometimes running out of source ports. You could
check this as well as the fact that the system allows you to
reuse connections still in TIME_WAIT state :
/proc/sys/net/ipv4/ip_local_port_range
/proc/sys/net/ipv4/tcp_tw_reuse
Also, please check with tcpdump if you see duplicate SYNs. This
is important, because a duplicate SYN will indicate that a port
could be allocated but the connection could not be establish for
whatever reason. However, the lack of duplicate SYNs would rather
indicate a source port shortage.
You can easily capture SYN/FIN/RST packets with tcpdump that way :
tcpdump -Svvni eth0 'tcp[13]&7!=0'
Also note the '-S' above which keeps sequence numbers intact, this
will be helpful to troubleshoot issues if some retransmits are
found.
Regards,
Willy
