Introduction
Managing connectivity with southbound NETCONF devices and mounts using OpenDaylight was once a particularly daunting task. There have been several different efforts made to mature the process of mounting NETCONF devices, as well as keeping devices connected. Although the process is not yet perfect (things rarely are), there have been a number of initiatives that have made the process much easier. Namely:
- Specification of a Distinct Schema Cache
- Enhanced Logging of YANG parsing ERROR(s) and Exception(s), including the specific model name and line number for broken models.
- Discount broken models as unavailable capabilities
Specification of a Distinct Schema Cache
Description
OpenDaylight allows the specification of a distinct schema cache directory per NETCONF mount. What does this mean? Basically, by default when you mount a southbound NETCONF device, the yang files downloaded from the device are placed in a default FileSystemSchemaCache. This location is here:
${KARAF_HOME}/cache/schema
All yang files are (by default) aggregated into this directory (note, this discounts the ability to use an external server for NETCONF yang as well as side-loading). Files are only placed in this directory if they do not already exist. Sometimes, for some strange reasons, vendors change the standard files (or make really poor judgements about how the models should work). In fact, ODL has done similar things as well (as depicted here). In this case, the MD-SAL binding specification v1 is incapable of resolving revisionless imports deterministically, so a patch was pushed to ensure that the import would resolve to the 2010 version only. The behavior of revisionless imports is undefined per the latest RFC 6020 7.1.5. There are device vendors who decided that the ietf-netconf-monitoring@2010-09-24 should resolve the revisionless import of ietf-{inet,yang}-types to 2013-07-15. This is sort of strange, since ietf-{inet,yang}-types@2013-07-15 did not even exist a tthe time the ietf-netconf-monitoring@2010-09-24 version was produced, but somewhat understandable as the new version of the model should be backwards compatible!
How to use
Here is a youtube video explaining how to use this functionality through mounting MD-SAL NETCONF northbound using a custom schema cache directory.
Enhanced Logging of YANG parsing ERROR(s) and Exception(s)
Description
Prior to OpenDaylight Beryllium, errors in NETCONF yang parsing were cryptic and hard to understand. Usually, parse errors amounted to a cryptic stack trace which had no pointers to the broken model names, nor the line numbers that were broken. As of OpenDaylight Beryllium, broken models provided by southbound NETCONF devices is reported to the karaf log.
How to use
An example of how one might go about finding what model is broken (and what line number) is demonstrated in this youtube video.
Discount broken models as unavailable capabilities
Description
Sometimes, a device provides broken models or models that OpenDaylight is not capable of understanding. Although these models can sometimes be fixed to achieve interoperability, there are cases in which the operator is not even interested in the information/functionality that the broken model provides. In versions of OpenDaylight prior to Boron, this left the mount hanging in an indefinite "connecting" state, and the mount effectively can't be used. In order to achieve partial interoperability in Boron, the capability to discount broken models as unavailable capabilities was added.
How to use
This video shows the functionality used to discount broken models in Boron. It also demonstrates the clear advantages this provides over the existing functionality from the Beryllium release.
Disable the application layer keep alive mechanism
Description
From time to time you may notice a get-config request against each southbound mount-point, especially if you have enabled verbose NETCONF logging. The reason for this keep-alive mechanism is to ensure that the underlying ssh connection to the southbound mountpoint is kept active and doesn't close. Sometimes, it is undesirable to keep this mechanism on; get-config can be fairly expensive and may take several minutes to complete. In such cases, disabling the keep alive is a good option.