Just wanted to say a sincere thanks. Several KBs were getting me lost and your situation/version is almost the same as mine so this was extremely helpful. Now time to knock out the updates before the critical cert issue hits.
Hi, no problem, glad it was useful, the cert issue is very unfortunate and to be honest the guidance from Palo themselves was a little vague lol, hope you get it all sorted and thank you very much for watching and commenting!
Hi, at 1:18 and 1:29 where does it say that you need to disable config sync? The official KB article only mentions to disable preemption. They say that you only need to disable preemption on one but not the other. But here you are referring to config sync. However , I couldn't find anything on the official HA firewall upgrade process KB article that mentions anything about disabling config sync. Did you possibly get config sync mixed up with preemption?
Hi Yes the official KB article does not make any mention of disabling the config sync for the upgrade process, however as with everything else in this industry there are multiple ways of achieving the same goal, personally if I am carrying out work that means the firewalls in a HA pair are being worked on independently (as in the case with HA upgrades) I want them as isolated from their partners control as possible, in fact I have seen issues where firewalls have had a config change half way through the process and hit commit errors which have then gone onto cause issues with traffic, in a lab this is fine but if it stops a production line as a result you usually have to start dusting off your CV if you were responsible! So no you don't have to at all and there is nothing wrong with not doing it is simply what I like to do to be as sure as I can that I am in control of the firewall and it's config and not the HA partner. Just as a side note I think it is important to remember that videos such as this where the process is well documented only really serve as a guide, seeing the steps written down in an official KB guide are awesome, but they are always happy path what I mean by this is clean firewalls in a demo or non-live environment, mostly they are firewalls/platforms that are set up specifically for the article to be written and screenshots taken, this video and others like (I hope) will supplement this by being able to watch a live run through of the process from an experienced point of view with things thrown in that are usually as a result of production experience. Thank you for watching!
Hi Good question, As long as the licenses show valid under Device > Licenses then you should be good to go, as far as I am aware there is no license requirement for upgrade, you do need a license to contact the license server and download the images from Palo Alto but without a license you can upload the file manually and upgrade. Hope that answers the question and thank you for watching!
Hey mate. This is nice and detailed. Just wondering, I see the plugins and I realise you are using these Palos in the Azure cloud. Would you advise the Azure HA method, like the one in your video, or the Loadbalancer method? I'm mulling over these, and I have to make a call on this shortly. Would like to know your opinion
Hi , These are actually VM-Series on ESXi they have the VM-Series plugins as well as Azure hosted, when deploying firewalls into Azure I would always prefer the Loadbalancer method, the firewalls when managed by Panorama can easily be kept in sync from a policy point of view and it provides a lot more flexibility when upgrading or troubleshooting, I am not sure about Azure but certainly in AWS traditional HA was always a bit skittish due to needing to make API calls to re-allocate interfaces etc. Thank you for watching!
You cut the video at minute 9:24, what problem did you have? I assume that the firewall went down and it took you an hour to recover it, If so, please tell us the error and how to recover it or avoid it?
Hi, Thank you for watching so closely! I think that you must be looking at the last login time and session expire times in the bottom left hand corner of the webui, these are the only time signatures I can see displayed on the video, these are not reflective of the actual time the video was shot just the last time logged in, the only thing I can think is that possibly one firewall was set to GMT and one to UTC (UTC does not have summertime) to account for the hour difference, that video was a long time ago now but I certainly don't remember any hour long recovery session, at 9:24 I am failing over the firewalls, as long as the HA is good (which it was) and the sessions were building there is very little that could go wrong. Thanks for watching!
Hi Yes that is the best practice for the upgrade procedure, and is how I did this in the video, if you look around the 6:30 mark you will see that the active firewall is suspended and then upgraded. Thank you for watching !
Yes thank you I was too impatient!@@mode4480 Great tutorial! I would make sure before all this, to make sure my HAs are healthy, has the latest content versions & in sync with PANORAMA. I just like to be very cautious as my environment cannot afford a downtime. AWESOME that you only lost 4 pings, doing an upgrade tomorrow, fingers crossed
No problems at all! have my fingers crossed for you too, I have had very few issues in general when upgrading Palo firewalls as the process is so well designed at the OS level, and of course if things go really wrong there is always the second boot partition you can roll back to.
Hi The truth of this as I often say is you could either, essentially by failing over to the passive and allowing your traffic to run across the same version of code as it was doing means that not only do you confirm that a failover works and traffic flows whilst you still have the known good version of code running on what was the active firewall (so in any failure event you could fail back) but also that version of code you are upgrading to on the now passive (previously active) is going onto a known firewall as it was passing traffic only seconds ago. Let's remember here that in Active/Passive one of the firewalls has been sat for however long it was since the last failover event and has just been receiving session information from the active, in our case as Palo engineers as long as the content versions match and the HA interfaces can see each other all will appear well, but there are a lot of things going on that can get themselves in a knot on the passive with the OS that could cause issues when upgrading or processing traffic. So, while you can indeed upgrade the passive firewall first then failover to it, what you would be doing in essence is taking a very secure process with a very predictable outcome and changing it to we are going to move traffic onto a firewall that has not been processing production traffic for a while and will be running a new version of software. Basically it is down to your appetite for risk, and in a production environment I do not like risk so I do it this way, but both ways will work and are valid. Hope this helps! and thank you for the question!
what is the scenario of upgrading HA pair ,where we first upgrade passive firewall. I am bit confused because over teacher told us to upgrade first passive one but actually steps i don't know. kindly clear this confusion.
HI, I'm not exactly sure what you mean, but everyone has their own method for teaching the best way to do things. Take HA upgrades, for instance. If you upgrade the Passive unit first, there should be no disruption to service, right? But what if there have been config sync issues in the past? When you failover, the policies/connectivity might not be the same, potentially disrupting traffic. Alternatively, you could upgrade the Active unit. The firewall should failover as a result of the reboot, theoretically causing no disruption since the failover should be seamless. But what if the failover doesn't happen as expected? If we have a stable pair of firewalls and we failover to the Passive, monitor traffic, and then continue with the upgrade process on the newly Passive device, then fail back and upgrade the Passive again, the chances of causing an issue are reduced. Ultimately, there are multiple ways to achieve results in networking/security. In my opinion, the best approach is to try and minimize disruption to production traffic. Hope this helps!
I am not sure at which point you mean, but we disable config sync to avoid any exchange between the two, then we suspend the active firewall to make it passive in order to upgrade as it will not be serving traffic, to completely control this we also disable preempt (where it is configured) to avoid the newly upgraded firewall taking over when it comes back up, then we will fail back using suspend to upgrade the remaining firewall, essentially the suspend step is create a graceful failover rather than simply rebooting. Hope this has helped, let me know if you have any more questions. Thank you for watching!
There are some other considerations depending on how far back you are going, but as a general rule yes, an example of the downgrade advice from Palo for 10.2 to 10.1 for instance can be found here, docs.paloaltonetworks.com/pan-os/10-2/pan-os-upgrade/upgrade-pan-os/upgradedowngrade-considerations#idabba79e8-9c44-4360-b961-db7f118df20a ( I really need to shorten the URLS but I think sometimes they look dodgy ) let me know if you think a video on downgrade would be useful and I can put one together. Thank you very much for watching!
Lol, in the meantime if you haven't made many changes to the configuration of the firewalls you could always switch partitions, not sure if you know this but Palo Altos maintain two boot partitions, when you upgrade the device you are actually upgrading the non active partition and then as part of the reboot the bootloader uses the new partition, from operational prompt, use the command debug swm revert and it will switch back the partition and boot into the previous version of code. Useful if it all goes completely wrong!