On 10/21/07, Can Erkin Acar <[EMAIL PROTECTED]> wrote: > > Tony Sarendal <[EMAIL PROTECTED]> wrote: > > On 10/21/07, Henning Brauer <[EMAIL PROTECTED]> wrote: > >> > >> * Tony Sarendal <[EMAIL PROTECTED]> [2007-10-21 14:50]: > >> > > stateless is poop. > >> > What will happen when the limit of maximum concurrent states is > reached > >> ? > >> > Will it stop forwarding new flows ? > >> > >> depends on the way you write your ruleset. > >> if you do nothing, exactly that happens. > > > > > > An incoming packet is either dropped or not, I don't see how the router > can > > do nothing. > > > > Besides that, the environment I am looking at is as an edge/peering > router. > > Basic filtering to protect infrastructure and where possible prevent > > spoofing, > > I do not consider such an environment a suitable place for a statelful > > device > > as they normally change behaviour when the limit of states is exceeded. > > > > A router that has a major performance drop when a certain limit of flows > is > > reached is something I normally stay away from, a router that stops > > forwarding of new flows when a flow limit is reached is worse. > > > > That is my reasoning for using stateless filters in my case. > > If OpenBSD/pf has a solution that solves these stateful limitations I > would > > be > > very interested in understanding it. > > There are several mechanisms for handling overload in OpenBSD/pf > They are designed to improve the stateful filtering experience, and > usually > non-stateful traffic suffers in case of overload. > > One of them is adaptive timeouts. This lets 'old/not-established' states > to be expired quickly, letting new states to be established. You need to > set suitable values for your traffic requirements, together with max > number of > states. This is much more useful than a best effort forwarding where > packets > belonging to valid states are equally likely to be dropped. > > Another mechanism is congestion handling. If an interface input queue is > full, > that means your CPU is not able to keep up with the incoming packets (or > that > you need to increase the queue size). In this case, pf stops ruleset > evaluation > altogether, and ONLY passes packets matching to states. Note that, in > this case > we are already dropping packets. Having pf choose only stateful traffic > to pass > is an improvement over not being able to pass any. > > Considering the fact that state matching is faster per packet when you > have > some less-than-trivial ruleset. Using stateful filtering is better in > almost > all cases (ie. except asymmetric routing as you pointed out earlier).
The last sentence sums up what I'm looking at. Although I don't feel that assymetric routing is an exception. /Tony
