On Sun, Sep 18, 2005 at 01:17:04AM -0300, Vinicius Pavanelli Vianna wrote:
> Hi,
> 
> I'm using OpenBSD 3.7 with pf and bridge enabled for a transparent
> proxy, and I'm having some packet loss somewhere in this bridge, since
> netstat -ni doesn't give me any ierrors

  what about pkts?  does the input corroborate to the output?

> this machine has about 30k packets/s, my question is: how can i see if
> pf is ok with this load on this machine?

  make an easy test ruleset:

---
pass all keep state
---
  
  see if that is better than going into vi and typing
  '8192opass all'<esc> and using that for your ruleset
  ( note, i don't know for certain if skipsteps make these rules
    get skipped; but -vsr shows them as having been evaluated )

> Almost all my pf rules have quick enabled, but i'm not using state in
> some rules, can this slow down the pf?

[pf.conf(5)]
     For each packet processed by the packet filter, the filter rules are
     evaluated in sequential order, from first to last.  The last matching
     rule decides what action is taken.
<...>
     quick
           If a packet matches a rule which has the quick option set, this
           rule is considered the last matching rule, and evaluation of subse-
           quent rules is skipped.

<...>
     Before any rules are evaluated, the filter checks whether the packet
     matches any state.  If it does, the packet is passed without evaluation
     of any rules.
<...>
     Also, looking up states is usually faster than evaluating rules.  If
     there are 50 rules, all of them are evaluated sequentially in O(n).  Even
     with 50000 states, only 16 comparisons are needed to match a state, since
     states are stored in a binary search tree that allows searches in O(log2
     n).
------------

  evaluating the entire ruleset (or until the first matching quick) is likely
  to be taking longer than matching to an existing state.  for my experience,
  if the machine doesn't have enough CPU to handle running statelessly
  in the average case, it probably also has other architectural slownesses
  that could be a bigger issue (eg, take a soekris 4501+1411 for instance; 
  the 4501 has a hard enough time moving data around the bus from A->B,
  which isn't going to show in CPU util; running stateful would probably
  be a step towards a snappier response, but still won't let you push
  40Mb/s of IPsec through the wire, or something like that.).

> and what's the maximum state limit?

  iirc, default is 10k.  there was a post about it < 3w ago on either
  misc@ or [EMAIL PROTECTED]

  or do you mean the super duper maximum you can set it to?

  probably the smaller of whatever the kernel can allocate for the
  purpose or what you have free for the kernel to try to allocate
  from.  i'd worry about that after evaluating how many states
  you're actually keeping while running statefully.  you might
  not even be close to the default limit.

  jared

- 

[ openbsd 3.7 GENERIC ( sep 10 ) // i386 ]

Reply via email to