On 12/19/07, Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote:James Nichols a écrit :So... Really unlikely a linux problem, but ...So you see outgoing SYN packets, but no SYN replies coming from the remoteRight, I meant to say SYN+ACK. I don't see them coming back.
peer ? (you mention ACKS, but the first packet received from the remote
peer should be a SYN+ACK),
I don't know how you can be so sure. Turning tcp_sack off instantly
resovles the problem and all connections are succesful. I can't
imagine even the most far-fetched scenario where a router or every
single remote endpoints would suddenly stop causing the problem just
by removing a single TCP option.
I can take these captures and take a look at the results.I dont understand, why dont you change IPs to mask them with 192.168.X.Y, or
Unfortunately, I don't think I'll be able to make the captures
available to the general public.
just ME, and peer1, peer2, peer...
I will see if I can do that, but it's major pain with 2000 hosts.
Plus, there is application data in the packets that I can't allow into
the public domain. I really don't think I can pull it off... I
literally would have to go through our legal department.
Random ideas :
1) Is your server behind a NET router or something ?
What's a NET router? I am behind a Cisco router and a firewall, but
these network components have completely been replaced/rebuilt several
times in the 4+ years that we've had this problem. I've looked at the
logs there and neither are doing anything other than passing the
traffic along.
2) Are you sure you are not using connection tracking, and hit a limit on it ?
I'm using ip_conntrack, but the limit I have for max entries is 65K.
The most I've seen in there are a couple thousand- that was one of the
first things I monitored very closely.