Best Practices for PAN-OS Upgrade

by on ‎09-06-2016 02:49 PM - edited on ‎06-25-2018 12:35 AM by Community Manager (191,451 Views)

Best Practices for PAN-OS Upgrade

The following procedure documents best practices for customers who are new to the PAN-OS upgrade process.  It’s intended as a foundation for customers who want to create their own more-specific upgrade procedures.

 

About the PAN-OS upgrade and customer responsibilities

  • You cannot skip installation of any feature  release versions in the path to your target PAN-OS

    release. Additionally, it is best practice to always download and install the latest maintenance release

    for each feature release and then reboot before you install the base image for the next feature

    release—this applies to each feature release through which you pass in the upgrade path.

  • In this example, we are upgrading a hypothetical customer (ACME, Inc.) from PAN-OS 7.0.16 to 8.0.6-h3 (with 7.1 as an interim step).
  • ACME firewall is configured in Active/Passive HA cluster managed by Panorama (this is the most common configuration in use today). We are not covering Active/Active, non-HA scenarios or scenarios where there is no Panorama installed.
  • This is a best practice document. It is not meant to be a step-by-step procedure.  Please create your own step-by-step procedure, if necessary.
  • Customer is responsible for verifying all steps before the upgrade.

Terminology

Active firewall

The firewall in an HA cluster that’s passing traffic

Passive firewall

The firewall in an HA cluster that’s not passing traffic

Primary firewall

The firewall in an HA cluster that’s usually the active firewall

Secondary firewall

The firewall in an HA cluster that’s usually the passive firewall

Feature release

 

Contains new features and bugfixes, typically ends with .0 (i.e. 7.1.0)

Maintenance release

Bug fixes only, typically ends with .number (7.1.2)

 

Dependencies

  • Before upgrade, make sure  the firewall is running a version of app + threat (content version) that meets the minimum requirement of the new PAN-OS (see release notes: https://www.paloaltonetworks.com/documentation.html).  We recommend always running the latest version of content to ensure the most accurate and effective protections are being applied.
  • Panorama should be running the same or a later version of a feature release than the firewall (up to two feature versions is supported but not recommended as of June 2016).

If the firewall is running

Panorama versions supported are

PAN-OS 7.0.x

7.0.x, 7.1.x, 8.0.x

PAN-OS 7.1.x

7.1.x, 8.0.x

PAN-OS 8.0.x

8.0.x

 

Table of contents

  1. Determine the need to upgrade
  2. Pre-upgrade checklist
  3. Panorama upgrade procedure
  4. Firewall upgrade procedure (HA)
  5. Post-upgrade checklist
  6. Troubleshooting resources
  7. Downgrade procedure

 

1. Determine the need to upgrade

  • In most cases, upgrade should be considered for only the following reasons:
  • We highly encourage customers to consult with Palo Alto Networks account team for upgrade decision. Your Palo Alto Networks account team can provide you with a recommended PAN-OS version.
  • For purpose of this document, we will be upgrading from 7.0.16 to 8.0.6-h3 to demonstrate upgrading process across two major releases (7.0 > 7.1 > 8.0).
  • NOTE:
    For any PAN-OS version prior to PAN-OS 8.0 (so PAN-OS 7.1 and lower) it is recommended to go to the latest maintenance release to prevent running into snags or issues during the upgrade.

  • Note about PAN-OS 8.0 base installation: 

    For PAN-OS 8.0, The additional (Optional when installing from the updates server. When installing from a manual file this step is mandatory) step of installing  and rebooting the base image was added to accomodate the larger size of the base image. This is considered best practice.

  • HA Upgrade NOTE:
    When upgrading across two major release versions at a time, there will be a time when there will be a network outage. Whereas if the devices are upgraded one major version at a time, HA will remain active, continue to synchronize sessions, and no network outage will be seen.

To maintain HA sync and activity, upgrade the HA pair in tandem one major release at a time. If you upgrade one device by two major upgrades, the newly upgraded device will stay in suspended mode with the error peer OS too old. So when you go to start the first OS upgrade on the second HA device, you will lose network connectivity until the upgrade is completed and the first device is moved out of suspended mode and into passive mode and HA capabilities resume functioning.

  

2. Pre-upgrade checklist

  • Review release notes.
  • Do not schedule Panorama and firewall upgrades at the same time.
  • Upgrade Panorama first, wait at least 24 hours and then upgrade the firewall.
  • A pro-active support case may be desirable for some critical environments, Please review this article: When to request a Support Event
  • Upgrade should be carried out during non-business hours to minimize impact.
  • Allocate sufficient time in the change window for upgrade, troubleshooting and possible downgrade procedures. It may take up to 2-3 hours to upgrade a slower/older system, depending on config. Multiply if upgrading across multiple versions.
  • Identify business contacts who will help verify application and network functionalities after the upgrade.
  • Back up configuration and device state before upgrade.
    2016-09-06_upgrade1.png
    • Device > Setup > Operations > Save Named Configuration Snapshot
    • Device > Setup > Operations > Export Named Configuration Snapshot
    • Device > Setup > Operations > Export Device State
      2016-09-06_ugrade2.png
    • Device > Support > Generate Tech Support File
  • Document any non-standard settings that should be applied post-upgrade
    • Disable tcp state checking
    • Non-syn tcp reject
    • Any debug setting if existing (not recommended)
  • Stage/Download necessary PAN-OS images ahead of time. You will need both the base image and the latest maintenance release. The base image should be installed but not rebooted.  In this case, we need to download the following versions
    • 7.0.18 (it is recommended to bring your current Feature release to the latest recommended maintenance release before preceding)
    • 7.1.0 (base image) (NOTE: If you are on a maintenance release version earlier than 7.0.6, you must install 7.0.6 before 7.1.0 will show up on your software download page)
    • 7.1.14 
    • 8.0.0 for firewalls, 8.0.2 for Panorama (base image) (NOTE: the 8.0 base image and maintenance versions will not become visible in the download section until you have a version of 7.1 installed)
    • 8.0.6-h3
  • Following the PAN-OS upgrade, you may need to upgrade associated software (such as Global Protect agent or User ID agent)
    • See the Associated Software Versions chart in the release notes
  • (Optional but recommended) Arrange for Out-of-Band access (Console access) to the firewall if possible. This is to help recover from any unexpected situations where we lose connectivity to the firewall after upgrade.

 

3. Panorama upgrade procedure

  • Make sure no policy or configuration changes are being made by acquiring a config lock
  • 2016-09-06_upgrade3.png
  • Click on padlock icon on upper right hand corner of GUI
  • If there are any locks, please remove the locks or talk with the admin who placed the lock in place, and remove or commit..
  • Clear or complete any pending commit job making a commit to panorama before starting the upgrade
  • (Optional but recommended) Post-upgrade failover testing:
  • Suspend Secondary Panorama to fail connection back to Primary Panorama to make sure failover still works after upgrade.
    CLI:
    > request high-availability state suspend
    GUI:
    Device > High Availability > Operations >  click Suspend local device

  • Verify suspend status on Secondary Panorama
  • Verify all firewalls are connected to Primary Panorama
  • Re-enable Secondary Panorama and High Availability function
    CLI:
    > request high-availability state functional
    GUI:
    Device > High Availability > Operations > click Make local device functional
  • Primary Panorama Upgrade procedure:
    1. Disable Pre-emption if enabled.
      (Disable preemption on High Availability settings to avoid unexpected failovers. Disabling preempt configuration change must be committed on both peers. Once completed, re-enabling must be committed on both peers).
    2. Go to Device > High Availability > Election Settings and uncheck Preemptive.  Then, commit the change:
      2016-09-06_upgrade4.png
    3. Suspend Primary Panorama to make Secondary Panorama as active
      From Primary Panorama, suspend High Availability function:
      CLI:
      > request high-availability state suspend

      GUI:
      Device > High Availability > Operations > click on Suspend local device. 
      2016-08-31_ha3.png
    4. Verify suspend status on Primary/passive Panorama.
    5. Verify all firewalls are connected to Secondary/active Panorama.
    6. On the Primary Panorama, download, install and reboot 7.0.18
    7. Download and install 7.1.0 (base version).
    8. Download and install 7.1.14, and reboot to complete the upgrade.
    9. Save/export tech support and Device state and save named device config snapshots (this is in case downgrade is needed).
    10. Download 8.0.2 (base version) (Recommended) Install the 8.0 base image and reboot before you install the target maintenance release.
    11. Download and install 8.0.6-h3, and reboot to complete the upgrade.
    12. Save/export tech support and Device state and save named device config snapshots (this is in case downgrade is needed).
    13. Re-enable Pre-emption, if so desired.
    14. This concludes upgrade on Primary Panorama.
  • Secondary Panorama Upgrade procedure
    • Download, install, and reboot 7.0.18
    • Download and install 7.1.0 (base version)
    • Download and install 7.1.14, and reboot to complete the upgrade.
    • Save/export tech support and Device state and save named device config snapshots (this is in case downgrade is needed)
    • Download 8.0.2 (base version) (Recommended) Install the 8.0 base image and reboot before you install the target maintenance release..
    • Download and install 8.0.6-h3, and reboot to complete the upgrade.
    • Save/export tech support and Device state and save named device config snapshots (this is in case downgrade is needed)
    • This concludes upgrade on Secondary Panorama
    • Backup config and device state files just in case:
      https://live.paloaltonetworks.com/t5/Configuration-Articles/Back-Up-Configuration-and-Device-State-f...

(Optional but recommended) Post-upgrade verification

  • Verify connectivity between Panorama and Firewalls. If something is not working, skip to troubleshooting section
    (For example, check if Panorama is receiving logs with correct time stamp from firewalls after upgrade is completed)
  • Test commit-all operations to managed devices, and verify new changes are applied as expected locally on the devices.

 

 

 

4. Firewall upgrade procedure (HA)

It is recommended to upgrade the Primary firewall first and then upgrade the Secondary firewall.  This is done for two reasons:

1.) Ensure that HA failover is functioning properly and 
2.) Ensure that the passive firewall is functioning properly and is able to pass traffic without issues.

  • Disable Pre-emption if enabled. Disable preemption on High Availability settings to avoid unexpected failovers. Disabling preempt configuration change must be committed on both peers. Likewise, once completed, re-enabling must be committed on both peers.
    To disable:
     Go to Device > High Availability >General > Election Settings <hit edit> and uncheck Preemptive. 
    Then, perform a commit. 
    2016-09-08_vpc6.png
    NOTE:
    This procedure relies on the administrator having foreseen access to their devices at all times, either by being local or having OOB connectivity to the management network which is best practice when upgrading the firewall. In the case where you do not have the option of achieving either, it is a good idea to change the procedure slightly to ensure you dont lose connectivity at the cost of having a less rigid upgrade path.

    Having the preempt enabled will require you to keep this config change in mind during the whole process as it could unexpectedly switch over the active membership while upgrading.

  • Primary firewall Upgrade procedure
    1. On Primary firewall, Suspend Primary firewall to make Secondary firewall active
      CLI
      > request high-availability state suspend
      GUI
      Device > High Availability > Operations > click Suspend local device
      NOTE: This will cause an HA failover. We recommend doing this first to verify the HA functionality is working before initiating the upgrade.  Production traffic is now going through the Secondary firewall which is now active.  
    2. Ask your business owners to verify all applications are working on the network.  If there is a problem, skip to troubleshooting section. If there is any problem, fix it before proceeding with upgrade.
    3. Upgrade Primary firewall. You can do this by either directly downloading and installing software onto the firewall itself or via Panorama Device Deployment > Software option.
    4. Download, install and reboot 7.0.18
    5. Download and install 7.1.0 (base version).
    6. Download and install 7.1.14, and reboot to complete the upgrade.
    7. Save/export tech support and Device state and save named device config snapshots (this is in case downgrade is needed).
    8. Download 8.0.0 (base version) (Recommended) Install the 8.0 base image and reboot before you install the target maintenance release..
    9. Download and install 8.0.6-h3, and reboot to complete the upgrade.
    10. On the Primary firewall, verify auto commit completes successfully (FIN OK) by running the command before proceeding to the next step: 
      > show jobs all 
      Run the following command to make Primary firewall functional again: 
      > request high-availability state functional
    11. This concludes upgrade on the Primary firewall.
  • Secondary firewall upgrade procedure:
    1. Suspend Secondary firewall to make Primary firewall active.
      From Secondary firewall, suspend High Availability function
      CLI:
      > request high-availability state suspend

      GUI:
      Device > High Availability > Operations > click Suspend local device. 

      Note: This will cause an HA failover. Production traffic is now going through Primary firewall with new software installed.
    2. Ask your business owners to verify all applications are working on the network. If there is a problem, skip to troubleshooting section. If there is any problem, fix it before proceeding with upgrade.
    3. Upgrade Secondary firewall. You can do this by either directly downloading and installing software onto the firewall itself or via Panorama Device Deployment > Software option
    4. Download, install and reboot 7.0.18
    5. Download and install 7.1.0 (base version)
    6. Download and install 7.1.14. reboot to complete the install
    7. Save/export tech support and Device state and save named device config snapshots (this is in case downgrade is needed)
    8. Download 8.0.0 (base version) (Recommended) Install the 8.0 base image and reboot before you install the target maintenance release.
    9. Download and install 8.0.6-h3. reboot to complete the install
    10. Verify auto commit completes successfully (FIN OK) by running the command before proceeding to the next step: 
      > show jobs all 

      Run the following command to make Secondary firewall functional again: 
      > request high-availability state functional
    11. This concludes upgrade on the Secondary firewall
  • (Optional but recommended) Arrange for Out-of-Band access (Console access) to the firewall if possible. 
    This is again to help recover from any unexpected situation where we are unable to login to the firewall.

  • Backup config and device state files just in case
  • Make sure no policy or configuration changes are being made by acquiring a config lock
    • Click on padlock icon on upper right hand corner of GUI
  • Make sure no pending commit jobs on firewall
  • (Optional but recommended) Post-upgrade verification
    • Now that both Primary and Secondary firewalls are both running the new software, it’s a good idea to test failover functionality again.
    • Run the following comma to suspend Primary firewall to fail traffic to the Secondary firewall
      > request high-availability state suspend
    • Ask your business owners to verify all applications are working on the network through the Secondary firewall.  If there is a problem, skip to troubleshooting section
    • Run the following CLI command to make Primary firewall functional again: 
      > request high-availability state functional
    • Repeat the process to verify traffic works fine through Primary firewall (suspend the Secondary firewall, test functionality on Primary firewall, then re-enable Secondary firewall)
    • This concludes failover test
  • (Optional but recommended) Enable preemption if it was disabled due to upgrade
    • Re-enabling preempt configuration change must be committed on both Likewise, once completed, re-enabling must be committed on both peers.
    • Go to Device > High Availability > Election Settings and check Preemptive.  Then, perform a commit.  
      2016-09-08_vpc6.png
  • This completes upgrade on the HA pair.

 

5. Post-upgrade checklist

The following Post-Implementation Activities should be performed prior to the change window end time. Performing these Post-Implementation Activities prior to the change window end time allows time to complete any potential corrective action that might be required after performing these activities.

  • Compare Post-Implementation results with Pre-Implementation results
    • Reapply the non-persistence settings from the pre-checklist
    • Check system logs for any unexpected errors
    • Check traffic logs for any traffic that’s unexpectedly allowed or denied
    • If applicable, verify connectivity and network functionality between firewall and panorama, specifically make sure log forwarding from firewall to Panorama is working. Also, validate changes will commit between Panorama and the managed devices.
  • Check system reports and incidents for any relevant outages.
    • Monitor helpdesk tickets post upgrade, this may take 24 to 48 hours
  • Let administrators know about the completion of the change.
    • Contact all stake holders to communicate any change IDs, describe change activity results, and verify that there are no relevant network alarms, incidents, or outages.
    • Monitor the appliance for any anomalies.

 

6. Troubleshooting resources

 

7. Downgrade procedure

If the issue cannot be resolved within the allotted change window, you should revert all changes.

    • Verify 7.1.0 (base image version) is still present on the system
    • Verify and install 7.1.14. reboot to complete the install. When prompted, use 7.1.14 snapshot file saved during the upgrade.
    • Verify 7.0.1 (base version) is still on the system
    • Download and install 7.0.18, and reboot to complete the downgrade. When asked, use 7.0.18 snapshot file saved before the upgrade.
      Note: After the Secondary firewall is rebooted, the CLI prompt should show non-functional.
    • On the prrimary firewall, verify auto commit completes successfully (FIN OK) by running the command before proceeding to the next step: 
      > show jobs all 
      Run the following command to make it functional again: 
      > request high-availability state functional
    • This concludes downgrade on the Primary firewall.
  • Downgrade the Primary firewall
    • Suspend the prrimary firewall to fail traffic to Secondary
    • On the Primary device, suspend the unit from the CLI. Run the command:
      > request high-availability state suspend
  • Save the following files for analysis:
    • Save and export Tech support and device state from both active and passive firewalls
    • All core dump files if there is any
    • Packet capture of problem traffic, if observed
  • Assuming the firewall is currently running 8.0.6-h3 already and traffic is currently going through the Primary firewall, follow the same upgrade process but in reverse order.
  • Downgrade the Secondary firewall
    • Verify 7.1.0 (base image version) is still present on the system
    • Verify 7.1.14 is still present on the system and install, reboot to complete the install. When prompted, use 7.1.14 snapshot file saved during the upgrade
    • Verify 7.0.1 (base version) is still on the system
    • Download and install 7.0.18. reboot to complete the install. When prompted, use 7.0.18 snapshot file saved before the upgrade.
      Note: After the Secondary firewall is rebooted, the CLI prompt should show non-functional.
    • On the Secondary firewall, verify auto commit completes successfully (FIN OK) by running the CLI command before proceeding to the next step: 
      > show jobs all 
      Run the following command to make it functional again: 
      > request high-availability state functional
    • This concludes downgrade on the Secondary firewall
  • (Optional but recommended) Enable preemption if it was disabled due to upgrade.
    • Re-enabling preempt configuration change must be committed on both Likewise, once completed, re-enabling must be committed on both peers.
    • Go to Device > High Availability > Election Settings and check Preemptive.  Then, perform a commit.  
      2016-09-08_vpc6.png
  • (Optional but recommended) Ask your business owners to verify all applications are working on the network.  If there is a problem, skip to troubleshooting section.
  • Upload all files to the Palo Alto Networks proactive support case for troubleshooting later.
  • This concludes the downgrade process.

 

Comments
by Fengrui
on ‎01-11-2017 06:02 AM

A great article, it seems there is some editorial issue for section 4, firewall upgrade procedure, the bullet points and sequence of upgrade are a bit messed up.

by
on ‎01-11-2017 12:32 PM

@Fengrui, I have modified section 4, please look again and let us know if it still needs help.

Thanks! 

by Fengrui
on ‎01-12-2017 01:39 AM

 @jdelio, the issue I was refering to is still there, my personal oppinion:

 

When doing a firewall upgrade, I'd upgrade the active(normally primary) firewall first, the reason being you will need to trigger a failover before doing the upgrade, and this can verify two things,

 

1. HA/failover is working

2. Original passive firewall is working and passing through traffic fine

 

This is also the sequence of Panorama upgrade outlined in this article, and the two notes in section 4 seem suggesting upgrading active/primary first as well:

 

- In section upgrade secondary firewall:

Note: This will cause an HA failover. Production traffic is now going through Primary firewall with new software installed.

 

- In section upgrade primary firewall:

Note: This will cause an HA failover. It is recommended to do this first to verify the HA functionality is working before initiating the upgrade. 

by
on ‎01-13-2017 05:32 PM

I have modified this again, please let me know if this is looking better yet. @Fengrui

 

Regards,

Joe

by Fengrui
on ‎01-16-2017 03:15 AM

Thanks Joe, this looks good to me! @jdelio

by dkillpack
on ‎01-26-2017 01:35 AM

To maintain ha sync and activity, upgrade the ha pair in tandem one major release at a time. If you upgrade one device by two major upgrades. The newly upgraded device will stay in suspended mode with the error peer OS to old. So when you go to start the first os upgrade on the second ha device, you will lose network connectivity until the upgrade is completed and the first device is moved out of suspended mode and into passive mode and HA capabilities resume functioning.

 

Please note this behavior in the document, when upgrading two major versions, there will be a time when there will be a network outage. Where as if the devices are upgraded one major version at a time, the HA will remain active and not network outage will be seen

by
on ‎01-26-2017 10:03 AM

@dkillpack, this is true, I will add this so everyone knows.

Thanks for reading and commenting.

by epeeler
on ‎02-16-2017 10:52 AM
@dkillpack Thanks for posting this. I'm pretty sure I've read in different places on the PA site that one can upgrade two major releases in an HA pair without breaking the HA. I found out the hard way a few months ago that this was not the case. I thought I had done something incorrectly that caused my problem but I'm glad to see that it wasn't "just me".
by AlbertJJ
on ‎05-01-2017 10:06 PM

Hope this is applicable for PAN OS 8 and >

by Community Manager
on ‎05-02-2017 04:00 AM

Hi @AlbertJJ this article is valid for all PAN-OS versions, the ones mentioned merely serve as an example

by HankLee
on ‎05-03-2017 11:41 AM

 I can't access

Under 

the Firewall checklist resource: (reference the link below)

Anyone has the problem to access? 

by
on ‎05-03-2017 12:25 PM

@HankLee, I am so sorry, that link is to an Internal Only document, and should not have been listed. 

If we can get a public facing document, I will fix the link to the new location.

But have to remove it for now.

by mkopcic
on ‎07-19-2017 02:52 AM

What dkillpack has written is true: 

 

To maintain ha sync and activity, upgrade the ha pair in tandem one major release at a time. If you upgrade one device by two major upgrades. The newly upgraded device will stay in suspended mode with the error peer OS to old. So when you go to start the first os upgrade on the second ha device, you will lose network connectivity until the upgrade is completed and the first device is moved out of suspended mode and into passive mode and HA capabilities resume functioning.

 

Please note this behavior in the document, when upgrading two major versions, there will be a time when there will be a network outage. Where as if the devices are upgraded one major version at a time, the HA will remain active and not network outage will be seen.

 

Could you please edit your documents? Your upgrade procedure is misleading. Please write that this procedure will cause network outage.

 

  1. Download 7.1.0 (base version)
  2. Download and install 7.1.11. reboot to complete the install
  3. Save/export tech support and Device state and save named device config snapshots (this is in case downgrade is needed)
  4. Download 8.0.0 (base version)
      As a best practice, when upgrading to PAN-OS 8.0, install the PAN-OS 8.0.0 base image and reboot the firewall before you download and install a PAN-OS 8.0 maintenance release. This is an optional extra step.
  5. Download and install 8.0.3. reboot to complete the instal

Thank you.

by clockhart
‎08-31-2017 01:28 PM - edited ‎08-31-2017 01:29 PM

I didn't see a mention of reminding the user to redownload the URL filtering database after performing a software upgrade. It's my understanding/experience that the database is removed during the software upgrade process, and the user must go to Licenses/PAN-DB URL Filtering/Download. Anybody else experience this?

 

Thank you

by Community Manager
on ‎09-01-2017 02:23 AM

Hi @clockhart

PAN-DB doesn't have an actual database, it relies on a cache solely

When you upgrade the firewall and reboot, the cache is cleared and you start with a clean cache. Redownloading the seed database will populate your cache with a selection of most popular URLs but this is not required, your firewall will fill up the cache on it's own as it processes URL filtering 

The advantage of downloading the seed after a reboot is that you'll not need to do a whole lot of cloud lookups because your cache is empty

by clockhart
on ‎09-01-2017 07:09 AM

@reaperThanks for the clarification ... it's the seed database that maybe should be redownloaded then? Just wondering because when I failed over to my newly upgraded system most of the URL categories were coming up as "unknown," and I had user issues. I have made it a practice now but maybe it's unnecessary.

 

I guess I'll have to look under the hood a little more on this. I've been thinking "Re-downloading the seed database will overwrite the current cache with the new seed entries. Are you sure you want to continue?" meant I was actually downloading a seed database. I guess it's a misonomer or just a local cache to the database in the cloud.

 

PAN-DB URL Filtering
License :                          valid                                   
Current cloud server :             s0200.urlcloud.paloaltonetworks.com     
Cloud connection :                 connected                               
Cloud mode :                       public                                  
URL database version - device :    20170831.40167                          
URL database version - cloud :     20170831.40167  ( last update time 2017/09/01 08:01:52 )
URL database status :              good                                    
URL protocol version - device :    pan/0.0.2                               
URL protocol version - cloud :     pan/0.0.2                               
Protocol compatibility status :    compatible                              

by Community Manager
on ‎09-01-2017 08:15 AM

Hi @clockhart

 

The seed 'database' is a cache 'prefiller' 

After the upgrade the cache will be empty, every single URL lookup will initially require a cloud lookup to get the category for every request, this will start filling up the cache

once a URL has been seen, no additional cloud lookup is needed

right after the reboot you're gonna need a lot of lookups if there's live user traffic and your lookups may get queued due to bandwidth restrictions or just sheer volume, this could lead to some unknowns as the lookup time is exceeded

 

the seed helps cope with the initial load 

 

 

hope this helps! :)

by clockhart
on ‎09-01-2017 09:35 AM

@reaperThank you. Very helpful!

by Albert_C
on ‎09-01-2017 01:36 PM

Hi @jdelio,

 

in 4. Firewall upgrade procedure (HA), 1. you advise to Suspend the Primary Firewall. I see this as recipe for disaster. If HA is NOT fully working you will end with one not-correctly-working and one suspended device. Good if they are in room next to you, worse if on the other hemisphere...

I switch device priorities (with preemption enabled). With Link and/or Path monitoring that provides good possibility of cluster autorecovery/switching is something goes wrong.

What do you think?

 

Regards,

Albert

by Community Manager
on ‎09-04-2017 01:27 AM

Hi @Albert_C the procedure that @jdelio describes relies on the administrator having foreseen access to their devices at all times, either by being local or having OOB connectivity to the management network which is best practice when upgrading the firewall. In the case where you do not have the option of achieving either, it is a good idea to change the procedure slightly to ensure you dont lose connectivity at the cost of having a less rigid upgrade path.

Having the preempt enabled will require you to keep this config change in mind during the whole process as it could unexpectedly switch over the active membership while upgrading

by perrim
on ‎09-19-2017 01:50 PM

https://www.paloaltonetworks.com/documentation/71/pan-os/newfeaturesguide/upgrade-to-pan-os-7-1/upgr...

 

https://www.paloaltonetworks.com/documentation/70/pan-os/newfeaturesguide/upgrade-to-pan-os-7-0/upgr...

 

In both of these guides linked above, they do not use the latest maintenance release, but rather just the base version when upgrading. Why does your guide indicate to go to the latest maintenance release and conflict with those guides?

 

Additionally, in testing an upgrade from 6.0.4, I found this line from your guide "Note: If you are on a maintenance release version prior to 7.0.6, you must install 7.0.6 before 7.1.0 will show up on your software download page" to be untrue. Once I was on 7.0.1 I was able to see 7.1.0 on the Software page. 

by jjosephs
on ‎09-20-2017 02:10 PM

@perrim - The Technical Documentation was published at the time any dot-0 version has been release. A dot-0 version is the base release. After that, Palo Alto Networks makes available maintenance releases on a regular schedule to address issues reported against the previous release of the same PAN-OS version. Generally speaking, many sites choose to wait around the .5 or .6 release before upgrading to a new PAN-OS version. Customer Support tends to recommend the latest stable release and this article has been written to support that idea.

 

Best regards,

Jerald

by
on ‎09-20-2017 05:03 PM

To @jjosephs@perrim
I have reworded section 4 a little. Please let us know if that reads better.

 

Thanks @reaper for the wording there :P

 

by jjosephs
on ‎09-20-2017 05:29 PM

Hey @jdelio, I realize now that the recommendation to disable pre-emptive mode on a firewall in section 4 should be at the very beginning of this section, before you suspend Primary to test HA failover and before you upgrade and reboot Primary. That's when it is going to do the most good

 

Jerald

by perrim
on ‎09-21-2017 09:31 AM

@jjosephs , @jdelio My question is why does this article have you use the latest maintenance release in the upgrade path, 7.0.16 -> 7.1.11 -> 8.03 instead of just using the base 7.1.0. 

by
on ‎09-21-2017 12:19 PM

@perrim  I understand fully what you mean.  Traditionally, when you are upgrading versions,  PAN-OS 7.0.x to 8.0.x then you would normally just download the 7.1.0 base image.. and normally are not required to go to 7.1.11.  But there may be a feature that is only in a minor release (x.x.1, x.x.2, etc.), that may be needed.  I will try to gather more information for you and let yoa know.

by sepatel
on ‎09-22-2017 06:56 AM

Hi Guys,

 

I note that the upgrade procedures for Panorama (Section 3) are using the wrong screenshots and wrong menu options. The screenshots and menu options are from a firewall and not Panorama. Please can you update when you get a chance.

 

Thanks,

Seetal

 

 

by perrim
on ‎09-22-2017 09:15 AM

@jdelio - If there is a feature that is needed/desired, wouldn't you configure it once you get to the final version you are upgrading to though?? TAC is pointing people to this document, but their answer is to only use the base version for upgrades where you need to cross multiple PANOS releases. I'd like to see the document in line with their recommendations. 

by
on ‎10-06-2017 03:46 PM

@perrim, and others. I have added some extra notes, and hopefully this will answer your questions on upgrading to minor versions (7.1.x) along the way.

by Quinn
on ‎06-22-2018 09:37 AM

@jdelio : Quick question for purpose of clarification.    Currently on the Panorama proceedure, acquiring the config lock and resolving existing locks is listed after  the upgrade process for the secondary Panorama.   However the bullet point alignment has them as part of the overall process.   Should these be moved to the top of the process as pre-upgrade tasks?

by Community Manager
on ‎06-25-2018 12:38 AM

Hi @Quinn

 

you're right, that section needed to be moved around a bit: pre upgrade config lock, upgrade, post-upgrade

 

thanks!

by dkillpack
on ‎07-10-2018 01:23 AM

Would it be possible to add a section on how to do a manual install and upgrade on the firewall from the GUI with screenshots as an alternate option of upgrade? This would be for those who do not have internet access for the device and is unable to download the new OS directly to the device.

by Community Manager
on ‎07-10-2018 06:13 AM

hi @dkillpack

I'll see about having a separate article created that better explains manual installation, as this article is already very lengthy and adding exceptions could cause confusion

by bridge
on ‎07-17-2018 03:56 AM

Why does Palo Alto say , upgrade the secondary first, and this article says do the primary first? Confusing!

by Community Manager
on ‎08-07-2018 06:45 AM

Hi @bridge 

I guess it may be different depending on your environment or your stance. 

Some prefer secondary over primary, but in the end it does not matter that much.

The above article serves as a playbook that will guide you through the upgrade process, based on recommendations compiled from years of TAC experience

Ignite 2018, Amsterdam, Netherlands
Ask Questions Get Answers Join the Live Community