How to identify the commit failure reason when no error message is displayed in the GUI

How to identify the commit failure reason when no error message is displayed in the GUI

101659
Created On 08/14/19 13:05 PM - Last Modified 08/24/23 17:04 PM


Objective


The objective of this article is to identify the commit failure reason when no valid error message is displayed in the GUI.

Environment


  • Any Palo Alto Firewall or Panorama
  • Any PAN-OS version


Procedure


  1. Connect to the CLI of the device where the commit failed and open the ms.log file using the less mp-log ms.log command, then navigate through the log file to the time of the commit failure.
2019-04-16 09:21:54.514 +0200 client authd reported op command was SUCCESSFUL
2019-04-16 09:21:55.773 +0200 client cryptod reported op command was SUCCESSFUL
2019-04-16 09:21:56.274 +0200 client authd reported op command was SUCCESSFUL
2019-04-16 09:21:56.334 +0200 client authd reported op command was SUCCESSFUL
2019-04-16 09:21:58.265 +0200 client useridd reported op command was SUCCESSFUL
2019-04-16 09:21:58.301 +0200 client useridd reported op command was SUCCESSFUL
2019-04-16 09:21:58.694 +0200 client authd reported op command was SUCCESSFUL
2019-04-16 09:22:00.125 +0200 client useridd reported op command was SUCCESSFUL
2019-04-16 09:22:03.525 +0200 client authd reported op command was SUCCESSFUL
2019-04-16 09:25:30.546 +0200 client device reported Phase 1 FAILED
  1. The message client device reported Phase 1 Failed indicates that the commit was successful up until the point where the device server process was attempting to make changes. Following up the message you may see the exact failure error similar to the one below:
<<vsys1 (vsys1)>>
Error: nat rule 'www.example.com': Mismatch of destination address translation range between original address and translated address
Error: Failed to parse nat policy
<</vsys1 (vsys1)>>
The example issue above was caused by a NAT policy with an FQDN object being resolved to 4 different IP's in the original packet, and the translated packet section containing a static /32 IP address, which would mean a 4:1 translation, which is not a valid configuration for static 1:1 mapping.
 
  1. If the information seen in ms.log is insufficient, go through the devsrv.log using less mp-log devsrv.log which can provide additional information on the failure.


Additional Information


To go through the logs use "Shift+g" keys to go all the way to the end of the log, where the latest messages are found. From here, you can use the "u"  key to go upwards in the log, and the "space bar" to go down the log again.

If the commit is failing while pushing from Panorama to the firewall (called a CommitAll), check the configd.log file instead of the ms.log using the command less mp-log configd.log to identify where the push is failing (similar to check done on the ms.log file on the firewalls).


Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PMb2CAG&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail