FG100D Upgrade from 4.0MR3 Patch 15 to 5.2.2

[Holy]

Hello,

i have to upgrade an 100D cluster from 4.0MR3 patch 15 to 5.2.2 

anyone has experience with updating it step by step? should oit go smooth or should i plan a lot of downtime?

another question. I thought to do it this way (think it will be safer)

- take 1 of the 100D from cluster

- update that appliance step by step to 5.2.2 

- change it with the active master that still have 4.0MR3

- test if everything works

- Update the another 100G with 4.0MR3 by putin in an USB with 5.2.2 image and a new 5.2.2 Config

- Reebot the 100G 4.0MR3 - it will now boot with new image and new config (will it work that way? )

- Connect the Cluster Members again als Active - Passive.

what do you think about it guys?

[Dave_Hall]

Read the documentation on Supported Upgrade Paths for FortiOS firmware, it includes information on HA configuration upgrades.

[Toshi_Esumi]

I don't think they can be in the same cluster if the firmware version is different. We regularly upgrade them (two units) as a cluster. But V4 to V5.2 is a big jump. I believe you need to take at least 1 or 2 intermediate steps before finally get to 5.2.2. You need to check the release notes backward from the final version toward v4MR3. Otherwise you might lose some config in the process.

We're currently running v5.0.9 for most of our FW clusters (upgraded from v4.0MR1 step by step time to time). Since 5.0 added more config integrity check, we lost some config, which were working by luck (conflicting config but working one was the first one). We needed to remove the conflicting but not working one, then put the working one back in. The upgrading process throws them out. Again, I strongly recommend what has changed through release notes of at least major versions.

[Holy]

you got me wrong.

i don´t want to put 2 different versions in one cluster.

look i will remove cluster > than i have 2 Device > i will leave 1 Device active and working on 4.0mr3

another Device i will disconnect completly from network > so there is no cluster anymore just a standalone appliance

i will Upgrade the removed appliance step by step with Upgrade Guides and so one, testing the config till it is on 5.2.2

i will Remove the Appliance with 4.0MR3 and put the new Upgraded 5.2.2 instead > i will test if everything works > then i will create an usb stick with 5.2.2 firmare image and the new 5.2.2 working config > then i will put That usb stick into the Appliance with 4.0mr3 > reboot it > after reboot it should be on 5.2.2 with this new config ( will it work that way? )

Now after i have both appliances on 5.2.2 i will put them into Active - Passive Cluster again.

thats my plan.

P.S. i mean of course upgardin it to 5.2.3

toshiesumi wrote:

I don't think they can be in the same cluster if the firmware version is different. We regularly upgrade them (two units) as a cluster. But V4 to V5.2 is a big jump. I believe you need to take at least 1 or 2 intermediate steps before finally get to 5.2.2. You need to check the release notes backward from the final version toward v4MR3. Otherwise you might lose some config in the process.

We're currently running v5.0.9 for most of our FW clusters (upgraded from v4.0MR1 step by step time to time). Since 5.0 added more config integrity check, we lost some config, which were working by luck (conflicting config but working one was the first one). We needed to remove the conflicting but not working one, then put the working one back in. The upgrading process throws them out. Again, I strongly recommend what has changed through release notes of at least major versions.

[Toshi_Esumi]

I don't know if booting it with the image and config on a USB mem is possible. You should ask Tech Support. But if you have local access to the units, which seems, you just need to upgrade the second one whatever the method is and attach it back to the cluster as backup then config would sync to the master/first one.

[emnoc]

I don't know why your making things so hard. No matter what your thinking you still have th a upgrade to take and it will be time consuming ( not much ) and service impacting.

To go from  4.0 MR315 to 5.2.3 is going to required a few upgrade steps, you can boot from a usb , and your flash only can hold 2 boot partitions. So if your worried, make 2 upgrades  maybe split the upgrades over 2 weekend so you can feel and test

i.e 4.0

MR3 to 18 and then 5.0.12 , weekend one

And the next weekend you go to 5.2.3

Just make a config backup thru-out  the process and between every upgrade and you should be very.

FWIW: This is not a very hard  process and plenty of others have done this with zero issues.

[Holy]

i do not try to make things hard :) but i am looking for a solution that will minimize downtime.

i don´t know if it will work that way, but hey at least i can try :)

what i realy want to test is, if i put an USB stick with 5.2.3 image and 5.2.3 config in a appliance with 4.0MR3 and reboot it, will it update then immediatly after reboot and without issues ? if so, than my way should work really good.

emnoc wrote:

I don't know why your making things so hard. No matter what your thinking you still have th a upgrade to take and it will be time consuming ( not much ) and service impacting.

To go from  4.0 MR315 to 5.2.3 is going to required a few upgrade steps, you can boot from a usb , and your flash only can hold 2 boot partitions. So if your worried, make 2 upgrades  maybe split the upgrades over 2 weekend so you can feel and test

i.e 4.0

MR3 to 18 and then 5.0.12 , weekend one

And the next weekend you go to 5.2.3

Just make a config backup thru-out  the process and between every upgrade and you should be very.

FWIW: This is not a very hard  process and plenty of others have done this with zero issues.

[emnoc]

if i put an USB stick with 5.2.3 image and 5.2.3 config in a appliance with 4.0MR3 and reboot it, will it update then immediatly after reboot and without issues ? if so, than my way should work really good.

Unless something changed in  FortiOS as a  new feature, than the short answer is no. You can upload the cfg via http or tftp, but not from a usb-device AFAIK

Ken

[Christopher_McMullan]

There is the usb-auto-install option in the CLI and in the GUI under System > Config > Advanced. It requires that a functioning version of firmware is already present on the FortiGate when booting with a USB drive inserted, and that the settings allowing either or both the upgrade of firmware or restoring the config are enabled.

I think the drive has to specifically be running FAT16 as a file system, which is one limitation.

When the drive is detected and mounted at boot time, the FortiGate will check in the root directory of the drive for a config file named "fgt_system.conf" and/or an image named "image.out" by default. You can change the file names that the FortiGate looks for. If it finds either, then if the image is a newer build than the current one, and/or if the config revision is newer than the running config, they will be upgraded/restored.

This is *not* a reliable solution for upgrading a device remotely, or in place of a console connection. You would have no way of knowing whether the upgrade/restored succeeded except anecdotally, if you notice traffic handling you didn't expect, or worse yet, the FortiGate stops passing traffic entirely. All that being said, you can use USB installation as a file source instead of TFTP or GUI uploads. Just make sure you upgrade with a working console connection. It would still be a good idea for redundancy to have a patch cable handy, and have the laptop loaded with a TFTP server program and a copy of the config and/or image you are trying to load.

[Holy]

Christopher McMullan_FTNT wrote:

There is the usb-auto-install option in the CLI and in the GUI under System > Config > Advanced. It requires that a functioning version of firmware is already present on the FortiGate when booting with a USB drive inserted, and that the settings allowing either or both the upgrade of firmware or restoring the config are enabled.

I think the drive has to specifically be running FAT16 as a file system, which is one limitation.

When the drive is detected and mounted at boot time, the FortiGate will check in the root directory of the drive for a config file named "fgt_system.conf" and/or an image named "image.out" by default. You can change the file names that the FortiGate looks for. If it finds either, then if the image is a newer build than the current one, and/or if the config revision is newer than the running config, they will be upgraded/restored.

This is *not* a reliable solution for upgrading a device remotely, or in place of a console connection. You would have no way of knowing whether the upgrade/restored succeeded except anecdotally, if you notice traffic handling you didn't expect, or worse yet, the FortiGate stops passing traffic entirely. All that being said, you can use USB installation as a file source instead of TFTP or GUI uploads. Just make sure you upgrade with a working console connection. It would still be a good idea for redundancy to have a patch cable handy, and have the laptop loaded with a TFTP server program and a copy of the config and/or image you are trying to load.

So you agree that it can be a more safer to Upgrade a cluster that way? 

of course i will have the physical accsess to that unit and make sure that auto-update is on.