Hi Clarisse,
Very good questions, please see my thoughts inline. Overall, I would say that the state of NSO NETCONF is STRONG! I have tested it with many vendors. What is more complext is the state of NETCONF/YANG in devices at wild. What we typically find is that companies announced "NETCONF support" but initial versions were pretty useless. However, if you go to most vendors "latest and greatest" versions, you will be pleasantly surprise. The one recommendation is to use NSO 5 and even better NSO 5.3 to get the latest fixes.
1. Is there a possibility to retrieve operational data directly in NSO via NETCONF? (compared to the live-status command via CLI NED)
(Roque) Yes. YANG has the concept of "operational" data. If you see the list of YANG models from XE, you will see some that finish with the "-oper" suffix (for example Cisco-IOS-XE-platform-oper@2019-11-01.yang). These are state information that NSO would retrieve via "show devices device BLA live-status". The great thing about YANG oper data is that the output is modeled, so no need for regular expressions. There are also "rpc" commands that are available to perform "clear" / "reboot" / "copy" operations.
Now, the hard part is to know what NETCONF state command corresponds to a CLI command. For this reason, the IETF is coming to help us with the use of NMDA. This is still not deployed but it will mean that you could have a mix of configuration and state information in the same tree. Please check the NSO Developers days video on NMDA.
That is not all. You may end up in a situation where you validated NETCONF for configuration but you are ready to move away from CLI show commands (or not all show commands are available). For this reason, there is now a special NED called "generic-ctu". This ned can be used as a "live-status NED" only to perform SSH based operations in the device prompt. So, you can have a NSO device that is configured via NETCONF but that still uses CLI for live-status.
2. Is there any possibility to self-test a package via NETCONF? How can one implement self checks before resp. after a service is being deployed in production monitor it's health after deployment?
(Roque) Please check one example here: https://github.com/NSO-developer/selftest
Note that it has been extended to use the "generic-ctu" live-status NED for NETCONF devices. I have also seen people using plan files to track progress of tests.
3. There is a tool called ntool (https://github.com/NSO-developer/ntool) which can determine the supported CLI operations aka commands for a CLI NED from a given (native formatted) configuration file. How can I determine if my NETCONF NED is supporting the commands/yang elements that I need (derived from a config file, similar to ntool).
(Roque) Good question. I really would like to see some sort of "translator" from CLI to NETCONF. Unfortunately, that would be "vendor specific" and you should ask the platform teams (I know Cisco has some pretty cool stuff). The nice thing about NETCONF is that more are more vendors are exposing everything (I have 400 modules in my latest XE NED) and that the NSO template structure and the device NETCONF XML is the same.
Here is the trick that I do:
1) Take your target real device and enable both SSH and NETCONF access.
2) In NSO, program two devices pointing to the same physical device. One uses CLI NED and one uses NETCONF.
3) Sync-from both devices
4) Commit your changes using the CLI NED.
5) Run on the NETCONF device: admin@ncs# devices device calo-asr903 compare-config outformat xml
... and you will have your template.
4. Generally speaking - is it a good idea to switch to NETCONF NEDs on the IOS XE platform? Is it mature enough? If yes, what are some guidelines to migrate from a CLI NED to a NETCONF NED in a safe manner?
(Roque) This is really a "depends" answer. I have had good experiences with ASR920 and XE17.2. I would say that there are many features in NSO (particularly for large installs) that work better in NETCONF than in CLI. One that comes to my mind is "commit no-overwrite" or "partial-sync-from".
5. Are there any best practices for using NETCONF in NSO? Are there actually ISPs which use it as a native configuration protocol?
(Roque) One of the key things that you loose with NETCONF is the access to CLI for "dry-run" operations and that is typically annoying for operations. So, you need to work with them to get used to the NSO "CLI" output rather than native.
6. Is NETCONF nowadays a good choice (compared to the rather bulky CLIs) for retrieving operational state data to conduct automated network tests? Is it possible to use (and if yes - DOES anyone actually use) pyATS via NETCONF/YANG? (I don't get the point in using CLI parsing nowadays and creating "YANG-inspired python classes" when there already is YANG itself as a data modeling language)
(Roque) Actually, I sit next to a XE teams that uses pyATS for NETCONF/YANG internally and I have used it with a couple of customers to run automation of testing. With NETCONF, there is no more need for the CLI parsing and the common data model in pyATS but you will be using the YANG modeling directly. Moreover, as the NETCONF responses are XML, you can directly use the xmltodict parser. Here one example from my code where nc_out is the resulting XML from the device:
data = xmltodict.parse(nc_out)['rpc-reply']['data']
So, if the CLI parser was the reason why you are using pyATS, you will loose that. But then, why do you need it? using the native YANG modeling is a way where your tests are independent of that middle layer. One other point that you may ask yourself is why using the pyATS NETCONF library to check a device when you will use NSO in production? One of the things that I have used is to create a pyATS library where instead of going directly to the devices, all tests are done via NSO using its northbound NETCONF API.
Looks like I should write a blog about these experiences.
See also how I program a device to use NETCONF:
testbed:
name: roque_testbed
devices:
iosxrv-1:
alias: iosxrv-1
os: "iosxr"
type: xrv-9000
credentials:
default:
username: cisco
password: cisco
connections:
netconf:
class: yang.connector.Netconf
ip: 10.51.35.119
port: 10187
ssh:
protocol: ssh
ip: 10.51.35.119
port: 10087
