R80.40 - R81.10 Upgrade sequence

[seanmc12]

I have a few firewalls to upgrade and want to do the management and log server 1 weekend, then do the gateways the following weekend. I know the Management server can be the same or a higher version than the gateway with limitations to the functionality of the lower level. Can the log server be on R81.10 as well while the Gateway is on R80.40?

I have a Central 6500 HA pair and then 4 remote 3800 firewalls. When I go to upgrade, should I do the 6500 HA pair first, then do the remote 3800s or upgrade the remote 3800s, then do the 6500 pair afterwards? When I am upgrading, will this break the SIC connection between them during or after the upgrade?

[_Val_ · Accepted solution]

Basically, you are on the right track. Upgrade you management servers, then log servers, and then finally, your security GWs. SIC will not be broken, remote upgrade is also possible.

For more details, please refer to the Installation and Upgrade Guide for R81.10

[the_rock]

I did something similar for a big customer few months ago. So, here is what we did and worked just fine. It was also from R80.40 to R81.10 and all upgrades were done in place from web UI

1) upgrade management server first -> reboot...verify cpm is up and dashboard works (you can do this by typing watch -d $FWDIR/scripts/./cpm_status.sh from ssh when device reboots and you see message management is up and ready, thats sign smart console will work)

2) upgrade log server with same method, verify it works

3) If all good, make sure logging still works and then upgrade gateway(s)...if single gateway, same process, if cluster, this is best way to do it...always standby first, reboot, change version of cluster in dashboard to R81.10, push policy (UNCHECK option "if it fails..." in install pop up window), verify connectivity), if all good, issue cpstop on current R80.40 active member, upgrade it, reboot, push policy (recheck "if it fails..", test connectivity

4) confirm VPN, browsing, inbound/outbound. natting, speed test and also cluster state, run cphaprob roles or cphaprob state on both members, make sure sync IP shows there and active/standby and you can also test failover by running clusterXL_admin down and clusterXL_admin up commands

Cheers,

Andy