From owner-freebsd-pf@FreeBSD.ORG Thu Mar 3 01:38:12 2005 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 032B916A4CE; Thu, 3 Mar 2005 01:38:12 +0000 (GMT) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11D9543D49; Thu, 3 Mar 2005 01:38:11 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) j231c7r7005105 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2005 02:38:08 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.3/8.12.10/Submit) id j231c7di028981; Thu, 3 Mar 2005 02:38:07 +0100 (MET) Date: Thu, 3 Mar 2005 02:38:07 +0100 From: Daniel Hartmeier To: Matthew Grooms Message-ID: <20050303013807.GH25140@insomnia.benzedrine.cx> References: <200502282232.17646.max@love2party.net> <4223931C.9000607@seton.org> <200502282326.41760.max@love2party.net> <4224B078.9020301@seton.org> <20050301185431.GA81982@cell.sick.ru> <4225174C.801@seton.org> <20050302081051.GB87159@cell.sick.ru> <422600A2.2080907@seton.org> <20050302191656.GA93112@cell.sick.ru> <42264A0A.1090301@seton.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42264A0A.1090301@seton.org> User-Agent: Mutt/1.5.6i cc: Gleb Smirnoff cc: freebsd-pf@freebsd.org Subject: Re: Fwd: pf + pfsync + carp testing ... X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical discussion and general questions about packet filter (pf) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 01:38:12 -0000 On Wed, Mar 02, 2005 at 05:19:38PM -0600, Matthew Grooms wrote: > On a slightly more depressing note, I don't think that state via > pfsync seems to be working right between the two firewalls. Sometimes ( > maybe every 1 out of 4 tries ) when the interfaces fail over, the > traffic flow stops. The reason why I believe it is a state sync issue is > that new connections can always be opened even while the previously > opened connections are stalled. This doesn't always happen when an > interface is going down either. It happens just as often when an > interface is coming back up and reclaims a MASTER state. Any ideas? It would help isolate the problem if you can provide the output of pfctl -vvss for one such stalling connection on both boxes, for comparison. The obvious requirement is that the state is actually present on the secondary box. If it is present, maybe we spot an inconsistency between the two state entries. If they look the same, maybe you can get a tcpdump -vvvS for the stalled connection (which matches the state entry). If the state is not present on the secondary, a tcpdump -nvvvei pfsync0 over the time between when the state was created on the primary and when it should have arrived at the secondary would help. Daniel