Bug 144875

Summary: ip_conntrack table full
Product: [Fedora] Fedora Reporter: Stephen Collier <judithc>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 3CC: jasone, pfrields, trevor, zing
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-01-31 18:13:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Stephen Collier 2005-01-12 09:02:58 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
ip_conntrack table full dropping packets. Going back to
kernel-2.6.9-1.724_FC3 fixes the problems. It seems to be related to
https://lists.netfilter.org/pipermail/netfilter-devel/2004-December/017908.html
. It seems to not be releasing the connections from the table even
after they are long gone.

Version-Release number of selected component (if applicable):
kernel-2.6.10-1.737_FC3

How reproducible:
Always

Steps to Reproduce:
1. use iptable with ip_conntrack
2. large number of connections (mail gateway)
3. run for a few hours
    

Actual Results:  drops packets

Additional info:

Comment 1 Thomas Woerner 2005-01-12 10:23:37 UTC
This is a kernel problem. 
Assigning to kernel.

Comment 2 Jason Eisert 2005-01-13 22:18:03 UTC
I have confirmed this as a problem as well.

Comment 3 Jason Eisert 2005-01-14 15:54:22 UTC
Does the 

Connnection track/rst fix			(Martin Josefsson)

Correct this problem in the kernel release

kernel-2.6.10-1.741_FC3

Comment 4 Zing 2005-01-20 04:00:31 UTC
kernel-2.6.10-1.741_FC3 works for me.

# cat /proc/net/ip_conntrack|wc -l
1055

much better than the ~32000 i would get with -737

Comment 5 Jason Eisert 2005-01-25 15:03:25 UTC
kernel-2.6.10-1.741_FC3 appears to still have the bug.

Comment 6 Trevor Cordes 2005-01-27 22:26:16 UTC
Yes, 741 still has the bug for sure.  It bit me too just recently. 
Unreplied TCP connections will hang around for 5 days and quickly fill
the 32k (depending on your RAM) table size.  I was doing nmap scans of
my own network and it would fill up the table in no time!

This is a very bad bug that under many normal conditions will cause
dropped connections to/from a system, resulting in intermittent and
hard to diagnose networking issues.

Comment 7 Stephen Collier 2005-01-28 22:39:21 UTC
I installed 741 last night, it seems to be OK, I am getting back to
the 150 or so table, not the 32000. I will confirm next week when full
load comes on the server on a weekday.

Comment 8 Stephen Collier 2005-01-31 09:51:17 UTC
kernel-2.6.10-1.741_FC3 has been running fine all day today. It has
resolved my ip_conntrack bug.

# cat /proc/net/ip_conntrack|wc -l
83

much better than 32000

Comment 9 Trevor Cordes 2005-02-01 15:19:14 UTC
This bug is NOT fixed as of 741!  My test from Jan 27 still has the
entries from that date.

To easily fill up your table with entries that don't expire for way
too long:

nmap -S 192.168.100.1 -sP 192.168.100.2-254

(change 192.168.100 to your internal subnet/ip)

each run of that command adds a couple hundred entries to the table:

cat /proc/net/ip_conntrack | wc

and they don't go away for at least days.

Tested and verified on: 2.6.10-1.741_FC3smp