cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Who Me Too'd this solution

Cyber Elite
Cyber Elite

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

Who Me Too'd this solution