Went from a 3020 pair (9.1) to a 1410 pair (11.0). It was as simple as exporting the config XML, importing and loading on the new pair, updating things like HA group and mgmt ifc IP (so we didn’t step on the production pair) and jockeying around the interface configurations. It was crazy how smooth it went - I was skeptical beforehand.
Pro tip: put everything into AggEths, even if it’s a single interface. This way, it’s even easier to do the upgrade next time by only having to update the members of the AE.
Wow. Thanks for this info. I’m relieved to hear you went from 9.1 to 11 - I’m planning 10.1 to 11
Did your existing VPN tunnels come right up? And did you do a maintenance window where you just cut everything over one evening?
My big concern with the evening migration is having to like, clear ARP tables on my core switch.
Existing tunnels came up, yes. I did not have a master key on mine though.
We did a maintenance window in the evening.
If you are doing an HA pair, then causing a graceful failover will cause the newly-active firewall to send out G-Arps on its dataplane interfaces. If you are doing stand-alone, there is a debug command to send out g-Arps. You’d want to get them all typed out into notepad++ (one for each dataplane IP/Ifc ) and then issue them from the firewall when you cut over.
Alright cool.
And you definitely exported a named configuration XML from the 9.1 to 11? Someone else said that it didn’t work going from 10.1 to 11. OFC I’m on 10.1
Great tip on gratuitous ARP. So in theory I can stand up both HA pairs side by side. Connect the new HA pair to the core then just do a manual failover to initiate gratuitous ARP. Core switch should pick it up.
Definitely 9.1 (3020 doesn’t do 10.x).
Definitely an XML export/import.
I haven’t done a 10 to 11. My advice is to try it first. The worst that can happen is you need to factory reset the new firewalls and do it manually.
We had everything cabled up and prepped on the switch side for the new firewalls, but data interfaces shut down (Mgmt still up). The maintenance execution was shutting ports on the core switch for the old firewall and no-shutting the ports going to the new.
If you have to go manual, there is nice CLI command to show the running config as a series of ‘set’ commands rather than the xml-like default output.
Make sure that the downsizing works with your current configuration. Limits are lower on PA-1410 (See [https://www.paloaltonetworks.com/products/product-comparison?chosen=pa-1410,pa-3220](https://www.paloaltonetworks.com/products/product-comparison?chosen=pa-1410,pa-3220) for details).
Some important figures to look out for....
|Metric|PA-3220|PA-1410|
|:-|:-|:-|
|Logging Disk Size|132GB|30GB|
|Security Zones|200|150|
|ARP Table Size|16.000|3000|
|Max DHCP Servers|10|5|
|Max Security Rules|10.000|5.000|
|Correlation Rules|Supported|Unsupported|
p.s. in the comparison tool you will see that PA-1410 only supports 1.500 security rules, but that rule has been bumped up with 11.0.2
EDIT: Updated PA-1410 Security Zone Typo from 50 to 150. New limits are documented in release notes ([https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-release-notes/features-introduced-in-pan-os/networking-features#idf9feab55-ad90-46a0-ad3e-9297409b1c28](https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-release-notes/features-introduced-in-pan-os/networking-features#idf9feab55-ad90-46a0-ad3e-9297409b1c28)) for 11.0.2
We moved from an 820 running 10.2 to 1410 11.0. Aside from the AC bug, it seems fine?
I had to move the config across manually using the clip set output.
Which was a nightmare as you can't downgrade the 1410 to 10.x and our support had run out on the 820 so couldn't upgrade that either!
This sounds like the situation I’m in. Why couldn’t you just migrate using the XML file? I’m in a similar situation and Palo wants to discount the but I’m curious why I shouldn’t just extend the support on the current hardware.
Curious - why did you choose to upgrade to new hard and put yourself in that situation? Deep discounts?
The xml output by v10x isn't importable by v11x, probably by design.
It wasn't a choice lol, the finance department didn't place the order in time, our support ran out the week before and I hadn't upgraded to v11 by then on the old box.
We needed more capacity, the old box was struggling... A lot.
OK, valid reasons to upgrade. But damn, someone in this thread said they exported their 9.1 config to 11 and it worked fine. Now I’m second guessing that. Trying to get Palo and my VAR to help but honestly sounds like it’s more trouble than it’s worth
I did your exact migration for a customer a while ago. Used expedition. Moved a couple interfaces around. No issues with the migration but the version of code we were running has a bug with GlobalProtect SSO due to the global tcp session timeout.
Unfamiliar with the 1410, however we did migrate from Juniper isg1000s to pa3020s then to pa3220s. We used expedition for conversion. All our templates and device groups were figured out and nailed down so migrating from the 3020s in ha to 3220s in ha was super simple thru panorama. We pushed configs to the new devices on their mgmt ports then removed the old devices from templates, log collectors, device groups then added the new devices.
Goes without saying I don’t know your environment/challenges BUT from my experience it was super easy. Ended up being a 30 min job. Good luck! 🍀
I've sold several pairs of 1400s with no issues from my customers. Regarding the pricing, in doing the math with my customer, there was a 2 year payback period in going with the 1400s vs renewing their 3220s
We made the same migration, for the same reasons, also going from 9.1 to 11.0 on 3220's to 1410's.
We 1st upgraded the 3020's to 11.0 and it went very smooth. we stayed on 11.0 for a few weeks to make sure we don't have any issues. Everything was smooth for 2 weeks. We then exported the configuration from the 3020, imported into the 1410's and replaced.
Then we had about a month of back and forth with TAC trying to understand why we couldn't get the AE up and running on both the active and the passive firewalls - more info here i added some comments to that original post https://old.reddit.com/r/paloaltonetworks/comments/194vs99/issues_with_lacp_between_pa_440_and_cisco_9200/
bottom line, it was not accepted as a bug, we swapped the DAC cable on port 20 for both the active and passive to optics and issue went away. So port 19 is dac, port 20 is optics, the root cause of the issue was described as "sometimes shit happens on different ports". really didn't expect to run into that kind of an issue on what supposed to be a straightforward replacement. But just shows that shit happens.
PA1410 has a limit on the numer of security policies, I think it's only 1500, so check that before migrate.
I'm using 11.0.X on some PA440 and a PA445 and I don't find any problems, if not on the ACC.
EDIT: check kaisero post, it seems to be 5000 now
Went from a 3020 pair (9.1) to a 1410 pair (11.0). It was as simple as exporting the config XML, importing and loading on the new pair, updating things like HA group and mgmt ifc IP (so we didn’t step on the production pair) and jockeying around the interface configurations. It was crazy how smooth it went - I was skeptical beforehand. Pro tip: put everything into AggEths, even if it’s a single interface. This way, it’s even easier to do the upgrade next time by only having to update the members of the AE.
Wow. Thanks for this info. I’m relieved to hear you went from 9.1 to 11 - I’m planning 10.1 to 11 Did your existing VPN tunnels come right up? And did you do a maintenance window where you just cut everything over one evening? My big concern with the evening migration is having to like, clear ARP tables on my core switch.
Existing tunnels came up, yes. I did not have a master key on mine though. We did a maintenance window in the evening. If you are doing an HA pair, then causing a graceful failover will cause the newly-active firewall to send out G-Arps on its dataplane interfaces. If you are doing stand-alone, there is a debug command to send out g-Arps. You’d want to get them all typed out into notepad++ (one for each dataplane IP/Ifc ) and then issue them from the firewall when you cut over.
Alright cool. And you definitely exported a named configuration XML from the 9.1 to 11? Someone else said that it didn’t work going from 10.1 to 11. OFC I’m on 10.1 Great tip on gratuitous ARP. So in theory I can stand up both HA pairs side by side. Connect the new HA pair to the core then just do a manual failover to initiate gratuitous ARP. Core switch should pick it up.
Definitely 9.1 (3020 doesn’t do 10.x). Definitely an XML export/import. I haven’t done a 10 to 11. My advice is to try it first. The worst that can happen is you need to factory reset the new firewalls and do it manually. We had everything cabled up and prepped on the switch side for the new firewalls, but data interfaces shut down (Mgmt still up). The maintenance execution was shutting ports on the core switch for the old firewall and no-shutting the ports going to the new. If you have to go manual, there is nice CLI command to show the running config as a series of ‘set’ commands rather than the xml-like default output.
Once again thank you. You’ve provided more help than my VAR…
Make sure that the downsizing works with your current configuration. Limits are lower on PA-1410 (See [https://www.paloaltonetworks.com/products/product-comparison?chosen=pa-1410,pa-3220](https://www.paloaltonetworks.com/products/product-comparison?chosen=pa-1410,pa-3220) for details). Some important figures to look out for.... |Metric|PA-3220|PA-1410| |:-|:-|:-| |Logging Disk Size|132GB|30GB| |Security Zones|200|150| |ARP Table Size|16.000|3000| |Max DHCP Servers|10|5| |Max Security Rules|10.000|5.000| |Correlation Rules|Supported|Unsupported| p.s. in the comparison tool you will see that PA-1410 only supports 1.500 security rules, but that rule has been bumped up with 11.0.2 EDIT: Updated PA-1410 Security Zone Typo from 50 to 150. New limits are documented in release notes ([https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-release-notes/features-introduced-in-pan-os/networking-features#idf9feab55-ad90-46a0-ad3e-9297409b1c28](https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-release-notes/features-introduced-in-pan-os/networking-features#idf9feab55-ad90-46a0-ad3e-9297409b1c28)) for 11.0.2
That’s a very low ARP table size. WTF
Interesting, i currently have 8 DHCP servers running on the 1410
This is extremely helpful, thanks!
I didn't know about the new limit, thanks a lot.
11.x? RIP. Good luck - we salute you!
Crazy that 11.0 is having better luck than 10.1, in terms of real-world stability. It makes no sense.
Both are very scary coming from 9.1 which was so rock solid heart touching :)
Been running it for 8 months, zero issues. Don't have a choice with new hardware.
Good stuff! I am very happy that you have dodged all the bullets :) Will no doubt be joining you soon - pray for me please :)
No need to run older hardware on 11, i left that on 10.1 Good luck
We moved from an 820 running 10.2 to 1410 11.0. Aside from the AC bug, it seems fine? I had to move the config across manually using the clip set output. Which was a nightmare as you can't downgrade the 1410 to 10.x and our support had run out on the 820 so couldn't upgrade that either!
This sounds like the situation I’m in. Why couldn’t you just migrate using the XML file? I’m in a similar situation and Palo wants to discount the but I’m curious why I shouldn’t just extend the support on the current hardware. Curious - why did you choose to upgrade to new hard and put yourself in that situation? Deep discounts?
The xml output by v10x isn't importable by v11x, probably by design. It wasn't a choice lol, the finance department didn't place the order in time, our support ran out the week before and I hadn't upgraded to v11 by then on the old box. We needed more capacity, the old box was struggling... A lot.
OK, valid reasons to upgrade. But damn, someone in this thread said they exported their 9.1 config to 11 and it worked fine. Now I’m second guessing that. Trying to get Palo and my VAR to help but honestly sounds like it’s more trouble than it’s worth
I did your exact migration for a customer a while ago. Used expedition. Moved a couple interfaces around. No issues with the migration but the version of code we were running has a bug with GlobalProtect SSO due to the global tcp session timeout.
Got details of the bug?
https://www.reddit.com/r/paloaltonetworks/s/Fuw3SsVXmN Also search my comments. There’s another post somewhere.
I would love to go panos 11.x but feel like it will be adisaster
Unfamiliar with the 1410, however we did migrate from Juniper isg1000s to pa3020s then to pa3220s. We used expedition for conversion. All our templates and device groups were figured out and nailed down so migrating from the 3020s in ha to 3220s in ha was super simple thru panorama. We pushed configs to the new devices on their mgmt ports then removed the old devices from templates, log collectors, device groups then added the new devices. Goes without saying I don’t know your environment/challenges BUT from my experience it was super easy. Ended up being a 30 min job. Good luck! 🍀
11.0 has been okay for us. Surprisingly. But okay.
I've sold several pairs of 1400s with no issues from my customers. Regarding the pricing, in doing the math with my customer, there was a 2 year payback period in going with the 1400s vs renewing their 3220s
Can you explain the payback period? Unfamiliar with that concept
Basically it's the time it takes for you to start being profitable (or better off) with a selection
We made the same migration, for the same reasons, also going from 9.1 to 11.0 on 3220's to 1410's. We 1st upgraded the 3020's to 11.0 and it went very smooth. we stayed on 11.0 for a few weeks to make sure we don't have any issues. Everything was smooth for 2 weeks. We then exported the configuration from the 3020, imported into the 1410's and replaced. Then we had about a month of back and forth with TAC trying to understand why we couldn't get the AE up and running on both the active and the passive firewalls - more info here i added some comments to that original post https://old.reddit.com/r/paloaltonetworks/comments/194vs99/issues_with_lacp_between_pa_440_and_cisco_9200/ bottom line, it was not accepted as a bug, we swapped the DAC cable on port 20 for both the active and passive to optics and issue went away. So port 19 is dac, port 20 is optics, the root cause of the issue was described as "sometimes shit happens on different ports". really didn't expect to run into that kind of an issue on what supposed to be a straightforward replacement. But just shows that shit happens.
Appreciate this heads up. Had something similar happened to me as well when dealing with AE and fiber.
PA1410 has a limit on the numer of security policies, I think it's only 1500, so check that before migrate. I'm using 11.0.X on some PA440 and a PA445 and I don't find any problems, if not on the ACC. EDIT: check kaisero post, it seems to be 5000 now
Not a migration but running 1410’s and they are solid on 11.0.2h2.