When there are signature updates in the dynamic application database, several entries in your current configuration may be deactivated. When there are multiple such dynamic applications, it is difficult to find the exact application that is inactive. This article explains how to:

• Find the deactivated dynamic application in the latest signature database
• Clear the commit error due to the inactive dynamic application

When an SRX device is not able to find a configured dynamic application in the installed database, it logs a commit error: "Error reading dynamic application names."

root@SRX# commit
[edit security application-firewall rule-sets JTAC-LAB-AppFw rule 1]
  'match'
    Error reading dynamic application names.
error: configuration check-out failed

As seen in the error message, only the rule-set and rule-name are given, but not the dynamic application name. Given this, when there are multiple dynamic applications specified under the rule, finding the exact application becomes difficult, as shown in this example:

root@SRX> ...JTAC-LAB-AppFw rule 1| display set                
set security application-firewall rule-sets JTAC-LAB-AppFw rule 1 match dynamic-application junos:TORRENTZ
set security application-firewall rule-sets JTAC-LAB-AppFw rule 1 match dynamic-application junos:BITTORRENT-APPLICATION
set security application-firewall rule-sets JTAC-LAB-AppFw rule 1 match dynamic-application junos:BITTORRENT
set security application-firewall rule-sets JTAC-LAB-AppFw rule 1 match dynamic-application junos:TORRENTLEECH
set security application-firewall rule-sets JTAC-LAB-AppFw rule 1 match dynamic-application junos:XUNLEI
set security application-firewall rule-sets JTAC-LAB-AppFw rule 1 match dynamic-application junos:GAMESTORRENTS

Scenario #1

A commit error is logged when there is a change in the dynamic application database following signature updates and your current configuration contains an entry that is no longer active.

The only location where the application name can be found is the nsd_chk_only log. The name will not be available under traceoptions .

To find the application name:

root@SRX> show log nsd_chk_only | match "dynamic appl"

Max Dynamic Applications per Policy = 4096
nsd_dynapp_config_read: Reading dynamic application config, check_only 1
Could not find dynamic application path
dynamic appl junos:XUNLEI's id is error appfw_build_app_list. ======> This dynamic applications is causing the issue
Error reading dynamic applications name appfw_parse_rule_match_obj.

root@SRX>

Delete this entry to fix the issue.

root@SRX# delete security application-firewall rule-sets JTAC-LAB-AppFw rule 1 match dynamic-application junos:XUNLEI
root@SRX# commit

Scenario #2:

There can be instances where the object is not part of the CLI dynamic application, could be caused by some Space problem, in this cases you should remove the problematic object from the configuration being pushed.

We would still need to check the log file to see what object is causing the conflict.

root@SRX> show log nsd_chk_only | match "dynamic appl"
       Max Dynamic Applications per Policy = 4096
nsd_dynapp_config_read: Reading dynamic application config, check_only 1
Could not find dynamic application path
dynamic appl junos:Any's id is error appfw_build_app_list.
Error reading dynamic applications name appfw_parse_rule_match_obj.

As in this case the object "junos:Any" does not exist in Junos but it's being added by Space.
After removing said object from the AppFW the user is able to push the change.

Adding new scenario