kyle wrote: > Hey list.. > > Im looking to upgrade my 3.9 boxes to 4.1. I plan on upgrading the > standby boxes first, and am expecting them to still be paired up > pf/carp/ospf-wise with the 3.9 active boxes while I burn them in. I > know in the past I ran into an issue where there were differences > between releases where pfsync wouldnt work(Im forgetting a bunch of > details), but the point being when that had happened I needed to pull > the trigger and upgrade the active firewalls at the same time as well. > > So, would pfsync work between a 3.9 and 4.1 box? Has the pf syntax > changed at all? Or can I restore my pf.conf from the 3.9 install onto > the 4.1 install without needing to make modifications? Would carp > still work? > > Anyway, any gotchas in a 3.9+4.1 pair of firewalls?
I'm not sure what you mean by "burn them in" -- these are existing machines, running 3.9..they've been burning in for over a year now. They work. Letting the standby boxes run 4.1 while all the traffic is going through the 3.9 boxes isn't doing any kind of testing at all. Do one box at a time, but keep moving, do them both. Don't split the machines like you are planning. You may have some issues on the 4.0 -> 4.1 transition, as the PF rule interpretation has changed, though that won't be a pfsync issue, that's a rules issue, and your 4.0 rules may run a tiny bit differently in 4.1 (and usually, better. It may fix things you didn't know you had problems with!) Do your work off-hours. That way, if you do break a state, it wont matter much, and probably no one will notice. Even if you ignore the CARP/PF issues, if you screw up, less likely anyone will notice. Some notes from a PF and CARP developer for a FAQ article, er..I haven't written: -1) Make sure your aliases match on the carp interfaces between boxes. You don't want to have five IP addresses on carp0 on one box and three on the other. Trust me on this. 0) Make sure your PF rules are synced, both on disk and in use. 1) completely upgrade your secondary box 2) Edit the hostname.carp files on the primary to have a higher advskew than the secondary. Yes, edit the files. 3) reboot primary, secondary will take over, and because of step two above, "primary" will stay..er..secondary. IF there was going to be a problem, this is when it happens. 4) Test. If there is any problem, fix or restore hostname.carp* on primary and reboot, primary will take back over until you figure out what went wrong. 5) Upgrade primary, verify states are syncing. At this point, either move the stickers on the firewalls showing which is primary and which is secondary, or restore your advskew values. Either way, AFTER the upgrades are complete, make sure both firewalls have had a chance to be "MASTER" to make sure it all works. This is non-peak time, remember? This is when you do this kind of testing. Do this all in one sitting. Don't leave it mixed-versions. Do it this way, and you really risk only one "bump" in the process. Nick.
