Managing Network Equipment with NETCONF & YANG using NSO
Overview
In this section, how to establish communication between NSO and the device being tested is discussed.
First, knowledge of the device must be added to NSO. This includes basic connection information such as IP address and authentication information.
Once NSO knows how to connect to a device, then NSO needs to be provided with the YANG data models which describe the device's management information. The YANG data models are used to build a Network Element Driver (NED) which NSO will use to communicate with the device via NETCONF.
Finally, the DrNED Examiner package is use to test whether the device interoperates properly with NSO.
The commands listed in this chapter are equally applicable for the bare-metal installation as well as when we use the nyat-container. In the latter case, we must remember to do docker exec -it ncs_cli -C -u admin
when we start the NSO CLI.
This section will go through the process of connecting your device to NSO in order for NSO to be able to communicate with it and drive further testing.
The steps include:
- Configure the NSO authentication group used when connecting to the device
- Configure the device in NSO
As communication with the devices being managed by NSO require authentication, a custom authentication group is created with the username and password required by the devices.
The example below creates a group named nsointerop
, make sure to replace and with the required username and password for the devices being managed. Feel free to use your own name for the authentication group.
Configuring the device in NSO can be done following the example below. This example assumes that the IP address for the device is 10.80.26.213 using the nsointerop
authentication group created in the previous step:
Please, note that the ned-id
of netconf here is only temporary as the NETCONF NED for the test1a device hasn’t yet been built. This generic ned-id
allows NSO to communicate with the device for basic NETCONF operations without any device specific knowledge. Once we have built the NETCONF NED for test1a, we need to go back and change the ned-id
to its true identity to allow device specific operations.