* Tony Sarendal <[EMAIL PROTECTED]> [2007-10-21 17:22]: > 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.
you misunderstood; if you do nothing to prevent that situation what you described happens. > 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. well, you can go stateful up to a certain point and handle stuff above stateless (better than dropping), like pass out on X from $foo pass in on X to $foo pass out on X from $foo keep state(max 10000) -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
