Re: Performance question for chains

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mar 13 2008 10:18, Покотиленко Костик wrote:
>
>1. You can match first packet in the nat table and DROP/ACCEPT there.

Just because it is possible, it is not good to do so.
Loading NAT introduces no less than 3 hooks, so you
do not really save any processing time.

Do not rely on the semantics of the nat table!
It gets the first packet yes, but what "first" is
depends on the implementation of connection tracking;
in some cases even *all*, or significantly more than one
packet goes through nat.

Do not do that, it needlessy needs resources and the nat table
is an IPv4-specific thing.

>2. You may consider using ipset patch, this will allow you to use
>bindings (IP/port single rule match). Also sets are hashed or in a
>tree-like structure, depending on what you choose.
>
>Also don't forget about RELATED packets. ICMP is not only a PING!


> I have a lot of FORWARD rules to the same IPs and handfull different ports and 
> I try to increase the overall performance. I have the following ruleset in my 
> mind to achieve this goal,
> 
> iptables -A FORWARD -d 10.0.0.1 -j next
> iptables -A next -p TCP --dport 111 -j next2
> iptables -A next2 -s 10.7.0.1 -j ACCEPT
> 
> This means that I have to traverse 2 chains and than the next2 chain for 
> finding the right IP. If the sender sends another packet the packet has to 
> traverse the same chains again. If I instead do a
> 
> iptables -A FORWARD -d 10.0.0.1 -m conntrack --ctstate ESTABLISHED -j ACCEPT
> iptables -A FORWARD -d 10.0.0.1 -j next
> iptables -A next -p TCP --dport 111 -j next2
> iptables -A next2 -s 10.7.0.1 -m conntrack --ctstate NEW -j ACCEPT
>
> The following packets just traverse the first rule. 
> 
> My question now is are there any drawbacks to do it this way? Or is there 
> another more convenient way to do it?

It is perfectly fine. You may want to use -g instead of -j, depending on 
your possibilities.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux