On Mon, Nov 5, 2012 at 1:41 PM, Jerome Alet <[email protected]> wrote: > Me, again :-) > > I've noticed something that might be helpful... > > When I have upgraded the slave member of my pfSense cluster, the version > number of the configuration file changes from 9.0 to 9.1 > > So I've got two members of the cluster with different versions, since > I've not upgraded the master yet, and I'm not sure I want to do it > before knowing the source of my problem. > > So master is still in 9.0 and slave is in 9.1. > > Could this be the cause of my problem ? I mean, when the master tries to > sync its configuration to the slave, doesn't it break the slave's > configuration ? > > Is the proper way to upgrade by upgrading the master first ??? > > Does this mean that if I upgrade the master now, all will be fine again > ?
Everything you did was fine as you did it, it's preferable to upgrade the secondary first, test it by disabling CARP on the primary, and if successful then upgrade the secondary. Doesn't really matter which order you do it in, but doing the secondary first makes it easier to keep traffic off of it should something go wrong with the upgrade (as the primary will always want to take over CARP, the secondary won't unless you take the primary down). You're running into some kind of regression and I'm not exactly sure what. I have a suspicion it's related to the various problems with if-bound states, but not sure. You can try either upgrading to a November 6 or newer snapshot, or just removing the line containing "set state-policy if-bound" from /etc/inc/filter.inc and reloading the filter rules under Status>Filter reload. See if that changes anything. Keep doing that only on the secondary and don't upgrade the primary until the secondary is fixed as it's almost certain it'll break too. _______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
