- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
02-18-2016 01:28 PM
Can anyone tell me the best way to upgrade from a HA pair of PA-2020's to new PA-3050's.
02-18-2016 02:21 PM - edited 02-18-2016 02:24 PM
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
02-19-2016 11:29 AM - edited 02-19-2016 11:56 AM
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
02-18-2016 02:21 PM - edited 02-18-2016 02:24 PM
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
02-19-2016 12:54 AM
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
02-19-2016 11:29 AM - edited 02-19-2016 11:56 AM
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
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!