Commit error via netconf only

316 views
Skip to first unread message

Arzhel Younsi

unread,
Mar 17, 2015, 6:49:06 PM3/17/15
to junos-p...@googlegroups.com
Follow up from https://github.com/Juniper/py-junos-eznc/issues/359

When committing a configuration (with the ansible module), the SRX (running 12.1X44-D45.2) returns "msg:Unable to commit configuration:error,any,mgd: application or application-set must be defined". The firewall logs returns many:

Mar 17 03:56:44  fw1 file[3594]: UI_CONFIGURATION_ERROR: Process: mgd, path: [edit security policies from-zone corp to-zone corp policy corp-access-any match application], statement: any, application or application-set must be defined
Mar 17 03:56:44  fw1 file[3594]: UI_CONFIGURATION_ERROR: Process: mgd, path: [edit security policies from-zone corp to-zone corp policy voip-access-any match application], statement: any, application or application-set must be defined

While the application bit is properly defined:

# show security policies from-zone corp to-zone corp policy corp-access-any
match {
    source-address xxx;
    destination-address yyy;
    application any;
}
then {
    permit;
}

# show security policies from-zone corp to-zone corp policy voip-access-any
match {
    source-address xxx;
    destination-address yyy;
    application any;
}
then {
    permit;
}

The load (through Python-EZ) works fine and returns (for example) the diff attached, which doesn't impact the application bit.

If I manually scp;load;commit the same config, it works fine (not even a warning).

I also opened a ticket with JTAC (2015-0316-0973) but their answer is a straight:

"Based on the case description I understand that you are getting a commit error only via netconf. I regret to inform you that JTAC officially does not support scripting and configuration via any software other  than Juniper's such as NSM or Space. However I did some research and found that all the bugs related to this error are caused by the application like NSM and Junos Space and not the SRX. You could try to find some meaning to the error by checking syslog, but  it seems that it is not telling us much.

Since this is out of our scope of support I will shchedule the closure of this case as of close of business today, in case you haveany further questions."

Is there anything I can do?

Thanks.

changes.diff

Nitin Kumar

unread,
Mar 18, 2015, 1:19:38 AM3/18/15
to Arzhel Younsi, junos-p...@googlegroups.com
Hi Arzhel,

As you said "The load (through Python-EZ) works fine and returns (for example) the diff attached, which doesn't impact the application bit."
Do share the PyEZ script which you used. 
Also share the ansible playbook which you are using for the process. These will help to get us to the root cause.

Nitin K

--
You received this message because you are subscribed to the Google Groups "Junos Python EZ" group.
To unsubscribe from this group and stop receiving emails from it, send an email to junos-python-...@googlegroups.com.
Visit this group at http://groups.google.com/group/junos-python-ez.
To view this discussion on the web visit https://groups.google.com/d/msgid/junos-python-ez/ea2be8db-4560-4c6f-a10d-e28ccc6c8935%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Arzhel Younsi

unread,
Mar 18, 2015, 5:55:22 PM3/18/15
to junos-p...@googlegroups.com, xio...@gmail.com
Hi,

By "the load" I mean the Ansible module load the config properly (no warnings or errors), and returns the proper diff (diff that I can load and commit manually as well). The issue seems to happen only at that commit (and commit check) phase.

I'm not sure sharing publicly the whole playbook (or config that I'm pushing) is possible (at least for now) but the diff of the changes (that don't impact the security policies) should give you an overview of what's going on.

To me it's seems to be a Junos issue, where for an unknown reason it thinks that "any" is an application name (not defined) and not a built-in keyword.

Thanks.

Arzhel Younsi

unread,
Mar 18, 2015, 9:48:14 PM3/18/15
to junos-p...@googlegroups.com, xio...@gmail.com
Okay, I found the issue.

The Junos configuration file I was pushing had a replace: groups { [...] } statement.
While loading that through the cli doesn't cause any issue to the hidden junos-defaults group, loading it through netconf causes the group to be deleted.
I'm not sure if that difference in behavior is expected, but at least I now know about it.

Thanks for your time!
Reply all
Reply to author
Forward
0 new messages