From owner-freebsd-pf@FreeBSD.ORG  Wed Aug  4 07:59:26 2010
Return-Path: <owner-freebsd-pf@FreeBSD.ORG>
Delivered-To: freebsd-pf@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 5E4A2106566B
	for <freebsd-pf@freebsd.org>; Wed,  4 Aug 2010 07:59:26 +0000 (UTC)
	(envelope-from rush@clink.ru)
Received: from hosting.clink.ru (hosting.clink.ru [194.165.18.3])
	by mx1.freebsd.org (Postfix) with ESMTP id 0FFDB8FC1E
	for <freebsd-pf@freebsd.org>; Wed,  4 Aug 2010 07:59:25 +0000 (UTC)
Received: from [192.168.50.225] (unknown [192.168.50.225])
	by hosting.clink.ru (Postfix) with ESMTPA id B535211DE6;
	Wed,  4 Aug 2010 13:59:18 +0600 (YEKST)
Message-ID: <4C592063.7090605@clink.ru>
Date: Wed, 04 Aug 2010 14:10:11 +0600
From: "Rushan R. Shaymardanov" <rush@clink.ru>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706)
MIME-Version: 1.0
To: Daniel Hartmeier <daniel@benzedrine.cx>
References: <4C58D456.5010701@clink.ru>
	<20100804062907.GA3834@insomnia.benzedrine.cx>
	<4C591915.7050807@clink.ru>
	<20100804074915.GB3834@insomnia.benzedrine.cx>
In-Reply-To: <20100804074915.GB3834@insomnia.benzedrine.cx>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: freebsd-pf@freebsd.org
Subject: Re: Keeping state of tcp connections
X-BeenThere: freebsd-pf@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Technical discussion and general questions about packet filter
	\(pf\)" <freebsd-pf.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-pf>,
	<mailto:freebsd-pf-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-pf>
List-Post: <mailto:freebsd-pf@freebsd.org>
List-Help: <mailto:freebsd-pf-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-pf>,
	<mailto:freebsd-pf-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Aug 2010 07:59:26 -0000

>
> Are you using adaptive timeouts?
>
> # pfctl -st | grep adaptive
Yes (they are used by default):

# pfctl -st | grep adaptive
adaptive.start             6000 states
adaptive.end              12000 states


>
> What's your state limit?
>
> # pfctl -sm | grep states

# pfctl -sm | grep states
states        hard limit   131072

>
> When the problem occurs, how many states do you have?
>
> # pfctl -si | grep current
 # pfctl -si | grep current
current entries                   120600
>
> If this value is higher than the adaptive.start value,
> timeout values get scaled down, which could possibly explain
> what you see. If so, try increasing the state limit and/or
> the adaptive thresholds:
>
>   set limit states 50000
>   set timeout { adaptive.start 50000 adaptive.end 60000 }
>

That was the problem. I increased states limit, but adaptive.start and
adaptive end remained default. No I switched adaptive timeouts off by
using set timeout { adaptive.start 0 adaptive.end 0 }

Thank you very much!

Shaymaradnov Rushan

> Other causes: do you use pfsync to synchronize states between
> multiple pf machines? If so, are their clocks synchronized and
> accurate?
>
> Did you change any (kernel) settings related to time, like HZ
> or such? Is your time synchronized in a special way, i.e. not
> just by ntpd?
>
> Daniel