HA Firewall Device Migration/Hardware Swap

cancel
Showing results for 
Search instead for 
Did you mean: 

HA Firewall Device Migration/Hardware Swap

L1 Bithead

Need to replace an HA pair of Panorama managed, currently deployed firewalls (PA-5220s) with a different pair of Panorama managed  firewalls (also PA-5220s), with minimum/no downtime; device licensing is different between #1 & #2 pairs, necessitating the swap.

 

Proposed procedure (detailed in attached picture)

- Copy Panorama DG/Template for HA pair #1 to replacement DG/Template for HA pair #2
- Push Panorama config to HA pair #2
- Replace current passive firewall (1b) with it's replacement (2d), sync sessions

- Swap HA roles (1b is now active)

- Replace current passive firewall (1a) with it's replacement (2c)

- Swap HA roles

- Delete DG/Template #1


Hardware is identical (HA requires this)

HA configs are identical: timers, peer IP addresses, etc.

 

Anyone see issues with the proposed procedure? Suggestions for alternative procedure?

 

Thought about using Panorama RMA procedure to just replace #1 firewalls one at a time and using HA to minimize downtime, maybe similar to above, start by serial number swap for passive firewall, HA swap, replace serial number for formerly active device, swap, etc hardware

1 ACCEPTED SOLUTION

Accepted Solutions

L5 Sessionator

Thank you for the post @Akeakamai

 

I agree with Otakar that swapping Firewalls for license migration might be overkill, however if this step is unavoidable in your scenario, I would say your proposed procedure looks functional, however I believe this could be a bit simplified.

 

Since you are using the same Firewalls with the identical configuration, I think you can use existing Device Group and Template Stack, so I would skip first step with cloning existing Device Group and Template Stack.

 

- Before you start with migration, disable HA Preemption in your existing Firewall HA pair to avoid unexpected failover during migration.

- Suspend in HA setting current passive firewall (1b) and disconnect all interfaces, then cable all ports in replacement firewall (2d).

- Upgrade replacement firewall (2d) to the same PAN-OS version, install the same content update, install license, but keep HA as suspended.

- Place replacement firewall (2d) into existing Device Group and Template Stack and push the configuration.

- After configuration is pushed, I would do basic verification that all setting was applied. If HA setting is configured for "auto" mode, you should at least see all interfaces to be up. Also all information under High Availability should be "Match" and HA1, HA1 Backup, HA2,... should be up.

- Clean/Replace old Firewall SN with new one in Panorama by: replace device old <old SN#> new <new SN#

- If you are using BGP peering, it might be safer to temporarily configure static route as a fall back if BGP session drops during Firewall failover.

- If you did not get stuck or came across any issue with any of the above steps, I would make replacement firewall (2d) functional in HA and proceed with failover (make firewall (1a) suspended).

- If all is running fine on firewall (2d) do the same procedure for firewall (1a) and replace it with firewall (2c).

- Make firewall (2c) active and enable preemption if necessary.

- Clean up all the configuration that was configured temporarily for migration purpose.

- Make failover test just in case to confirm all is working as expected.

 

As always unexpected thing can happen, so I would schedule this task for weekend or during time with lowest traffic. Also, I would recommend to to do bench mark connectivity test before and after replacement work to avoid falsely troubleshooting things that were actually not functional before replacement.

 

Kind Regards

Pavel

Help the community: Like helpful comments and mark solutions.

View solution in original post

4 REPLIES 4

Cyber Elite
Cyber Elite

Hello,

Why not just swap the licensing? Might be a simpler solution.

Just a thought.

Swapping licenses would be the easiest solution, Palo Alto told us that was not an option, hence my migration plan

L5 Sessionator

Thank you for the post @Akeakamai

 

I agree with Otakar that swapping Firewalls for license migration might be overkill, however if this step is unavoidable in your scenario, I would say your proposed procedure looks functional, however I believe this could be a bit simplified.

 

Since you are using the same Firewalls with the identical configuration, I think you can use existing Device Group and Template Stack, so I would skip first step with cloning existing Device Group and Template Stack.

 

- Before you start with migration, disable HA Preemption in your existing Firewall HA pair to avoid unexpected failover during migration.

- Suspend in HA setting current passive firewall (1b) and disconnect all interfaces, then cable all ports in replacement firewall (2d).

- Upgrade replacement firewall (2d) to the same PAN-OS version, install the same content update, install license, but keep HA as suspended.

- Place replacement firewall (2d) into existing Device Group and Template Stack and push the configuration.

- After configuration is pushed, I would do basic verification that all setting was applied. If HA setting is configured for "auto" mode, you should at least see all interfaces to be up. Also all information under High Availability should be "Match" and HA1, HA1 Backup, HA2,... should be up.

- Clean/Replace old Firewall SN with new one in Panorama by: replace device old <old SN#> new <new SN#

- If you are using BGP peering, it might be safer to temporarily configure static route as a fall back if BGP session drops during Firewall failover.

- If you did not get stuck or came across any issue with any of the above steps, I would make replacement firewall (2d) functional in HA and proceed with failover (make firewall (1a) suspended).

- If all is running fine on firewall (2d) do the same procedure for firewall (1a) and replace it with firewall (2c).

- Make firewall (2c) active and enable preemption if necessary.

- Clean up all the configuration that was configured temporarily for migration purpose.

- Make failover test just in case to confirm all is working as expected.

 

As always unexpected thing can happen, so I would schedule this task for weekend or during time with lowest traffic. Also, I would recommend to to do bench mark connectivity test before and after replacement work to avoid falsely troubleshooting things that were actually not functional before replacement.

 

Kind Regards

Pavel

Help the community: Like helpful comments and mark solutions.

View solution in original post

L1 Bithead

Thank you for your detailed response, unfortunately it landed in my Spam folder for a week. We came to a similar conclusion to your's independently, you provided useful additional info, and validated our similar approach.

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!