On Friday 19 April 2002 20:46, Ankit Jain wrote: > > On demand is: > > * NAT targets executed > > Is there a need to do DNAT before the creation of the conntrack > entry?
No, and is why, if doing on-demand conntrack entry creation, DNAT would need to create a conntrack entry if there is none already. > Why would modules have to create the conntrack entry? > If the filter ACCEPTS the packet, the code branch in > the core can create the entry. Is there something I am missing? The approach I presented was to have conntrack entries created only when needed, not earlier, not later. The time when the contrack entry absolutely must be created depends on the ruleset. If your are using SNAT then this is in PREROUTE, if DNAT then in POSTROUTE. The "filter" table is inbetween these two.. > > The question is which of the overheads is the worst.. > > A) the temporary creation/deletetion of conntrack entries for > > packets blocked by the ruleset > > B) the addition of yet another filter table, executed before > > conntrack C) the increased code path to dynamically create > > conntrack entries "only when needed" > > My question was is there fundamentally/architecturally wrong with > C? What I proposed in 'C' is quite complex to implement, and adds a small amount overhead. Evaluating the full effects of the added overhead compared to the gain in not having to create conntrack entries for dropped traffic is a very complex task as it depends a lot on the situation, ruleset etc. Regards Henrik
