About gvyas

Hellp Dat.tran Were you able to resolve this issue. I also have same problem. I am planning to open a case with TAC but before that want to understand if there was any resolution associated to this since this is a very old case. Regards Girish Vyas ... View more

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 ... View more