Good to know it helped,
probably you also need check for "set optimization aggressive" it will
also reduce number of states if it works for your use cases.
--
Evgeniy
On Thu, Jun 2, 2016 at 2:40 PM, Tim Korn wrote:
> Hi Evgeniy,
> Thank you for your reply. The states hard limit was the problem
Hi Evgeniy,
Thank you for your reply. The states hard limit was the problem. The
default limit is quite low :)
--
Tim Korn
Network Ninja
On Thu, Jun 2, 2016 at 3:48 AM, Evgeniy Sudyr wrote:
> Tim,
>
> from your problem description I can suggest you to check if you are not
> hitting
Tim,
from your problem description I can suggest you to check if you are not hitting
states hard limit with (note - during load when you can reproduce issue):
pfctl -si
pfctl -sm
Default limit is: stateshard limit1
--
Evgeniy
On Thu, Jun 2, 2016 at 3:29 AM, Tim Korn wrote:
>
On 02/06/16 04:29, Tim Korn wrote:
Hi. I have a pair of openBSD boxes (5.8) setup as a core/firewall. I have
ten VLANs tied to a physical NIC (Intel 82599). This is a new setup and it
was just recently put in service. Traffic was fine (or at least we didn't
notice any issues) until a large jo
Hi. I have a pair of openBSD boxes (5.8) setup as a core/firewall. I have
ten VLANs tied to a physical NIC (Intel 82599). This is a new setup and it
was just recently put in service. Traffic was fine (or at least we didn't
notice any issues) until a large job was run which roughly doubled traff
5 matches
Mail list logo