Le mercredi 06 avril 2011 à 13:02 -0700, David Miller a écrit :
From: Arnaldo Carvalho de Melo <acme(a)ghostprotocols.net>
Date: Wed, 6 Apr 2011 16:57:19 -0300
> Something like ftrace code changing when the user inserts the first
> rule?
>
> People wanting top performance disable it in the build, but thos wanting
> to stick to vendor provided kernels don't have that choice :)
Using ftrace-like stubs would be an interesting idea, and I highly encourage
people to work on something like that.
However I want to reiterate that I think that real rules are installed
in Jesse's case, and once he removes those the majority of the
overhead will disappear. The FC14 workstation I'm using right now, on
which I've made no modifications to the installer's netfilter settings,
has the following rules:
--------------------
[root@ilbolle davem]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
ACCEPT udp -- anywhere 224.0.0.251 state NEW udp dpt:mdns
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ipp
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
REJECT all -- anywhere anywhere reject-with
icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with
icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@ilbolle davem]#
--------------------
I suspect Jesse has something similar on his test box.
I suspect problem is worse than that.
I remember last time I work on a fedora kernel, it had conntrack enabled
And yes, conntrack can really slowdown a router, because of default
parameters.
cat /proc/sys/net/nf_conntrack_max