Re: iptables: memory allocation problem

[Herve Eychenne <rv@wallfire.org>]

On Tue, Dec 16, 2003 at 07:29:59PM +0100, Herve Eychenne wrote:

 Hi again,

> I'm currently setting up a quiet big firewall, and I experience some
> annoying problems. Here is what I get right now:
> # iptables -A INPUT -j ACCEPT
> iptables: Memory allocation problem
> Well... something is going wrong, obviously.
> [...]
> Note that the machine is still perfectly functionnal. I can log in
> (remotely) and do whatever I want without any problem. I just seem to be
> running out of kernel memory for the iptables rule insertion.
> So I suspect there is a kind of memory leak somewhere.
> [...]
> The machine is a SMP (4 processors) with Xeon 2.40GHz.
> The host is running iptables-1.2.9 with 2.4.23 vanilla kernel (highmem
> 4Go activated, as there is 1.5G of RAM), and no real exotic
> patch-o-matic module added (I'll provide the list on request if you
> want) and no module support (I'll send .config on request as well).
> [...]
> I tweaked the number of buckets (based on my document
> http://www.wallfire.org/misc/netfilter_conntrack_perf.txt)
> # cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
> 3579157
> # cat /proc/sys/net/ipv4/netfilter/ip_conntrack_buckets
> 3579157
> Note: maybe it's a little too much (there's no real memory consuming
> userspace command running, so I want to reserve as much as possible for
> conntrack), but I think I can recall having an iptables memory
> allocation only one time (I was surprised, but forgot
> about it) a long time ago on the same machine before I had set these
> parameters to something else than the default.

I know... nobody dared to reply... too bad... :-(
So here's your punishment. ;-)
Well... after a reboot and 2 days without problem, another issue
showed up.

I tried another "iptables-restore <myrules", which produced no
memory outage. Then, shortly after, I came up with the strange
idea of wanting to know how many entries there was in the conntrack.
What a foolish idea... as my
# wc -l /proc/net/ip_conntrack
simply locked the machine: my remote shell freezed, no traffic could
go through the firewall, and the console itself was completely
unresponsive.
After 2 or 3 minutes, I decided I could not wait any longer, as I
had to reboot the firewall as soon as possible to get the important
traffic back.

Do you think it is possible that a wc -l on a huge conntrack (there
could have been up to 3 million entries (as you can see in the
quoted text above), but I have absolutely no idea of how many there
were here) would take so much time (more that 3 minutes on a
4*2.4 Ghz) and would get the kernel so busy that it would even
freeze the console?
Or do you think it's clearly a bug?

Well, anyway, as conntrack listing locks conntrack state, don't you
think we should definitely provide a way to read ip_conntrack_count
through /proc/sys/net/ipv4/netfilter/ip_conntrack_count ? (aka
"Yet Another Oneliner Patch For Patch-O-Matic")

 Herve

-- 
 _
(°=  Hervé Eychenne
//)
v_/_ WallFire project:  http://www.wallfire.org/