Re: performance issues (nat / conntrack)

["Jean-Michel Hemstedt" <jean-michel.hemstedt@alcatel.be>]

> > I'm doing some tcp benches on a netfilter enabled box and noticed
>  > huge and surprising perf decrease when loading iptable_nat module. 
> Rather similar to the results I posted about a week ago.

yes, i noticed it after my tests, sorry for this new thread. ;o)

> 
>  > - Another (old) question: why are conntrack or nat active when there are
>  > no rules configured (using them or not)? 
> I noticed this too.  After a test using conntrack the next test
> without "using" conntrack would perfom poorly unless I did rmmod.

yes, minor issue if documented... but serious risk.

> 
>  > Since in my test, each connection is ephemeral (<10ms) ...
> When all works correctly, the end of each connection should be noticed
> by conntrack and the connection removed from the table, right?

yep

> In which case the table should never get very full.

ideally yes, but from the conntrack machine perspective, the rest of
the world should not be considered reliable... and in fact it is not.
So, timouts should be reviewed, especially if we know that the average
tcp connection duration on the www is about 20 seconds. 
Generic timeouts are not suited to real world traffic.

> So I'm guessing that large number of entries in conntrack table is
> evidence that packets are being lost.  

not only: a crashed endpoint breaking the tcp sequence causes also
garbage entries in conntrack (known issue).

> In particular, if the syn
> packet arrives but is never forwarded, you get one of those conntrack
> entries where conntrack thinks (incorrectly) the syn has been
> forwarded so it's waiting for the reply.  Ideally the entry should
> not be added to the table until the packet goes out.

??? or is served locally ???

> 
> Just wondering, how did you measure cpu load?
> 

procinfo -n10 ; [d] for showing differences, which in fact, computes
                   the differences of cumulated cpu time (got from 
                   /proc/stat) on the given period: (tsys1-tsys0)/T
                   (I was too lazy to write a script...)

--

Maybe my mail was not clear... I've been surprised by 2 issues:
1) conntrack timeout garbages (which was addressed by you mail)
2) nat performance killing: I really don't understand it, especially
   when there's no rule active on it, and thus no translation active.

I can admit the overhead of conntrack because of the number of
entries and criteria it has to manage, but this one can be 
dimensionned and understood. 
But what about NAT??? In my opinion, the NAT overhead should only
be a delta against the conntrack overhead. But what I noticed is 
an overhead as big as the conntrack overhead! why?

_______________________________________________________________________
-jmhe-               He who expects nothing shall never be disappointed