Weird Behaviour on Palo Alto PA2020

Skidilliplop · 12 Jul 2012 at 14:26

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.

GhostlyPea · 12 Jul 2012 at 15:32

How big is the rule base on the 2020 compared to the 500?

- GP

York · 12 Jul 2012 at 15:51

We had a PA2050 in as a trial unit a few weeks back (and now have a 4050 on order

) but I know from talking to the pre-sales engineers that they warned us the web interface can be slow on the 2000 series.

Apparently it's because the processors in the control plane aren't really as fast as they need to be to cope with all the new functionality, meaning it can be slow to update when you have a lot going on. The data plane is apparently fine, just management of the device that is slowed down.

In the newer products its not supposed to be an issue as they've massively beefed up the control-plane to cope.

Skidilliplop · 12 Jul 2012 at 16:32

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.

tarkawa · 12 Jul 2012 at 18:04

Palo Alto Networks

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.

GhostlyPea · 12 Jul 2012 at 20:29

TBH from other vendors they can take a similar length of time... I personally wouldn't worry too much

- GP

Skidilliplop · 16 Jul 2012 at 10:07

tarkawa said:
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

bigredshark · 16 Jul 2012 at 11:04

GhostlyPea said:
TBH from other vendors they can take a similar length of time... I personally wouldn't worry too much

- GP

Like what? My Juniper's commit 25k+ lines in less than 20 seconds.

PA are known to have slow management on some of the boxes, I hear the new ones are much improved but I've not seen them personally, nice boxes but just a little bit too much of a departure from the normal firewall feature set for us.

GhostlyPea · 16 Jul 2012 at 12:42

bigredshark said:
Like what? My Juniper's commit 25k+ lines in less than 20 seconds.

Mainly the older Checkpoints (Nokia/UTM-1 boxes) but the newer GAIA 2012 appliances are much better. I don't have much experience with the decent Junipers that I know you use, only the web GUI Netscreens (and even then it's limited). Watchguard and Cisco saving is pretty fast, just those Checkpoints - although this seems to be due to the verify/install operation as it doesn't immediately commit the changes. Maybe 3 - 4 minutes was a tad overestimating in general, but at least 2 clients of ours do have clusters that have 3 minute commits (full from verify to completion)

- GP

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?

Skidilliplop · 16 Jul 2012 at 13:57

GhostlyPea said:
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.

bigredshark · 16 Jul 2012 at 14:06

Main advice these days being learn the SRX series (JUNOS) rather than SSG (ScreenOS). The SSG is still very good and has plenty of life left, particularly in the higher end boxes but the SRX is the future and (being JUNOS) is a more powerful platform. It'll also give you an insight into the JUNOS based switching (EX series) which is starting to become a compelling product at all levels.

GhostlyPea · 16 Jul 2012 at 15:14

@ PJ - That was actually the plan --> run Olive. I need a copy of the binary though.

@ BRS - Advice taken. I've had enough exposure of ScreenOS to manage that, but it's JUNOS that's, as you say, where it's heading.

Cheers

- GP

tarkawa · 16 Jul 2012 at 19:24

Skidilliplop said:
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

Well, you're correct, but there's more too it. PA built their systems user friendly meaning its tough on the device whether you use GUI or CLI. To make the CLI work, you have to recreate the system from scratch, so yes the CLI is just as slow because it's the same system and some of their cmds are 3 lines long. If it were built around the CLI, it would be much faster.

tarkawa · 16 Jul 2012 at 19:35

bigredshark said:
Like what? My Juniper's commit 25k+ lines in less than 20 seconds.

PA are known to have slow management on some of the boxes, I hear the new ones are much improved but I've not seen them personally, nice boxes but just a little bit too much of a departure from the normal firewall feature set for us.

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.

tarkawa · 16 Jul 2012 at 19:41

GhostlyPea said:
Mainly the older Checkpoints (Nokia/UTM-1 boxes) but the newer GAIA 2012 appliances are much better. I don't have much experience with the decent Junipers that I know you use, only the web GUI Netscreens (and even then it's limited). Watchguard and Cisco saving is pretty fast, just those Checkpoints - although this seems to be due to the verify/install operation as it doesn't immediately commit the changes. Maybe 3 - 4 minutes was a tad overestimating in general, but at least 2 clients of ours do have clusters that have 3 minute commits (full from verify to completion)

Correct, Checkpoint, PA, Nortel back in the day, are all slow with their mult-step process to save/commit a config. Not sure what you mean by the Netscreens are limited? Because you cant get any faster saving the config. CLI you type save and it's done in seconds if not immediately. The GUI saves automatically with every change you make. About the same for Cisco.

GhostlyPea · 16 Jul 2012 at 23:24

tarkawa said:
Correct, Checkpoint, PA, Nortel back in the day, are all slow with their mult-step process to save/commit a config. Not sure what you mean by the Netscreens are limited? Because you cant get any faster saving the config. CLI you type save and it's done in seconds if not immediately. The GUI saves automatically with every change you make. About the same for Cisco.

Where I said limited I was referring to my exposure to them, not the save time ^

- GP

York · 18 Jul 2012 at 21:08

Skidilliplop said:
So would you say 3minutes+ is normal York?

Spoke to a Palo Alto SE today that was in doing some configuration migration/setup with us today and asked about commit times. He did say that on the latest code release the 2000's have become noticeably slower to commit.
He also wasn't surprised by several minute commit times on a PA2020.

As a comparison our brand new PA4020 with no (very very little) configuration was taking around 20-30 seconds to commit.

Skidilliplop · 19 Jul 2012 at 11:34

tarkawa said:
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