topic Re: Panorama commit procedure in General Topics

Panorama commit procedure

minow — Sun, 10 Aug 2014 07:10:14 GMT

hey

does anyone have a document that describes "step by step" the commit procedure of the panorama?

just had a quick talk with support and apparently the commits from panorama are calculating directly to the running configuration

Re: Panorama commit procedure

HULK — Mon, 11 Aug 2014 04:59:37 GMT

Hello Minow,

It would better to commit the Panorama configuration local to the Panorama first ( Panorama-Candidate configuration). Then, you may proceed for a "device-group" commit to push that change into the multiple PAN firewall.

Example:

Reff DOC: Panorama Administrator's Guide 5.1 (English)

Hope this helps.

Thanks

Re: Panorama commit procedure

minow — Tue, 12 Aug 2014 19:43:09 GMT

yes this one i know... you better commit on panorama after any changes at least for versions up to 6.0.3

me question was how the device itself handles the commit that comes from panorama... it is very unclear... if you will look at the configuration files on the devices there are a lot

running config

candidate config

template config

merge config < which have lets say the final "running config"

it is very confusing how the device will compile / merge / calculate the config that comes from panorama

thanks

Re: Panorama commit procedure

djoksimovic — Sun, 17 Aug 2014 09:27:22 GMT

Hi Dor,

In 6.0 commit process from Panorama should be performed the following way:

- if "Merge with Candidate Config" option is disabled then config sent from Panorama is merged directly with local running-config on the firewall and then applied (committed) on MP and DP

- if "Merge with Candidate Config" option is enabled config sent from Panorama is merged with candidate config and intermediate commit is done on candidate config. Then running-config is totally replaced by candidate-config.

Re: Panorama commit procedure

minow — Sun, 17 Aug 2014 10:54:33 GMT

on the second option i do not agree..

if we are talkin gabout the "template" config then yes but it depands on the force template values and whether this was already configured on the local device

if we are talking about the device-group then for sure the pushed configuration is merged with the runing-config.

for example:

i copied all the rules, obejcts to panorma and then deleted all of them from the device candidate config.

pushed policy to the device and the commit failed on duplicated objects

Re: Panorama commit procedure

minow — Thu, 28 Aug 2014 06:46:59 GMT

i have been told that since 6.0, if you copy the rule from the local device to panorama and they have the same name and you removed it from the candidate config.... commit should work fine and not alert for duplicates.

been tried and test migration like this:

Template:

1) show all relevant configuration in "set" mode,

2) put them on the right location of the template

3) commit with "force template values"

4) commit without "force template values" this is very important if you will have connection problem with panorama you could just overwrite configuration locally without disabling panorama's template

Device group:

1) copy all objects from the local device to the "shared" on panorma

2) copy the ruleset from the local device to panorama by editing the relevant location in the XML file and then importing on panorma

3) deleting all the rules and objects that I copied

4) commiting from panorma

finelaysing::

1) use the "show" command in the configureation mode and see what configuration I had missed locally on the device

2) if found something so migrate if to panorama

Re: Panorama commit procedure

gvyas — Thu, 30 Oct 2014 06:45:41 GMT

Hello minow,

To the best of my knowledge, the commit from Panorama to device works as follows :-

While commiting the config, the commit process should be first completed on Panorama.

Once the commit is completed, you can proceed with the commit of device group. While pushing the config to the device group you have the following options and their meaning as below

It is recommended to Preview your changes to be sure that the changes being pushed is what is required. Additionally you can put a commit lock to avoid administrators overstepping on one another

Merge with Candidate Config—Choose this option to cause the device to include its local candidate configuration when the commit is invoked from Panorama. If this option is not checked, the device local candidate config is not included.And this will require a separate commit to get the local device changes pushed. It is recommended to leave this option unchecked when you have local administrators making changes on a device and you don’t want to include their changes when pushing a configuration from Panorama.

Include Device and Network Templates—This option is available when committing a Device Group from Panorama and is a combo operation that will include both the device and network template changes. The template that will be applied to the device is the template that the device belongs to as defined in Panorama > Templates. You can also select Commit Type Template to commit templates to devices. This is termed as full commit. Alternatively, you have is a partial commit, wherein you can choose not to push your template values and push only the Policy and objects.

During the commit process, the entire config is pushed during the commit and not just the changes.

The commit process runs in two phases. Phase 1 is verification/validation of the config and Phase 2 as push of new configuration flash.

Below are some of the engines that process the commit change during the 2 phases

routed - This engine verifies and handles Routing configuration

ha_agent - This is necessary for HA config for HA control and Data Plane.

device - This engine handles the changes related management portal / Device Tab

ikemgr - This is used for the VPN settings

keymgr - This is generally used in Operational mode i.e, generating keys to provide access to device or handling Key management

logrcvr - This engine handles the process for local logs and log forwarding to syslog.

dhcpd - This is used for assignment of DHCP pool and its related config.

sslvpn - As the name specifies this is used to handle ssl vpn related config.

useridd - This is used to maintain the user - id cache and relevant config to agents and mapping of Ip to user and user to group.

authd - This process handles the authentication of the user and service accounts used for cofnigurations

dagger - this is used to kill a process and generally used in Ops mode only.

Of the above the major commit time is used for Device and User-id Module as general observation.

In case more details are required you can always run the below command before initiating the commit process from Panorama,

tail follow yes mp-log ms-log.

This command will help you how the commit is actually handled, After issuing this command run a commit from PAN. Similar what has been said earlier will be observed.

Hope this helps

Regards

Girish Vyas