Hardware Upgrade

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Hardware Upgrade

L0 Member

Can anyone tell me the best way to upgrade from a HA pair of PA-2020's to new PA-3050's.

 

 

2 accepted solutions

Accepted Solutions

L5 Sessionator

Hi,

 

welcome.

 

How complex is your configuration? Sort of a simple migration plan would involve steps like:

 

- ensure all boxes are running with matching versions of everything - Pan-OS, av updates, apps, content, wf

- leave new boxes uncabled for data ports yet 🙂

- export configuration from active 2020,

- import that configuration into one of the new 3050 devices,

- fix interfaces as they probably won't match, check the rest of the configuration if it corresponds to your the original one,

- export state from newly configured active 3050, import it into other 3050,

- adjust configurations for HA differences as they are now mirroring each other (at minimum you should change: management IP addresses, HA peers configuration, hostnames)

- re-check if new 3050 pair corresponds to 2020s configurations once again.

- check HA failover on new devices while uncabled. Test new devices with simple lab setups to ensure everything that's critical would work - this is optional, depending how critical your infrastructure is, I guess.

- announce maintenance window, re-cable devices, test if everything is reachable, perform failover within maintenance window to ensure all works when devices switch roles.

- if everything is fine, unrack old devices a week later, if possible.

 

For better experience I would consult your SE and open a case with TAC if needed prior to deployment or if you have problems after importing configuration, just to ensure smooth results. If you announce maintenance during weekdays you should not be having trouble getting assistance from TAC even during migration.

 

If you had some particular concerns about upgrade in mind, please elaborate a bit your question 🙂

 

Best regards,


Luciano

View solution in original post

Hi, you're welcome.

 

As far as import of configurations between platforms goes, things that get broken are interface mismatches and any configuration dependant on those interfaces (for example, what might break down.... GP portals or VPN tunnels, perhaps communication with some servers that had data interfaces set up, NAT, service routes).

Once I got new devices, I would test import; if I experience too many breakdowns I would consider either manually configuring rest on the new device, or changing dependant part of the configuration on the old platform to correspond to the interfaces existing on a new platform and than importing again. If discrepancy is too high, you might consider re-designing your network. For what it's worth, you will see full list of whatever is broken when you attempt to import configuration, so you will be able to copy that output and work on the configurations to fix it.


My colleague today correctly pointed my attention to the fact that you could just set up HA once you are sure new active device is set up. This is correct, and expected and "more" proper way to do it, rather than dumping device state. Not that anything would be wrong with device state import; only difference is - you need to set up those passive/secondary device details (hostname, management IP address, HA details at least) prior to setting up and pushing configuration - and if you were importing dumped state you would change them after the import.

 

Regardless of your production setting of the feature, I might avoid using pre-emption until I am sure of my cluster behaving as expected - just to be sure there aren't any unexpected failovers while you are setting everything up.

 

Good luck, and as I said - if needed, you always have additional resources in SE and TAC.

 

Best regards,

 

Luciano

View solution in original post

3 REPLIES 3

L5 Sessionator

Hi,

 

welcome.

 

How complex is your configuration? Sort of a simple migration plan would involve steps like:

 

- ensure all boxes are running with matching versions of everything - Pan-OS, av updates, apps, content, wf

- leave new boxes uncabled for data ports yet 🙂

- export configuration from active 2020,

- import that configuration into one of the new 3050 devices,

- fix interfaces as they probably won't match, check the rest of the configuration if it corresponds to your the original one,

- export state from newly configured active 3050, import it into other 3050,

- adjust configurations for HA differences as they are now mirroring each other (at minimum you should change: management IP addresses, HA peers configuration, hostnames)

- re-check if new 3050 pair corresponds to 2020s configurations once again.

- check HA failover on new devices while uncabled. Test new devices with simple lab setups to ensure everything that's critical would work - this is optional, depending how critical your infrastructure is, I guess.

- announce maintenance window, re-cable devices, test if everything is reachable, perform failover within maintenance window to ensure all works when devices switch roles.

- if everything is fine, unrack old devices a week later, if possible.

 

For better experience I would consult your SE and open a case with TAC if needed prior to deployment or if you have problems after importing configuration, just to ensure smooth results. If you announce maintenance during weekdays you should not be having trouble getting assistance from TAC even during migration.

 

If you had some particular concerns about upgrade in mind, please elaborate a bit your question 🙂

 

Best regards,


Luciano

Luciano,

 

Thanks for this. Our main concern was whether the config from old to new would import correctly.

 

We have a 2 week window to carry out the configuration and testing prior to deployemnt so we should be good to go.

 

Regards

 

R

Hi, you're welcome.

 

As far as import of configurations between platforms goes, things that get broken are interface mismatches and any configuration dependant on those interfaces (for example, what might break down.... GP portals or VPN tunnels, perhaps communication with some servers that had data interfaces set up, NAT, service routes).

Once I got new devices, I would test import; if I experience too many breakdowns I would consider either manually configuring rest on the new device, or changing dependant part of the configuration on the old platform to correspond to the interfaces existing on a new platform and than importing again. If discrepancy is too high, you might consider re-designing your network. For what it's worth, you will see full list of whatever is broken when you attempt to import configuration, so you will be able to copy that output and work on the configurations to fix it.


My colleague today correctly pointed my attention to the fact that you could just set up HA once you are sure new active device is set up. This is correct, and expected and "more" proper way to do it, rather than dumping device state. Not that anything would be wrong with device state import; only difference is - you need to set up those passive/secondary device details (hostname, management IP address, HA details at least) prior to setting up and pushing configuration - and if you were importing dumped state you would change them after the import.

 

Regardless of your production setting of the feature, I might avoid using pre-emption until I am sure of my cluster behaving as expected - just to be sure there aren't any unexpected failovers while you are setting everything up.

 

Good luck, and as I said - if needed, you always have additional resources in SE and TAC.

 

Best regards,

 

Luciano

  • 2 accepted solutions
  • 4544 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!