On 5/31/12 9:51 PM, Nick Gustas wrote: > 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-unsubscr...@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 >
This mimics the behavior of some manufacturers like Juniper and is *definitely* the kind of option we're looking for. While I lack the skills to port this, I'm definitely available for testing. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
