Weird Behaviour on Palo Alto PA2020

[Skidilliplop]

Anyone else out there got a PA2020 in production use?

We have one PA2020 and a few PA500s. The PA2020 seems to be incredibly slow in the management interface. Configs taking 3-5minutes to commit compared to 30 seconds on the PA-500s. Sometimes my HTTPS session times out before the commit finishes it takes that long. It seems to have gotten even slower recently, though it's never been quick.

Having never used one before I don't know if that is normal? for a £10,000 box I'd sincerely hope not.

Just wanted other people's experience to try and figure out if it's just a trait of that model or we've got a defective unit. I did a quick Google and nothing came up on the first 5 pages for anyone complaining about it, which I imagine there would if it was a common issue.

Operationally it seems to perform OK from what I can see, just the management side is painful to work with. Which means convincing support that it's defective will be fun.

 

[Skidilliplop]

In terms of security rules, NAT rules etc the PA500 has more. Though the 2020 is doing QoS and some other things which pads out the config file (albeit mostly with lines containing just }'s )

In total config on the PA2020 totals about 4900 lines, the 500 totals 1800 lines.

Sounds a lot but for something that's got a tagging and search feature in the rule pages it's clearly designed to have a lot more rules than it has.
I've got extreme networks switches with 4000 line XML config files that cost a lot less, and don't have problems interrogating those in their screenplay web interface.

So would you say 3minutes+ is normal York?

I can't see me stomaching this if there's any choice. If it's defective great, if not I'll be looking to part exchange it for a better model. Tbh for the line speed we have a PA500 would actually suffice in it's place, and it won't drive me mental when testing minor tweaks like "add an app to a rule and test" which should take 2 minutes ends up taking 15.

 

[Skidilliplop]

I have prod experience on all models but the 200, 500, and 2020 I work on the most often. The 2020 commit times on my devices are 4-10 minutes, so 3 min is pretty good. All depends on how much you have configured and what services are running. For example, the 500's commit time is 2 min, until I turn on policy profiles (URL, AV, etc.), then it jumps up to about 10 min.

PA made a huge attempt to make this FW as GUI friendly as possible. As you already know, the easier it is for the admin, the harder it is for the device, which explains the situation we're all in. I don't know about anyone else, but I prefer command line based OS's.

This is the only negative with PA, IMHO. Unfortunately, were stuck with this mgmt nightmare.

To a degree I agree with that. But the PA2020 commits just as slowly from CLI as it does the GUI, and it has a dedicated management processor. So bulky as the GUI might be, for a 10-12k piece of kit they could afford to splash £100 more on better control plane hardware

 

[Skidilliplop]

Edit - @BRS: I do want to learn Juniper as my exposure here at my current company is limited (One of the few vendors we don't have much contact with) and they are of course one of the market leaders. Is there any particular material you would recommend for simulation/emulation for the interfaces and management/config and reading?

The latest version of GNS3 supports JunOS images and virtual box hosts. If you can get hold of the binaries that should do the job.

 

[Skidilliplop]

Some is misinformation. Regardless if you use a 200 or 5000 series, the GUI/MGMT is identical. Slowness is dependent on the size of the config. The hardware is the difference. You get what you pay for, well, not really, all their products are WAY OVER PRICED, but you get the idea.

I must inform you, the new ones, in terms of code, are worse. If your #1 priority is stability and not new features, you want v3.1 and nothing else. I find new bugs quite often.

^ Yes I had noticed the PA500 I have on 3.1.x is a lot quicker than the ones on 4.1.x. And there have been some annoying bugs in 4.1. Most noticeably 4.1.5 which crashed and restarted the 2020 control plane with every commit. 4.1.4 still does that when trying to use granular commit too.
I'd roll it back to 3.1 but some of the features in 4 are quite important for what the 2020 is doing, e.g FQDN address objects, netflow server profiles (was amazed the base release didn't support sflow or netflow) and kerberos authentication.
Maybe when they eventually get granular commit working it'll speed things up a bit