Date: Thu, 31 May 2012 15:51:24 -0400 From: Nick Gustas <freebsd-lists@tychl.net> To: Damien Fleuriot <ml@my.gd> Cc: freebsd-stable@freebsd.org Subject: Re: Why Are You Using FreeBSD? Message-ID: <4FC7CBBC.6090204@tychl.net> In-Reply-To: <4FC7A1DB.6040409@my.gd> References: <C480320C-0CD9-4B61-8AFB-37085C820AB7@FreeBSD.org> <4FC779C0.7020801@ohlste.in> <4FC77EAD.1090900@my.gd> <4FC78A94.8070008@ohlste.in> <4FC79136.6000205@my.gd> <4FC79E45.4060505@gmx.com> <4FC7A1DB.6040409@my.gd>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/31/2012 12:52 PM, Damien Fleuriot wrote: > On 5/31/12 6:37 PM, Nikos Vassiliadis wrote: >> On 5/31/2012 5:41 PM, Damien Fleuriot wrote: >>> Furthermore, when upgrading the CARP Master firewall, we need to plan >>> with the Project Manager a failover to the CARP Backup firewall. >>> Yes, I know about pfsync, yes, we use it, no, it doesn't *instantly* >>> sync sessions for PF. >> A bit offtopic on this thread, but isn't pfsync designed to do just >> that? instantly? >> >> With instantly I really mean: >> Communicate every change to the stable table to the other firewall >> in order to let the stateful connections survive a firewall failover. >> Obviously, some packets will be lost, but TCP connections should >> survive, right? >> >> I am not arguing, I ask. >> >> Nikos > Updates aren't instantaneous, they're sent in bundles. > > This means that when you failover, you lose the connections that have > completed a SYN/SYNACK/ACK sequence on your main firewall but which > aren't synched on your backup. > > These connections will continue with the peer sending regular non-syn > packets, which your backup-now-master PF will drop. > > > On topic, if anyone has an awesome idea around this, I'm all ears, this > exact topic is causing us some level of discomfort at work, when we need > to swap firewalls for updates. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" I don't see this option on FreeBSD 9, but on OpenBSD pfsync has a defer flag that would appear to address your issue. The options are as follows: defer Defer transmission of the first packet in a state until a peer has acknowledged that the associated state has been inserted. See pfsync(4) for more information. -defer Do not defer the first packet in a state. This is the default. From pfsync(4) The pfsync interface will attempt to collapse multiple state updates into a single packet where possible. The maximum number of times a single state can be updated before a pfsync packet will be sent out is con- trolled by the maxupd parameter to ifconfig (see ifconfig(8) and the ex- ample below for more details). The sending out of a pfsync packet will be delayed by a maximum of one second. Where more than one firewall might actively handle packets, e.g. with certain ospfd(8), bgpd(8) or carp(4) configurations, it is beneficial to defer transmission of the initial packet of a connection. The pfsync state insert message is sent immediately; the packet is queued until ei- ther this message is acknowledged by another system, or a timeout has ex- pired. This behaviour is enabled with the defer parameter to ifconfig(8). I'm sure this could be ported over. -Nick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FC7CBBC.6090204>