Panorama/Firewall performance

[Tony_Kiser]

Historically, for a LONG time, we have created an object for every IP address and every port (for port based rules).  Over the years, this has lead to our config being HUGE.  Last tech support file from Panorama is 85MB.  With thousands and thousands of objects, my opinion is that's contributing to the performance issues we see; the fact that all these objects get sent to the firewalls, and has to be updated everytime we do a push.

So question is this; do others agee with this?  Has anyone actually backed down the object list (like removing unused, and removing objects for single IP policies, and just put the IP in the rule itself only) and then seen a performance gain?  It would be a substantial task, but possibly a useful one.  Thoughts?

[BPry]

@Tony_Kiser,

So I think the one thing that needs to clear up here is when you are seeing the performance impact. When it's just pushing and commit the configuration then yes, as the XML file grows it takes longer to push out to the firewall and the validation process obviously takes longer as it has to validate more. If you think you are seeing a performance impact on actually processing the traffic, then that isn't something we would expect. 

Just as a basic premise I actively try not to use objects when I don't have to, and I think it's kind of a hold over from people who were used to configuring ASAs and moved to Palo Alto. You should be removing any objects that you don't actually use anymore, single IPs and IP ranges should just be entered and don't need to be an address object. Really the only time I use an address object is when I want to tag the address for use in a dynamic address-group, or when I want to provide a name to the address object for people who might not know the IP. 

That being said past the actual commit process being faster, as it has to analyze less and it should take less time for the firewall to build the running-config, you wouldn't expect a true traffic performance gain from doing so.  

[Remo]

In our environment we do it a little different than @BPry. All the config is on panorama and there we use objects for about everything. Specially for all internal servers - if they are used or not - but just in case we need them the objects are already there. Also useful is if the IP changes for whatever reason, then only one change is required and the object is changed on all firewall where it is used.

But what we have configured is the option that only the used objects are pushed to the firewalls. So far we do not see a big performance impact because of too many objects and with this option there is no impact when pushing the config to the firewalls.

[aleksandar.astardzhiev]

Indeed intersting suggestion by @BPry...We also use to create object for each network, host, or range (or at least in most of the times), but really don't have definitive reason for that...Probably legacy logic from Checkpoint firewall.

From the question it was not very clear if all of the host objects are being used in all policy, but I would backup that suggestion to disable "Share unsuable addresses and service objects".  It should be very good start to tackle this.

Over the GUI go to Panorama -> Setup -> Management -> Panorama Settings -> Disable/uncheck "Share unsused addresses and service objects with devices"

[MP18]

Hi Remo,

Can you please explain more on this

But what we have configured is the option that only the used objects are pushed to the firewalls. So far we do not see a big performance impact because of too many objects and with this option there is no impact when pushing the config to the firewalls.

Regards

Mike

[Remo]

@MP18

I am talking about the option that @aleksandar.astardzhiev also described:

---

@aleksandar.astardzhiev wrote:

Over the GUI go to Panorama -> Setup -> Management -> Panorama Settings -> Disable/uncheck "Share unsused addresses and service objects with devices"

---

[Tony_Kiser]

Ya, the performance impact we see is things like changing context from one FW to another within Panorama, commits, etc.  Not processing performance.  The other "indirect" impact is that we currenlty can't pull the config into Expedition because of the size limite of the XML that Expedition can process.  And yup, i've been at this company for about 2.5 years, and they are, overall, a shop converted from ASA side of the world  🙂

[LukeBullimore]

Hey @Tony_Kiser

Try running your configuration through the Expedition tool, it'll highlight all the unused objects and can easily delete them. It'll also show duplicate objects that you can merge etc.

https://live.paloaltonetworks.com/t5/Expedition-Migration-Tool/ct-p/migration_tool

When exporting the configuration in Expedition it'll also try to compress the XML into one line as much as possible which really saves on configuration file size.

Cheers,

Luke.

[Tony_Kiser]

That's actually part of the issue @LukeBullimore; our xml is so big, Expedition can't digest it.  🙂

[LukeBullimore]

Hey @Tony_Kiser

You can actually increase the max file size upload limit 🙂

1. Edit the file "php.ini" found in the folder:

/etc/php/7.0/apache

You can use vi, or nano e.g.

sudo nano /etc/php/7.0/apache/php.ini

Find the line "upload_max_filesize = 2MB"

Modify the value to something of your choosing, e.g. 100MB

Restart the apache2 service

sudo systemctl restart apache2

[Tony_Kiser]

DUDE!!  That's gold!  Thanks.