Upgrading 600E failover pair

[ps48625]

Hi

I am planning an upgrade of two (HA Pair) of 600E firewalls.  They are currently 6.08 and I will need to go through several steps to get them to required version 6.4.5.

My question is- would it be safer to shut down the switch ports on the secondary firewall and just upgrade one of the firewalls (and then upgrade the secondary firewall in a different change window) ?  If there were any unexpected issues this would enable me to fail back to the secondary firewall safely.

I have done a similar process with other vendor's firewalls but am not sure if this method is supported or advisable with Fortigate firewalls.

Many thanks

[Toshi_Esumi · Accepted solution]

If your network tolerate longer downtime, you could isolate the backup in case the upgrade is not one step like your case. If one step, it's easy to swap the boot partition back if something goes wrong.

But eventually you need to figure out what was exactly wrong with 6.4.x (6.4.6 has been released) in live. And it would double your work and time. Then finally, as long as you keep the config backup for each step, you can always flush the drive and load the whatever the version you want to go back to, then upload the saved config.

So we never did the way you're considering. 

[Toshi_Esumi · Accepted solution]

If your network tolerate longer downtime, you could isolate the backup in case the upgrade is not one step like your case. If one step, it's easy to swap the boot partition back if something goes wrong.

But eventually you need to figure out what was exactly wrong with 6.4.x (6.4.6 has been released) in live. And it would double your work and time. Then finally, as long as you keep the config backup for each step, you can always flush the drive and load the whatever the version you want to go back to, then upload the saved config.

So we never did the way you're considering. 

[ps48625]

Thanks very much for you reply.  Yes I think it is better to do as you suggest rather than upgrading in two change windows

[BK_LGW]

toshiesumi wrote:

If your network tolerate longer downtime, you could isolate the backup in case the upgrade is not one step like your case. If one step, it's easy to swap the boot partition back if something goes wrong.

But eventually you need to figure out what was exactly wrong with 6.4.x (6.4.6 has been released) in live. And it would double your work and time. Then finally, as long as you keep the config backup for each step, you can always flush the drive and load the whatever the version you want to go back to, then upload the saved config.

So we never did the way you're considering. 

Hi, I'm in a similar situation with two 501E FGTs in A/P HA. Mine are currently running 6.2.1 and I've read that staying on .0 or .1 releases leaves you plagued with bugs so I was considering upgrading them to 6.4.6 - BUT in order to get the go-ahead, I need to show higher-ups that 6.4.6 doesn't break anything (especially IPsec VPN, remote work is big) by introducing any new bugs. I was thinking I'd be able to do that by splitting my HA into two units, upgrading one of them to 6.4.6 and leave the other on 6.2.1 and then I'd let them run independently for a week or two. I'd do some testing with small groups of people and gradually increase and if nothing breaks, I'd use the test results and experience to convince execs to allow for the full upgrade. I take your point that there'd be double work and time but I don't see another way to test the release before committing to it.  What do you think, Toshi? Also - I wonder if I should go all the way to 6.4.6, I've seen good things about 6.2.8.

[ede_pfau]

IMHO you are missing a test environment - you don't fully trust the upgrade but have to resort to the second production machine for testing and fall back, resp.

You should know that the main versions at the moment are FortiOS 6.0, 6.2, 6.4 and 6.8 a.k.a. 7.0. Within the respective main version you should upgrade to the latest patch asap. This will take care of functional bugs and security flaws.

Upgrading to a higher OS version needs some consideration. Usually, with a lot of new stuff and 'better ways' to handle known features, the syntax will change in parts which makes reverting difficult. Upgrading does a good job in trying to adjust syntax changes, but you have to understand the stuff first.

And, a new main version starts with patch 0, and we all know "never upgrade to patch 0 or 1" (or anything below patch 5) may save your butt some day.

So, in my opinion, one should keep patching up and upgrading apart.

In your case, patching up to 6.2.8 is a very good choice. If you are running a cluster, you will have good reasons for it, so keep it functional, patch it as a cluster. Then, consider upgrading if you need new features or want to learn, plan downtime, keep backups, test every aspect of your config but do it on a spare firewall in the lab.

[BK_LGW]

Thank you for this great reply, ede. I hadn't considered patching and upgrading as separate processes but you're absolutely right. After I reviewed 6.4.6's release notes, there aren't many features that would justify an upgrade for now. Our biggest use is really SD-WAN, IPsec VPNs, UTM and authentication via FSSO. 6.4.x doesn't seem to improve any of those and there aren't performance improvements I've read about. I'll work on comparing 6.2.8 and 6.4.6 but I'll likely stick to 6.2.x. As for lack of test environment, it's an unfortunate situation but I may be able to get a spare unit next year to act as a backup in storage. That could act as a lab until it's needed. I'll still likely have to prove to higher ups that 6.2.8 is proper before I can get the go ahead to update both. It's just that kind of production environment but I'll try to convince them of otherwise.

[nomeursy · Accepted solution]

Did upgrade a HA pair of FTG1200D’s with 140 VDOMS, 250+ VPN tunnels, running on it, last year. Patched it from 5.6.x to 6.0.8 (followed the supported upgrade path of if I remember correctly was 5 steps) But I did first break the HA and took 1 off-line (cables disconnected, WAN-LAN and HA), did the upgrades and checked after every step the config and logs. Then wen done, I swoped the cables, so the upgraded unit was handling the traffic and the other was off-line (lost about 10 seconds of traffic during the swop). Run it for 2 days, then upgraded the other unit and restored the HA. After the HA was in sync, patched the WAN and LAN cables off the off-line unit and done. Yes, double the work, but much less stress about everything was working after the upgrade. The network and connectivity could not go down for long period off time 24/7, so about 4 hiccups in connectivity of about 10 seconds spread over 2 days, it was verry much acceptable. Wouldn't do it any other way!

[BK_LGW]

Thank you for this. We ended up breaking another HA of two 301E units and using one of those as the test unit. It'd have been easier to do the 501E production one but higher ups wanted to be cautious, which I agree with. So now the 301E is humming along on 6.4.6 with no problems thus far. I need to get some more traffic through it make sure nothing weird happens but I think it's a success. *knock on wood

[joepope]

Since it is an HA cluster, the firmware upgrade takes care of both nodes.  The cluster will failover the sessions and upgrade each node.  if you block one node your cluster may get out of sync and it is a pain sometimes resolving that.  I have never had issues will firmware upgrades on the HA.  Just make a backup first.