I often get the question how much effort would it be to port existing service XYZ from using a CLI NED to a NETCONF NED? And if the effort is reasonable (=tiny), what would be the steps to do this?
The short answer is that it depends a little. Both on the service and the device, but in my experience it's typically not that much work. In some cases I have been able to do this without actually changing any code, just updating XML templates and NSO configuration. For the long answer, read on. The answer is so long in fact, that I'm going to split it up into a few blog posts. Note that far from all devices that boast a NETCONF/YANG interface are mature enough for this to be a good idea.
As service to be ported, I selected our "standard demo", the L3VPN example system that ships with NSO. This service uses CLI NEDs for IOS, IOS XR and a NETCONF NED for JunOS devices. In this effort, I decided to make the system allow some (or all) of the IOS devices to be managed over NETCONF. Basically, the service will support a new device type, IOS over NETCONF, in addition to all existing device types.
The overall process is this:
1) Establish NETCONF communications
- Set up device, NSO and service meta data
- Update NSO configuration to plug in the new NETCONF device(s)
- Build a NETCONF NED for the device
- Adjust NEDs to co-exist (should ideally not be needed, but currently it is)
- Ensure sync-from works
2) Extend service with (additional) support for the NETCONF variant of the device
- Switch NSO to talk to the device over CLI
- Configure a service instance, commit
- Switch NSO to talk to the device over NETCONF
- View the configuration changes in XML
- Take this XML as input to new sections in the service templates
- Fill in variables as given by the CLI version of the template
3) Verify the service mapping
- Re-deploy dry-run to see that nothing is forgotten
- Un-deploy the service
- Re-deploy the service
- Compare the configuration
4) Extend the service
- Repeat steps 2 and 3 until all aspects of the service has been covered
Here are the posts with the details for each of the steps above:
- Porting an existing service to use a NETCONF NED, part 1
- Porting an existing service to use a NETCONF NED, part 2
- Porting an existing service to use a NETCONF NED, part 3
