Operating System: All
Platform: All

Attachment karaf.log has been added with description: karaf log having netconf connect trace enabled

Hi Erik,

Continuing our discussion here:

Yes, the Juniper capability is in different format than expected in ODL or stated in RFC.

We could introduce a fallback into netconf connector to check for the juniper version of candidate capability string, or make it less strict when looking for candidate capability (maybe checking only for substring "netconf:capability:candidate:1.0").

The fix is pretty easy, we just need to modify class:
controller/opendaylight/md-sal/sal-netconf-connector/src/main/java/org/opendaylight/controller/sal/connect/netconf/listener/NetconfSessionPreferences.java ... there's a method called isCandidateSupported().

If you feel like modifying the class yourself, feel free to take this bug and submit a patch. It would be great if you could do that, since you can also test the fix against the Juniper device.

If not, let us know and we will take care of this.

Maros

https://git.opendaylight.org/gerrit/#/c/22265/

This works, the candidate config is now locked instead of the running config.
And various other netconf requests are performed.
However the restconf call still does not work. Shall I create a new bug report?

Hi Erik, thanks for the commit.

We can discuss the failure here and maybe open another bug later.
So whats the failure now ? Can you provide more information ?

Attachment karaf_after_applied_patch.log has been added with description: karaf log after applied patch

I am trying to excute a restconf call to cahnge the host-name of the device.
The call is:

curl -X POST --data "<system xmlns='http://xml.juniper.net/xnm/1.1/xnm'><host-name>newswitch</host-name></system>" http://admin:admin@localhost:8181/restconf/config/opendaylight-inventory:nodes/node/sw-opennaas-1/yang-ext:mount/configuration:configuration -H "Accept: application/xml" -H "Content-Type: application/xml" -v

When viewing the logs, I see that ODL successfully locks the candidate config and performs some <get-config> actions on the 'system' tree of the configuration.
However after this the lock is released, and the config wasn't adjusted.
Please find the log attached, the call starts at line 3151.

the REST call produces the following body:

<errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">
<error>
<error-type>protocol</error-type>
<error-tag>data-exists</error-tag>
<error-message>Data already exists for path: /(http://xml.juniper.net/xnm/1.1/xnm?revision=1970-01-01)configuration/system</error-message>
</error>
</errors>

Does this mean that I am using a wrong URL for accesing the system subtree?

I also tried to delete the host-name from the configuration, so that I am sure there was not host-name element in the configuration, but this did not help.

Hi Erik,

So its just restconf telling you the data exists and cannot be created again. POST method was recently changed from performing merge operation to create operation, whch fails when data is already present. The error is expected now. You can try using PUT (replace) instead with the same data, but dont forget to update the URL by adding the system element to it. The URL for PUT should probably look like this:

http://admin:admin@localhost:8181/restconf/config/opendaylight-inventory:nodes/node/sw-opennaas-1/yang-ext:mount/configuration:configuration/configuration:system

Maros

Attachment karaf_put_log.txt has been added with description: karaf put log

Hi Maros,

I tried the PUT, using:

curl -X PUT --data "<system xmlns='http://xml.juniper.net/xnm/1.1/xnm'><host-name>newswitch</host-name></system>" http://admin:admin@localhost:8181/restconf/config/opendaylight-inventory:nodes/node/sw-opennaas-1/yang-ext:mount/configuration:configuration/configuration:system -H "Accept: application/xml" -H "Content-Type: application/xml" -v

As a response I get a error 500.

In the logs I do see a edit-config request, but it does not list the host-name element, for some reason it is not added.

<edit-config>
<target>
<candidate/>
</target>
<config>
<configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm"/>
</config>
</edit-config>

Please find the output attached in the karaf_put_log file

Hi Erik,

The request with empty configuration is expected, it is RESTCONF trying to ensure parent structure performing a "merge edit-config rpc" with empty configuration container. After that a real edit should follow. But your device has a problem with the empty configuration container:

<error-message>syntax error, expecting <configuration></error-message>

I believe this is the same issue that you faced some time ago(<configuration/> vs <configuration></configuration>) and moving to Lithium should have helped with that (With Helium this was failing when get-config requests were invoked trying to find out if the parent structure exists). Now the get-configs + optional edits are replaced with a single edit (the one that fails for you now). But it looks like we were not successful in avoiding the issue and right now we have 3 options:

• Make Restconf ensure parents optional
• Make Restconf ignore (with warning) the error when ensuring parents and try to edit the real data anyway
• Make Netconf serialize empty elements this way: <configuration></configuration> instead of this <configuration/> (possibly optional setting)
• Fix your device - highly unlikely

I ll try to discuss the best option here with other ODL devs and make it into Lithium asap.

Maros

Property to change the output to html(no self-closing tags) is
ThreadLocalTransformers.getPrettyTransformer().setOutputProperty(OutputKeys.METHOD, "html");
Tested, and output was:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"></hello>
instead of
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>

In RFC specifications are used self-closing tags when possible,
so this seems be default but some option should be introduced.

Part of code where html property we set in netconf(netconf-subsystem) in NetconfMessageToXMLEncoder.java (line 56) to test it:
StreamResult result = new StreamResult(new org.opendaylight.controller.netconf.nettyutil.handler.BufferedWriter(new OutputStreamWriter(os)));
DOMSource source = new DOMSource(msg.getDocument());
ThreadLocalTransformers.getPrettyTransformer().setOutputProperty(OutputKeys.METHOD, "html");
ThreadLocalTransformers.getPrettyTransformer().transform(source, result);

So it's possible to compile netconf with this change without tests and check if this doesn't cause any other error.

Hi Erik,

Could you test the html output method with your device ? It removes the self closing tags but also removes the xml declaration and formatting from the output so we are not sure if that wont break something else.

Hi,

I tried the parsing option, and it gave some mixed results.

For reading configurations, for the <source> tag the Juniper device only accepts the short form:
<candidate/> or <running/>
If you send <candidate></candidate> or <running></running>
It will fail.
So the proposed fix will break this.

For <edit-config>, apparently the Juniper then does not care about the formatting of the candidate/running tag.
The change does help, and the logs show that indeed the candidate config is adjusted and committed.
But the result is not reflected on the switch, the hostname stays the same. This might be due to some other issue, since I have the same problem, when manually sending RPC's through 'ssh -s netconf'.

Anyway, before I provide any details, I just found out that Juniper announced a new Junos release, which introduces RFC-compliant NETCONF as a new feature.
Also see: http://pathfinder.juniper.net/feature-explorer/feature-info.html?fKey=6855&fn=Enforcing+RFC-compliant+behavior+in+NETCONF+sessions

So I am trying to obtain this version, and will let you know if this solves the problems.

Move to NETCONFI project.

We will need to port the fix for less strict candidate capability checking to Netconf repo.

As for the other issue, please open a new bug if new Junos doesnt fix your issues.

I consider accepting:

urn:ietf:params:xml:ns:netconf:capability:candidate:1.0 

as a valid capability be a breakage of the protocol because:

The shorthand form MUST NOT be used inside the protocol.

In addition, Junos device now supports correct namespaces: https://www.juniper.net/documentation/us/en/software/junos/netconf/topics/concept/netconf-session-rfc-compliant.html.

We have successfully tested https://github.com/Juniper/yang/tree/master/22.3/22.3R1 models with netconf testool and device is connected.

Finally, the requirement to shorthand namespace is invalid according to RFC, Junos models are valid and is has been proven they can be used with ODL, and Junos device has recently added settings to operate in compatible manner.

Thus, closing this issue.