Management is still terrible

[rsullivan]

We've been using this platform for over a year now and the interface is not great to say the least. It takes no less than 30 minutes to make the most basic change. Is anyone else feeling the pain? Our SE is useless. Please create a Java client to remove the burden from the appliance.

[gafrol]

Totally agree, the most complaints we receive during eval from clients is the slowness of the WebUI.

Also compared to other FW vendors this is the slowest user interface I have seen so far.

[djbisbey]

Hi,

got to agree, each interation of s/w update has made the front end slower and slower. Shame as its the only downside to a great product. Think they should spend time on tweaking the front end in future releases.

Darren

[kalyanram.piratla]

Hello Everyone,

I have been working on Palo from version 3.1 all the way to 4.1.3.  Honestly speaking, there has been a considerable change in version 4.1.x.  Can I ask which version are you running at the moment.  If you are on the latest version and even then if it takes 30mins for changes to take affect, then I would suggest having a look at your management server for the load. 

[shp555]

What model PA do you have?

[Retired Member]

30 minutes to commit a change is definitely too long. PAN-OS versions as well as hardware platforms can definitely see differences in management plane performance. 4.1 has in general seen much improved management plane performance for many customers. However, on any platform 30 minutes is not expected. 

One recommendation is if you are using application-filters in your configs, that can cause longer time during the config validation stage. So best to avoid application filters if not absolutely needed. Otherwise should open a case with TAC to have the commit time looked into.

-Richard

[djbisbey]

That seems a bit silly, if application filters are a potential problem omitting them is the only answer? I have quite a few application filters setup and they work very well and I like the flexbility of them..

I have had the process committing for up to 15 mins worse case, but the management CPU does get a bit high at times.

We use a PA500 and each iteration of s/w has made the commit process get longer, I know the commit process is complicated that I accept but taking a longtime can be a pain..

Darren

[mikand]

Which version of PANOS do you use then?

Commiting a somewhat clean setup (inlcluding threat prevention and url categories etc) on 5xxx boxes took just seconds with 4.1.x compared to older versions of PANOS.

It would be interresting to see "guidelines" in case one think commiting takes too long for what one can check for.

If you have riddicolous large app filters then I can understand why it will take a few more seconds to compile the security rules but at the same time this is the point of using app filters.

Will for example disabling "rematch flows to new security rules" (or whatever that setting is named) change the speed of commits? Or is the commitspeed purely a mgmtplane thing to compile the code which the FPGA/ASIC will be loaded with?

[blwallace]

I too would like to chime into this discussion.  I worked through an issue last night where the only changes I was making were renaming some of my static routes.  I went through 6 commits and it took me over 4 hours to get the job done.

Model	PA-2020
Serial #	xxxxxxxxxxx
Software version	4.1.0
GlobalProtect Client	0.0.0
Application version	292-1294
Threat version	292-1294
Antivirus version	681-931
URL Filtering version	3809
GlobalProtect datafile version	0
Time	Wed Feb 29 13:17:07 2012
Uptime	92 days, 14:14:54

I have:

• 47 security policies
• 25 NAT
• 275 address objects
• 58 address groups
• 0 user defined applications
• 14 application groups
• 0 application filters

I takes an average of 10 minutes, minimum to do just a simple, one item change/commit.  Way too slow for modern times.  Should I open a support ticket - or is this just the new PaloAlto?

[kbrazil]

Please open a ticket.  I have seen up to 10 minute commits for only the first time a new custom application or vulnerability signature is being compiled into the FPGA.  If there are no changes to the signature, subsequent commits should not take that long.

There might be another process running in the background of the management plane that is using the resources.  That said, the PA-2000 series management plane is much slower than the PA-4000 and PA-5000 seriies.

Cheers,

Kelly

[nwallette]

Committing changes on 3.1.x on my 2020s is nerve-wracking during an outage or when I mistakenly change something I didn't mean to change.  (Not that it ever happens...)

Commits on 4.1.x are a lot faster on one of my yet-to-be-deployed 500s, but I have other bones to pick with that series.  (Anyone else see commit failures, especially when leaving out policy and object changes?)  It's a very ambitious dynamic web GUI.  The devs have done a pretty good job with it, but it's not as solid as 3.1.

At least it's not Java.  Please don't go there.

[kalyanram.piratla]

@ Nwallette,

Commit failures while creating objects or security rules has been identified as a bug in the code.  It will be fixed in version 4.1.4 which is due in a month's time.

[jennis@hilton.k12.ny.us]

I agree, Please don't go the Java route!