active-passive firmware upgrade

[apex]

Hi All, I wonder if you can help me. I' ve got two Fortigate 110C boxes running in an active-passive cluster. They are on the firmware 3.0 and I' d like to upgrade them to 4.0 MR3. I know that I can' t jump directly from 3.0 to 4.0 MR3 and will have to do it step by step, but I was wondering what is the best way to do it. Do I upgrade the master first and slave will automatically get upgraded? or do I have to break the cluster? And do it separately? How does the process look like? Thanks in advance! A

[apex]

Thank you ede_pfau, I just checked the release notes for 4.0.4 and as you mentioned - the upgrade is supported from v3.00 MR6 P4 or later, or MR7 P2 or later. I' m on MR7, but is there a way to find out which patch release am I on? Just want to make sure I can jump directly to 4.0.4, rather than 3.0 MR7 P2. Thank you once again! A

[ede_pfau]

Fortinet uses a build number to unambiguously identify the firmware. Get that from either the web GUI (don' t ask me where in v3.00) or the CLI with " get sys stat" . Every version with build# >= 733 should be fine then.

[apex]

Thank you ede_pfau, Mine is: Version: Fortigate-110C 3.00,build5418,090402 Branch point: 741 So I' m guessing - I' m qualified

[ede_pfau]

build 741 indicates that your build is based upon 3.00 MR7 patch5. So go ahead.

[apex]

Thank you ede_pfau for all your help!

[apex]

Hi All, I' ve got a quickie - how would you proceed with a manual upgrade? What steps do I need to take? Thanks for your help! A

[ede_pfau]

hmmm - all upgrades are ' manual' . Just refer to the second post in this thread. In the Web GUI, applet ' Licenses' , click ' Upgrade' in the FortiOS line. You are addressing a cluster so no need to configure the 2 FGTs individually. As always: - plan for an network outage this usually is just seconds (per version, you will take several steps) but you never know - make config backups before each upgrade step! as you have the firmware images you can always step back and make it run again if anything unfortunate happens - check the config errors from the CLI (see above for command)

[apex]

Hi ede_pfau, Thank you for your reply - what I meant was - how does this process look like if I' d like to break the cluster and do it separately. Do I need to set up an IP address on the slave after breaking up the cluster in order to connect to its webinterface? or once the cluster is broken, I shall be able to connect to it using the original IP address of one of the interfaces, and proceed with the upgrade? Thanks, A

[ede_pfau]

If you break up the cluster, both units regain their respective IPs that were configured before forming the cluster. If you started with a ' naked' slave-to-be then most probably the interfaces won' t have any IP addresses (but I' m not sure about this as I' ve never done it this way). And yes, to connect to the FGT it must have a unique IP address on the interface you are connected to (physically). You have to watch out that you don' t have 2 devices on the same subnet with identical IP addresses, and that applies to all interfaces (internal, WAN, DMZ etc.) All that changeing of the configuration during the upgrade process carries the risk of a malconfiguration. And it leads to longer network downtime as the units have to change back to the virtual cluster MAC address when re-combining. So why would you prefer to do the upgrade on a splitted cluster? Way too much hassle. Some years ago this used to be a viable alternative as one couldn' t be sure if the inter-cluster upgrade went through OK. But that is long ago, and you' re best off if you upgrade the cluster ' as-is' . Maybe some other forum members could contribute their experience with cluster upgrades, too.

[apex]

Thank you for your reply. So after breaking the cluster, upgrading the 2nd and then 1st box, I shall be able to re-connect them easily and it all shall be working as it was. Or the cluster needs to be re-configured? Thanks, A