Upgrade secondary PA

[jdprovine]

i have done this in the past to save time but I was interesting in hearing what the community has to say about and if anyone else has done this

I usually upgrade my secondary PA the afternoon before I do the primary ithe next morning and they are in a mismatched state for 12 hours. I am now going to do an upgrade from 7.0.12 to 7.1.0 and then to 7.1.0.9.

So the plan is to upgrade the secondary on a Thursday night first to  7.1.0 and the to 7.1.0.9 and leave it till Friday morning. Then on Friday morning I  would fail over to the secondary , upgrade the primary to 7.1.0 and then to 7.1.0.9 and then fail back to the primary.

I look forward to you comments and suggestions

[BPry]

@jdprovine,

I haven't ever let it go a full 12 hours but I'll commonly upgrade our secondary unit during the afternoon and then upgrade our primary unit during the evening during off hours. I really haven't had any issues with it outside of once where our primary unit went down due someone not paying attention to what power cable went where, it failed over to the secondary unit and traffic passed perfectly fine and nobody noticed. 

I wouldn't say that leaving a version mismatch is a common practice but I wouldn't really call it a dangerous one either. 

Just wanted to ponit out as well that you don't need to actually install 7.1.0 as the base image to upgrade to 7.1.9 if you are already running 7.0.12. You simply need to have both 7.1.0 and 7.1.9 downloaded and then perform the upgrade to 7.1.9; you don't need to actually install 7.1.0 and then install 7.1.9

[jdprovine]

Well I put a ticket into TAC and they told me that I had to install 7.1 before going to 7.1.09. The only issue I have run into during a mismatch condition is that I cannot commit a security policy. 

Yeah and there is that chance that the primary dies and it fails to the secondary and something in the upgrade does not work LOL

[TranceforLife]

Interesting. As per Palo official guide @BPry is right:

But please read the @Raido_Rattameister comment here. I think safer to install anyway 

[reaper]

lemme see if I can review all the articles and 'fix' inconsistencies

the normal process of going from one major version to the next, is to download the base only, then download and install the minor version and reboot (the base imagis is only required to provide base files to the oprating system not included in maintenance packages)

It doesn't hurt to install the base image, but it has no effect as it will install on the standby system volume (hard disk partition), and then if you install the maintenance release, it will install to that same system volume and overwrite the previous installation

[jdprovine]

@TranceforLife

I believe you LOL but I think I will go ahead and install 7.1 and the 7.1.0.9, I don't know about the rest of you but TAC is very quick to respond but I am not as confident in the answers I have been receiving lately

[jdprovine]

LOL 

@reaper

I know you can read and find all the inconsistency , you have certainly helped me alot in the past reaper 

[Remo]

Things to remember: Always follow the documentation when upgrading ... 😛
Never try things like upgrading one firewall two minor/major releases while the second one remains on the old release (for example upgrade one to 7.1 while the other one still runs 6.1). Even if you don't care about lost sessions or other synchronized data. When the updated fw booted up completely ond both fw's see each other, BOTH firewalls will enter non-funcional state ...

[BPry]

@Remo,

That's the point of disabling 'preempt' prior to performing the upgrade to my knowledge. It prevents the firewall from freaking out because of a version mismatch. I've done exactly what you've described without any issues on a pair of 3020s. 

[Remo]

@BPry

In my case (also pair of 3020) I think it was when I tried to skip 6.0 or 6.1 ... not sure what it really was ... And normally I have preemtion disabled ...

I only remember that the firewall booted up and both suddenly saw both clustermembers as non-functional ...

Anyway but I probably don't try this again 😛

[jdprovine]

@BPry

Interesting I have never had the HA freak out when its been in mismatch