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). Can
