Date: Thu, 3 Mar 2005 02:38:07 +0100 From: Daniel Hartmeier <daniel@benzedrine.cx> To: Matthew Grooms <mgrooms@seton.org> Cc: freebsd-pf@freebsd.org Subject: Re: Fwd: pf + pfsync + carp testing ... Message-ID: <20050303013807.GH25140@insomnia.benzedrine.cx> In-Reply-To: <42264A0A.1090301@seton.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050303013807.GH25140>