ip_conntrack_max vs ip_conntrack

Hi all,

could someone please explain me what is the relation between the number in /proc/sys/net/ipv4/ip_conntrack_max and number of lines in /proc/net/ip_conntrack?

On one of our very loaded firewalls (with 1GB RAM) we are still getting "ip_conntrack: table full, dropping packet." message. We tried to tweak all different parameters, e.g. hashsize to up to 1048576, ip_conntrack_max, ip_conntrack_tcp_timeout_established, etc. Unfortunately sooner or later the kernel always starts dropping packets. At the same time however there are at most a few thousands of lines in /proc/net/ip_conntrack.

I instrumented the kernel to dump the same output via printk() once ip_conntrack_count reaches ip_conntrack_max. When I set _max=128 and run nmap through the firewall it of course very soon prints the "dropping packets" message, but along with only 6 (=six!) lines of connections. Where was the rest, 122 connections, lost? What does the ip_conntrack_count actually count?

Quoted 14 lines · Michal Ludvig

Hi all,

could someone please explain me what is the relation between the number in /proc/sys/net/ipv4/ip_conntrack_max and number of lines in /proc/net/ip_conntrack?

On one of our very loaded firewalls (with 1GB RAM) we are still getting "ip_conntrack: table full, dropping packet." message. We tried to tweak all different parameters, e.g. hashsize to up to 1048576, ip_conntrack_max, ip_conntrack_tcp_timeout_established, etc. Unfortunately sooner or later the kernel always starts dropping packets. At the same time however there are at most a few thousands of lines in /proc/net/ip_conntrack.

Quoted 6 lines

I instrumented the kernel to dump the same output via printk() once ip_conntrack_count reaches ip_conntrack_max. When I set _max=128 and run nmap through the firewall it of course very soon prints the "dropping packets" message, but along with only 6 (=six!) lines of connections. Where was the rest, 122 connections, lost? What does the ip_conntrack_count actually count?

Ok one thing you might want to do is check to see if you dont have a bug in your kernel somewhere.. I found the one I talked about earlier by doing the following:

cat /proc/slabinfo |grep ip_conntrack
cat /proc/net/ip_conntrack | wc -l

Not the best and very racy.. but the 2 did NOT match up in any shape or form. I then played around with various conntrack modules until I figure d it out to being something with conntrack_irc and conntrack_ftp in the kernel I was running. Removing those allowed for the 2 to match up closely when doing HTTP crashloads on the firewall. Adding either one of them caused what looked like a resource leak.

As far as I can tell.. a POM-only patched 2.4.26 did not exhibit this problem.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

could someone please explain me what is the relation between the number in /proc/sys/net/ipv4/ip_conntrack_max and number of lines in /proc/net/ip_conntrack?

On one of our very loaded firewalls (with 1GB RAM) we are still getting "ip_conntrack: table full, dropping packet." message. We tried to tweak all different parameters, e.g. hashsize to up to 1048576, ip_conntrack_max, ip_conntrack_tcp_timeout_established, etc. Unfortunately sooner or later the kernel always starts dropping packets. At the same time however there are at most a few thousands of lines in /proc/net/ip_conntrack.

I instrumented the kernel to dump the same output via printk() once ip_conntrack_count reaches ip_conntrack_max. When I set _max=128 and run nmap through the firewall it of course very soon prints the "dropping packets" message, but along with only 6 (=six!) lines of connections. Where was the rest, 122 connections, lost? What does the ip_conntrack_count actually count?

Thanks in advance!

Michal Ludvig
- --
SUSE Labs [email protected]
(+420) 296.545.373 http://www.suse.cz
Personal homepage http://www.logix.cz/michal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBVKEQDDolCcRbIhgRAupGAKCF4F6Mvk0YARZMj5S21vI/95u71ACfWDn2 UVB5lEV0YC58et/rvFbJEEY=
=AryG
-----END PGP SIGNATURE-----

But still,
The /proc/net/ip_conntrack should contain all connections tracked by that firewall (ie, passing through the firewall), am I right ??

Quoted 4 lines · Mohamed Eldesoky

But still,
The /proc/net/ip_conntrack should contain all connections tracked by that firewall (ie, passing through the firewall), am I right ??

This list is all actively tracked connections, all not yet completed, but
possibly tracked connections (called expectations) that the netfilter code is watching for. You need to pay attention to the state of the connection, but you've got the right idea.

I can't recall all the states off the top of my head, but they are fairly
clearly labelled.

	Alistair Tonner.

	<< SNIPPAGE>>

But still,
The /proc/net/ip_conntrack should contain all connections tracked by that firewall (ie, passing through the firewall), am I right ??

Quoted 3 lines · Mohamed Eldesoky

But still,
The /proc/net/ip_conntrack should contain all connections tracked by that firewall (ie, passing through the firewall), am I right ??

Yes, and it will remember the connections made for a time. It's a list of all the connections the conntrack system have seen, and it's used to check the established and related connections.

--
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
[email protected]
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn like fabulous yellow Roman candles.
-- Jack Kerouac, "On the Road"

Well, I want to make sure that it remembers only connections that passes THROUGH it !!

Quoted 24 lines · Mohamed Eldesoky

Quoted 3 lines

But still,
The /proc/net/ip_conntrack should contain all connections tracked by that firewall (ie, passing through the firewall), am I right ??

Yes, and it will remember the connections made for a time. It's a list of all the connections the conntrack system have seen, and it's used to check the established and related connections.

--
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
[email protected]
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn like fabulous yellow Roman candles.
-- Jack Kerouac, "On the Road"

Quoted 2 lines · Mohamed Eldesoky

Well, I want to make sure that it remembers only connections that passes THROUGH it !!

Are you saying you don't want to track local connections?

This file keeps track of anything that *_conntrack_* would watch. As far as I know this includes local connections --

If you are accepting any connections locally, they are very likely in this table.

I've seen at least one discussion about breaking this up into different
files. That gets messy very quicky from a code point of view, as well as from a logic point of view. I certainly prefer the idea of having one place to track connections.

Alistair Tonner

Quoted 26 lines · Jose Maria Lopez

Quoted 24 lines · Mohamed Eldesoky

Quoted 3 lines

But still,
The /proc/net/ip_conntrack should contain all connections tracked by that firewall (ie, passing through the firewall), am I right ??

Yes, and it will remember the connections made for a time. It's a list of all the connections the conntrack system have seen, and it's used to check the established and related connections.

--
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
[email protected]
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn like fabulous yellow Roman candles.
-- Jack Kerouac, "On the Road"