NetFilter
[Top] [All Lists]

Re: NAT performance + table processing

To: Július Bemš <julo@atknet.sk>
Subject: Re: NAT performance + table processing
From: Покотиленко Костик <casper@meteor.dp.ua>
Date: Thu, 09 Aug 2007 21:26:46 +0300
Cc: netfilter@lists.netfilter.org
Delivered-to: sp-com-lists@consult.net
Delivered-to: netfilter-list1@securepoint.com
In-reply-to: <000b01c7daac$f4b57030$de205090$@sk>
List-archive: </pipermail/netfilter>
List-help: <mailto:netfilter-request@lists.netfilter.org?subject=help>
List-id: General discussion and user questions <netfilter.lists.netfilter.org>
List-post: <mailto:netfilter@lists.netfilter.org>
List-subscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter>, <mailto:netfilter-request@lists.netfilter.org?subject=subscribe>
List-unsubscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter>, <mailto:netfilter-request@lists.netfilter.org?subject=unsubscribe>
Organization: СК "Метеор"
References: <000b01c7daac$f4b57030$de205090$@sk>
Reply-to: casper@meteor.dp.ua
Sender: netfilter-bounces@lists.netfilter.org
В Чтв, 09/08/2007 в 19:44 +0200, Július Bemš пишет:
> Hi,
> 
> I wrote some performance tests of NAT table. The main idea is, that I add
> 10000 random+senseless rules to the NAT table (snat, postrouting) and then I
> add some rule to specific position which will stop traversing of NAT table.
> I use UDP packets. 
> 
> When I insert my reasonable rule to position 2000 and  run my test, it shows
> delay of packets cca 300ms. But when I run it more times, this delay is 2ms.
> I don't understand why, because I use UDP(connectionless) - so I think, that
> netfilter must process each packet and find appropriate rule. Is this true?
> Or does netfilter do some optimalization? Because this behavior is expected
> in TCP, but not UDP.

UDP is connectionless, you are right. But conntrack thinks of it like of
connection-oriented. If several UDP packets have the same source IPs and
ports and same destination IPs and ports conntrack thinks those are
belonging to the same "connection".

-- 
Покотиленко Костик <casper@meteor.dp.ua>



<Prev in Thread] Current Thread [Next in Thread>