Re: Upgrading a CARP firewall cluster
‐‐‐ Original Message ‐‐‐ On Tuesday, April 30, 2019 9:29 PM, Lyndon Nerenberg wrote: > On our systems, we run the 'a' machine as primary and the 'b' machine > as backup. When upgrading, we do the 'b' machine first, since this > doesn't disrupt the primary. After the 'b' machine is fully configured, > monitor its state table to ensure it's consistent with the 'a' > machine. Once you are convinced pf is staying in sync, demote the > 'a' machine and upgrade it. Thanks for your procedure tips, that's pretty much the same procedure I use except that I didn't even demote the "a" machine before upgrading it. Now I guess demoting the machine in question before upgrading it is the best practice and so I checked the OpenBSD FAQ about CARP and see different methods. The "carpdemote" way seems the cleanest way so as I have 8 carp interfaces all in the default carp group, should I simply run the following command: $ ifconfig -g carp carpdemote 50 or what is your way of demoting the server before upgading it? Regards, Mabi
Re: Upgrading a CARP firewall cluster
mabi writes: > Now I would first like to upgrade the cluster to 6.4 and then to 6.5 and was > wondering if it is possible to operate that cluster for a short amount of tim > e having one node running 6.3 and the other node with 6.4 and then the same f > or going to 6.4 to 6.5. In general this is not a problem. We run several carp-ed firewall (and load balancer/proxy) pairs, and upgrade them in this manner. As was already mentioned, always read the release notes to look for carp or pfsync changes that might cause trouble. On our systems, we run the 'a' machine as primary and the 'b' machine as backup. When upgrading, we do the 'b' machine first, since this doesn't disrupt the primary. After the 'b' machine is fully configured, monitor its state table to ensure it's consistent with the 'a' machine. Once you are convinced pf is staying in sync, demote the 'a' machine and upgrade it. Make sure you have 'net.inet.carp.preempt=1' in /etc/sysctl.conf, and set advskew appropriately on each host in the pair. --lyndon
Re: Upgrading a CARP firewall cluster
mabi(m...@protonmail.ch) on 2019.04.30 08:21:43 +: > Hello, > > I have an OpenBSD 6.3 firewall cluster made out of two nodes (one master, one > backup) using CARP and pfsync. This cluster also makes use of trunk and vlan > interfaces. > > Now I would first like to upgrade the cluster to 6.4 and then to 6.5 and was > wondering if it is possible to operate that cluster for a short amount of > time having one node running 6.3 and the other node with 6.4 and then the > same for going to 6.4 to 6.5. > > Is this safe? or could there be any incompatibilities in carp/pfsync which > would prevent me to do that upgrade in two steps while keeping everything > online? > > Cheers, > Mabi This is only a problem when we change the protocols involved, and that would be mentioned in the upgrade guide. Since there were no protocol changes to carp(4) or pfsync(4) between 6.3 and 6.5, you should not have a problem with this upgrade. In fact, you could go 63 -> 64 -> 65 on one firewall while the other stays on 63. /Benno
Re: Upgrading a CARP firewall cluster
‐‐‐ Original Message ‐‐‐ On Tuesday, April 30, 2019 11:20 AM, Igor Podlesny wrote: > CARP should be of no worries at all and PF state table's sync is > easily verified. > If after backup's upgrade-reboot it has roughly same amount of entries > you can safely demote master and repeat procedure. > Even if there were some major differences maximum what you could loose > is connections state table. Thank you Igor for the details. As you mention it doesn't really matter much if the connection state table gets lost in the worst case.
Re: Upgrading a CARP firewall cluster
On Tue, 30 Apr 2019 at 15:24, mabi wrote: [...] > Is this safe? or could there be any incompatibilities in carp/pfsync which > would prevent me to do that upgrade in two steps while keeping everything > online? CARP should be of no worries at all and PF state table's sync is easily verified. If after backup's upgrade-reboot it has roughly same amount of entries you can safely demote master and repeat procedure. Even if there were some major differences maximum what you could loose is connections state table. -- End of message. Next message?
