Fastest way to commit Panorama changes

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Fastest way to commit Panorama changes

L1 Bithead

Hey All, I have a customer who has about 50 PA FW's and Panorama. They will be using Cyberark to rotate passwords on service accounts, the account that the FW's are using for LAPD will be changing. Cyberark will make and replicate its change very fast but the FW commits will take way longer and USER ID will break as soon as the change is made. It's a 24/7 operation so I need to be as noninvasive as possible, will scripting or API call's speed up the commit process? 

 

Thanks

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

@Pasquale01,

So just to be clear, User-ID shouldn't be clearing its cache when the password starts failing once the service account is changed. The cached user-id entries will still be present until their age-out limit is reached, you simply won't be able to get any updates until the commit with the updated password is actually applied. So yes that's a disruption, but not a "everything stopped working because we dropped the entire user-id database" disruption. 

 

On to your other question, it would technically be quicker to push the change directly at the device instead of pushing it through Panorama. You aren't talking about a huge amount of time difference however. Whenever you're automating anything on the firewall I don't recommend doing it through a CLI script. The API is the easier option, is actually built for these sort of situations, and will allow you to easily build out a pretty robust script with built in job status and failure detection.

Once you have the script operational just be mindful that you'll want to run the commit on all devices in parallel if you actually want to see a performance improvements over Panorama. This means that you'll either need to spawn 50 instances of the script targeting your firewalls or set the script up with proper threading to actually handle a parallel run. 

View solution in original post

1 REPLY 1

Cyber Elite
Cyber Elite

@Pasquale01,

So just to be clear, User-ID shouldn't be clearing its cache when the password starts failing once the service account is changed. The cached user-id entries will still be present until their age-out limit is reached, you simply won't be able to get any updates until the commit with the updated password is actually applied. So yes that's a disruption, but not a "everything stopped working because we dropped the entire user-id database" disruption. 

 

On to your other question, it would technically be quicker to push the change directly at the device instead of pushing it through Panorama. You aren't talking about a huge amount of time difference however. Whenever you're automating anything on the firewall I don't recommend doing it through a CLI script. The API is the easier option, is actually built for these sort of situations, and will allow you to easily build out a pretty robust script with built in job status and failure detection.

Once you have the script operational just be mindful that you'll want to run the commit on all devices in parallel if you actually want to see a performance improvements over Panorama. This means that you'll either need to spawn 50 instances of the script targeting your firewalls or set the script up with proper threading to actually handle a parallel run. 

  • 1 accepted solution
  • 2569 Views
  • 1 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!