From: Eric Dumazet <dada1@cosmosbay.com>
To: James Nichols <jamesnichols3@gmail.com>
Cc: Jan Engelhardt <jengelh@computergmbh.de>,
linux-kernel@vger.kernel.org,
Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: After many hours all outbound connections get stuck in SYN_SENT
Date: Wed, 19 Dec 2007 19:03:27 +0100 [thread overview]
Message-ID: <47695CEF.4090908@cosmosbay.com> (raw)
In-Reply-To: <83a51e120712190943m3bf0e2e4v2ea6b660142e9a5a@mail.gmail.com>
James Nichols a écrit :
> On 12/19/07, Eric Dumazet <dada1@cosmosbay.com> wrote:
>> James Nichols a écrit :
>>>> So you see outgoing SYN packets, but no SYN replies coming from the remote
>>>> peer ? (you mention ACKS, but the first packet received from the remote
>>>> peer should be a SYN+ACK),
>>> Right, I meant to say SYN+ACK. I don't see them coming back.
>> So... Really unlikely a linux problem, but ...
>>
>
>
> 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.
>>> Unfortunately, I don't think I'll be able to make the captures
>>> available to the general public.
>> I dont understand, why dont you change IPs to mask them with 192.168.X.Y, or
>> 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.
I still dont understand.
"tcpdump -p -n -s 1600 -c 10000" doesnt reveal User data at all.
Without any exact data from you, I am afraid nobody can help.
>
>> 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.
Typo error, I meant NAT. Most routers doing NAT have some limits, timers, hacks...
>
>> 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.
Now please try without conn tracking module. I saw many failures in the past
that were trigered by conntrack.
Do you have some firewall rules, using some netfilter modules like hashlimit ?
WARNING: multiple messages have this Message-ID (diff)
From: Eric Dumazet <dada1@cosmosbay.com>
To: James Nichols <jamesnichols3@gmail.com>
Cc: Jan Engelhardt <jengelh@computergmbh.de>,
linux-kernel@vger.kernel.org,
Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: After many hours all outbound connections get stuck in SYN_SENT
Date: Wed, 19 Dec 2007 19:03:27 +0100 [thread overview]
Message-ID: <47695CEF.4090908@cosmosbay.com> (raw)
In-Reply-To: <83a51e120712190943m3bf0e2e4v2ea6b660142e9a5a@mail.gmail.com>
James Nichols a écrit :
> On 12/19/07, Eric Dumazet <dada1@cosmosbay.com> wrote:
>> James Nichols a écrit :
>>>> So you see outgoing SYN packets, but no SYN replies coming from the remote
>>>> peer ? (you mention ACKS, but the first packet received from the remote
>>>> peer should be a SYN+ACK),
>>> Right, I meant to say SYN+ACK. I don't see them coming back.
>> So... Really unlikely a linux problem, but ...
>>
>
>
> 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.
>>> Unfortunately, I don't think I'll be able to make the captures
>>> available to the general public.
>> I dont understand, why dont you change IPs to mask them with 192.168.X.Y, or
>> 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.
I still dont understand.
"tcpdump -p -n -s 1600 -c 10000" doesnt reveal User data at all.
Without any exact data from you, I am afraid nobody can help.
>
>> 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.
Typo error, I meant NAT. Most routers doing NAT have some limits, timers, hacks...
>
>> 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.
Now please try without conn tracking module. I saw many failures in the past
that were trigered by conntrack.
Do you have some firewall rules, using some netfilter modules like hashlimit ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2007-12-19 18:03 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-14 20:39 After many hours all outbound connections get stuck in SYN_SENT James Nichols
2007-12-17 23:14 ` Jan Engelhardt
2007-12-18 15:34 ` James Nichols
2007-12-18 16:05 ` Jan Engelhardt
2007-12-18 16:45 ` James Nichols
2007-12-18 17:19 ` Jan Engelhardt
2007-12-18 18:09 ` James Nichols
2007-12-18 18:14 ` Jan Engelhardt
2007-12-18 18:21 ` James Nichols
2007-12-18 18:30 ` Jan Engelhardt
2007-12-18 18:32 ` Eric Dumazet
2007-12-18 19:44 ` James Nichols
2007-12-18 20:37 ` Eric Dumazet
2007-12-18 21:20 ` Jan Engelhardt
2007-12-19 16:53 ` James Nichols
2007-12-19 17:07 ` Eric Dumazet
2007-12-19 17:43 ` James Nichols
2007-12-19 17:58 ` Jan Engelhardt
2007-12-19 18:12 ` James Nichols
2007-12-20 14:41 ` Glen Turner
2007-12-20 16:37 ` James Nichols
2007-12-20 21:05 ` Ilpo Järvinen
2007-12-21 6:06 ` Jan Engelhardt
2007-12-21 4:51 ` Glen Turner
2007-12-21 13:57 ` James Nichols
2007-12-19 18:03 ` Eric Dumazet [this message]
2007-12-19 18:03 ` Eric Dumazet
2007-12-19 21:27 ` Ilpo Järvinen
2007-12-20 16:08 ` James Nichols
2007-12-20 20:44 ` Ilpo Järvinen
2007-12-20 20:49 ` Justin Banks
2007-12-18 19:45 ` James Nichols
2007-12-18 20:28 ` Chuck Ebbert
-- strict thread matches above, loose matches on Subject: below --
2007-12-16 16:34 James Nichols
2007-12-17 16:27 ` James Nichols
2007-12-19 12:54 ` Ilpo Järvinen
2007-12-19 17:38 ` James Nichols
2007-12-19 18:32 ` Ilpo Järvinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47695CEF.4090908@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=jamesnichols3@gmail.com \
--cc=jengelh@computergmbh.de \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.